Record the time window and time zone, attempt count, amounts and currencies, outcome categories, returned decline or advice codes, and repeated signals visible in your authorized records. Separate provider blocks, issuer declines and integration errors, and count attempts separately from orders. Stripe identifies bursts of failed or blocked payments and suspicious low-value payments as possible card-testing symptoms, but a pattern does not prove that every buyer is fraudulent. Give the provider and integration owner the evidence, the affected checkout path and a timeline of changes; ask them to assess the protection that actually applies to that integration.
For: A research-only store owner or operations lead responding to an unusual concentration of small failed card attempts.
Measure the burst without calling every failure an attack
Define the start and end of the observed window, the clock used, and the system from which you counted. Payment attempts, store orders and payment objects are different units. Several retries can belong to one order; an invalid integration request may never create a payment record. Keep those counts separate so a provider can reproduce the observation.
Use your own comparable earlier records to describe what changed. If no earlier measurement exists, report the observed count and window without inventing a normal rate or percentage increase. Group amounts by currency and record the pattern actually present. Small values alone do not establish an attack, and this guide supplies no universal count or amount threshold.
Stripe's card-testing guide identifies spikes in failed or blocked payments, certain failed requests and suspicious low-value payments as investigation signals. It also warns that excessive payment retries can resemble card testing. Include any automated retry activity in the timeline. A recent checkout change or retry run is evidence to compare with the burst, not a proven explanation.
Separate where each attempt stopped
Stripe distinguishes issuer declines, blocked payments and invalid API calls. A provider block stops the attempt without obtaining issuer authorization. An issuer decline is a different outcome returned through the payment network. An invalid API call points to a request the integration sent incorrectly and typically does not appear as a payment in the Dashboard. Do not describe all three as banks rejecting customers.
Record the outcome category, decline code, advice code and any displayed block reason in the secure incident record. Mark missing fields as unavailable rather than deriving them from the storefront message. If requests failed without payment objects, have the integration owner supply a redacted request-error summary instead of treating an empty payment search as a zero-attempt count.
For repeat signals, use the comparisons already available in authorized store or provider records: whether the same provider-visible payment-method reference, customer account, email, device signal or address pattern appears again. Not every integration exposes every signal. Record match counts or internal references rather than copying raw personal data. A repeated email or address alone is not proof that its owner carried out the activity.
Look for successful payments within the same observed pattern as a separate group. A failed-attempt report can miss payments that got through. Stripe's fraud guidance distinguishes suspicion from certainty, while its card-testing guidance calls for handling fraudulent successful payments. Have the authorized payment owner review those real payments under the provider's process; do not label or refund every small order based only on its amount.
Ask about the protection your integration can actually use
Give the provider and the checkout maintainer the platform, gateway or plugin version, affected checkout path, observation window and outcome breakdown. Ask which controls handled the observed attempts, which attempts reached authorization, and what evidence supports changing a control. The provider can explain its payment outcomes; the developer or platform vendor can establish what the integration sends and which paths its controls cover.
Stripe documents card-testing protections for its recommended integrations, including the latest Payment Element and Checkout. Their effectiveness depends on the integration and the risk information supplied. The guide distinguishes card-testing controls from Radar's protection against fraudulent disputes. A plugin displaying Stripe branding does not by itself establish that it uses a particular integration, version or control.
Ask the maintainer whether the actual implementation uses appropriate challenge, rate-limiting and session controls, and how a proposed change will affect legitimate customers. Stripe warns that a single signal such as an IP address is generally insufficient by itself. Record the provider's recommendation and the person authorized to implement it. This worksheet does not prescribe a live threshold or authorize disabling protections to make declines disappear.
Keep the response and legitimate customer support traceable
Log each store-side change with its time, owner and intended effect. Compare subsequent observations using the same definitions and window lengths. Count suspected activity and ordinary customer difficulties separately. A fall in failures after checkout becomes unavailable is not evidence that legitimate buyers can still complete their intended purchases.
Do not add retries to investigate the burst. Follow returned advice codes: do_not_try_again forbids using that card again for the same transaction, while try_again_later and confirm_card_data describe different next steps. Stripe's recommendation of no more than eight retries applies only where retries are permitted; it is neither a target nor an incident-response procedure. Its card-testing guide warns against continuing retries on fraudulent customer records after an attack.
Keep the store's real customer-service route easy to find and identify the business consistently. Stripe describes those practices as part of dispute and fraud prevention, not as a substitute for card-testing controls. Customer messages should acknowledge the specific payment difficulty without accusing the buyer or promising that another attempt will work.
The immediate response belongs to your provider and the people responsible for the integration. For a Prism checkout-review consultation, provide a non-sensitive summary of the pattern and the review you want scoped. Scope, responsibilities, fees and terms need confirmation; an inquiry is not a staffed incident channel or a promise of round-the-clock response.
Failed-attempt incident log
Complete this from the real incident records and preserve the detailed evidence in authorized systems. Use counts, categories and non-sensitive references in the blank column. Mark unavailable evidence explicitly. Repeat the observation with the same units after a documented change; fewer failures alone do not establish effective protection or legitimate-customer access.
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.
Failed-attempt incident log. The last column is for temporary notes.
Incident fact
Evidence to retain
Interpretation or question
Your observed record
Attempt count and time window
Evidence to retainStart, end, time zone, source system and whether the count is attempts, payments or orders.
Interpretation or questionCompare like units. If earlier activity was not measured, do not claim a percentage spike.
Amounts and currencies
Evidence to retainObserved value pattern separately for each currency; distinguish failed from successful payments.
Interpretation or questionLow values can support investigation but do not establish fraud on each order.
Decline and advice codes
Evidence to retainCodes and messages returned for the attempts, with unavailable fields marked.
Interpretation or questionKeep do_not_try_again separate from advice permitting a later attempt or correction. Do not generate more attempts to fill gaps.
Provider blocks versus issuer declines
Evidence to retainOutcome type, displayed block reason and network result where available.
Interpretation or questionA provider block without issuer authorization is not an issuer decline. Ask which control acted.
Invalid or unrecorded requests
Evidence to retainRedacted integration-error references for attempts with no payment object.
Interpretation or questionAn empty Dashboard search does not measure requests that failed before a payment record existed.
Repeated signals
Evidence to retainCounts of repeated provider references, accounts, emails, device or address signals actually available.
Interpretation or questionKeep raw identifiers private; a shared signal is a lead, not an accusation against a buyer.
Changes and retry activity
Evidence to retainTimes and owners of checkout, plugin, rule or retry-policy changes during and before the window.
Interpretation or questionSeparate authorized changes and automated retries from unexplained activity before assigning cause.
Successful payments needing review
Evidence to retainNon-sensitive references to successful payments within the suspicious pattern and the authorized review owner.
Interpretation or questionAssess individual payment evidence under the provider process; do not assume all successes are genuine or all small payments fraudulent.
Response and subsequent observation
Evidence to retainProvider case reference, assigned maintainer, agreed action and later comparable observations.
Interpretation or questionCheck both the suspected activity and legitimate customer difficulties before declaring the response effective.
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
Stripe's controls and outcome names apply to Stripe integrations. Another provider must explain its own filtering, available signals and retry rules.
A suspicious pattern is not proof against every customer. Do not collect card numbers, security codes, authentication codes, secrets, private payment links or customer lists in this worksheet or the public form.
Technical fraud protection does not establish underwriting approval for a research-only business. No fraud-prevention result or incident-response availability is promised.
Protect yourself from card testing | Stripe Documentation — checked 2026-09-29. Documents investigation signals, integration-dependent protections, the limits of single-signal filtering, developer/vendor involvement, monitoring and the risk of excessive retries. It does not diagnose a merchant's actual burst.
Common types of online fraud — checked 2026-09-29. Describes card testing and distinguishes suspected fraud from a guarantee that a payment is fraudulent; payment success does not establish cardholder consent.
Stripe declines — checked 2026-09-21. Separates issuer declines, provider blocks and invalid API calls; a block does not obtain issuer authorization and invalid calls typically do not appear as payments in the Dashboard.
Stripe card declines — checked 2026-09-21. Advice codes require different next steps. The recommendation of at most eight retries applies only where retries are permitted; further retries may be treated as fraud.
Stripe dispute and fraud prevention — checked 2026-09-21. Recommends recognizable business identification and an easy-to-find customer-service contact; these practices do not replace technical card-testing protection.
Prism solutions — checked 2026-09-21. Published support includes storefront review, card-processing preparation and help with provider website questions. Scope, fees and terms are discussed before work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The public form asks for the website, products and question and excludes card details, passwords and customer records. Follow-up is by email; the request does not book an appointment, purchase a service or submit a processing application. No incident-response hours are stated.