Find what failed when a returning buyer selected a saved card
First establish whether the buyer could select the saved method on the intended account and whether the failed payment actually used that method. Then read the provider's failure and advice codes. A card that expired or was replaced is one possible explanation, but prior success followed by failure does not prove a broken stored credential. Stripe also documents authentication_required for some off-session failures, and the issuer can decline a payment independently of how the card was entered. Use existing authorized records to distinguish a method-selection problem, required customer authentication and an issuer decision before choosing who must act.
For: A research-only merchant or support lead investigating an existing saved-card failure through the WooCommerce Stripe extension.
Confirm the saved option was available and selected
The WooCommerce Stripe extension documents saving payment methods to customer accounts and presenting stored options at checkout. Begin by establishing whether the returning buyer was using the intended store account and whether the expected saved option appeared. A missing option is a different symptom from a selected option that produced a declined payment.
Compare the real order or payment record with the buyer's report of the selection. Record only whether the references match in the authorized systems. Do not infer that the default method was used merely because it is listed on the account. If the selected method cannot be established, preserve that uncertainty before assigning a failure to the stored card.
Also identify the integration involved in the earlier success and the later failure. A method displayed by one checkout integration does not, by its presence alone, prove that another integration used it for the failed attempt. If the store recently changed its payment setup, the maintainer needs that dated change alongside the records. It is evidence to investigate, not a proven cause.
A changed card and an authentication request need different responses
Ask whether the card expired or was replaced since it was saved, without requesting its number or security code. If the provider's existing record exposes relevant expiry information, compare it within authorized access and record only the finding. A reported replacement or an old displayed expiry is a clue; neither establishes the state of the stored credential or the reason for this particular failure without the payment result.
Read the decline and advice codes on the failed payment. Stripe documents authentication_required for some off-session failures. Off-session means the customer was not actively participating in that payment flow. A buyer actively choosing a saved card at checkout is a different context, so record what actually happened rather than labeling every saved-card attempt off-session.
Stripe's 3D Secure documentation describes an additional issuer-controlled authentication step. A need for that step is not established by the phrase saved card failed, and entering the card again does not by itself prove that the issuer's requirement has been met. When the result names required authentication, the next issue is the supported customer authentication path for that integration. The cardholder completes any issuer challenge privately; support must not collect the code.
Use the decline result and existing comparisons
A plain issuer decline remains possible even when the method was saved correctly and previously succeeded. Stripe says issuers discuss decline specifics only with their cardholders. Record the reason the provider actually supplied, including when it is generic. Do not turn a generic result into an expired-card or invalid-token diagnosis.
Advice codes distinguish different next steps. Stripe's do_not_try_again instruction rules out using that card again for the same transaction; confirm_card_data points to information the customer needs to correct, while try_again_later has a different meaning. These codes do not authorize a diagnostic sequence. Follow the applicable provider guidance for the real payment rather than repeatedly submitting the stored method until something changes.
Compare only other authorized attempts that already exist. If the records contain both an off-session failure and an on-session result, note whether the failure code specifically supports an authentication explanation. If a newly entered method later succeeded for that customer, it shows that particular attempt succeeded. It does not prove the old credential was invalid: the method, participation, time or issuer decision may differ. If there is no such comparison, write not observed instead of creating another charge.
Assign the next action from the evidence
The store or integration maintainer owns an unresolved missing-option or method-association question. The customer owns confirmation of a card replacement, correction through the legitimate payment interface when instructed, and completion of any supported issuer authentication. The issuer is the appropriate contact for a decline explanation available only to the cardholder. The payment provider can clarify an ambiguous result in its own record.
Write the handoff as a finding with a limit: saved option absent; selected method not established; authentication explicitly required; data correction advised; issuer decline with no specific reason; or integration error still unexplained. Include the existing attempt's time and a redacted result. Do not erase the failed-method evidence or delete saved options merely to make the account screen look clean.
If the pattern needs a Prism checkout-review consultation, describe which saved-card step failed, the platform and the result category. Scope, responsibilities, fees and terms are agreed before work. Keep private payment references, customer account details and credentials in authorized systems. A consultation cannot decide an issuer response or establish provider eligibility for the business.
Saved-card failure map
Complete this from existing authorized records and the customer's non-sensitive report. Record findings rather than card details or payment-method tokens. Each row narrows who should act; no row calls for a new diagnostic payment. Mark unavailable comparisons not observed.
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-card failure map. The last column is for temporary notes.
Evidence
What to compare
Interpretation and next owner
Your finding
Saved method present
What to compareWhether the intended account offered the expected stored method at the reported checkout.
Interpretation and next ownerAn absent option is a store/account or integration question before it is a payment-decline question.
Method actually selected
What to compareThe buyer's report against the order or payment association in authorized records; note the integration used.
Interpretation and next ownerA listed default does not establish the method on the failed attempt. Unmatched records stay with the integration owner.
Expiry or replacement reported
What to compareWhether the customer reports a card change and whether authorized provider records contain relevant expiry evidence; record only the conclusion.
Interpretation and next ownerTreat a changed card as a possibility to compare with the failure code, not proof of an invalid stored credential.
Authentication result
What to compareThe actual failure code and any recorded authentication requirement or outcome.
Interpretation and next ownerauthentication_required supports an authentication question; an unspecified failure does not.
Issuer decline and advice
What to compareThe provider's decline reason and advice code, including generic or absent results.
Interpretation and next ownerFollow the actual advice. The issuer discusses private decline specifics with the cardholder.
On-session or off-session context
What to compareWhether the buyer was participating during each existing attempt and whether the reported failure occurred only off-session.
Interpretation and next ownerAn existing difference can support further authentication investigation; saved-card use alone does not establish off-session use.
Existing newly entered method result
What to compareAny already-authorized later attempt and its recorded outcome, or not observed.
Interpretation and next ownerSuccess on a different attempt does not prove why the original one failed. Do not create a comparison charge.
Next action and owner
What to compareThe narrow supported finding, missing evidence and customer, maintainer, provider or issuer responsible for the next step.
Interpretation and next ownerChoose the owner from the failure category before asking for re-entry, deletion or another payment.
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
Saved-method presentation described here belongs to the WooCommerce Stripe extension. Another integration needs its own documentation and records.
No new diagnostic charges or repeated retries are part of this comparison. A previous success does not guarantee later authorization, and a later failure does not prove a bad token.
Never collect full card numbers, security codes, authentication codes, passwords or payment-method tokens in worksheets or the public form.
https://woocommerce.com/document/stripe/customer-experience/checkout — checked 2026-09-29. The Stripe extension allows customers to save payment methods to their accounts and presents stored options at checkout. This does not establish which method an unseen failed payment used.
Stripe card declines — checked 2026-09-21. Documents authentication_required for some off-session failures, distinct next steps for do_not_try_again, try_again_later and confirm_card_data, and that issuers discuss decline specifics only with cardholders.
3D Secure authentication — checked 2026-09-21. 3D Secure adds a cardholder-authentication step that the issuer can require; the issuer controls the final flow. A saved-method failure alone does not establish that authentication caused it.