Ravelin is a PCI DSS Level 1 SAQ-D certified Service Provider. This enables us to receive, process and store sensitive cardholder information and to use this data to empower our fraud prevention services. Merchants and service providers are able to submit Primary Account Numbers (PANs) to Ravelin, either in full, or encrypted using our client-side encryption SDKs. Sending cardholder data, as defined by the PCI specification, to Ravelin has implications for your own PCI DSS assessment process. Ravelin does not accept submission of CVV, PIN or magnetic stripe data.
The information associated to a payment card varies in sensitivity, and therefore requires different levels of protection.
Cardholder data is defined by the presence of the Primary Account Number (PAN). However, the cardholder name, BIN, last four digits, service code and expiration dates are also considered cardholder data when located alongside the PAN. For cards encrypted via Ravelin’s client-side encryption SDKs, the card ciphertext is not recoverable by any entity other than Ravelin, so it does not constitute cardholder data from the perspective of your organisation; SAQ-A and SAQ-AEP merchants may pass encrypted cardholder data through their servers.
Authentication data encompasses the CVV, PIN and magnetic stripe data, and should never, under any circumstances, be stored after authentication. Ravelin does not accept submission of authentication data in any form.
The BIN/IIN number and last four digits of the card do not constitute cardholder data, as long as they are not accompanied by the PAN (including even a hash of the PAN). Payment tokens or equivalent identifiers, paymentMethodIds, instrumentIds and billing addresses do not constitute cardholder data, and are not subject to the protections required by the PCI DSS.
In order to produce reliable graph networks that correctly link associated customers together, Ravelin
requires an instrumentId, an identifier that is globally unique to a single payment instrument, across all
customer accounts. While some PSPs or payment gateways may offer an identifier that meets these criteria, not
all do. Ravelin is able to generate and manage these identifiers, but to do so we need to receive the
full card details, including the full PAN. Merchants who are unable to source an instrumentId
should consider including the submission of full PANs or encrypted PANs in their integration; Ravelin
considers the existence of an accurate instrumentId mandatory for accurate fraud predictions. We do not
recommend merchants attempt to generate an instrumentId themselves without first consulting Ravelin or other
payment security or PCI DSS experts.
If you wish to send either full PANs or encrypted cards to Ravelin, you must send these to pci.ravelin.com. This dedicated domain name, used primarily for cardholder data, gives us finer grain control over the security and routing of sensitive traffic coming from your servers. You must not send any cardholder data, as defined by PCI DSS, directly to api.ravelin.com.
Full PAN’s must be sent via HTTPS, using TLS 1.2 or above, and must be sent using your secret Ravelin API
token. If you are including the PAN in your requests, you are able to omit inclusion of the instrumentId,
cardLastFour and cardBin fields. In order to handle full PANs on your servers, you must be a PCI DSS
SAQ-D certified merchant. For merchants who are SAQ-A or SAQ-AEP certified, you must instead consider using
Ravelin’s client-side encryption services.
Ravelin offers Android, iOS and JavaScript SDKs that include client-side encryption functionalities. This enables you to encrypt the customer’s full card details as they are entered into your payment page, and pass the encrypted card details back through your own servers without increasing your PCI DSS scope. This maintains the requirement for SAQ-A and SAQ-AEP that the processing of sensitive cardholder data is outsourced to a third-party, as in this case, the decryption key required to retrieve the original card details is only available to Ravelin, rendering the cardholder data unreadable to all parties except for Ravelin. The encrypted contents will contain the PAN (and thus BIN and last four digits), the expiry month and year, as well as the name on the card, while all other fields associated with the payment method (such as the registration time or the billing address), can be sent in plaintext alongside the ciphertext material.
Encrypted card details must be submitted to Ravelin via HTTPS, using TLS 1.2 or above, and must be sent using your secret Ravelin API token. For more information on using our SDKs, you can refer to the documentation for our Android, iOS or JavaScript SDKs.
It is vital that all e-commerce merchants who handle cardholder data are PCI compliant. Non-compliance with the PCI DSS can lead to fines from your acquiring bank, and may also prompt your acquirer to increase the transaction fee they charge. Evidence of a data breach of cardholder data from a non-compliant merchant can result in significant fines, as well as your acquiring bank potentially revoking your ability to process card payments entirely.
If you are submitting either full PANs or encrypted card details to Ravelin, then Ravelin becomes a third-party service provider that you must identify during your assessment, which means you must provide evidence of Ravelin’s PCI DSS SAQ-D compliance (which is available upon request).
If you have any questions regarding Ravelin’s or your own PCI DSS compliance, please contact us at
support@ravelin.com.
Was this page helpful?