Start with the actual checkout integration and Session mode, then identify the existing provider Customer passed to that Session. In the Stripe reference checked for API version 2026-08-26.preview, the create-Session customer parameter describes most-recently-saved-card prefill in payment mode, and default-card prefill in subscription mode, with a most-recent-card fallback if the default is not a card. Valid billing address, name and email on the payment method are required for card-detail prefill. Compare those conditions with the observed choice before changing a default; this rule is not a promise about every checkout or every saved method.
For: A research-only merchant investigating a returning buyer’s report that checkout shows a different card from the one expected as default.
Locate the screen and setting behind the word default
Record where the buyer expected a default: a store account page, a provider record or the checkout itself. Preserve the wording of the setting and the time it was observed. A store preference and a provider setting may be separate records; the shared label does not establish that the checkout reads either one.
Identify whether the flow actually uses Stripe Checkout Sessions and record the relevant integration, connector version and configured API version. A page displaying Stripe branding is not enough to apply a particular API parameter’s behavior. If the flow uses another API or provider, investigate its own documented selection rule instead.
Keep the initial choice distinct from a method the buyer selected later and from a method used for a completed payment. The question here is which choice appeared before payment. A charge record alone cannot reconstruct every option the buyer saw or the initial prefill.
Compare the Session mode with the documented card rule
The Stripe API reference checked on September 29, 2026, at the URL carrying version 2026-08-26.preview describes the customer parameter when creating a Session with an existing Customer. In payment mode, the most recently saved card payment method is used to prefill the checkout details. The paragraph does not say that the Customer’s default must take priority in this mode.
For subscription mode, that same parameter description says the Customer’s default payment method is used if it is a card; otherwise the most recently saved card is used. The choice therefore depends on both mode and the type of the default. Do not apply the subscription rule merely because the buyer has bought before, or treat a most-recently-saved rule as a most-recently-used rule.
These observations are bounded to the cited version and existing Customer parameter. They do not establish every saved-method display rule, a connector’s mapping or identical behavior in the version your site runs. Record the actual version and have its applicable documentation checked before turning this comparison into a configuration change. Do not switch API versions or payment modes just to make the chosen card resemble an expectation.
Check the Customer association and prefill prerequisites
Inspect the Customer reference actually supplied when the Session was created, through authorized provider or integration records. Compare it with the Customer record on which the expected default was observed. If those references differ, the default being inspected is not yet evidence about the Customer used by that checkout. If the reference is absent or unknown, the existing-Customer rule does not settle the report.
The cited parameter description requires a valid billing address, billing name and billing email on the payment method for Checkout to prefill card details. Record whether those prerequisites were met at the relevant time, without copying the personal values into a worksheet. Missing prerequisites mean the documented conditions for that prefill were not met; they do not, by themselves, explain which alternative option appeared.
Likewise, today’s saved-card list may differ from the list at Session creation. Use available dated records to distinguish what is known about the original attempt from what is visible now. A provider record that was edited later should not be presented as proof of the earlier checkout state. Do not alter a live customer record, detach a method or ask for another purchase simply to investigate this discrepancy.
Decide which question the evidence leaves open
When the existing Customer matches, the relevant version confirms the rule and payment mode shows the most recently saved eligible card with the documented prerequisites, investigate whether the original expectation incorrectly assumed a default-card rule. In subscription mode, compare the recorded default’s type and the stated fallback. If a required field is missing, investigate prefill completeness. If the documented conditions all appear to be met but the display differs, preserve the unresolved discrepancy for the integration owner.
When only the store’s saved choices differ, ask which store record the connector maps to the Customer and which documented rule controls its visible options. Do not conclude that every method saved with the provider must be shown. A prefill rule is narrower than a complete specification of availability, display order or the method eventually charged.
For a Prism checkout consultation, summarize the observed difference, the named integration and which comparison remains unresolved. Agree scope, responsibilities, fees and terms before work. Keep private references in authorized technical records; the public inquiry needs the website and problem summary. A working saved-card flow does not establish approval to process the research-only business.
Saved-choice scope comparison
Complete this for one genuine reported checkout using dated, authorized records. Use internal aliases rather than card data or private checkout URLs. A matching row supports one part of the comparison; it does not prove the whole cause. Mark unavailable historical state unknown.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Saved-choice scope comparison. The last column is for temporary notes.
Comparison item
Evidence to examine
How the result directs investigation
Your finding
Provider default scope
Evidence to examineExact setting label, Customer association, default method type and observation time.
How the result directs investigationEstablish which record contains the expected default before comparing it with a Session.
Store saved choices
Evidence to examineWhat the signed-in store user could actually see and the connector’s documented mapping.
How the result directs investigationA store preference does not establish that the provider Session reads the same preference.
Checkout integration
Evidence to examineCheckout API or product, connector and version, and configured API version.
How the result directs investigationUse the cited prefill rule only after confirming the relevant integration and version.
Session mode
Evidence to examineThe actual mode on the reported Session.
How the result directs investigationPayment and subscription modes use different card-selection rules in the cited reference; do not infer mode from repeat purchasing.
Existing Customer supplied
Evidence to examineAuthorized comparison of the Session creation Customer with the record holding the expected default.
How the result directs investigationA different, absent or unknown Customer association needs resolution before a default comparison.
Card and billing prerequisites
Evidence to examineMethod type, most-recently-saved association and whether required billing address, name and email were valid at that time.
How the result directs investigationRecord presence and validity without copying values; missing prerequisites leave prefill unestablished.
Actual selected method
Evidence to examineInitial checkout observation, any later buyer selection and any completed payment record, kept separate.
How the result directs investigationDo not use the eventual charge as proof of the initial choice or of all choices displayed.
Next owner question
Evidence to examineThe specific unresolved mode, mapping, version, prerequisite or display discrepancy.
How the result directs investigationAsk the integration owner to explain the named gap from the original records before authorizing changes.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
The prefill behavior cited is scoped to the existing Customer parameter in the captured 2026-08-26.preview reference; it is not stable-version verification or a universal rule for Stripe integrations.
Prefill does not establish which methods are all available, whether a payment succeeded or whether the merchant is eligible.
Do not collect card numbers, security codes, authentication codes, API secrets or private payment-link tokens in the worksheet or consultation form.
Checkout Session status and existing Customer prefill in captured API reference — checked 2026-09-29. In the captured create-Session customer parameter, payment mode uses the existing Customer’s most recently saved card; subscription mode uses its default if it is a card, otherwise its most recent saved card. Valid billing address, name and email on the payment method are prerequisites for card-detail prefill. These observations are specific to the captured reference and parameter, not all connectors, versions or saved-method display rules.