The customer chose the product, entered the card, and then the bank’s confirmation window opened — and that is where a measurable share of them disappear. Nothing was declined. The payment simply never finished.
This step has a name, a purpose and, more usefully, a set of things you can change about it. Most of the loss at 3-D Secure is not caused by the check itself; it is caused by how the checkout around it is built.
Contents
- What the step actually is
- Frictionless and challenge
- Where the conversion is actually lost
- The trade-off nobody states plainly
- What to fix on your side
- What to measure
- Two habits that pay for themselves
- In short
What the step actually is
3-D Secure is the confirmation the card issuer runs before approving an online payment: a push in the banking app, a code, a biometric prompt. In Europe it exists because strong customer authentication is required for most online card payments, and the acronym you will see for that requirement is SCA. What the gateway around it does is unpacked in our piece on what a payment gateway is.
The part worth knowing as a merchant is the trade-off. When the payment is authenticated, liability for a fraud dispute generally moves away from you — that is what «liability shift» means. Skipping authentication where it is possible keeps the customer in your checkout but leaves the fraud exposure with you.
Frictionless and challenge
Not every authentication interrupts the customer. When the issuer is satisfied by the data sent with the payment, it approves silently — the industry word is frictionless, and the customer never sees a window. When it is not satisfied, it asks the customer directly: a challenge.
You do not control which one happens, but you influence it heavily. The issuer decides on the strength of the data your checkout sends, which is why the most effective work on 3-D Secure conversion is done before the window would ever appear.
Where the conversion is actually lost
- The customer never receives the prompt. An old phone number at the bank, notifications switched off, a device change. Frequent, invisible, and impossible for you to fix directly — which is why it must be recoverable.
- The window opens badly on mobile. Half the abandonment at this step is a layout problem, not a security decision.
- The customer does not recognise the merchant name. If the confirmation says an unfamiliar legal entity, cautious people cancel. This is the same descriptor problem that later produces disputes.
- The session dies while they switch apps. Going to the banking app and back is normal behaviour; a checkout that loses state in the meantime turns a successful authentication into a failed payment.
- Nothing happens after failure. The customer is left on an error screen with no second route and no explanation.
Which decline groups these produce, and how to read them, is unpacked in our piece on why traditional payment gateways do not work for high-risk businesses.
The trade-off nobody states plainly
Turning authentication off wherever possible raises completed payments and raises fraud disputes at the same time. Those disputes cost 100,00 EUR each on top of the returned amount, count against the ratio the card schemes monitor, and eventually move the rate and the reserve — MDR runs 3%–5% and the rolling reserve 10% for 180 days. A refund you issue yourself costs 50,00 EUR and does not count against the ratio.
So the decision is not «more authentication or less». It is «where does authentication cost me less than the disputes it prevents» — and the answer differs by ticket size, product and customer base. What the thresholds behind the ratio are is set out in our piece on VAMP guidelines for high-risk merchants.
All published fee lines sit on the pricing page.
What to fix on your side
Send everything the issuer can use. The more complete the data with the payment request — billing details, contact, device, order context — the more often the issuer approves silently. This is the single highest-value change and it happens before the customer sees anything.
Test the flow on a real phone. Not a desktop emulator. Go to the banking app, wait, come back, and see whether the payment still completes.
Keep the merchant name consistent. The name in the confirmation, the name at checkout and the name on the statement should be the same recognisable brand.
Give a second route after a failure. Another card, a payment link, a transfer. Most abandoned payments are abandoned at the error screen, not at the price.
Retry on a schedule, not in a loop. An unfinished authentication is a soft outcome and is worth retrying later; hammering it five times in a minute recovers nothing and looks like card testing.
How routing and retries are put together is described under payment processing.
What to measure
One number is not enough. Track how many payments reached authentication, how many were approved silently, how many were challenged, how many challenges were completed, and how many customers came back after a failure. A checkout with an excellent approval rate and a terrible challenge-completion rate looks healthy in a summary and is losing money every day.
Two habits that pay for themselves
Run one real payment through the full flow after every checkout change, on a phone, with a card that will be challenged. Most breakage at this step is introduced by an unrelated release and discovered by a drop in revenue a week later.
And keep a short note of what the customer sees at each stage — the wording in the confirmation, the name shown, the message after a failure. It is the cheapest document you will ever write and the first one you will want when the completion rate moves.
In short
3-D Secure is not where conversion goes to die; a badly built checkout around it is. Send complete data so the issuer can approve silently, test on a real phone, keep the merchant name consistent, always offer a second route after a failure, and measure the challenge step separately. Then the authentication protects your merchant account instead of quietly costing it revenue.

