A saved payment method is not blanket permission to charge later

Separate setup, permission and payment

Source facts: Stripe’s Setup Intents API prepares a payment method for future payments without creating a charge.[2] Setting up a card can involve authenticating the customer or checking its validity with the customer’s bank.[2] Editorial recommendation: keep three questions separate in your operating model: did the customer agree to the intended use, did payment-method setup complete, and did the later payment actually succeed? A saved-method label should not answer all three. For example, a rental business could collect a card before the rental and request payment afterward, but its internal record should still distinguish setup from collection. This guide concerns Stripe, not a PayIn feature, and addresses consent and authentication recovery rather than SCA exemption policy or fraud liability.

Ask what the customer is actually allowing

Source facts: Stripe requires explicit consent for future on-session use, such as displaying a saved payment method at a later checkout.[2] Future off-session use also requires permission; an agreement, sometimes called a mandate, allows charging when the customer is not actively using the website or app.[2] Editorial recommendation: write separate, understandable explanations for customer-present reuse and merchant-initiated future collection. Do not assume that a customer choosing a convenient saved card also agreed to any later merchant charge. Before designing the interface, write down the intended transaction: who starts it, whether the customer will be present, and what purchase or obligation it covers. Use that description to review the consent language, rather than letting an existing checkbox determine the business policy.

Make future-charge terms specific enough to review

Source facts: Stripe says to add payment-processing terms to the website or app and let customers opt in.[2] At a minimum, those terms must address permission to initiate a payment or series of payments, the anticipated frequency, and how the amount will be determined.[2] Editorial recommendation: explain whether collection is one-time or recurring and describe the amount calculation in ordinary language. For a usage-based service, identify what usage will be counted and how the applicable price is selected; these are illustrative drafting questions, not Stripe-approved legal wording. Retain the accepted terms version, acceptance time, customer reference and covered purpose as an internal evidence record. Assign someone to reassess the agreement when the intended charging arrangement changes rather than silently expanding its meaning.

Configure usage to match the intended payment journey

Source facts: the SetupIntent usage parameter tells Stripe how payment details will be used later; the documentation recommends on_session for customer-present payments only and off_session for off-session payments or a mixture of both.[2] If omitted, usage defaults to off_session.[2] Stripe explains that preparing a card for off-session use can introduce authentication during setup and reduce later customer intervention, but usage remains an optimization.[2] Editorial recommendation: set and document the intended value explicitly so reviewers can compare configuration with the accepted terms. Do not present the default as evidence of customer permission. Prepare support messaging for possible setup authentication, and distinguish a technical configuration decision from the separate decision that a particular future charge is covered by the customer’s agreement.

Do not treat permission to charge as permission to redisplay

Source facts: Stripe identifies allow_redisplay on the PaymentMethod object as a way to distinguish methods saved only for offline use from methods that may be presented for future on-session purchases.[2] It separately requires explicit consent for that future on-session use.[2] Editorial recommendation: review saved-method display rules independently from the rules for scheduled collection. A card collected for a later service charge should not automatically become a selectable payment option throughout every checkout experience merely because the system holds its identifier. Maintain a clear mapping between the consent purpose and the experience where the method is shown. The cited overview does not provide a complete implementation specification for allow_redisplay; verify the relevant integration details before choosing field values or claiming a display rule is enforced.

Build a route back to customer authentication

Source facts: Stripe warns that later authentication can still be required regardless of whether a card was set up for on-session or off-session use.[2] When an off-session card payment requires authentication, its instruction is to bring the customer back online to complete the payment.[2] Editorial recommendation: make that return journey an explicit product requirement, not an improvised support exception. Explain which payment needs attention, direct the customer to an authenticated account experience, and let them complete the required payment flow. Do not ask customers to send card details or authentication codes to support. Keep the obligation identifiable throughout recovery and check its current payment state before presenting an action. Record a pending customer action rather than describing a notification, a click or the start of authentication as payment success.

Review the whole consent-to-recovery journey before release

Source facts: Stripe places responsibility for compliance with applicable laws, regulations and network rules on the business saving payment details.[2] Its Setup Intents guidance also calls for an application recovery process because setup cannot eliminate every later authentication request.[2] Editorial recommendation: review a complete scenario with product, engineering and the appropriate legal adviser: inspect the displayed terms, the recorded acceptance, the intended usage setting, permitted redisplay and the customer’s return path. Include a customer who abandons authentication and one whose intended charging arrangement changes. Define an owner for unresolved customer actions and avoid promises of guaranteed collection. These are proposed acceptance checks, not executed payment tests or a legal sufficiency assessment. Source verification date is 2026-09-20; the source does not state a publication date.

Sources and dates

Verified on 2026-09-20. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.

2. Stripe: Setup Intents [2] ↗

   Source date: Not stated · Verified: 2026-09-20