3-D Secure: what makes a payment fail

"Payment failed." That is the sentence your customers see, and it is the one that costs you sales. Behind it lie very different causes — not all of them yours to fix, but some are.

What 3-D Secure really is

When a customer pays by card, their bank may require proof of identity: a code by SMS, a confirmation in the banking app, sometimes a fingerprint. That is 3-D Secure.

It is not an option you turn on or off: the buyer's bank decides, transaction by transaction. Your job is simply not to break the flow while it happens.

Causes of failure, by frequency

1. Abandonment during authentication. The customer does not receive the SMS, cannot find their app, or gives up. It is by far the leading cause, and it does not show up in statistics as a "decline" — the payment simply stays pending and then expires.

2. Refusal by the issuing bank. Insufficient funds, limit exceeded, card blocked for international or online payments. Many Moroccan cards are blocked for online payments by default: the customer has to ask their bank to enable them, and often does not know that.

3. Wrong card details. One digit too many, an expiry date in the past, a mistyped security code.

4. Fraud suspicion. An unusual amount, a burst of attempts, a card already declined several times.

What you can improve

Do not lose the customer during authentication. If your page reloads, closes or loses its state while the customer switches to their banking app, you lose the sale. The hosted page handles that cycle; if you build your own, test it on mobile, on a slow network, with a third-party banking app.

Show a pending state on return. The customer comes back to your site before the result is known. A page that shows "failed" by default turns a payment in progress into a lost sale — the customer will not try again.

State the real cause when you know it. "Check with your bank that your card is enabled for online purchases" saves sales that "Payment declined" loses for good.

Offer an alternative. This is the single most effective measure: a cash payment link, payable at an agency, recovers a meaningful share of customers whose card was declined.

What you cannot change

The decline rate of issuing banks is not yours to set. A limit, a card not opened for international use, a risk policy: those are the customer's bank's decisions.

You can, however, measure. The portal shows, for each link and each session, where buyers stop — how many opened the page, how many entered their card, how many went through. If the drop happens before card entry, your problem is not the bank: it is your page. If it happens after, the conversation to have is with your customers, about enabling their card.

Reading a decline: four concrete cases

"Authentication failed" on several different cards, the same day. It is probably not your customers: check your integration — a badly built session or a broken redirect produces exactly this pattern of failures.

The same customer fails three times, then succeeds from another browser. The classic culprit: a popup blocker or third-party cookie protection kicking in during authentication. Nothing to fix server-side; a help message on your payment page ("allow your bank's window to open") recovers part of those sales.

Declines clustered in the small hours. Limits reset, bank batches run: a card declined at 11 pm sometimes goes through at 8 am. Suggesting a later retry is not an admission of failure, it is sound advice.

A stable failure rate that suddenly climbs. Compare with volume first: a spike in failures during an advertising campaign usually signals new buyers who are less used to 3-D Secure — not an outage.

The integration-side checklist

• The payment page opens in the main tab, never in a hidden iframe — bank authentication is designed to be seen.
• The amount and merchant name displayed are exact: that is what the bank shows the cardholder, and a mismatch makes people walk away.
• Your return page tolerates all three outcomes — success, failure, abandonment — without a blank screen.
• Order confirmation relies on the webhook, not on the browser return.
• You log the decline reason returned by the API, not just "failed": it is what makes the diagnoses above possible.

A measurement beats a hunch

Before optimising anything, look at the funnel. Most of the "3-D Secure problems" reported to us turn out, on inspection, to be earlier drop-offs: a form that runs too long, an amount that surprises, a page that takes eight seconds to render on a mobile network.