Review a pattern of blocked customer payments

Count confirmed blocks separately from other failures

Stripe's declines documentation distinguishes issuer declines, blocked payments and invalid API calls. A blocked payment was stopped by Stripe Radar or another Stripe block before issuer authorization. An issuer decline is a different outcome; an invalid API call is an integration request problem and typically does not appear as a payment in the Dashboard.

Use the payment detail record available through the authorized Dashboard or API to classify each attempt. Record the exact outcome, any message and the provider identifier. Keep an attempt with no matching provider record in an unresolved group. A generic checkout error or a store's failed-order label is not enough to add it to the confirmed-block group.

Do not send every affected buyer to their bank merely because the store calls the event a decline. If the documented block happened before issuer authorization, the first investigation is the recorded control and integration path. Where the record instead establishes an issuer decline, follow the provider's advice for that attempt; Stripe says issuers discuss decline specifics with their cardholders.

Build a pattern from attempts, orders and a defined time window

Choose the start and end of the review window and preserve the time zone on each source. List each confirmed blocked attempt and the associated store order, amount, currency, payment method and checkout route where those facts are available. Identify repeated attempts on the same order instead of reporting them as separate customers or lost sales.

Keep a separate order count and attempt count. If you compare blocks before and after a change, use the same definitions and identify missing records. A rise in complaints is evidence of more reports, not a calculated increase in the block rate. Do not supply a rate unless the corresponding complete attempt population and consistent window are available.

Add dated customer contact through an internal support reference. Record what the buyer reported and any relevant order history your business is authorized to inspect. A returning customer or an emphatic message does not establish that the present payment is legitimate. Use the pack to support review, not to label all blocked attempts as false positives.

Compare the first observed block with actual changes: checkout or gateway releases, risk-setting changes made by an authorized person, catalog changes and provider notices. An earlier change is a candidate to investigate, not a proven cause. No recorded store change also leaves provider-side and other causes open.

Ask who controls the particular rule

Provider-enforced controls and merchant-configurable controls need different owners. Do not assume a block is something the merchant can switch off, or that all filters can only be changed by the provider. Ask the provider to identify the control responsible for the named attempts, whether the account can administer it, and which authorized role or integration owner would be involved.

Request an explanation tied to the evidence: whether the payment reached issuer authorization, what observable information led to this outcome, what additional records the review process requires and whether the same control accounts for the other listed attempts. The provider may not disclose every risk signal. Record what it confirms, what it declines to disclose and what remains unknown.

If a change is proposed, ask for its exact scope, the merchant authorization needed, what risk it introduces and how results will be evaluated from subsequent real records. Keep the person proposing the change and the person authorizing it explicit. Do not make a blanket disabling or allow-listing decision from customer complaints alone.

Stripe states that allow-listing does not itself retry a payment. A control change is not a payment result and not a promise that a subsequent attempt will succeed. Any allowed next attempt remains subject to the applicable advice and account conditions.

Separate risk review from eligibility and retry decisions

Stripe's card-decline guide recommends no more than eight retries where retrying is permitted and warns that further retries may be treated as fraud. That is a limit in its card-decline guidance, not an eight-attempt troubleshooting plan and not permission to repeat a provider-blocked payment. A do_not_try_again instruction must not be overridden by the general maximum.

Keep the research-only business description and product disclosure accurate throughout the review. Stripe's September policy evidence separates prohibited examples from restricted categories and says approvals are service-specific and may be modified or revoked. It prohibits misleading business information and processing for undisclosed products. These rules do not decide the eligibility of an unseen merchant, and a filter adjustment does not confer approval.

Do not rename products, hide the catalog, split payments or coach a buyer to change details to evade the control. Use the provider's written next step for the actual outcome. When no permitted next step is established, keep that order's payment question unresolved and communicate that status without promising acceptance.

The evidence pack supports a provider review and a scoped checkout conversation. For a Prism consultation, describe the confirmed pattern, affected checkout path and question that remains. Confirm any diagnostic or follow-up work, responsibilities, fees and terms; keep customer records, payment credentials and the full internal pack out of the public form.

Blocked-order evidence pack

Keep one attempt log for the defined window, with separate totals for attempts and distinct orders. Use the blank fields to index your actual records and decisions. Include only confirmed outcomes; mark missing fields unknown. Share records only through the relevant authorized channel, without card data or customer exports.

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.