An off-session charge needs the customer to return

Classify the recorded failure before choosing a retry

Off-session describes an attempt made when the customer is not actively in the payment flow. It does not mean every failed saved-card payment has the same cause. Find the payment reference associated with the order or invoice, the time of the failed attempt, its recorded error and its latest state. Keep the provider's wording separate from a store message that merely says payment failed.

Stripe's card-decline guidance documents authentication_required for some off-session failures. It also distinguishes advice such as do_not_try_again, try_again_later and confirm_card_data. Those messages cannot be collapsed into a generic instruction to retry. An authentication requirement points to customer participation; a different error needs its own documented response. If the error or next action is absent, record that gap instead of diagnosing authentication from the fact that the card was saved.

If the cardholder wants the issuer's specific explanation for a decline, Stripe says issuers discuss those details with the cardholder. Support can explain the recorded payment outcome and the store's next step without claiming to know the bank's private reasoning.

Check permission and the unpaid obligation separately

Stripe's save-and-reuse guidance distinguishes saving payment details from charging them. A successful setup does not show that the current order was paid. It also limits future use to the purpose agreed with the customer. Locate the retained consent record rather than assuming that a stored credential authorizes every later order or every recovery attempt.

For offline charges, Stripe describes terms covering initiation of the payment, anticipated timing or frequency, how the amount is determined and cancellation for a subscription. Compare the intended charge with the actual agreed scope. If that record is missing or does not cover the use, stop treating the stored method as sufficient authorization and resolve the appropriate payment arrangement with the customer through the supported flow.

Separately compare the existing order or invoice amount and currency with its payment history. Check whether a later payment already satisfied it, whether an adjustment changed what is due, and whether another attempt remains unresolved. A historical failure is not enough to establish that the full amount is still collectible today. Do not create a second obligation just to get a fresh payment screen.

Choose a supported route where the customer can act

Have the integration owner identify the documented customer-present recovery path for the checkout and payment product actually installed. It should let the customer review the existing obligation, complete the supported payment flow and perform any authentication themselves. Record whether that flow continues the existing payment or creates a replacement, and how its result remains connected to the original order. Do not assume every gateway exposes the same recovery screen or reuses the same payment object.

Before inviting the customer back, assign one owner to coordinate the recovery with any automatic retry process affecting that obligation. Confirm the current payment state and the intended next action through authorized controls so an unattended attempt is not inadvertently competing with the customer-present attempt. This is a coordination requirement, not an instruction to disable an account-wide control or bypass authentication.

Customer communication should identify the order through the store's established channel, say that the payment needs attention and direct the customer to the verified recovery route. Keep one-time codes, bank passwords, card numbers and private payment-link tokens out of support notes and this worksheet. Staff cannot complete the customer's bank challenge by receiving a code over chat. A return to the store or completion of a challenge still needs a matching provider payment result before the order is marked paid.

Close the handoff with the payment result

After the customer acts, reconcile the resulting provider reference and status to the original order and amount. Record whether payment completed, another action remains or a different failure now applies. If a new reference was created, keep the association with the earlier failed attempt so a later support agent does not interpret the old failure as a fresh instruction to collect again. Do not promise that returning guarantees approval.

For a Prism checkout-review consultation, describe the website, research-only products, platform and the authentication-related recovery question. Keep the private timeline and consent record internal; the public form is not their upload channel. Scope, responsibilities, fees and terms are established before work. Follow-up is by email, and an inquiry does not book an appointment, purchase implementation or submit a processing application. The provider remains responsible for eligibility and account terms.

Customer-return requirement

Use this for one real unpaid obligation and its existing failed payment. An authentication requirement selects a customer-present investigation; it does not itself authorize collection. Resolve permission, current amount and overlapping attempts before sending a recovery instruction. Store only internal references and non-sensitive summaries.

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.

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.