Reduce card payment fraud, meet Strong Customer Authentication requirements, and shift liability to the issuing bank.
3D Secure (3DS) is a security protocol that adds an extra verification step to online card payments. During the checkout process, customers complete an additional authentication step to verify the cardholder's identity, which reduces fraud and meets regulatory requirements.
How it works
3DS lets the customer's bank require an additional verification step that only the cardholder can complete.
As part of the authentication, the customer's bank can run the 3D Secure Method - a silent device check also known as device fingerprinting. A hidden iframe in the checkout collects information about the device being used and sends it to the bank - the customer never sees this step. If the device check isn't completed, the payment steps up to a full 3DS challenge.
When a customer pays by card, the issuing bank decides whether a full challenge is needed - a frictionless flow can be enough for it to approve the payment, with no additional verification for the customer. When the issuer requires additional verification, the customer completes a full challenge on the issuing bank's Access Control Server (ACS) page. A challenge can have different formats:
- One-time password (OTP) - The cardholder is asked to provide a one-time password sent to their phone, which is registered with their bank account. This is the usual format of the challenge.
- Bank application verification - The cardholder is asked to verify the transaction using their card bank application. This is a more modern and common format.
PSD2 and Strong Customer Authentication
The Payment Services Directive (PSD2) regulations stipulate that merchants must be compliant with the Strong Customer Authentication (SCA) procedures from 1st January 2021. The Financial Conduct Authority (FCA) has extended the deadline for the UK to 14th September 2021.
To protect merchants and cardholders - including from stolen cards being used without the cardholder's knowledge - Revolut performs a 3DS challenge whenever a card payment requires one. This also means you don't have to worry about PSD2 compliance - Revolut takes care of it for you.
Benefits
Payments that are successfully authenticated using 3DS are covered by a liability shift, which means that the liability of the payment in case of fraud is with the issuing bank and not with you as a merchant.
In case of a chargeback for a payment where 3DS was used, by default the cardholder's bank is responsible and liable to refund this amount to the cardholder.
As a merchant, using 3DS for payment authentication does not mean that you are immune to any disputed payments.
3DS in your integration
If you accept card payments with the widget, an SDK, or the Hosted Checkout Page, Revolut handles the 3DS flow from end to end. The customer only sees a challenge if the issuing bank requires one, and Revolut renders it automatically - no changes are needed on your side.
If you've built a custom card integration on the Merchant API, your integration handles the 3DS states and payloads. When a payment requires 3DS, it enters the authentication_challenge state - the challenge is either a full 3DS challenge or a silent fingerprint step, and your frontend renders it for the customer. Track the outcome with webhooks or by polling the payment.
When a customer pays with a saved card, the payment is still customer-initiated, so the same rules apply - the issuing bank can require a challenge, and your integration handles it the same way. For a complete walkthrough, see: Speed up customer checkout by using saved card details.
Set enforce_challenge to forced when creating an order to always require a 3DS challenge for card payments - useful when testing your challenge handling.
By default (automatic), Revolut challenges payments only when required.
Test 3DS in the Sandbox
Test every 3DS scenario in the Sandbox environment with dedicated test cards - frictionless approvals, approved and failed challenges, timeouts, and fingerprint flows: