You're viewing our new Unified Payments API documentation. Click here to access our Classic API docs.

3D Secure payments

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 (3DS2) – 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.

3DS2 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.

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

If you do business in Europe, you must ensure that you can support 3DS2 and comply with SCA by 14 September 2019. This includes merchants who have not previously used 3DS.

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)

After 14 September 2019, banks will decline payments that require SCA and don’t meet these requirements.

When is Strong Customer Authentication required?

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.

Exemptions to Strong Customer Authentication

If a payment falls into one of the SCA exemptions, we can request the relevant exemption when processing the payment. The customer's bank will then assess the risk of the payment and decide whether to accept the exemption or request strong authentication if it still thinks it necessary.

These exemptions include:

"Merchant-initiated” payments

Payments originating from the merchant where the payment is made with a saved card, such as direct debits, recurring payments and subscriptions, are exempt. However, to benefit from this exemption, you'll need to strongly authenticate the customer's card when you save it or when you take the first payment.

Low-risk payments

The payment may be exempted if the acquirer's or bank’s average fraud level for card payments, and the amount, does 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 authentication, meaning all subsequent payments to that business will be exempt.

Mail order and telephone orders (MOTO) payments

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

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 works

With 3DS2, 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, 3DS2 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 3DS2 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.

How helps you get SCA-ready

We are delivering our 3DS2 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.

Phase I

From April 2019, we will start to roll out our fully integrated browser 3DS2 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 3DS2, 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 3DS2 support in each region in line with the card scheme networks’ release schedule.

Our 3DS2 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.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

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, 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 If you need any help or support, then message our support team at

3D Secure payments

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.