Introduction
Payment authentication is a balancing act, and it’s easy to fall off either side.
Make it too loose, and you invite fraud, chargebacks, and regulatory trouble. Make it too strict and real customers bail at checkout because they can’t get through an authentication step they didn’t expect.
That’s the gap 3D Secure 2 (3DS2) and Strong Customer Authentication (SCA) are meant to fill.
If you run product or you’re a founder, here’s the part worth internalizing: 3DS2 isn’t just a security screen that pops up after someone types in their card. It’s a risk-based authentication process that spans your app, your payment gateway, the card network, and the customer’s issuing bank. Four parties, one checkout.
Done well, most legitimate payments go through without a hitch. When the bank does want extra verification, a good integration makes that challenge feel like part of checkout, not a technical redirect that appears out of nowhere.
So payment gateway integration is more than flipping a switch in a provider dashboard. Your team has to actually understand authentication states, browser and mobile flows, failed challenges, abandoned sessions, delayed results, exemptions, webhooks, and recovery paths. That’s the real work.
Why 3DS2 and SCA matter
SCA came out of Europe’s PSD2 framework as a way to make electronic payments harder to fake.
The core requirement: authenticate with at least two independent factors from different categories.
- Something the customer knows, like a PIN or password.
- Something the customer has, like a registered phone or a banking app.
- Something the customer is, like a fingerprint or face scan.
Whether a given transaction actually needs SCA depends on the payment type, the institutions involved, where the transaction happens, and whether an exemption applies. Don’t hardcode assumptions about this into your product. Confirm the legal and operational details with your payment provider and your compliance people first.
The European Commission publishes the official PSD2 implementing and delegated acts, including the SCA standards. If you operate in Europe, that’s a solid primary reference: European Commission: Payment Services Directive.
3DS2 is one of the main technologies card issuers and payment providers use to run this authentication for online card payments.
The old 3D Secure leaned on jarring redirects and static passwords. 3DS2 handles richer transaction data, mobile apps, biometrics, and risk-based decisions. And no, it doesn’t mean every transaction forces the customer to punch in a code. One of the whole points is to let low-risk payments through with no extra friction.
How a typical 3DS2 payment flow works
Every provider exposes slightly different APIs, but the shape of a 3DS2 flow is usually the same.
1. The customer starts the payment
They enter or pick their payment details and confirm the purchase. Your frontend sends the payment info to your backend, or to the provider’s approved client-side component. How you handle sensitive card data depends on your integration model and your PCI DSS responsibilities.
A hosted checkout or tokenized component keeps most of the sensitive data out of your systems. A fully custom API or mobile SDK gives you more control but hands you more implementation and compliance work in return. Pick your trade-off deliberately.
For a deeper comparison, see our guide to hosted, API, and in-app payment gateway integration.
2. Authentication data gets collected
3DS2 can send contextual information to the issuing bank’s Access Control Server (ACS). Depending on the channel and provider, that might include:
- Device and browser details.
- Transaction amount and currency.
- Billing and shipping info.
- Customer account history.
- Merchant details.
- Previous authentication data.
- Signals about recurring or merchant-initiated payments.
The issuer uses all of this to assess risk. This is exactly why implementation quality matters. If the data is missing, inconsistent, or badly formatted, the issuer has less to work with, and you’re more likely to trigger a challenge or an outright failure.
3. The issuer picks frictionless or challenge
The bank looks at the request and decides whether it can authenticate without bothering the customer. Two paths:
- Frictionless: authentication happens in the background.
- Challenge: the customer has to complete an extra verification step.
EMVCo notes that a challenge tends to show up when a transaction can’t clear the frictionless flow or when the issuer reads it as higher risk. Their 3DS business overview has more on how that decision gets made.
4. Authentication finishes
If it succeeds, your app gets authentication data you can pass into the payment authorization request.
Authentication and authorization are related, but they are not the same thing. An authenticated customer can still get declined for insufficient funds, card limits, issuer fraud rules, an expired or blocked card, merchant restrictions, wrong payment details, or a temporary issuer or network hiccup.
And an authentication response is not proof that money landed in your account. Don’t treat it that way.
5. The payment is authorized and finalized
The gateway submits for authorization and returns an initial result. Your system then confirms the real business state using server-to-server notifications, gateway queries, or reconciliation jobs. The browser response on its own is not the source of truth. Customers close the page, lose signal, or interrupt the redirect all the time.
Frictionless flow: authentication with nothing to see
In a frictionless flow, the bank authenticates using the contextual data it already has and never asks the customer to do anything extra.
To the customer, it looks like a plain card payment: enter details, confirm, see the result. For legitimate low-risk transactions, that’s the experience you want.
Here’s the catch: you usually don’t get to decide whether the issuer goes frictionless. Your provider can request an exemption or pass along risk data, but the issuer makes the final call on both authentication and authorization. So don’t build checkout on the assumption that authentication stays invisible. Your interface has to handle both paths the same way.
Challenge flow: when the customer has to verify
A challenge means direct interaction. Depending on the bank and device, the customer might approve the payment in a banking app, enter a one-time password, confirm with a fingerprint or face scan, type a banking password or PIN, or go through some other issuer-controlled method.
Visa describes the same idea: low-risk transactions can authenticate in the background, while riskier ones can trigger extra verification.
The challenge might show up in an embedded frame, a browser redirect, a native mobile screen, or a banking app. That variety is where the UX risk lives.
The customer may not get why some other company is suddenly asking them to verify. They switch to their banking app and forget to come back. The one-time password shows up late. The authentication screen doesn’t fit the mobile layout. Their accessibility settings make the issuer’s interface hard to use. You can’t control the issuer’s screen, but you can prepare the customer for it and recover cleanly once they’re back.
UX principles for 3DS2 challenges
Explain what’s happening. Before the challenge, show something short and human:
- “Your bank may ask you to verify this payment. Please complete the verification and come back to this screen.”
Skip the protocol jargon. Nobody wants to read “Launching ACS challenge” or “Processing 3DS method.” They want reassurance, not terminology.
Keep the payment context on screen. Where you can, keep showing the merchant name, the order summary, the amount and currency, and a clear payment-in-progress status. It tells the customer they’re still buying the same thing.
Don’t call an unfinished payment failed. A redirect, an app switch, or a slow webhook can leave a payment unresolved for a few seconds, sometimes longer. When you don’t know the status, say so:
- “We’re confirming your payment.”
Don’t flash “Payment failed” just because your frontend didn’t hear back fast enough.
Preserve the order. A failed challenge shouldn’t wipe out the customer’s basket, booking, entered data, or reservation. Keep the order in a recoverable pending state until you know the outcome. For time-sensitive inventory, decide up front how long it stays reserved and what happens when authentication drags on.
Design for mobile interruptions. Mobile users often leave your app to approve the payment in their bank’s app, and your app has to restore the right state when they return. Test app backgrounding and foregrounding, deep links and return URLs, tab changes, device rotation, expired sessions, the customer closing and reopening the app, and the banking app approving the payment after your original screen already timed out.
Make retry actions specific. “Something went wrong” isn’t good enough. The next step should match the actual state: retry authentication, try the same card again, use another card, switch payment methods, go back to the order, wait while confirmation is checked, or contact support with an order reference.
SCA exemptions aren't guaranteed approvals
Some transactions can qualify for an exemption or sit outside normal SCA scope, like certain low-value payments, merchant-initiated transactions, trusted beneficiaries, or payments scored as low risk.
But an exemption is a request, not a promise. The issuer can still demand authentication or decline outright. So your app has to be able to start a challenge even when the original plan was to request an exemption.
One more thing for founders: don’t treat exemptions as a way to dodge authentication. They’re part of a risk and compliance strategy, not a conversion lever you pull whenever you want a smoother checkout.
Work with your provider to nail down which exemptions it supports, which transactions are eligible, what data you need to supply, how soft declines come back, how to retry with authentication, and how all of this affects your fraud exposure and liability.
Edge cases your integration has to handle
The success path is the easy part. Whether your integration is actually reliable comes down to everything that happens off that path.
The issuer wants authentication after an exemption attempt. You may get a soft decline, meaning authentication is required. Recognize it and restart the payment through a 3DS2-authenticated flow where that’s appropriate. Don’t show it as a permanent card decline before you check whether the gateway expects an SCA retry.
The customer fails the challenge. Wrong code, rejected request, failed biometrics, too many attempts. Show a clear result and offer a sensible retry or an alternative method. Don’t keep throwing the same challenge after the issuer has returned a final failure.
The customer cancels the challenge. Cancellation isn’t the same as a technical failure. Say something like:
- “The bank verification was cancelled. Your card has not been charged.”
Only make that second sentence definitive once your backend has actually verified the payment status.
The customer abandons the flow. They close the window, leave the app, or never come back after banking-app authentication. Keep the payment and order tied together with persistent identifiers. A webhook or a later status query might reveal the payment succeeded even though the session vanished.
The challenge times out. A timeout doesn’t prove the payment failed. Mark the attempt as unresolved until your backend confirms the final status with the provider. You’ll probably want a scheduled job that queries payments stuck in an authentication-pending or processing state.
The frontend says failure, the webhook says success. Classic distributed-systems problem. The customer loses connectivity after a successful authorization, or the redirect dies while the gateway’s server-to-server notification arrives just fine. Treat authenticated gateway events and status queries as more trustworthy than the browser screen.
The webhook is duplicated. Providers retry webhooks when they don’t get a timely ack. Your handler has to be idempotent, so the same event can’t create two orders, send two confirmations, or apply the same balance change twice. Our guide to webhooks, retries, and idempotency covers how to build this.
The payment stays pending. Some attempts hang unresolved longer than expected. Build a reconciliation process that periodically compares your records against gateway data and flags payments that are pending too long, successful at the gateway but incomplete on your side, marked successful internally but missing gateway confirmation, or refunded and reversed without your local state catching up.
The customer retries and creates another attempt. A retry should normally spawn a new payment attempt linked to the same order, not overwrite the old one. That gives you a real audit trail: order ID, payment attempt ID, gateway reference, authentication status, authorization status, failure reason, timestamp, and final resolution.
A practical payment status model
Don’t try to represent this whole process with just “success” and “failed.” A more useful internal model might look like:
- created
- authentication_required
- authentication_in_progress
- authenticated
- authorization_pending
- authorized
- declined
- cancelled
- expired
- failed
- captured
- refunded
- partially_refunded
Your names can differ. The point is to separate authentication status from financial status. `authenticated` doesn’t mean `authorized`. `authorized` doesn’t mean `captured`. `challenge_cancelled` isn’t `issuer_declined`. `frontend_timeout` isn’t a final result. Keeping these apart makes your customer messaging, support tools, analytics, and reconciliation all better.
Testing 3DS2 before launch
One successful sandbox payment is not a test plan. Run at least these scenarios:
- Frictionless authentication with a successful payment.
- Challenge authentication with a successful payment.
- Wrong one-time password.
- Customer cancellation.
- Challenge timeout.
- Soft decline followed by an authenticated retry.
- Authentication success followed by an authorization decline.
- Duplicate webhook.
- Delayed webhook.
- Missing browser return.
- Customer refreshing mid-authentication.
- Customer opening checkout in multiple tabs.
- Mobile banking-app switch and return.
- Expired checkout session.
- Retry with the same order.
- Retry with a different card.
- Provider outage or malformed response.
- Payment completing while your app is temporarily down.
And check the real production configuration before you go live. Sandbox behavior doesn’t always match every issuer, device, card network, and mobile banking app you’ll meet in the wild.
How Appricotsoft approaches 3DS2 and SCA integrations
At Appricotsoft, we want to build software that’s useful, dependable, and something our clients and we are actually glad to ship. For payments, that means treating authentication as a full product workflow, not a single API call.
We usually start by mapping the checkout journey, the payment and authentication states, provider responsibilities, SCA and exemption assumptions, browser and mobile return flows, webhook processing, and the retry and reconciliation rules, plus support and admin visibility and how we’ll monitor the launch.
Our Unison delivery framework keeps those decisions visible through a shared backlog, acceptance criteria, a risk register, a decision log, a QA workflow, and regular demos. AI can help draft test scenarios, review logs, or write documentation, but people review the output and stay responsible for the result.
In practice, that turns into a handful of safeguards: explicit payment state transitions, idempotent backend operations, secure webhook verification, clear challenge recovery, server-side status confirmation, structured provider error mapping, reconciliation for unresolved transactions, monitoring for conversion and failure patterns, and documentation the support and ops teams can actually use.
A payment flow has to satisfy several groups at once, and they don’t always want the same thing. Customers want speed and clarity. Founders want conversion and predictable costs. Compliance wants proper controls. Support wants visibility. Developers want reliable provider contracts and testable state transitions. Good integration work connects all of them.
Frequently asked questions
Is 3DS2 the same as SCA?
No. SCA is a regulatory requirement. 3DS2 is a technical protocol commonly used to meet it for online card payments.
Does every 3DS2 payment show a challenge?
No. Low-risk transactions can clear the frictionless flow with nothing visible to the customer.
Can a merchant force frictionless authentication?
You and your provider can send useful data and request eligible exemptions, but the issuer makes the final authentication call.
Does a successful 3DS2 authentication guarantee the payment goes through?
No. Authentication confirms the customer per the issuer’s process. Authorization can still fail on funds, limits, issuer rules, or other conditions.
Who decides whether SCA is required?
It depends on the transaction, the applicable rules, the payment providers, and the issuing bank. Your provider should explain how it classifies transactions and handles exemptions, exclusions, soft declines, and authentication requirements.
Should we build 3DS2 ourselves?
Most companies integrate it through a gateway, processor, or approved SDK rather than implementing the protocol from scratch. You still design the surrounding checkout, backend states, webhooks, retries, and recovery logic.
What should customer support be able to see?
The order, payment attempts, authentication result, authorization result, provider reference, timestamps, failure category, and the recommended next action. Sensitive authentication or card data shouldn’t be exposed unnecessarily.
Conclusion
3DS2 and SCA aren’t just compliance or backend problems. They shape checkout conversion, customer trust, support load, fraud exposure, and payment reliability all at once.
A good implementation lets low-risk customers move through checkout with minimal friction while still supporting secure challenges when the bank asks for one. It also survives cancellations, timeouts, app switching, soft declines, duplicated notifications, and slow results.
The one principle that carries the most weight: never design only for the happy path.
At Appricotsoft we combine product thinking, secure system integration, QA, and operational planning to build payment flows that stay understandable for customers and manageable for the business. The goal isn’t just to connect a gateway. It’s to build a payment experience you can run and scale with confidence.
Planning a new checkout, or trying to fix an unreliable one? Request a payment gateway integration estimate from Appricotsoft.
