To reduce carding, protect the requests that create payment attempts as well as the payment-processing step itself. Use your provider's current fraud controls, constrain automated retries, and check every flow that can validate or save a payment method.
A checkout page is only one possible entry point. An add-card form or a direct API call may reach the same verification operation without following that page's browser flow.
Identify the payment operation being abused
OWASP defines carding as using automation to test payment-card details. The important observation is the repeated verification workflow, not merely a large number of visits to checkout.
Inventory the operations that reach your provider: payment creation, payment-method setup, saved-card changes, and retries. Record which component calls the provider and which checks happen before that call.
Keep raw card details and security codes out of investigation logs. Use provider references and approved internal identifiers rather than making a second store of payment data. OWASP's logging guidance describes sensitive values that should be excluded or appropriately handled in logs.
Confirm the pattern before imposing a broad block
Compare request counts with provider outcomes over the same time window. Look for the operation where the increase starts, repeated failed attempts, and whether successful customer journeys changed too.
Those patterns are investigation leads. Declines also happen to legitimate customers, and a provider incident or broken integration can produce retries. Check release history and provider status before treating every failure as abuse.
| Observation | Check alongside it | Possible next action |
|---|---|---|
| Verification attempts rise without completed purchases | Setup-card and saved-card routes, not only checkout | Review controls on the operation creating those attempts |
| Failures rise immediately after a release | Request payloads and retry behavior | Fix the integration before tightening traffic policy |
| One session produces repeated attempts | User retries and the provider's transaction references | Bound retries without duplicating the payment operation |
| Attempts arrive through many client sources | Route, timing, and available session evidence | Review a combined pattern rather than one IP threshold |
| Legitimate completions fall after a rule change | Challenges, blocks, and payment errors separately | Revert the new rule if it exceeds the agreed customer-impact limit |
Use the provider's supported protections
Stripe's card-testing guidance recommends current Payment Element or Checkout integrations and explains that protection depends partly on the integration and information it supplies. If you use another provider, review that provider's corresponding controls instead of copying Stripe-specific settings.
Check that your live integration still sends the supported risk information and handles the provider's responses correctly. A customized form can have a different protection path from a hosted checkout. Treat migration or integration changes as a reason to recheck this path.
Do not promise that a provider control catches every attempt. Request-side protection and payment-side decisions observe different things and need to be investigated together.
Bound retries before expensive operations
Determine whether a request is creating a new payment operation or retrying an existing one. Follow the provider's documented retry and idempotency behavior; do not turn a timeout into an uncontrolled loop of fresh payment attempts.
Use separate budgets for operations with different costs. A page refresh, a payment-method setup, and a payment confirmation are not interchangeable units of work. OWASP's API resource-consumption guidance supports endpoint-specific rate limits and limits on repeated operations.
Review the identity behind each budget. A network address can be shared by many shoppers. An account or session can also make several legitimate attempts. Decide what happens when a required identifier is missing, and test that case explicitly.
Enforce a rejection before the unwanted provider call. Returning an error after completing the expensive operation changes the response without preventing that operation.
Keep the response useful without leaking unnecessary detail
Give a legitimate customer a clear next step appropriate to the provider result. Avoid displaying internal risk rules or diagnostic detail that the user does not need. Keep detailed provider information in the approved operational tooling.
Measure challenges separately from payment declines. A customer who cannot complete a browser challenge never reaches the same stage as a customer whose payment was declined. Combining those outcomes into one failure count hides where the problem is.
Validate changes without using real cards
Use the provider's test mode, documented test payment methods, and a staging flow you control. Do not test with real or stolen card details, and do not run an abuse simulation against live payment processing.
Rehearse normal checkout, an ordinary retry, a provider timeout, an interrupted browser challenge, and a request missing the expected session. Check whether the provider was called, whether an operation was duplicated, and whether the customer can recover.
No result is implied by this checklist. It is a method for checking your integration. Choose acceptable customer-impact limits and a rollback owner before the rule reaches production.
Where Centinel fits
The checkout and carding use case covers automated abuse around payment workflows. Bot management can supply a request-policy layer at a supported integration, while your provider evaluates the payment operation.
A bot classification is not proof that a card is stolen, and a human-looking browser is not proof that a transaction is safe. Keep those decisions separate. If browser automation is part of the observed pattern, review the browser evidence model and begin with the specific endpoint producing the unwanted attempts.