%201.svg)
rétrofacturation?
Ce n'est plus votre problème.
Récupérez 4 fois plus d'rétrofacturation s et PRÉVENTION jusqu'à 90 % des messages entrants, grâce à l'IA et à un réseau mondial de 20 000 commerçants.
Plus de 600 avisEn bref :
- Investigate card setup and failed attempts as well as completed payments.
- Compare suspicious patterns with legitimate retries and payment incidents.
- Coordinate payment-flow controls with post-purchase review.
- Track customer impact, completed losses, and later disputes separately.
Card testing is fraudulent activity that attempts to determine whether payment-card details can be used successfully. For merchants, it can appear as abnormal card-setup attempts, authorization activity, or low-value payments and can lead to fees, operational disruption, and later disputes.
{{cta}}
Recognize a Pattern, Not Just a Small Order
Low value alone is not proof of card testing. Compare unusual activity with your normal traffic, promotions, subscription retries, and payment incidents. Look at failed attempts as well as completed orders.
| Signal | What to Investigate | Possible Legitimate Explanation |
|---|---|---|
| Unexpected rise in failed payments | Timing, affected payment flow, and linked attempts | Issuer outage or integration problem |
| Many card attempts linked to accounts or sessions | Whether behavior is coordinated and abnormal | Customers retrying after a payment error |
| Unusual low-value successful orders | Connection to the broader failure pattern | Promotion or genuinely inexpensive products |
| High card-setup activity with little shopping activity | Which account and payment flows are involved | A migration or payment-method update |
| Repeated retries after an incident | Whether automated jobs continue the traffic | Poorly configured recovery or retry logic |
Stripe’s card-testing guidance covers card setup as well as payments. A report limited to completed sales can miss the activity that needs attention.
Coordinate an Active-Incident Response
- Identify the affected payment flow
Identify whether the issue involves saving cards, making payments, or automated retries.
- Coordinate the incident team
Bring the payment integration owner, fraud team, and support into one incident workflow.
- Apply supported controls
Work with your provider or developer on the affected flow using supported controls.
- Inspect suspicious completed orders
Match suspicious completed orders to the incident and check fulfillment status.
- Check legitimate transactions still work
Confirm that abusive activity falls while legitimate customers can still transact.
- Assign follow-up ownership
Assign an owner for follow-up exceptions and customer reports.
Record when each control changed and what happened afterward. A drop in all traffic is different from selective suppression of abusive attempts. Your incident log should distinguish an effective control from an unrelated service outage.
Place Controls Where They Can Act
Use the current case and provider requirements
Protect the payment flow and check every entry route
Control timing
Payment-flow protections can reduce abusive requests before successful orders exist. Post-purchase review can act before fulfillment. Chargeback alerts and evidence responses address later events; they do not replace protection of the payment flow.
Supported payment and setup flows
Stripe recommends supported integrations and layered mitigations rather than relying on an IP filter alone. Do not assume a payment-page change protects every route that can create a payment or save a card.
For broader control ownership, see payment fraud prevention. OWASP’s transaction authorization guidance emphasizes enforcing authorization and permitted state changes on the server.
Handle Completed Orders Separately From Failed Attempts
A failed authorization is not a completed sale to refund. For a completed suspicious order, check capture, fulfillment, refund, and dispute status before choosing an action. Use the provider’s supported workflow.
Review refund and chargeback reconciliation and unauthorized-transaction investigation. A successful authorization does not independently prove cardholder consent.
Retain Evidence for Resulting Disputes
Connect the dispute to its payment, order, authentication result, incident history, and any refund. The allegation and applicable rules determine the response, not the transaction’s low value.
3D Secure may affect liability for eligible fraud disputes, subject to conditions. Confirm the recorded result rather than treating authentication as a universal guarantee. Use representment guidance and consistent evidence records to prepare the case.
Measure Recovery From the Incident
Track attempted and successful payments, confirmed fraud, fees, fulfillment losses, complaints, and legitimate payment success. Compare equivalent traffic periods and check for continuing automated retries.
Review fraud management responsibilities to keep teams aligned. If post-purchase review is a gap, explore Chargeflow Prevent as one part of the control set.
Measure an authorization spike without inventing a chargeback result
Hypothetical incident: 500 authorization attempts from a suspicious pattern occur in one hour; 20 are approved and 2 become paid orders. Record each denominator separately. The approval proportion is 20 ÷ 500 = 4%; the paid-order proportion is 2 ÷ 500 = 0.4%. Neither number is a chargeback rate or proof that every attempt was fraudulent.
Retain the baseline period, event time, affected payment routes, observed identifiers, control changes, and later legitimate-order acceptance. Monitor subsequent fraud reports and dispute filings separately. The VAMP guide explains the program context; confirm current enumeration conditions with your acquirer before comparing an internal incident metric to a network metric.
Continue learning: Online payment fraud
Use Online Payment Fraud: Choose a Merchant Investigation Guide to choose the next merchant task in this topic.
- Ecommerce Fraud: Types, Chargeback Outcomes, and Merchant Response: Ecommerce fraud types and routes to specialized investigations.
- Ecommerce Fraud Protection: Build Controls Around Chargeback Outcomes: Implementing ecommerce fraud controls and measuring acceptance tradeoffs.
Sources and scope
Source notes updated: October 11, 2026. Card-testing investigation. Keep authorization attempts, approvals, paid orders and later disputes as separate populations. Confirm the payment-provider controls and monitoring records before attributing a change to an intervention.
For a live case, retain the governing document’s edition or effective date, the relevant provision, and the provider notice.
Foire aux questions
Does card testing always involve a small purchase?
Card testing can involve card-setup and authorization activity as well as low-value payments. A completed purchase is not required for every attempt.
Does every declined payment indicate card testing?
A declined payment does not establish card testing. Investigate linked patterns and rule out ordinary retries, issuer problems, and integration errors.
Can card testing produce chargebacks?
Successful unauthorized payments associated with card testing can lead to disputes. Failed attempts can still create operational strain or applicable processing costs.
Can post-purchase tools stop all card-testing requests?
Post-purchase controls act after a transaction reaches that stage. Payment-flow protections are also needed before successful orders exist.
rétrofacturation?
Ce n'est plus votre problème.
Récupérez 4 fois plus d'rétrofacturation s et PRÉVENTION jusqu'à 90 % des messages entrants, grâce à l'IA et à un réseau mondial de 20 000 commerçants.
.png)
