Why Card Payments Fail on Your Website: 3D Secure / SCA Errors and How to Fix Them

A "3D Secure failed" or "3D Secure authentication failed" error means the extra check the customer's bank asked for (an approval in the banking app, a one-time SMS code or a fingerprint) did not complete. It is not an out-of-funds decline, and it rarely means your site is broken: usually the customer did not approve in time or never got the request, and less often an outdated payment integration cannot show the bank's window. Below is how to tell which one you are dealing with from your payment dashboard, and what to fix.

You probably know the scenario: customers add products to the cart, reach the payment step, and everything stalls. The card is declined, a strange screen from the bank appears, or the page freezes on an error message. It is frustrating, because the sale was practically made. Once you understand what happens in the few seconds between "Pay" and "Thank you for your order", most of these errors become easy to diagnose.

What 3D Secure and SCA actually are

SCA (Strong Customer Authentication) is a European rule that came with the PSD2 directive and has applied since 14 September 2019. For online card payments in the European Economic Area (the UK has its own equivalent), the bank must confirm that the person paying really is the cardholder, using at least two of three factors: something you know (a PIN or password), something you have (your phone) and something you are (a fingerprint or face).

3D Secure is the mechanism that carries out that check. Customers see it branded as Visa Secure, Mastercard Identity Check or American Express SafeKey. The current version, 3DS2, sends the bank data about the device and the transaction, and the bank can either approve the payment silently (the "frictionless" flow) or ask for an explicit confirmation (the "challenge" flow). The old version, 3D Secure 1, is no longer supported by the major card brands, so an integration still built on it will produce declines.

Outside Europe the rules differ by country, but card issuers can still request 3D Secure on a payment they consider risky. Either way, when the step works the customer barely notices it. When something is misconfigured, you get declines, blank pages or endless loops.

Not every payment needs a challenge: SCA exemptions

A common question is why one customer is asked to confirm and another is not. SCA has several exemptions that your payment provider can request:

• Low-value payments: under EUR 30 (GBP 25 in the UK) can be exempt, but the bank must ask for authentication again once the exemption has been used five times since the last successful authentication, or once the exempted payments add up to more than EUR 100 (GBP 85).
• Transaction risk analysis: the provider can request an exemption for low-risk payments, within limits tied to its fraud rate.
• Fixed-amount recurring payments: the first payment is authenticated, later ones can be exempt.
• Merchant-initiated transactions: charges to a saved card while the customer is not present technically fall outside SCA, as long as the card was properly authenticated when it was saved.
• Trusted beneficiaries: if their bank offers it, the customer can add your business to a trusted list.

The key point: your provider asks for the exemption, but the customer's bank makes the final call. That is why two similar orders can take different paths, and why your checkout must always be able to show the bank's confirmation window.

The most common causes, by where they come from

Before fixing anything, separate the causes on the customer's side from those at the bank and those on your own site.

On the customer's side:

• They did not approve in time: the banking-app request or the SMS code is only valid for a limited time, and after that the payment fails.
• Notifications are off, the banking app is missing or out of date, or the bank has an old phone number on file.
• They closed the bank's window, tapped "Cancel" or entered the wrong code several times.
• A pop-up blocker or an aggressive ad-blocker kills the 3D Secure window; a VPN can trigger extra risk checks at the bank.

At the bank:

• The card is not enrolled in 3D Secure (the service was never activated for that card) or is not enabled for online payments.
• The bank's authentication server is temporarily unavailable.
• The bank declines the payment under its own risk rules.

On your site:

• The integration is outdated: it relies on 3D Secure 1 or a legacy API (Stripe warns that integrations on its old Charges API may see high decline rates from banks that enforce SCA).
• The bank's window cannot load: a strict Content Security Policy, a sandbox attribute on the iframe, or a security plugin blocking the payment provider's domains.
• The return from the bank is not handled: the page freezes and the order sits in "pending" forever.
• Saved-card charges (subscriptions, later payments) are attempted on cards that were never authenticated when they were saved.

How to diagnose the problem step by step

Do not guess. Open the failed transactions in your payment provider's dashboard (Stripe, Adyen, PayPal/Braintree, or a local provider such as NETOPIA, PayU or EuPlătesc in Romania) and read the exact reason. In Stripe, go to Transactions > Payments and use the status filter: "Incomplete" for payments the customer started but did not finish (usually stuck at authentication), "Failed" for declined charges to a saved card made while the customer was not present. Hover over the status badge to see the reason.

