Ravelin is a PCI DSS 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
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
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, Ravelin will issue you a unique host
name for your organisation to integrate against, in the form of
$ORG_NAME.api.ravelin.com. This 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
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
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.
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