A stored card can support two different payment flows: a customer selects it during checkout, or a merchant initiates a later charge under an agreed arrangement. The difference affects the consent a business collects, the information it sends to its payment provider and how it handles a request for authentication.
A token makes payment details reusable within the provider’s system. It does not, by itself, establish permission to charge a customer for any purpose. Stripe and Adyen describe separate setup and subsequent-payment steps in their documentation, checked October 31, 2026.
Start with the agreed future use
A customer may save a card for a later purchase they initiate, authorize a recurring subscription, or agree to a charge whose timing or amount depends on a later event. Those are different arrangements. The checkout and the payment records should make the agreed use clear before the merchant relies on the stored method.
Stripe’s save-and-reuse guide says businesses should obtain consent for the specific intended use. For offline charges, its guidance calls for terms covering the customer’s agreement, expected timing and frequency, how the amount is determined, and the cancellation policy for a subscription. Stripe also says to retain the customer’s written agreement.
A stored payment identifier and a record of that agreement serve different jobs. The identifier points the integration to a payment method; the agreement records what the customer authorized. Neither guarantees that a later payment will be approved.
Customer-initiated versus merchant-initiated
In a customer-initiated payment, the customer returns to the checkout and chooses a saved method. Adyen calls its one-click flow CardOnFile: the shopper selects previously stored details to make a purchase.
In a merchant-initiated flow, the business triggers the later transaction under the customer’s arrangement. Adyen distinguishes a Subscription, where the business bills at regular intervals, from UnscheduledCardOnFile, used for non-fixed timing such as an automatic top-up. A subscription and a threshold-based top-up may both use stored credentials, but they should not be described as the same billing schedule.
The customer’s absence from checkout is a practical distinction, not a reason to assume every attempted charge qualifies for an authentication exemption. Eligibility depends on the relevant rules, payment method and transaction context. Design a path for cases where the customer must return to authenticate or provide another method.
What Stripe and Adyen store and send
Stripe’s SetupIntent can prepare a payment method for future use without taking an initial payment. It tracks the setup flow and can trigger additional authentication when required. Stripe’s documentation distinguishes preparing a payment method from the later payment itself; a successful setup is not a successful future charge.
Adyen’s online tokenization flow sends a token-lifecycle webhook when payment details are tokenized. For a later subscription or unscheduled card-on-file payment, its documented /payments request includes the stored payment method ID, the same shopper reference used when the token was created, shopperInteraction: ContAuth, and the appropriate recurringProcessingModel. Adyen also documents an AUTHORISATION webhook for the outcome.
These are provider-specific fields, not interchangeable names for a universal API. Before implementation, check the current provider documentation, account permissions and payment-method support. Keep credentials and raw card data out of application logs; tokenization changes the flow but does not by itself settle the full scope of a business’s security obligations.
Handle a later payment as its own event
The merchant should connect the attempted charge to the customer, the stored method and the arrangement that authorized it. Record the intended amount and reason in the business system, then reconcile the provider’s response and relevant events with the payment record.
A network timeout or repeated webhook is not proof that a second charge is needed. Use the provider’s idempotency and event-handling guidance for the integration, and check the existing payment state before retrying. Our guides to idempotency keys and webhook retries explain those separate controls.
If authentication is required or the payment is declined, bring the customer back through the provider’s supported recovery flow. Do not silently treat an unsuccessful attempt as settled. Customers also need a way to update their payment method or cancel an ongoing arrangement under the terms provided to them.
