3D Secure 2: What It Does at Checkout
3D Secure 2 checks that the shopper is the cardholder before the payment clears. Here is how the two flows work and what to expect when you add it.
Your customer types a card number and hits pay. Before the payment clears, their bank may ask them to prove who they are. That check is 3D Secure 2 at work.
What 3D Secure 2 is
3D Secure 2 is a way to verify the identity of the person behind a card payment. It adds a verification step to online card sales. The bank decides whether the shopper has shown enough proof that they are the real cardholder.
If you are new to the idea, read how does 3D Secure work first. The 3D Secure protocol page goes deeper into the plumbing.
Why merchants turn it on
The main reason is rules. PSD2 SCA is one of the regulations that require strong customer authentication for online payments. Adyen suggests 3D Secure 2 to meet rules like these. Stripe's Strong Customer Authentication rules apply without any setup on your part. They block payments that were not verified, unless an exemption applies.
The second reason is fraud. 3D Secure 2 adds a layer of verification for card-not-present transactions. A fake sale can come back at you as a chargeback later, so catching it before the payment clears spares you that fight.
The two flows
A qualifying sale takes one of two paths. The bank that issued the card picks frictionless or challenge.
In a frictionless flow, the transaction completes without further shopper interaction. Your customer never sees anything and may not know a check happened.
In a challenge flow, the shopper has to do something extra. Adyen's docs give biometrics or two-factor authentication as examples. A box appears, the customer approves, and the payment continues. More friction, more proof.
You do not pick the flow. Stripe says it cannot promise your 3DS choice will hold. The card's issuing bank makes the final call on which path a sale takes. You can state what you would like, but the bank decides in the end.
Native or redirect
There are two ways to show the authentication to your customer.
The Native implementation keeps the shopper on your site. The bank that issued the card runs the check inside your website or app. The Redirect implementation sends shoppers to the card issuer's own site to complete the check.
Redirects can cost you sales. Adyen's documentation says redirection might lead to lower conversion rates because of technical errors or shoppers dropping out of the authentication process. If you can, go native.
How to integrate it
Most small merchants will not build this from scratch. Adyen and Stripe both have support built in.
Adyen's Sessions flow integration has built-in support for 3D Secure 2, so no extra configuration is needed. Stripe turns on 3DS by itself when a rule like Strong Customer Authentication calls for it. It only asks the customer to log in if the card supports 3DS. During 3DS2, Stripe.js gathers basic facts about the device. It sends them to the issuing bank for risk checks.
If you want more say, Stripe lets you set request_three_d_secure to any, which requests 3DS with a preference for a frictionless flow. When you call confirmCardPayment or handleCardAction, Stripe shows the login box in a pop-up.
Costs change, so look at what your provider charges today on their own pricing page.
Testing in a sandbox
Do not test challenge flows on live cards. Use your provider's test environment.
Stripe provides a test card that triggers 3DS authentication challenge flows while in a sandbox. Run a payment with it and watch what your customer would see.
Two layout details matter. Card issuers must show 3DS2 content at several set sizes, including full screen. Stripe lists them as 250x400, 390x400, 500x600, 600x400 and full screen. Also, do not put the sandbox attribute on the 3DS iframe. Some banks' code breaks when it is sandboxed.
What it does and does not promise
When the check succeeds, the bank that issued the card may take the loss for a fake sale instead of you. Stripe's docs say the bank can still take on the fraud loss even if the cardholder never finished 3DS.
But 3D Secure 2 does not stop all fraud. Treat 3DS as one layer, not the whole answer.
When authentication fails
Sometimes the shopper fails the challenge. Sometimes they see the box and quit. Either way, the payment does not complete, and Stripe reports a status other than succeeded. A succeeded status means the payment completed and no further steps are required.
For the failure paths and what to do about each one, see 3D Secure authentication failed. A shopper may also drop out of the authentication process. Look at where in the flow they dropped out.
Where it fits
3D Secure 2 is one layer of verification. Pair it with your own order review. If you take cards that skip the check, read about the 3D Secure credit card side too. Used that way, it earns its place in your checkout.