Letzte Aktualisierung January 11, 2019

About Hips

HIPS Payment Group Ltd is a financial technical service provider, to enable consumers to make online purchases. The activities of the company follow local laws, regulations and industry practice. HIPS Payment Group Ltd's principal place of business is registered at St Mary’s Place, DUBLIN D07 P4AX, IRELAND, registered in the Irish companies register CRO under the registration number 639131..

HIPS Betalservice AB is a provider of financial services (factoring services), to enable consumers to pay after delivery. In the EU/EES, HIPS Betalservice AB is registered as a financial institution firm by Sweden's financial supervisory authority under number 559114-1873 by the Swedish Financial Supervisory Authority (www.fi.se), Box 7821, 10397 Stockholm, Sweden.

Hips Payment Group Ltd and HIPS Betalservice AB's principal place of business is registered at Strandgatan 1, 302 46 Halmstad (Sweden), collectively called "Hips".

Our Role

Hips Checkout is a technical platform of storing your Payment Credentials, but it doesn’t change anything else about your relationship with the Merchant you’re paying or your bank or credit card company. You are ultimately responsible for the purchases you make using Hips Checkout. Also, the Merchant is the one responsible for providing you the goods or services that you purchase using Hips Checkout, not Hips. Hips will use our reasonable efforts to keep your Payment Credentials secure. Hips may buy any debt from you to the Merchant (factoring), in that case you will be notified and must fulfill you payment toward Hips and not the Merchant.

HIPS has been audited by a PCI-certified auditor and is certified to PCI Service Provider Level 1. This is the most stringent level of certification available in the payments industry. To accomplish this, we make use of best-in-class security tools and practices to maintain a high level of security at HIPS. The PCI audit occurs annually.

HIPS act as a financial technical service provider, which support the provision of payment services to banks and authorized payment institutions. Some of HIPS services includes a e-commerce platform ("Checkout"), for such services HIPS act as a commercial agent authorised via an agreement to conclude the sale on behalf of the payee.

Security at HIPS

Security is one of the biggest considerations in everything we do. If you have any questions after reading this, or encounter any issues, please let us know.

All card numbers are encrypted on disk with AES-256. Decryption keys are stored on separate machines. None of HIPS’s internal servers and daemons are able to obtain plaintext card numbers; instead, they can just request that cards be sent to a service provider on a static whitelist. HIPS’s infrastructure for storing, decrypting, and transmitting card numbers runs in separate hosting infrastructure, and doesn’t share any credentials with HIPS’s primary services (API, website, etc.).

Vulnerability Disclosure and Reward Program Policy

No technology is perfect, and HIPS AB believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.

Disclosure Policy

  • Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
  • Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
  • Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

Thank you for helping keep HIPS AB and our users safe!

Calculating Security Impact

Understanding security impact of a given report is understanding what mitigating or multiplying factors exists. Below are some categories to consider when assessing security impact.

Multiplying Factors

sensitivity of user data exposed -- when a vulnerability exposes user data, the sensitivity of the type of information exposed influences the security impact.

scale of exposure -- when considering security impact of any given vulnerability, it's important to understand the scale of exposure and how many potential victims exist if the vulnerability was exploited at scale.

severity of forged actions -- when a vulnerability allows an attacker to forge requests/actions on behalf of the user, the sensitivity/severity of those actions determine the security impact. For example, updating a user's last name versus their bank account number have drastically different security impacts.

Mitigating Factors

requires user interaction -- when an exploit scenario requires a human from Hips or a Victim to manually interact before exploit is successful.

authorized relationship -- when an exploit scenario involves an authorized relationship or is given express permission from the Victim.

requires brute forcing -- exploit scenarios that require an Attacker to brute force a value in order for the exploit to be successful. For example, the need to brute force a phone number, email, or UUID. The amount this mitigating factor comes into play is dependent on how "hard" it is to brute force the value in question -- brute forcing phone numbers is much "easier" than a UUID.

existence of rate limiting -- exploit scenarios that are mitigated by rate limiting the number of requests, inhibiting the ability to exploit a vulnerability at scale. Forging various IP headers (X-Forwarded-For, X-Real-IP, Client-IP, True-Client-IP) are not considered to be "mitigating" factor since it doesn't require actually having unique IPs.

physical access -- exploit scenarios requiring physical access to a device.

noticeable to victim -- exploits that are noticeable to victim. For example, changing someone's password on their account would lock them out of their account and would be immediately noticeable. account put into arrears or banned -- when an exploit then puts the Attacker's account into arrears or results in a ban.

social engineering -- when an exploit requires social engineering a person to be successful.

requires privileged network position -- when an exploit (often times MiTM) requires having privileged network position to be successful

requires multiple accounts -- when an exploit requires the ability to mint new accounts indefinitely.

Report States

We strive to be consistent with how we close reports and below are the details for each state:

spam -- a report with no useful information\ needs more info -- not enough actionable information in report to triage\ not applicable -- no reproducible security vulnerability or explicitly out-of-scope per our guidelines\ duplicate -- a vulnerability that has previously been found either internally or via Hackerone\ informative -- a reproducible issue with negligible security impact or an issue with a product that doesn't affect our service/software (e.g. an S3 bucket named hips-secret-stuff that isn't actually related to us)\ triaged -- either a valid report or a report that needs more investigation from an internal team, typically the former\ resolved -- a verified vulnerability that has been fixed

Bounty Amounts

Previous bounty amounts are not considered precedent for future bounty amounts -- software is constantly changing and therefore the given security impact of the exact same issue at different times in the development timeline can have drastically different security impacts.

We focus bounty amounts on the security impact of any given issue -- things that influence security impact are the scale of exposure and the various mitigating and multiplying factors.

We recognize that researchers value receiving bounties sooner than later, but basing payouts on security impact often requires us to get to resolution before we completely understand the potential security impact. 

The general process for determining bounty:

  • Determine the approximate scale of exposure to try and answer "how many users could be exploited by an Attacker?"
  • Determine mitigating factors that reduce the security impact of different issues -- this often involves asking "What could make this vulnerability hard to exploit?" or "How sensitive are the things being changed/accessed by the vulnerability?"
  • Determine multiplying factors that increase the security impact of different issues -- this also often involves asking "How sensitive are the things being changed/accessed by the vulnerability?" or "What other exposure exists that the researcher didn't explicitly call out?"
  • With the answers from above, we have a good picture of security impact and potential exploitability of any given issue and can use those details to determine bounty amount.

The bounty ranges:

A reward of USD $500 may be provided for the disclosure of qualifying vulnerabilities. At our discretion, we may increase or decrease the reward amount based on the mitigating and multiplying factors. 

If you report a vulnerability that does not qualify under the above criteria, we may still provide a reward of USD $100 if your report causes us to take specific action to improve HIPS's security.

Bounty payouts, if any, will be determined by Hips in its sole discretion. In no event is Hips obligated to provide a payout for any Submission. The format, currency and timing of all bounty payouts shall be determined by Hips in its sole discretion. For example, Hips may give you one (1) payout in-full or a partial payout when the vulnerability is first verified followed by an additional payout once the vulnerability has been fixed. You are solely responsible for any tax implications related to any bounty payouts you may receive.

Report Quality

High quality submissions allow our team to better understand the issue and relay the vulnerability to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions.

  • Check the scope page before you begin writing your report to ensure the issue you are reporting is in scope for the program.
  • Think through the attack scenario and exploitability of the vulnerability and provide as many clear details as possible for our team to reproduce the issue (include screenshots if possible).
  • Please include your understanding of the security impact of the issue. Our bounty payouts are directly tied to security impact, so the more detail you can provide, the better. We cannot payout after the fact if we don't have evidence and a mutual understanding of security impact.
  • In some cases, it may not be possible to have all of the context on the impact of a vulnerability. If you're unsure of the direct impact, but feel you may have found something interesting, feel free to submit a detailed report and ask.

