Checkout choices begin before the menu appears

A checkout menu looks like a row of payment methods. By the time that row appears, however, the consequential choices have already been made. The system has interpreted what the customer is trying to authorize, assembled the transaction context, removed methods that cannot complete that intent, decided which parties and interfaces can be trusted, and prepared a recovery path if the first attempt does not resolve cleanly.

The menu is therefore an output, not the decision. Treat it as the beginning and the product becomes a logo catalogue: show everything, rank the familiar names, then improvise when a method fails. Treat it as the end of an earlier decision pipeline and every visible option becomes a promise: this method can be used here, for this purpose, with a credible path to completion or recovery.

Start with the financial intent

“Pay” is not a sufficiently precise intent. A customer might be settling one order now, paying with a credential already stored, saving a new credential for later customer-initiated purchases, establishing a fixed subscription, or permitting future charges triggered by an event. Those actions may share a card form. They do not create the same agreement or the same downstream transaction.

Visa’s public stored-credential framework makes the distinction concrete. It separates cardholder-initiated transactions, where the cardholder actively participates, from merchant-initiated transactions performed without that active participation. It also distinguishes recurring, instalment and unscheduled future transactions, and requires consent before a credential is stored for later use.1 In the EU strong-customer-authentication rules, creating, amending or initiating the first transaction in a same-amount, same-payee recurring series is treated differently from later transactions in that series.2

That classification has to exist before method selection. A checkbox labelled “save this card” cannot quietly stand in for an agreement to make future merchant-initiated charges. Nor can a one-time purchase be retrofitted into a subscription after authorization. The product should first create an explicit payment intent containing the payee, amount and currency, what is due now, whether the customer is present, whether a credential may be stored, and what future use—if any—the customer has agreed to.

This intent should be versioned when its meaning changes. If the customer changes the cart total, switches from one-time purchase to instalments, or accepts a recurring plan, the system is no longer rendering the same payment choice problem. The menu must be recomputed from the new intent.

Context turns a catalogue into candidates

The next decision is not “which methods does the merchant support?” It is “which supported methods can this customer use in this transaction, in this environment?”

The W3C Payment Request model captures that separation. A payee declares the methods it accepts, transaction details such as the total, and optional information required to fulfil the purchase. The user agent presents the request only after those inputs exist.3 The Web-based Payment Handler specification then describes the browser computing candidate handlers by comparing merchant-accepted methods with handlers known through registration, method manifests or the operating system; an optional CanMakePaymentEvent can further filter handlers able to respond.4

This is a useful product model even outside browser APIs. Begin with merchant acceptance. Intersect it with what the device or channel can invoke. Intersect again with the customer’s usable instruments and the demands of this transaction. Only the survivors belong in the visible menu.

Context also determines the likely authentication journey. EMV 3-D Secure exchanges transaction, payment-method and device information between merchant and issuer, which the issuer can use when authenticating the consumer.5 Under the EU rules, authentication for remote payments must be dynamically linked to the amount and payee; changing either invalidates the authentication code.2 A method that worked moments ago may therefore need to be re-evaluated after the order total or payee changes.

Collect context with restraint. The Web-based Payment Handler specification says request information should not be shared with a handler before the customer selects it, and calls for clarity about the handler’s origin and cross-origin data sharing.4 Eligibility does not justify broadcasting the checkout to every possible provider. The pipeline should acquire only the context needed for the next decision, at the latest safe moment.

Eligibility must finish before ranking begins

Now the system can answer a yes-or-no question for each candidate. A practical eligibility predicate asks:

accepted × invocable × instrument_usable × transaction_compatible × authentication_possible

Each term should be independently explainable. “Wallet unavailable” might mean there is no handler on this device, no enrolled instrument, an unsupported transaction property, or a temporarily unavailable authentication capability. Those are different conditions. They should not collapse into a low ranking score.

Credential scope is one reason. EMV payment tokens can be constrained to a particular merchant, device or payment scenario.6 Possessing a token is not enough; its domain controls must permit this use. A token provisioned for one device should not appear as an interchangeable card credential on another. A credential allowed for one payment scenario should not be assumed valid for every future intent.

Hard gates should remain hard. If ranking mixes eligibility with preference, a familiar method or a commercially preferred method can outweigh a condition that should have excluded it. Filter first. Then order the eligible set using stable product priorities: the customer’s explicit preference, continuity with a previously selected instrument, expected effort, and transparent price or benefit.

Pricing belongs inside the same recomputation. Payment Request supports method-specific modifiers that can change the total and add display items such as a discount or surcharge when a method is selected.3 A method is not honestly presented if its cost appears only after the customer commits. When selection changes the economics, the total should change beside the selection and before confirmation.

Trust is part of what the menu promises

