Payment controls and records

Allowing a payment did not automatically retry it

A permitted allow-list change affects how later matching attempts are evaluated under the relevant merchant-configurable rules; it does not retry the existing payment. Stripe documents that distinction explicitly. Record the rule change separately from the original attempt, then inspect the current payment history for any genuine later action. Before an approved retry, establish whether the original payment remains failed and follow the recorded decline advice. A rule change is neither issuer authorization nor confirmation that money was collected.

For: A research-only merchant who changed a permitted payment risk control and expected an earlier failed attempt to complete.

Updated 2026-10-01

Get help with checkout

Separate the configuration event from the payment event

Preserve the original payment reference, outcome and time. Then record the time, scope and authorized owner of the allow-list change. Those are two different events. Stripe’s declines guidance says allow-listing does not retry a payment. It must not be recorded as a successful retry simply because the administration screen confirmed the change.

Where the account exposes a merchant-configurable allow-list action, its relevance is to later matching attempts under the applicable rules. Do not extend that into a promise that all controls are bypassed or that an issuer will approve the next request. The earlier attempt’s outcome remains part of the history.

If the store appears to have retried after the edit, find the corresponding payment action and result. It could be a separate event in the integration’s actual history; proximity in time does not establish that the allow-list edit itself created it. If no later attempt is recorded, describe the evidence as a configuration change with no recorded retry.

Identify which failure the change could address

Stripe separates issuer declines, blocked payments and invalid API calls. A blocked payment did not obtain issuer authorization. An issuer decline is the issuer’s refusal, and an invalid API request is a different integration problem. Stripe says invalid API calls typically do not appear as payments in the Dashboard, so the absence of a payment there is not proof that checkout sent a valid request.

Read the original outcome rather than relying on the store’s generic failure message. If the record identifies a merchant rule as the issue, an authorized rule review can address that rule’s future decisions. If it identifies an issuer decline or invalid request, a list edit does not by itself resolve that distinct failure. Keep the recorded outcome separate from your theory about why it happened.

An allow-list entry also does not settle whether the payment provider permits the research-only business or a particular payment arrangement. Merchant risk settings, issuer authorization and account eligibility remain separate. Do not change the business description, hide products or alter transaction presentation to get around a restriction.

Reconcile current state before deciding on another attempt

Reopen the provider history for the affected order before anyone takes another payment action. Check for a later successful payment, an authorization, a processing state or a separate unresolved attempt. The original failure screen does not establish the current state of every attempt attached to the order. Keep any later result linked to its own time and reference.

If the records do not establish whether the order already has a successful or outstanding payment, leave the next payment action undecided. Resolve that missing state first. A retry log is useful because it separates the operator’s intention from the provider’s observed result; a note saying allowed does not fill either column.

Use the recorded advice for the actual decline. In Stripe’s card-decline guidance, do_not_try_again means the same card should not be retried for that transaction; try_again_later allows a later attempt, and confirm_card_data calls for the customer to correct information. None means that a merchant should copy card details into a support note or edit them on the customer’s behalf. Issuers discuss detailed decline reasons with their cardholders.

Record a decision and the result it actually produced

The account owner should record whether the next step is to stop, obtain the missing payment state, have the customer follow the documented advice, or authorize a supported retry. Permission to change a risk rule is not automatically permission to charge again. Follow the account’s documented process and the customer authorization applicable to the payment.

Where a retry is permitted and genuinely performed, record its time, payment reference and outcome separately. Do not erase the original decline, assume success from the absence of an error, or repeatedly submit until something works. The retry’s own result determines whether a new issuer or provider decision needs attention.

For a Prism checkout-review consultation, describe the website, products, original outcome, risk-setting change and unresolved payment-state question in ordinary language. Prism can discuss storefront and provider website questions; diagnostic access, implementation and follow-up responsibilities need an agreed scope. Scope, fees and terms precede work. The public request receives email follow-up and does not purchase a service or submit a processing application.

Risk-change versus payment-action log

Use this for one real failed attempt and the authorized change that followed it. Keep configuration and payment timestamps separate. A completed rule-change row cannot close a missing payment-result row. Maintain private payment references internally and put only a nonsensitive summary in an inquiry.

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.

Risk-change versus payment-action log. The last column is for temporary notes.
Event or decision	Evidence to record	What that evidence establishes	Your entry
Original payment outcome	Original attempt time and reference, outcome type, error and advice code where present.	Whether the documented failure was blocked, issuer-declined or an invalid request.	Original payment outcome: Your entry
Authorized rule change	Change time, specific merchant-configurable rule or list scope, reason and authorized operator.	A future decision-rule change; it does not establish a new payment attempt.	Authorized rule change: Your entry
Current payment state	Current provider history for all payment attempts already associated with the order.	Whether a successful, authorized or still-processing payment requires reconciliation before another action.	Current payment state: Your entry
Applicable retry advice	The advice actually returned for this decline and the relevant provider instructions.	Whether to stop, wait or have the customer correct information; an allow-list entry does not override the advice.	Applicable retry advice: Your entry
Recorded retry if any	A genuine later payment action, its time, reference and returned outcome.	What was attempted and what happened; leave absent actions unclaimed.	Recorded retry if any: Your entry
Account owner decision	Named owner, authorized next action and any unresolved state preventing it.	Who decides whether a supported payment action may proceed, separately from the earlier list change.	Account owner decision: Your entry

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 documented allow-list and decline behavior is Stripe-specific. It does not establish equivalent controls in another provider or plugin.
An allow-list change does not establish issuer approval, provider eligibility, successful collection or permission to retry a do_not_try_again outcome.
Do not include card numbers, security codes, authentication codes, payment-link tokens, API secrets or customer records in the worksheet or consultation form.

Related guides

Sources

Stripe declines — checked 2026-09-21. Stripe distinguishes issuer declines, blocked payments and invalid API calls. A block does not obtain issuer authorization; allow-listing does not retry the payment, and invalid API calls typically do not appear in the Dashboard.
Stripe card declines — checked 2026-09-21. Advice codes do_not_try_again, try_again_later and confirm_card_data require different next steps. Issuers disclose detailed decline reasons to cardholders; retry permission cannot be inferred from a risk-list change.
Prism solutions — checked 2026-09-21. Public support includes storefront review, processing preparation and help with provider website questions. Scope, fees and terms are discussed before work; eligibility and account terms remain provider decisions.
Prism contact — checked 2026-09-21. The form requests the website, products and question without card details, passwords or customer records. Email follow-up does not book an appointment, purchase work or submit a processing application.

Get help with checkout

Is this happening on your own store?

Get help with checkout All resources