3D Secure payments

Verify your customers' online card payments with the new authentication standard.

Overview

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 were 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 does all the work for you.

Alternatively, you can develop your own integration using our JavaScript software development kit, giving you full control over your 3DS 2.0 payment flow.

🚧

As of 14 September 2019, if you do business in Europe, you need to be able to support 3DS 2.0 and comply with SCA. This includes merchants who have not previously used 3DS. Please see below for more detail on the SCA enforcement timeline.

What is Strong Customer Authentication?

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)

🚧

We expect that banks will start to decline payments that require SCA and don't meet these requirements from 31 December 2020. See below for more details on the enforcement timeline.

Does Strong Customer Authentication apply to me?

The SCA requirements only apply to you if both of the following statements are true:

1. you are processing payments from cards issued in Europe, and
2. you are processing payments through a European acquirer.

If neither, or just one, of the above statements is true, you should apply SCA to transactions on the basis of best practice.

However, even if it does apply to your business, particular payments you process may fall out outside its scope or be exempt from it.

When will Strong Customer Authentication be enforced?

The SCA requirements officially came into effect on 14 September 2019.

However, on 16 October 2019, the European Banking Authority (EBA) published an Opinion stating that it will allow national regulators to delay enforcement of SCA until 31 December 2020.

Most European regulators are aligned with this roadmap. Currently:

• 7 countries stated, before the above Opinion, that they would align with the transition timeline set out by the EBA: Cyprus, Czech Republic, Greece, Ireland, Lithuania, Luxembourg and Slovakia.
• 19 countries have subsequently aligned themselves with the EBA's 15-month transition period: Austria, Bulgaria, Croatia, Denmark, Estonia, Finland, France, Germany, Italy, Latvia, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovenia, Spain and Sweden.
• France has formally aligned itself with the 15-month transition period, but maintains an extra 3-month grace period on a case-by-case basis.
• The United Kingdom has confirmed its decision to stick to its own 18-month transition period.
• Hungary has yet to announce whether or not it will maintain its previous position of a 12-month transition period.

Regardless of the delay in enforcement, we recommend that you start supporting 3DS 2.0 as soon as possible to avoid any potential issues, particularly where issuers may decline transactions submitted without SCA.

When is Strong Customer Authentication required?

SCA applies to “customer-initiated” payments – so, most online card payments and bank transfers. However, specific low-risk payments fall outside its scope or are exempt.

Out of scope for Strong Customer Authentication (SCA)

"Merchant-initiated" payments

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.

🚧

As of 14 September 2019, you need to strongly authenticate the customer's card when you save it or when you take the first payment. However, we expect that banks will not start enforcing this until 31 December 2020. See above for more details on the enforcement timeline.

Mail order and telephone orders (MOTO) payments

Mail order payments and phone sales fall outside the scope of SCA.

One leg out (OLO)

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:

Exemptions to Strong Customer Authentication

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:

Low-risk payments

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

Low-value payments

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.

Payments to a trusted business

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

Corporate payments made with virtual and lodge cards (typically used for business travel expenses) or from central travel accounts are exempt.

How 3D Secure 2.0 works

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:

Frictionless flow

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.

Challenge flow

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.

📘

Liability shift
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.

What is liability shift, and when does it occur?

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.

More particularly:

• 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.

Electronic Commerce Indicator (ECI) values

How Checkout.com helps you get SCA-ready

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.

We'll 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.

Phase I

In April 2019, we rolled out our fully integrated browser 3DS 2.0 solution. It uses our existing 3DS integration and it gathers all the required information on your behalf – so no need to change your existing integration.

Our 3DS 2.0 solution helps 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.enabled parameter set to true before 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.

Phase II

In 2020, 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.

Can we help?

Thanks for using Checkout.com. If you need any help or support, then message our support team at [email protected].