Payment controls and records

Let the decline advice decide whether another attempt is allowed

Treat do_not_try_again as a stop instruction for that card on the same transaction. It is not a temporary failure to retry after a delay. Stripe distinguishes it from try_again_later, which permits a later attempt, and confirm_card_data, which calls for the customer to correct submitted information. Match the advice to the actual payment attempt, stop conflicting automatic or manual retries, and give the customer only the next step the evidence supports. The issuer's private reason is not something the merchant can infer from the code.

For: A research-only merchant whose support team or checkout automation is about to retry a declined card payment.

Updated 2026-10-01

Read the advice on the attempt you are handling

Locate the actual provider payment reference, the attempt time, and the advice code. Keep the advice code separate from a general decline message and from the store's order label. The next-action instruction may be more useful than the sentence the customer saw, but only if it belongs to the same attempt.

An order can have more than one attempt in its records. Preserve which advice came from which attempt so a later support agent does not apply an older instruction to a different result. If the record does not show an advice code, mark it unavailable. An absent code is not evidence of permission to keep trying; obtain the applicable guidance for the recorded outcome before choosing a retry.

The code names here are Stripe's documented advice codes. If another provider supplies the payment, use that provider's definition and instructions. Similar-looking words do not establish identical retry rules.

Give each code its own action

do_not_try_again means do not reuse the card for the same transaction. Stop any scheduled retries for that attempt and tell staff not to submit it manually. The customer may need to speak with the issuer. Waiting overnight does not turn this instruction into try_again_later, and changing the order reference is not a basis to bypass it.

try_again_later permits a later attempt. It does not say the next attempt will succeed, explain the bank's internal decision, or supply a universal waiting interval. Use any applicable provider or network instruction to set the permitted timing and record who owns that decision. Do not interpret later as an immediate loop.

confirm_card_data calls for the customer to correct the submitted information. Direct the customer to the approved payment-entry path to make the correction. Do not ask support to collect the card number or security code in email or chat, and do not keep submitting unchanged information while waiting for a reply.

Make manual support and automation follow the same instruction

Identify every place that can initiate another attempt for the affected transaction: the installed payment workflow, a scheduled recovery action, or a staff member acting from an order screen. Ask the implementation owner to establish which of those paths is active. A support note that says stop is insufficient if a queued action still submits the payment.

Stripe recommends no more than eight retries where retries are permitted and warns that further retries may be treated as fraud by issuers. This recommendation is neither a target nor permission to attempt a payment eight times. A do_not_try_again instruction takes the retry question off that path entirely; another applicable restriction can also be more limiting.

Record the stop or correction action separately from the payment outcome. Canceling a planned retry does not make the order paid. Correcting the checkout's handling of an advice code also does not change a past issuer decision. The completion evidence for this operational task is that the team and active retry path now follow the documented advice.

Explain the next step without inventing the reason

Tell the customer whether the same-card attempt must stop, a later attempt is permitted, or information needs correcting through checkout. Keep the explanation tied to what was returned. Do not translate a generic decline into a claim about insufficient funds, suspected fraud, a closed account, or the customer's intentions.

Stripe says issuers discuss decline specifics only with their cardholders. A customer contacting the issuer is therefore a way for the customer to obtain an explanation, not a promise that support can obtain it or that the bank will reverse the decision.

For a Prism checkout consultation, summarize the observed retry behavior, the platform, the website, and the research-only products. Keep actual customer records and card details out of the public form. Ask for the scope needed to examine the mismatch between advice and checkout behavior; responsibilities, fees, and terms are agreed before work. An inquiry is not a booked appointment, a purchased repair, or a processing application.

Decline-advice action table

Use this for one real payment attempt. Enter its reference and actual code, then complete only the action row that matches. A blank or unfamiliar code remains unresolved; it does not default to a permitted retry. Keep customer identity and card data out of the worksheet.

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.

Decline-advice action table. The last column is for temporary notes.
ControlEvidence or instructionAction to recordYour entry
Payment referenceProvider reference and time for the declined attempt, matched internally to the order.Identify this attempt without copying the customer's card details or private payment link.
Advice codeThe exact code shown for this attempt, distinct from the decline message.Record the provider and code; mark unavailable when no advice is shown.
do_not_try_again actionStripe instructs against using the card again for the same transaction.Stop queued and manual retries for this transaction; record the responsible owner.
try_again_later actionStripe permits a later attempt; this label alone supplies no universal interval.Record the applicable timing instruction and who may initiate the permitted attempt.
confirm_card_data actionStripe calls for correction of submitted information.Record the approved customer-entry path and whether correction is still outstanding; do not enter the corrected card data here.
Customer communicationThe documented next action and only the reason actually disclosed.Record whether the customer needs to contact the issuer, return later, or correct information.
Retry owner and active pathsThe person responsible and any active automatic or manual route for the transaction.Confirm that each route follows the advice; retain the reference to the setting or operational action checked.

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 three code definitions and retry recommendation are Stripe-specific; another provider needs its own documentation.
  • No number of unused retries overrides do_not_try_again, and no waiting interval or successful result is promised here.
  • Do not collect card numbers, security codes, authentication codes, private payment links, passwords, or customer records in this worksheet or the public inquiry.

Sources

  • Stripe card declines — checked 2026-09-21. do_not_try_again stops reuse of the card for the same transaction; try_again_later permits a later attempt; confirm_card_data calls for correction. Issuers discuss specifics only with cardholders. Stripe recommends at most eight retries where permitted and warns that more may be treated as fraud.
  • Prism solutions — checked 2026-09-21. Prism offers storefront review, card-processing preparation, and help with a provider's website questions. Scope, fees, and terms are discussed before work; the provider decides eligibility and account terms.
  • Prism contact — checked 2026-09-21. The form asks for the website, products, and question, excludes payment card details, passwords, and customer records, and leads to email follow-up. A request does not book an appointment, purchase a service, or submit a processing application.

Get help with checkout

Is this happening on your own store?