Authentication is the point in a card payment where a customer's patience is tested. A good 3D Secure 2 setup is nearly invisible. A bad one sends customers into loops, blank screens and error pages, and it can hide the problem from you because the failure happens in a step you do not control.
This article explains how 3DS2 works in plain terms and, more usefully, where integrations break in practice. The failures are consistent across merchants, which means you can design against them.
How 3DS2 works
3D Secure is a protocol that lets the customer's bank (the issuer) confirm that the person paying is the cardholder. 3DS2 improves on the first version in two ways: it passes much more information about the payment to the issuer, and it supports modern mobile and app experiences.
At a high level, the flow looks like this:
- You start a payment and send the authentication request, with data about the customer, device and transaction.
- The issuer assesses the request.
- Frictionless: the issuer is satisfied and authenticates without asking anything of the customer.
- Challenge: the issuer wants proof, so the customer is shown a step such as a one-time code or an approval in their banking app.
- The result comes back, and the payment either continues to authorization or ends.
The more complete your data, the more often the issuer chooses the frictionless path.
Frictionless and challenge flows
You do not control which path a payment takes. The issuer does. What you control is the quality of the information you send and the experience around a challenge.
A frictionless flow costs nothing in customer effort. A challenge flow costs some, and sometimes a lot: a code that arrives late, an app that does not open, a screen that is hard to read on a small phone. Each of those moments is a place where customers leave.
Where integrations break
The return step fails
After a challenge, the customer is sent back to your system. If the return address is wrong, blocked or tied to a session that no longer exists, the customer ends up on an error page and your system never records the result. The bank may even have authenticated them successfully.
Design against it: make return handling robust, accept the result server to server where possible and recover the session from the payment identifier instead of depending on a cookie.
Sessions expire during the challenge
Customers take time to find a code or open an app. If your session or your payment window expires in the meantime, the payment fails after the customer did everything right.
Design against it: allow enough time for the challenge, and make an expired session recoverable without making the customer start over.
The challenge screen does not load
Challenge screens are often shown in an embedded frame or a pop-up. Browser settings, content security rules, frame restrictions and blockers can stop them from appearing. The customer sees nothing, and often blames you.
Design against it: test the challenge in every major browser and on real phones. Check that your own page policies allow the authentication frame to load. Offer a clear fallback if it does not appear.
Results are not handled
An authentication can end in several ways: success, failure, rejection, an unavailable service or a timeout. Integrations that handle only success treat everything else the same, which means customers get a vague error and you lose sales that a better message might have saved.
Design against it: list every possible outcome, decide what the customer sees for each and decide whether a retry or another method is the right next step.
Incomplete data
3DS2 relies on data such as the customer's email, billing details and device information. When these are missing or wrong, issuers have less to go on and challenge more often.
Design against it: collect and send accurate data. Check that fields are formatted the way your provider expects, and that a missing value does not silently drop the whole block.
App and browser transitions
When a challenge opens another app, such as a banking app, and the customer returns, your page may have been suspended or reloaded. The state they left is gone.
Design against it: make the payment resumable. Store enough on the server that returning to your page picks up where the customer left off.
Slow or missing one-time codes
Codes by text message do not always arrive promptly. If your flow does not tell customers what to expect or how to ask for another, they leave.
Design against it: you do not control the issuer's code delivery, but you can write clear guidance around it and avoid timeouts that are shorter than a realistic wait.
3DS loops
A loop is when a customer completes authentication and is sent back to authenticate again. Usual causes:
- The result is never processed, so your system thinks authentication has not happened.
- A duplicate payment attempt is created when the customer returns.
- A return page reloads the payment and starts a new authentication.
- An error is shown as a retry prompt without explaining the real problem.
Break the loop by tracking one payment through authentication with a single identifier and by making result handling safe to repeat.
Sandbox is not production
Authentication flows in a sandbox are simplified. They rarely reproduce the variety of real issuers, real challenge screens and real mobile transitions. Many problems appear only when real customers try to pay.
That is why we recommend a controlled go-live, followed by close watching of authentication outcomes.
What to measure
Add these views to your reporting:
- How often payments are authenticated frictionlessly and how often they are challenged
- Where customers abandon during a challenge
- Authentication outcomes by issuer, device and browser
- Errors in the return step
Averages hide problems. Break the numbers down until a pattern appears, then fix that pattern.
Regional notes
Authentication rules and issuer behavior differ across the Middle East. Local issuers can differ in how often they challenge and how their challenge screens behave, so test with cards from the markets you serve.
Design the customer's side of the story
Most guidance about 3DS2 focuses on the protocol. The customer experiences something simpler: a short interruption. Tell them in advance that their bank may ask for confirmation. Keep your own page visible and branded around the challenge where you can. Give clear copy for each failure, so a declined authentication reads as "try another card or method" rather than a dead end.
A short checklist
- Send complete, correctly formatted data with every authentication request
- Handle every authentication outcome, not only success
- Keep the return step server-driven and resilient
- Allow enough time for a customer to finish a challenge
- Test the challenge in all major browsers and on real phones
- Make payments resumable after an app switch
- Monitor authentication outcomes by issuer and device
Where to go next
3DS2 problems are a common cause of declines and drop-off. Our payment gateway integration service builds authentication flows with these failure modes in mind. If you are already live and seeing friction, our approval-rate optimization service looks at authentication, retries and routing together. You can also read our integration checklist for the full build list.