Then look for a pattern. Do all the failures come from one bank? Only from phones? Only from links opened inside Instagram or Facebook? If they cluster around one bank, the cause is probably on that bank's side (a temporary outage or how it sets up its cards); if they come from everywhere, look at your integration.

Finally, test the flow yourself. In test mode, providers offer cards that force the 3D Secure step (in Stripe, 4000 0000 0000 3220 always requires authentication), and you can simulate both success and failure. Then try a real card on a phone and on a desktop. If it works for you but not for customers, the issue is usually their device, bank or network. If it fails for you too, it is configuration. For causes beyond 3D Secure, see our guide on what to do when customers say they cannot pay on your site.

One useful detail: when a decline is flagged as suspected fraud or a stolen card, Stripe recommends showing the customer a generic decline message instead of the exact reason.

For your developer: reading the 3D Secure response

Some providers show the standard EMV 3-D Secure fields in the transaction details, and they show where authentication broke; with others you can ask support for them. The most useful values:

What to check in the code:

• Use your provider's current, SCA-ready API (in Stripe: Payment Intents, Checkout or the Payment Element) and keep the payment plugin up to date.
• Handle the state where the payment needs an extra action (requires_action in Stripe): show the bank's window in a modal, an iframe or via a redirect with a return_url, then re-check the payment status when the customer comes back.
• Allow the provider's domains in your Content Security Policy (for Stripe: js.stripe.com, hooks.stripe.com and the origin of your return_url) and do not put a sandbox attribute on the 3D Secure iframe, because some banks' pages fail when sandboxed.
• Confirm the order from the provider's server-side notification (webhook or IPN), not only from the browser redirect. Otherwise a customer who closes the tab after paying is charged while the order stays "pending".
• For subscriptions, authenticate the card when it is saved and build a path that brings the customer back to confirm if the bank asks again. Our article on recovering failed subscription payments covers that part.

Why 3D Secure fails more often on mobile

On a phone there are more places where the 3D Secure step can break:

• The customer leaves the browser to approve in the banking app. When they come back, some phones have reloaded or closed the page, and if your site relies only on the browser returning, the order is lost.
• In-app browsers (when someone opens your shop from a link in Instagram, Facebook or TikTok) sometimes handle new windows and redirects badly. If your failures come from there, test that exact path.
• Banking-app notifications are switched off or delayed by battery saving, and weak signal makes the SMS code arrive too late.
• Apple Pay and Google Pay are a good fallback on mobile: the customer confirms with a fingerprint, Face ID or the phone's passcode, and wallet payments usually do not open the classic 3D Secure window.

What you can fix yourself and what needs a developer

Without a programmer you can:

• Add a short line at checkout: "You will get a confirmation request in your banking app. Approve it, then come back to this page to complete your order." Many customers simply abandon because they do not understand the bank's screen.
• Offer an alternative payment method (Apple Pay or Google Pay, bank transfer, cash on delivery where it makes sense) for people who struggle with 3D Secure.
• Check that your payment plugin or module is on the latest version and that your provider confirms you are on 3D Secure 2.
• Put the customer checklist below on your help page.

What needs a developer: updating the integration, moving to the provider's current API, displaying the bank's window correctly, handling the return after authentication and confirming orders via webhook. If the page freezes right after the bank's window, it is almost certainly code that does not handle the response coming back from 3D Secure.

One thing you cannot do is switch 3D Secure off to stop the declines. Stripe, for example, does not let you turn it off manually through its API.

If you are the one paying: what to try

You can copy this list onto your shop's help page:

• Try the payment once more. Often the confirmation simply timed out.
• Make sure your banking app is up to date with notifications on, and that the bank has your current phone number.
• Turn off your ad-blocker and VPN for a moment and open the shop in Chrome, Safari or Firefox rather than inside Instagram or Facebook.
• Check in your banking app that online payments are enabled on the card and that your limits allow the amount.
• If the error keeps coming back, call your bank or use another card or payment method.

How we handle payments at MPO Web Studio

When we build a store, we treat payment as the most sensitive part of the site, because that is where the money is won or lost. We use providers that support 3D Secure 2 natively, confirm orders from server-side notifications, test the flow on phone and desktop before launch, and add the messages that guide customers through the bank's confirmation step.

We work fully remotely and prepare a free demo before you pay anything, including the checkout flow, so you can see for yourself how it behaves.

If you are losing orders at payment and cannot work out why, message us on WhatsApp with an example of the error from your provider's dashboard. We will look at it together and tell you honestly whether it is a five-minute fix on your side or something in the integration.