3-D Secure authentication / Strong Customer Authentication

The issuer checking that the real cardholder is paying: silent from device signals most of the time, a code or app tap when it wants more proof.

the extra bank verification popupthe OTP screen during payment3dsscaverified by visa3d securethat text message code at checkouttwo factor for card payments

See it

Live demo coming soon

What it is

3-D Secure is the protocol the card issuer uses to satisfy itself that the real cardholder is behind a payment. In 3DS2 your processor first sends the issuer a pile of device and transaction signals, and most payments come back authenticated with nothing shown to the buyer at all (the frictionless flow). Only when the issuer wants more does the customer see the thing everyone pictures: a code, a tap in the banking app, a face scan (the challenge flow). Strong Customer Authentication is the European rule (PSD2) that requires two factors on in-scope online payments; 3DS is how card payments satisfy it.

You want it whenever you sell to the UK or EEA, where SCA applies to payments in scope of the rules, and selectively on high-ticket or risky orders anywhere else. In scope is doing real work in that sentence: exemptions (low value, low risk, trusted beneficiary) and out-of-scope cases (merchant-initiated charges, mail and telephone orders, transactions where one side of the payment sits outside the region) all exist, and the issuer still gets the final say on whether an exemption is honored. The payoff beyond compliance is liability shift: on an authenticated payment, eligible fraud chargebacks commonly land on the issuer instead of you. Commonly, not universally, since it turns on scheme rules, region, the dispute reason code, and whether authentication actually succeeded rather than merely being attempted.

The mistake is treating it as an on/off switch. Forcing a challenge on every payment costs real conversion, so let the processor request the exemptions and decide by default, and escalate to a forced challenge only on your own risk rules. The second trap lands later: authenticate the card once while the customer is present and store that credential, or your background renewals start failing with 'authentication required' and nobody is there to tap anything.

Ask AI for it

Wire 3-D Secure 2 into this checkout with Stripe Payment Intents. Create the PaymentIntent server-side with the amount computed from the cart, mount the Payment Element, and confirm on the client so the SDK renders the issuer challenge itself instead of me hand-rolling an iframe. Leave request_three_d_secure on 'automatic' so low-risk payments take the frictionless flow, and only force 'any' for orders above my risk threshold or flagged by fraud rules. Handle the requires_action status, the customer abandoning the challenge, and a post-challenge decline as three distinct UI states with retry. When saving a card, run a SetupIntent with off_session usage so the credential is authenticated once for later merchant-initiated charges. Add a line above the pay button warning that the bank may ask them to confirm, and make sure the challenge works inside an in-app browser and on mobile Safari.

You might have meant

card vaulting card on file credential tokenizationoff session payment merchant initiated transactionchargebacksoft decline vs hard declinepayment service provider

Go deeper