> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/cards/stored-credentials/one-click-payments.md). # One-Click Payments Returning customers pick their saved card and confirm – no typing, no friction, no lost sale at the checkout form. One-click payments let returning customers complete purchases using previously stored payment credentials, without re-entering card details. The customer selects a saved card at checkout, confirms the purchase, completes authentication where required – and is done. In the terms of the Stored Credential Framework, a one-click payment is a subsequent Customer-Initiated Transaction (CIT): the customer is actively present and confirms the payment, but instead of typing card data, the payment references the token created during their first purchase. This distinguishes it from a Merchant-Initiated Transaction, where your systems charge the token without the customer’s participation. The business case is simple: manual card entry is one of the biggest sources of checkout abandonment, especially on mobile. Every field the returning customer does not have to fill in is conversion you keep. ### Capability Summary
CapabilitySupport
Payment MethodsPayment Cards (Visa, Mastercard)
PrerequisiteA successful initial CIT with the customer’s consent to store credentials – see Stored Credentials
Transaction TypeSubsequent Customer-Initiated Transaction (CIT)
How the Card Is ReferencedToken ID returned by the initial payment and stored in your systems
AuthenticationEMV® 3DS where required; exemptions and frictionless flow often apply – the issuer decides
Multiple Saved CardsSupported – one token per stored card, managed against your customer profiles
Integration OptionsHosted Checkout, Merchant API
Sandbox TestingAvailable
Availability depends on your merchant agreement, enabled services, and acquiring configuration. ### How It Works 1. The card is saved once. During a regular purchase, the customer opts in to saving their card (see Customer-Initiated Transactions). The payment response returns a token ID – store it against the customer’s profile, together with the card display details available from the payment information (such as the card brand and masked number), so the customer can later recognize the saved card. 2. You present the saved card at checkout. When the customer returns and signs in, your checkout offers their saved card(s) – clearly labeled, with the option to pay with a different card instead. 3. The customer confirms; you reference the token. You initiate the payment referencing the stored token ID instead of card data – via Hosted Checkout or the Merchant API. 4. Authentication where required. Where required, the customer completes EMV® 3DS – many one-click payments proceed through the frictionless flow, based on the issuer’s risk assessment and applicable SCA exemptions. 5. Authorization and confirmation. The payment proceeds through the standard authorization flow; you receive the result in the response and via callback notifications, and fulfil on the confirmed paid status. {% hint style="warning" %} One-click still means one click. The customer must actively confirm each payment – a charge triggered without the customer’s action is a Merchant-Initiated Transaction and must be processed as one. Do not process MITs as one-click payments, or vice versa. {% endhint %} ### Designing the Experience * Opt-in, not opt-out. Saving the card is the customer’s active choice at the first purchase – for example, an unticked “Save my card for faster checkout” checkbox. Never store credentials silently. * Label saved cards clearly. Show the card brand and masked number (“Visa •••• 4242”) so the customer knows exactly what they are paying with. A customer can have several saved cards – let them choose. * Make the amount unmissable. Display the amount prominently next to the confirmation – speed should never feel like a charge the customer did not see coming. * Let customers manage their cards. Give customers a way to view and delete their saved cards. When a customer deletes a card, remove the token reference from their profile and stop using it. * Always offer a fallback. Keep full card entry available – for new cards, expired tokens, or customers who prefer not to save. ### When Saved Cards Change Saved cards live on the token lifecycle described under Tokenization: * Where network tokenization is enabled, reissued or renewed cards are updated automatically – the saved card keeps working and your token reference stays valid. * If a token is suspended or deactivated, one-click payments with it are declined. Process token status notifications, hide the affected card from the customer’s saved methods, and prompt them to add a card again through a regular payment. ### One-Click Beyond Gateway Tokens * Digital wallets. Apple Pay, Google Pay, and Click to Pay deliver their own fast-checkout experience – the “saved card” lives in the wallet, not in your systems. Offer them alongside one-click for maximum coverage. * Pay by Bank. Pay by Bank supports its own one-click model based on a stored bank and account reference – see [One-Click Payments with Pay by Bank](/payment-methods/pay-by-bank/payment-processing.md). ### Testing Before requesting Production activation, verify in the Sandbox environment: * The initial CIT with the consent step, token creation, and storage of the token ID and card display details. * A one-click payment with the stored token, including frictionless and challenge 3DS scenarios. * Payment with a second saved card, and switching to full card entry. * A declined one-click payment, including with a suspended or deactivated token – the customer must get a clear message and a retry path. * Deleting a saved card – the token reference must no longer be offered or used. ### Frequently Asked Questions #### Is a one-click payment the same as a recurring payment? No. A one-click payment is customer-initiated: the customer is present and confirms each purchase. A recurring payment is merchant-initiated: your systems trigger the charge without the customer. Both use the same stored token, but they follow different rules – see Merchant-Initiated Transactions (MIT). #### Does the customer skip 3-D Secure with one-click? Often, but not always. Subsequent CITs may qualify for SCA exemptions and frequently complete through the frictionless flow – but the issuer makes the final decision and may require a challenge. The gateway handles this automatically. #### Can a customer save more than one card? Yes. Each saved card is a separate token; store the token IDs against the customer profile and let the customer choose at checkout. #### What happens if the saved card expired or was replaced? With network tokenization, card reissuance and expiry updates are applied to the token automatically, and the saved card keeps working. If a token is deactivated, payments with it are declined – you receive a token status notification and should ask the customer to add a card again. #### Do I need the customer’s consent again for each one-click payment? The consent to store the credentials is given once, during the initial CIT. Each one-click payment is then confirmed by the customer at checkout – that confirmation is the authorization for that specific purchase. ### Related Documentation * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [Customer-Initiated Transactions](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) (CIT) * [Merchant-Initiated Transactions](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) (MIT) * [Tokenization](/payment-methods/cards/tokenization.md) * [EMV® 3-D Secure](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS) * [One-Click Payments with Pay by Bank](/payment-methods/pay-by-bank/payment-processing.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/payment-methods/cards/stored-credentials/one-click-payments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.