You're viewing documentation for our latest API. This will not impact your integration, but you will need the documentation relevant to you. If you have an account with Checkout.com you have received an email confirming which version to use.
Authenticate your customers' payments with 3D Secure to reduce fraud and meet regulatory requirements.
We currently support versions up to, and including, 2.2.0 of the 3D Secure protocol.
3D Secure (3DS) – commonly known by its branded names: Visa Secure, Mastercard Identity Check, American Express SafeKey, and Diners Club ProtectBuy – requires customers to complete an extra authentication step with their card issuer when making a payment. Typically, you direct the customer to their bank’s website where they enter a password or a code sent to their phone to verify the payment. It uses a wider range of data and biometric authentication to allow for “frictionless authentication”, meaning a smoother, more secure payment flow for both you and your customers. If you do business in Europe, it's the best way to comply with the new Strong Customer Authentication (SCA) requirements introduced by the revised Payment Services Directive (PSD2).
With 3DS, you can embed the authentication process in your checkout flow, making for a better user experience.
Whenever a customer makes a payment, 3DS allows the merchant and a payment provider like us to send over 100 data elements (such as the customer's shipping address, device ID and payment history) to the cardholder's bank to assess its risk level. This all takes place behind the scenes within your web or mobile checkout flow.
Based on this data, the customer's bank will then choose to immediately authenticate the payment frictionless flow or ask for more information before authenticating the payment (challenge flow).
If the data is sufficient for the bank (so they trust that it is the cardholder making the payment), the payment will qualify for frictionless authentication and complete without affecting the customer's experience.
If the bank decides it needs more proof, the authentication will follow the challenge flow and your customer will be prompted for additional information to authenticate their payment.
If the 3DS authentication is successful (whether following the frictionless or challenge flow), the liability for the payment is passed to the bank, protecting you from fraudulent transactions. However, if a payment relies on one of the exemptions mentioned above, the liability remains with you, the merchant.
This is when the liability for fraud-related chargebacks (for instance, your customer denies they made the purchase, suspecting someone has stolen their card details) shifts from you to the card issuer.
As a general rule, the shift occurs when a payment is successfully authenticated with 3DS.
If you attempt authentication but the issuer doesn't support 3DS or its access control server doesn't respond, the liability shifts to the issuer, as long as the attempt includes a cryptogram (CAVV/AVV) from the card scheme's directory server. See ECI 06 (non-Mastercard) / 01.
If the card supports 3DS but authentication could not be attempted for technical reasons (for example, there's a network error, or the customer closes the window during verification), liability remains with you, but you can decide whether or not to authorize the transaction. See ECI 07 (non-Mastercard) / 00.
If authentication fails because the cardholder does not pass the challenge, liability remains with you and you should not proceed with the payment. See ECI 07 (non-Mastercard) / 00.