A payment option is not merely a route. It asks the customer to believe a particular party, amount and instrument are involved. That belief can be broken by small inconsistencies: a wallet opens under an unexplained origin, the amount in authentication differs from the order total, a saved instrument has an ambiguous label, or a fee arrives on the last screen.

Standards turn some of these interface details into security properties. Secure Payment Confirmation requires the user agent to communicate the payee name or origin, transaction currency and value, and payment-instrument details while collecting consent. Those details are then available for verification as part of the authentication assertion.7 The EU dynamic-linking rules similarly require the payer to be made aware of the amount and payee and require protection of the information displayed throughout authentication.2

The implication is broader than one protocol. Keep the payee label, amount, currency and chosen instrument consistent from order review through authentication and result. Make a change visible before asking for consent again. Preserve recognizable instrument labels across the menu, challenge and receipt. Trust comes from continuity that the system can verify, not from adding a lock icon to a moving target.

The surrounding page matters too. PCI SSC’s payment-page guidance focuses on authorizing scripts, checking their integrity, monitoring for tampering, and managing security-impacting HTTP headers; it applies even to pages that can affect embedded payment iframes.8 A well-labelled method menu on a page whose scripts can be silently changed is not a trustworthy checkout surface.

Recovery is a choice made in advance

The cleanest menu design can still meet an expired instrument, rejected authentication, issuer decline, provider error or network timeout. Recovery should not begin with “show the same menu again.” It should begin by identifying what is known.

A validation failure may allow the customer to repair the current response. The Payment Request API’s retry() model can report field or payment-method errors and let the customer supply new values or choose another instrument. But it cannot switch to a different payment handler within that retry; the original response remains tied to the selected handler.3 That boundary matters. “Try another card in this wallet” and “choose another payment method” are different recovery transitions and may require different UI.

A timeout is more dangerous because the financial result may be unknown. Public Adyen documentation describes idempotency keys as a way to resend a timed-out payment call without performing the operation twice, while also noting the scope of those keys and recommending asynchronous server-to-server notifications for missing responses.9 The general design lesson is to give the customer’s financial intent a durable identity and keep it separate from each technical attempt.

That produces a safer recovery sequence. First reconcile an indeterminate attempt. If it is still pending, say so and prevent a fresh payment from masquerading as a retry. If it definitively failed, update the eligibility set using the failure reason. Preserve valid customer input. Explain why the previous choice is no longer available. Then invite a new selection from the remaining candidates.

Do not automatically move a customer from one visible method to another after they have confirmed. The new method may present a different instrument, fee, authentication step or party. Return to a truthful choice point and obtain confirmation for the revised path.

The decision record is the real checkout model

The visible menu can stay simple if the decision behind it is explicit. For each render, retain the intent version, relevant context, candidate methods, exclusion reasons, ordering rationale, displayed totals, selected instrument, authentication state and permitted recovery transitions.

That record makes difficult product questions answerable. Was a method hidden because the merchant did not accept it, because the device could not invoke it, or because the credential was ineligible? Did the total change after selection? Did the customer authorize this purchase only, storage for later use, or a recurring agreement? After a timeout, is the system repeating one attempt or creating another?

Checkout quality is often judged at the menu: the right logos, the right order, the fewest taps. Those details matter, but they are downstream. The real product work begins earlier, where intent is made precise, context is gathered carefully, eligibility is enforced, trust is preserved and failure is given a safe next state. Get those choices right, and the menu becomes smaller, clearer and true.

Sources

1. “Improving Authorization Management for Transactions with Stored Credentials.” Visa. https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/stored-credential-transaction-framework-vbs-10-may-17.pdf (opens in a new tab)
2. “Commission Delegated Regulation (EU) 2018/389.” European Union, EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R0389 (opens in a new tab)
3. “Payment Request API.” World Wide Web Consortium. https://www.w3.org/TR/payment-request/ (opens in a new tab)
4. “Web-based Payment Handler API.” World Wide Web Consortium. https://www.w3.org/TR/web-based-payment-handler/ (opens in a new tab)
5. “EMV® 3-D Secure.” EMVCo. https://www.emvco.com/emv-technologies/3-d-secure/ (opens in a new tab)
6. “EMV® Payment Tokenisation.” EMVCo. https://www.emvco.com/emv-technologies/payment-tokenisation/ (opens in a new tab)
7. “Secure Payment Confirmation.” World Wide Web Consortium. https://www.w3.org/TR/secure-payment-confirmation/ (opens in a new tab)
8. “New Information Supplement: Payment Page Security and Preventing E-Skimming.” PCI Security Standards Council. https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming (opens in a new tab)
9. “API idempotency.” Adyen Docs. https://docs.adyen.com/development-resources/api-idempotency (opens in a new tab)