When the bank’s screen disappears, the shopper has to recognise what replaces it
A card payment can stop for a check by the shopper’s bank. EMVCo, which manages the 3-D Secure specification, describes how that works: many payments go through without anything extra, and when the bank judges the risk to be higher, the shopper is challenged with a one-time code, a biometric check or another method. Whatever form it takes, the shopper knows whose check it is. It is the bank’s code, the bank’s app, the bank’s name on the screen.
Newer authentication routes take that familiar screen away. In delegated authentication, the bank hands the check to a specific third party and accepts its result. In the browser route described below, the bank still does the checking, but the shopper confirms in a dialog drawn by the browser, with the unlock method of their own device. That is good news for speed, and it moves a question of trust to a place most checkouts have never looked at. The shopper has to recognise a confirmation that no longer carries the bank’s own screen.
The authors of the W3C’s Secure Payment Confirmation, a browser standard for exactly this step, explain why the route matters. They describe an earlier attempt to delegate authentication from the bank to specific third parties, and note that it did not scale to the tens of thousands of online merchants that accept cards. Their alternative lets the merchant start the bank’s own check, while the browser shows the confirmation. The standard is a Candidate Recommendation Draft, the most recent version dated 13 October 2026, and whether a shopper meets it depends on their browser and on whether their bank takes part.
The dialog shows your name, your total and the shopper’s card
What makes the standard useful to read, even before it reaches your checkout, is that it spells out what the shopper sees. The browser has to show the name of the payee, its web address or both, the currency and amount of the payment, and the name and icon of the card being used. The browser draws that dialog, not the website, so a malicious page cannot fake it, and the details shown are included in the signed proof of the confirmation.
Each of those details is a point where the shopper can hesitate. The payee name is not chosen by the browser: it is supplied in the payment request made for your shop. If what appears there is a legal entity name, a platform name or an abbreviation the shopper has never seen on your site, the confirmation looks like a payment to someone else. The same applies to the web address if your payment step runs on a different domain from your shop.
The amount is the second check. The shopper compares it, consciously or not, with the last total they saw on your page. If shipping or a currency conversion appears for the first time in the dialog, the confirmation reads as a surprise at the one moment the shopper is asked to approve with a fingerprint. The card name and icon should match the card the shopper selected on your page; a generic label or a different card raises the same doubt as an unknown payee.
The first payment still goes through the bank
A faster confirmation has to be set up once, and the standard’s own example shows where that happens: during a normal challenge. The shopper pays, the bank asks for a code by text message in a frame on the merchant’s checkout, and after that check offers to register the device for next time. To the shopper this is an extra question inside your payment step, at a moment when they only wanted to pay. Make sure nothing on your page covers that frame, that a time limit on your side does not run out while the shopper reads it, and that the order is still there when they come back from it.
The standard also builds in exits, and each one returns the shopper to your checkout. The shopper can decide not to use the fast confirmation and authenticate another way, cancel the payment, or, where offered, opt out for that bank. When no registered credential matches the device, for example on a new phone, the explainer says the merchant should fall back to the traditional flow, and the standard is written so that the site does not learn whether a credential exists. In practice, a customer who confirmed with a fingerprint last month gets a code again today, and may not understand why, even if the browser shows a short notice first.
That inconsistency is what the shopper sees of the new route. Your checkout should treat each exit as a normal path: back to the same payment step, basket and address intact, with the other payment methods in view.
In a Dutch checkout, this is a card question
Most Dutch online payments never meet this dialog. 3-D Secure is a card protocol, and the published examples of the browser route are card payments that use it in the background. According to the Betaalvereniging, iDEAL accounts for 71% of online purchases in the Netherlands, against 8% for credit cards. That minority, together with foreign shoppers who pay by card, is who may meet a confirmation without a bank screen, and because it is a minority, a fault there easily disappears in your overall figures.
Place a card test order this month on a phone and on a laptop, in more than one browser. You will only see the browser confirmation with a card registered at a participating bank, in a browser that supports it; where your test set-up allows that, note every name, web address and amount that appears in any confirmation screen, and hold them against the shop name and total on your own payment page. Then repeat the order, cancel at the confirmation and choose the other way to authenticate, and check that each time you land back on the payment step with the order intact. Any name the shopper would not recognise and any exit that empties the basket is a point to fix, starting with the exits.
Sources: w3.org, github.com, emvco.com, betaalvereniging.nl
