Verify your customers' online card payments with the new authentication standard.
The 3D Secure (3DS) protocol, commonly known by its branded names Verified by Visa, Mastercard SecureCode, American Express SafeKey and Diners Club ProtectBuy, introduced an additional layer of verification to protect you from liability for fraudulent card payments and make online payments more secure.
The next generation of authentication – 3D Secure 2.0 (3DS 2.0) – is designed to help merchants in Europe comply with the new Strong Customer Authentication (SCA) requirements that will be introduced by the revised Payment Services Directive (PSD2) on 14 September 2019.
3DS 2.0 uses a wider range of data and biometric authentication to allow for “frictionless authentication”, meaning a smoother checkout flow for both you and your customers – curbing cart abandonment rates and improving the user experience, all while improving the security of your payments.
And if you're already using our existing 3DS integration, you don't have to do anything – our hosted solution will do all the work for you.
If you do business in Europe, you must ensure that you can support 3DS 2.0 and comply with SCA by 14 September 2019. This includes merchants who have not previously used 3DS.
When a customer makes an online payment, their bank may "challenge" them to provide more information before authenticating the payment – this is where SCA comes in.
SCA requires you to build additional authentication into your payment flow, using two out of the following three authentication elements:
- Something the customers knows (e.g., a password or PIN)
- Something the customer has (e.g., a mobile phone or wearable device)
- Something the customer is (e.g., a fingerprint or facial recognition)
After 14 September 2019, banks will decline payments that require SCA and don’t meet these requirements.
SCA will apply to “customer-initiated” payments – so, most online card payments and bank transfers. However, specific low-risk payments fall outside its scope or are exempt.
Payments of a fixed or variable amount originating from the merchant, where the payment is made with a saved card, such as direct debits, recurring payments and subscriptions, are out of scope. However, this must be agreed between merchant and a cardholder and addressed through T&Cs.
After 14 September 2019, you'll need to strongly authenticate the customer's card when you save it or when you take the first payment.
Mail order payments and phone sales fall outside the scope of SCA.
Payment transactions where a merchant/acquirer or an issuer are based outside of the European Economic Area (EEA).
Possible scenarios of one leg out (OLO) payments which are considered as out of scope for SCA:
If there is an SCA exemption that may be applicable to a payment, the relevant exemption may be requested in either the authentication or payment authorization. The customer's bank will then assess the risk of the payment and decide whether to accept the exemption or request strong customer authentication if they still think it is necessary.
These exemptions include:
The payment may be exempted if the acquirer's and issuer’s average fraud levels for card payments and the amount do not exceed the following thresholds:
- Below 0.13% and the payment is less than €100
- Below 0.06% and the payment is less than €250
- Below 0.01% and the payment is less than €500
Payments below €30 are considered low-value and may be exempt. However, the bank may still trigger strong authentication if, within a 24-hour period, this exemption has been used five times since the customer's last successful authentication or the total value spent on the card without SCA exceeds €100.
The customer may add a merchant to a whitelist after the initial strong customer authentication, meaning all subsequent payments to that business will be exempt.
Corporate payments made with virtual and lodge cards (typically used for business travel expenses) or from central travel accounts are exempt.
With 3DS 2.0, you can embed the authentication process in your checkout flow, resolving the clunky user experience that the original 3DS sometimes delivers.
Whenever a customer makes a payment, 3DS 2.0 allows the merchant and a payment provider like us to send over 100 data elements (e.g., the customer's shipping address, device ID and payment history) to the cardholder's bank to assess its risk level. And this all takes place behind the scenes within your web or mobile checkout flow – no redirects needed.
Based on this data, the customer's bank will then choose to immediately authenticate the payment or ask for more information before authenticating the payment, directing the payment toward one of two flows:
If the data is sufficient for the bank (i.e., 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 2.0 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 (e.g., your customer denies they made the purchase, suspecting someone has stolen their card details) shifts from you to the card issuer – generally the customer’s bank.
The shift occurs when a 3DS payment is successfully authenticated.
If the card issuer confirms that the card is enrolled for 3DS and the cardholder authentication is successful, the liability shifts from the merchant to the issuer, and the merchant can authorize the payment. See ECI 5 / 2 below.
If the merchant attempts authentication of the cardholder but the issuer is yet to participate in 3DS or its access control server is unable to respond, the liability will still shift to the issuer, as long as the attempt includes a cryptogram (CAVV/AVV) from the issuer. See ECI 6 / 1 below.
If, however, the issuer confirms enrolment but the authentication of the cardholder fails (e.g., there's a network error, or the customer closes the window during verification), liability remains with the merchant, and it is for the merchant to decide whether or not to authorize the transaction. See ECI 7 / 0 below.
3DS authentication was successful; transaction secured by 3DS.
3DS authentication was attempted but was not or could not be completed.
Yes (where a cryptogram was included in the attempt)
3DS authentication either failed or could not be attempted.
We are delivering our 3DS 2.0 solution in a phased approach, minimizing the impact on merchants who are currently using our existing 3DS integration and giving you the time to build an integration that best suits your needs.
From April 2019, we will start to roll out our fully integrated browser 3DS 2.0 solution. It will use our existing 3DS integration and we'll gather all the required information on your behalf – so no need to change your existing integration.
We'll then gradually switch traffic onto 3DS 2.0, starting with European merchants whose issuers support the new protocol. If the bank does not yet support the new version, the request will automatically default to the original 3DS. We'll activate full 3DS 2.0 support in each region in line with the card scheme networks’ release schedule.
Our 3DS 2.0 solution will help you comply with SCA in two main ways:
- Exemption flags in the authorization flow. This may result in soft declines, in which case the payment will be declined and it will be the responsibility of the merchant to resubmit the payment request with the
3ds.enabledparameter set to
truebefore the payment can be authorized.
- Flags for SCA-exempt payments, like low-value payments and those to trusted merchants, to help you achieve the highest conversion rates.
From September/October 2019, the second phase of our rollout will give you a wider selection of integration options and the use of exemption flags in the authentication flow. You'll be able to submit additional optional fields to help with the banks' risk-based authentication (RBA) decisions, and split authentication and authorization into two steps (e.g., submitting authentications through Checkout.com, and submitting authorizations through a third party – and vice versa).
In addition, we are building a scheme token service to help merchants operating card-on file (COF) and subscription businesses comply with SCA. For such merchants, the initial payment must go through strong authentication, but, by using our scheme token service for COF processing, subsequent customer- and merchant-initiated payments will be exempted from SCA.
We'll continue to improve our solution and offer you more features and services as they become available.
Thanks for using Checkout.com. If you need any help or support, then message our support team at firstname.lastname@example.org.