The bank’s authentication screen is a checkout step, so stop counting it as abandonment
Between the moment a shopper presses pay and the moment the order is confirmed, a card payment can pass through a screen your shop did not design. The shopper’s bank asks for a code, a fingerprint or an approval in the banking app. Whether that screen appears is decided in the end by the shopper’s bank, not by your shop, but the shopper meets it inside your checkout, and when it goes wrong they do not blame the bank.
A contributed blog on Finextra, written after the United Kingdom’s 14 March 2022 deadline for strong customer authentication on online payments, makes the commercial case in two parts. The first is a projection from Forter’s analysis: merchants that send every UK card transaction through 3-D Secure could lose 8 to 10% of revenue, through shoppers who fail authentication and payments that are declined afterwards. The blog presents it as its own projection, not a measured result. The second part is more useful because you can check it in your own data. Merchant systems, the blog notes, often cannot tell a shopper who abandoned the cart from a payment that failed in authentication. Both show up as the same drop-off.
In a Dutch checkout the card authentication step concerns a minority of orders. According to the Betaalvereniging, iDEAL accounts for 71% of online purchases in the Netherlands, and with iDEAL the shopper already confirms every payment with their bank’s own secure method, such as the banking app. Credit cards accounted for 8%. That makes the card step easy to overlook in a report dominated by iDEAL, and for a shopper who rarely pays by card an unexpected bank screen is less familiar than the iDEAL approval they know.
One drop-off, three different problems
A shopper who reaches the payment step and leaves without an order can have left for very different reasons, and the authentication step hides three of them behind one number.
The first is a shopper who gave up at the bank screen. The phone with the banking app was in another room, the app asked for a fresh login, or the screen looked unfamiliar enough to raise doubt. The second is a challenge that failed: a wrong code, a code that never arrived, or a time limit that ran out while the shopper switched between apps. The third is technical: the authentication screen did not load, or the return from the banking app landed on an error page instead of the order.
Each needs a different response. The first is about expectation and timing. The second is about what the shopper can do next, such as requesting a new code or choosing another method without starting over. The third is a fault to be fixed, not a behaviour to be influenced. As long as all three sit inside a single abandonment rate, none of them gets the right fix.
The shopper cannot see who decided to ask
EMVCo, which manages the 3-D Secure specification, describes the two outcomes from the shopper’s side. Many payments pass without anything visible happening. When the card issuer judges the risk to be higher, the shopper gets a challenge, typically a code or a biometric check. The issuer makes that judgement on data it receives from the merchant side about the purchase, the card and the device used.
From the shopper’s point of view, this makes your checkout inconsistent. Last week the same card on the same site went through with one tap. Today a code is requested. The shopper has no way of knowing that the bank decided, and reads the difference as something your shop changed. That is also how exemptions from authentication appear to a shopper: when they apply, nothing happens, and when the bank declines one, the payment suddenly needs the step after all. The Finextra blog advises sending a payment to authentication up front when the issuer is unlikely to accept an exemption. For the shopper, that means one expected step instead of a refusal.
A refusal still happens, and that case deserves a test of its own. A declined exemption should arrive as one more step inside the same payment. If your checkout shows it as an error, followed by a cart the shopper has to resubmit, a routine bank decision becomes a failed order.
Returning customers should meet the step less often
The blog also describes a model in which the shopper completes full authentication once, at the first checkout, and confirms later purchases with biometrics. Whatever the technical route, the principle is sound from the shopper’s side. A customer who has bought from you before, on the same phone, should feel that the shop recognises them. Meeting the same challenge on every order teaches a loyal customer that paying at your shop takes effort.
What you collect in the checkout also matters here. The issuer bases its decision partly on what it receives about the transaction and the device. A checkout that collects complete, consistent details gives the bank more to judge with than a minimal form. You do not control the outcome, but you do control whether the information the bank uses is there.
Put the authentication step in your funnel this month
Add separate events for the moments around authentication: payment started, authentication requested, authentication completed, and payment result. Split them by payment method, device and new versus returning customer. Then place test orders by card on a phone, leave the banking app open for several minutes before returning, enter a wrong code once, and note what your checkout shows each time. Every screen that ends in an empty cart or an error without a next step is a place where the bank’s decision is costing you an order. Fix those first, starting with the return from the banking app.
Sources: finextra.com, emvco.com, EMV 3-D Secure, betaalvereniging.nl and ideal.nl
