Optimize your Checkout.com payment flow for 3D Secure

Strong Customer Authentication (SCA) is now in place in the UK and across the European Economic Area (EEA). Whether you operate in the SCA regions or not, you can use our 3D Secure solution to optimize your authentication strategy.

In this article, we share our essential tips to optimize your Checkout.com integration, maximize your 3D Secure success rate, and authorize more transactions in SCA countries.

To authenticate or not?

You can use the 3ds.enabled field to choose whether 3D Secure authentication is performed when sending payment requests to our API. Setting this to true means your transactions will benefit from liability shift, however, this also means customers must go through 3D Secure and experience more friction when they pay.

By setting a risk strategy based on the transaction value, you can choose the authentication strategy that’s right for you. For example, you could choose to set this value to false for low value transactions within your risk appetite. Big ticket items carry higher risk, so you may wish to set this to true and benefit from liability shift in the event of fraud.

You can read guidance on how to set your preference in our documentation, and read more on when liability shift occurs during a transaction here.

The SCA mandate

If both your business and your customer’s bank are based in the EEA or UK, you’ll fall under SCA regulations. This means that unless you intend to apply an exemption, you must request 3D Secure authentication and send the field in your payment requests along with the 3ds.enabled field to indicate your preference for whether a 3DS challenge should be performed.

For guidance on when to apply 3D Secure in SCA markets, please see our SCA Business Scenarios documentation. We’ve also included guidance on the fields you’ll need to include when you submit recurring and subscription transactions (also known as Merchant Initiated Transactions or MITs) in SCA countries.

Using SCA exemptions

SCA exemptions let you request exemptions from Strong Customer Authentication in the UK and EEA if the transactions meet certain criteria. The customer's bank has the final say on whether to apply the requested exemption, using their assessment of the payment risk.

As with countries outside of the SCA regions, you should consider your business risk appetite, and apply exemptions only if you’re willing to accept the risk of liability in case of fraud. You can read more about the available exemptions here.

Checkout.com recently enabled exemption during the authentication flow. You can now set "3ds.enabled": true, when sending an exemption request, and we’ll automatically upgrade the transaction to 3D Secure if the bank rejects the exemption.
If you’re requesting the exemption with "3ds.enabled": false, we recommend amending this to true, as you’ll no longer receive a 20154 response code if the bank rejects the exemption.

Recognizing and responding to a soft-decline

Soft declines are a key component of SCA regulations, where issuers may decline transactions sent without 3D Secure (3DS) authentication. As mentioned above, our API will return these transactions with a 20154 response.

If you’ve not done so already, we strongly recommend speaking with your Customer Success Manager to discuss options to retry soft declined transactions with 3D Secure after you receive a 20154.

This is especially important for Mastercard transactions, as the card scheme will require UK and EEA merchants to re-attempt transactions using 3D Secure within 15 minutes of receiving a soft decline and will apply assessments (fines) to acquirers where the soft-decline retry rate is below a certain threshold.

Storing cardholder data

Some UK and EEA banks have begun to require strong authentication if merchants store cardholder details for future use. If you’re a business that doesn’t store cardholder data and only accepts one-off payments, this could mean more payments are challenged unnecessarily.

You can use the store_for_future_use field in the source object of your payment request to specify whether you're using a token or card for a one-off payment or storing card details when processing an initial payment request:

• Set store_for_future_use: true when you intend to store card details e.g. to perform a card verification for subsequent payments, or offer a smoother checkout experience when your customer next visits your website

• Set store_for_future_use: false if you don’t intend to store transaction details for future use. Note that in this scenario, we won’t return a payment instrument with the response

The Business Scenarios section of our SCA compliance guide outlines when to use this field, along with the other recommended fields to submit.

Flagging out of scope transactions

Merchant Initiated Transactions e.g subsequent recurring / installments, after the initial payment cannot go through 3D Secure as the cardholder isn’t present during the transaction.

If you’re processing these transaction types in SCA markets, it’s important that you send these transactions to our platform with the correct parameters. We’ll then send these on to the card issuer, who should recognize that the transaction is out of scope for SCA and not attempt a challenge.

Read our documentation for guidance on flagging these transaction types.

What comes next

In October, the card schemes will sunset 3D Secure Version 1. Checkout.com is in the process of automatically enabling 3D Secure Version 2 (3DS2) if you’re currently configured with 3D Secure version 1 to meet the October deadline set by the schemes.

In addition, Visa has recently released guidance for acquirers on inclusion of priority data elements within authentication requests. We’re looking into how to best leverage all the available data elements within the 3D Secure request to improve approval rates and maximize issuer confidence - resulting in more frictionless experience outcomes. We’ll be in touch with you to share more news in due course.