Program Policies

  • If we receive several reports for the same issue, we offer the bounty to the earliest report for which we had enough actionable information to identify the issue.
  • Video only PoCs will not be considered.
  • Using duplicate HackerOne accounts is against our policy and can result in a program ban.
  • Currently, our program has zero trial reports for researchers with a signal of 1.0 or less.
  • A vulnerability must be reproducible for us to be considered in-scope.
  • Please follow the Terms & Conditions of all of our in-scope domains.


  • Host header injections
  • Denial of service
  • Spamming
  • Social engineering (including phishing) of HIPS AB staff or contractors
  • Any physical attempts against HIPS AB property or data centers
  • Reports that do not demonstrate a technical vulnerability, like spear phishing.
  • Discussion of SPF/DMARC/DKIM records without verifiable proof of spoofing to a major mail client (e.g. gmail).
  • Signing up with multiple accounts to abuse invite/promo code usage.
  • Invite/Promo code enumeration or collection.
  • Vulnerabilities whose primary security impact is focused on Phishing
  • UUID enumeration of any kind.
  • invite/Promo code enumeration.
  • account oracles -- the ability to submit a phone number, email, UUID and receive back a message indicating an account exists.
  • Open redirects. 99% of open redirects have low security impact. For the rare cases where the impact is higher, e.g., stealing oauth tokens, we do still want to hear about them.
  • Reports that state that software is out of date/vulnerable without a proof of concept.
  • Reports that affect only outdated user agents or app versions -- we only consider exploits in the latest browser versions for Safari, FireFox, Chrome, IE and the versions of our application that are currently in the app stores.
  • Stack traces or path disclosure.
  • CSV injection.
  • Best practices concerns.
  • Highly speculative reports about theoretical damage -- please always provide a proof-of-concept.
  • Vulnerabilities that cannot be used to exploit other users or Hips -- e.g. self-xss or having a user paste JavaScript into the browser console.
  • Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.
  • Reports from automated web vulnerability scanners (Acunetix, Vega, etc.) that have not been validated.
  • Distributed denial of service attacks (DDOS).
  • Physical or social engineering attempts (this includes phishing attacks against Hips employees).
  • Content injection issues.
  • Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.)
  • Missing cookie flags on non-authentication cookies.
  • Issues that require physical access to a victim's computer/device.
  • SSL/TLS scan reports (this means output from sites such as SSL Labs).
  • Banner grabbing issues (figuring out what web server we use, etc.).
  • Open ports without an accompanying proof-of-concept demonstrating vulnerability.
  • Out-of-scope domains
  • Exposure of any data to trusted parties via javascript (ie. query string grabbing etc)

Trusted parties

  • Google
  • Facebook
  • Rollbar
  • New Relic
  • Amazon AWS
  • Intercom
  • CloudFlare

In Scope Domains

Note: Severity shown here only indicates the maximum severity possible for reports submitted to the Asset.

Domain Maximum severity
dashboard.hips.com Critical
api.hips.com Critical
checkout.hips.com Critical
my.hips.com Critical
id.hips.com Critical
cdn.hips.com Medium
hips.com Medium

Out of Scope Domains

  • support.hips.com
  • mpi.hips.com
  • jobs.hips.com

Contact us

Our security team rapidly investigates all reported security issues. If you believe you’ve discovered a vulnerability in HIPS’s security, please get in touch with HIPS Security Incident Response Team at sirt@hips.com (optionally encrypted using our public PGP key). We will respond as quickly as possible to your report. We request that you not publicly disclose the issue until it has been addressed by HIPS.


We're always happy to help with code or other questions you might have! Search our site for more information or send us an email (support@hips.com)!

Need help or bulk pricing?