Summarize this page with
Card testing uses repeated payment attempts to discover whether card details are usable. Containment needs to cover the payment endpoint, related sessions and the retry path. A single IP limit is easy to evade and can penalize unrelated shoppers behind a shared network.
- 1Map the payment endpoint
- 2Connect related attempts
- 3Contain supported retries
- 4Measure legitimate recovery
Identify the protected action
Map where an account, guest or script can create a payment attempt. Include saved-card flows, donation forms, mobile clients and direct server endpoints. Protect the operation that starts screening or authorization; a disabled button alone does not protect a reachable backend.
Use your processor's documented integration and collect only supported payment references. Keep raw card details out of fraud logs and editorial test records. The Stripe card-testing guide describes controls around its payment integrations.
Connect attempts across changing identifiers
Count attempts through several available relationships: account, session, device, payment reference and network. Device and network intelligence can connect repeated sessions when the IP changes. A shared IP can also belong to a workplace or mobile carrier, so avoid treating it as proof that several buyers are the same person.
ShieldLabs adds live device, network and account-risk context before payment. A payment engine supplies transaction evidence. Evaluate both inputs at their actual decision time and inspect the vendor review for scope.
| Observation | Investigation | Possible response |
|---|---|---|
| Many payment attempts from a related session | Check collection, timing and payment results | Restrict repeated attempts using supported controls |
| New IP but recognized device activity | Inspect related accounts and earlier attempts | Reassess the combined evidence |
| Missing collection or a timeout | Check integration health | Use an explicit pending or fallback path |
| A legitimate customer retries once | Inspect issuer response and customer flow | Preserve a reasonable recovery route |
Work an illustrative incident
Suppose a storefront observes 600 attempts in ten minutes, concentrated in 12 related sessions. Those numbers are an illustrative example. They establish a burst worth investigating, not 600 confirmed fraudulent customers. First check the endpoint and affected payment flow. Preserve identifiers and response codes, apply supported containment, and confirm that the burst subsides without breaking normal checkout.
A low authorization rate alone is insufficient ground truth. A broken integration can also produce failures. Check deployment timing, the processor's status and whether the traffic reaches a real authorization call.
Measure recovery and cost
Track attempted screening, authorization, completed legitimate orders, missing results and customer recovery separately. Per-screened-payment plans can incur charges even for unsuccessful attempts; verify the exact billing event. Use the cost checklist and false-decline guide.
FAQ
Is one IP rate limit enough?
No. Correlate supported account, device, session and payment evidence, and protect the underlying endpoint. Shared networks and rotating exits require different handling.
Does a successful challenge prove a safe payment?
No. Challenge completion supplies one piece of interaction evidence. The payment and related account activity still require assessment.
Should every suspicious attempt be retried?
Use the processor's documented retry behavior. Repeated automatic retries can increase screening cost and obscure the original failure.
Continue reading
- Guest checkout fraud: evaluate risk without requiring an account
- How to measure false declines alongside missed payment fraud
Compare all ten tools or read the complete deployment guide.