O que é a fraude por teste de cartão e como evitá-la?

Card testing fraud is automated abuse that checks whether stolen or generated payment credentials are usable, by sending small payments or card-setup requests through a merchant's payment flow. It can target card setup and payment attempts, including transactions that fail or never become completed orders.

That makes an order-only response incomplete. Attempts, declines, and card-setup requests need monitoring alongside orders, while support and finance handle the successful unauthorized charges. Card networks call the high-volume, scripted form enumeration. Post-purchase screening can complement these controls, but it cannot undo the load and authorization activity created before an order exists.

{{cta}}

How a Card Testing Attack Unfolds

An attack runs in four stages, and your payment flow is visible in only two of them. Visa describes the scripted version as automated testing of payment data elements to guess a full account number, CVV2, or expiration date, often concentrated on one BIN or a small set of BINs. That concentration is the pattern behind a BIN attack. Low-volume manual testing adjusts to each decline response, while scripted enumeration cycles through combinations at scale.

Card testing is the probing stage of broader payment fraud: the cards it confirms fund larger purchases elsewhere. Two details change how you monitor.

• Card setup is a favored path. Stripe's guidance notes that validations during card setup do not typically show up on cardholder statements, so fewer cardholders notice and report them. Watch saved-card volume, not only payments.
• A confirmed card may sit unused. In Visa's Fall 2025 ecosystem report, 85% to 93% of exposed accounts recovered from two carding shops traced to enumeration attacks at least 12 months earlier. The same report describes testing spread across merchants at low velocity that stays under traditional rate limits, so a quiet week after an attack does not mean the cards are burned.

Attackers favor businesses with fast approvals and small tickets, such as donation pages, subscriptions, and event ticketing. Our guide on who card testers target and how to harden your business goes deeper on those targets and the friction tactics that discourage them.

Signs of Card Testing Fraud in Your Payment Data

Inspect where the unusual activity enters: checkout, saved-card setup, donations, account creation, or another payment-enabled feature. Compare attempt volume, failures, and successful payments with a normal period for that same path. A sales promotion can increase legitimate traffic, so volume alone is not a sufficient finding. A spike in generic declines or payment errors on one path is typically the earliest signal; track your decline codes by path rather than as one site-wide rate.

Quanto a fraude por teste de cartão realmente custa para você?

The test charges themselves are small. The costs that follow are not, and several continue after the attack stops.

Sources: Visa Payment Ecosystem Risk and Control biannual report, Spring 2025 for the first two figures; Visa Acquirer Monitoring Program fact sheet, 2025 for the thresholds.

Como você PREVENÇÃO detecta fraudes em testes de cartões?

Stripe's card-testing guidance covers both card setup and payments, and recommends layered controls because a filter on one signal such as IP address is usually not sufficient. Merchants using Stripe should have the integration owner review the relevant implementation and provider signals. Place each control where it can act, and treat the set as one layered ecommerce fraud prevention program.

Card Testing During Black Friday and Cyber Monday

An attack that lands on a holiday weekend arrives on top of the heaviest traffic of the year, which gives it cover, and a busy sales day also produces more legitimate declines. In 2026, Black Friday is November 27 and Cyber Monday is November 30. Baseline your payment paths before November 20 and compare against the same hour of previous peaks, not an ordinary Tuesday. The triggers below are examples. Build yours from last November's logs and your own percentiles.

Holiday Weekend Runbook

Name an incident lead, an engineer with deploy access and a contact at your processor before Thanksgiving (November 26). Then work in this order:

1. Confirm (first 15 minutes). Check for failed and blocked payments, 402 and generic_decline spikes, and low-value payments with nonsensical names or emails. Save timestamps and sample IPs.
2. Contain (first hour). Turn on or tighten CAPTCHA on every request that saves a card or makes a payment, and validate it on the server. Add rate limits, such as a cap on new customers per IP per day. If guest checkout is the entry point, require login or session validation before payment.
3. Protect real buyers. Change one control at a time, watch the approval rate for legitimate orders after each change and keep a rollback path.
4. Refund the strays. Refund suspicious payments that went through, as Stripe recommends, so cardholders do not report them as fraud later.
5. Stop retries. Do not retry cards attached to fraudulent customers. Excessive retries can look like card testing and repeat the original attack.
6. Check your keys. Confirm secret keys have not been exposed. With leaked credentials, testers can create payments and set up cards directly.
7. Call your processor and log every change. Give them timestamps, volume, sample IPs and the controls you changed, and record each rule changed, who approved it and when, so you can reverse it after the weekend.

The sections below cover containment, refunds and disputes in more detail. Successful test payments can surface as fraud reports and disputes weeks later, so keep watching your ratios through January. For the wider peak-season plan, see our BFCM readiness guide and BFCM chargeback prevention guide, and for the dispute timeline, why Q1 is the real chargeback season.

Contain Abuse Without Disabling Legitimate Commerce

Assign an incident owner and involve the team that maintains payment integration code. Record the affected path, start time, observed signals, and actions taken. If the attack continues after a checkout change, check whether another endpoint still accepts equivalent requests.

• Validate security controls on the server, not only in the browser.
• Review recent configuration or deployment changes that may have exposed a path.
• Monitor legitimate payment success while tightening controls.
• Keep a documented exception route for real customers affected by the response.

Do not publish secret keys or collect card security codes in support tickets. Preserve permitted identifiers and verification outcomes through your provider, and fold the incident record into your wider merchant fraud protection program so the next attack starts from a known playbook.

Separate Failed Attempts From Completed Payments

Failed attempts can create processing activity and operational strain without producing a chargeback. Successful unauthorized payments create another task: identify their current state and coordinate the supported resolution. Do not calculate exposure solely from completed order revenue.

If a payment is uncaptured, the available action may differ from a settled charge. If a dispute has already opened, check that case before issuing a separate credit, because a chargeback after a refund leaves you debited twice.

Document each resolution against the original payment. A bulk action should have an exception report for failed or unresolved items, not just a confirmation that the job ran. Finance needs to distinguish requested refunds, completed refunds, and other settlement movements.

Do Not Confuse Card Testing With Friendly Fraud

Card testing typically involves unauthorized credential use. Intentional friendly fraud involves misuse of a genuine purchase relationship. One is not proof of the other, and the genuine cardholder should not be labeled an abuser because their credentials appeared in an attack.

An existing account involved in suspicious activity may also have been compromised. Use the account takeover fraud response when changes in login or account control precede the payment activity. Secure the account separately from resolving the affected purchases.

Handle Disputes Using the Actual Evidence

For a resulting chargeback, read the chargeback reason code and case instructions. Delivery does not independently establish that the cardholder authorized a card-testing payment. Review whether a supported response exists rather than challenging every confirmed unauthorized payment automatically.

The processor evidence guidance emphasizes relevant, readable records. Keep the response focused on the claim and submitted through the accepted workflow. An explanation that your store was attacked does not itself transfer liability or guarantee recovery.

Confirm the Fix and Prevent Repeat Exposure

Compare attack attempts, legitimate approvals, successful fraudulent payments, and unresolved customer reports after containment. Review whether the apparent improvement comes from stopping abuse or blocking most traffic. Continue checking the affected entry points when normal purchasing resumes.

Use the dispute workflow audit to close gaps between incident response and finance. Chargeflow covers the later stages: Prevent screens orders after checkout and before fulfillment, alerts catch disputes before they become chargebacks, and recovery workflows handle the ones that remain. Each serves a different stage and should have clear ownership.

{{cta}}

Perguntas frequentes

Can card testing happen without a successful purchase?

Yes. Card testing can target card setup or failed payment attempts, so order history alone does not show the entire attack. Review the relevant payment and integration activity.

How can I detect card testing attacks?

Look for a spike in declines or errors on one payment path, many different cards from one IP, device, or session, many saved cards with no purchases, and low-value approvals with similar behavior. Compare each against a normal period for that same path, and include slow attempts spread over several days.

Do card networks detect card testing for me?

Partly. Visa monitors enumeration across its network, but network-level detection does not replace controls on your own payment and card-setup endpoints. You still need bot checks, velocity limits, and decline-code monitoring where the requests enter.

Which tools catch card testing?

No single tool covers every stage. Bot and CAPTCHA controls act before the form, velocity rules in your payment provider's risk tooling act at submission and authorization, network intelligence works at issuer level, and order screening handles approved orders after checkout.

Does post-purchase screening stop all card testing?

No. Post-purchase screening can help review completed transactions, but it does not replace controls on card setup and payment-attempt paths. Protect the entry points where the abuse occurs.

Should every card-testing chargeback be challenged?

A card-testing chargeback should be assessed against its facts and applicable rules. Confirmed unauthorized use may be a valid claim, even if the merchant fulfilled the resulting order.

How can I tell card testing from a busy Black Friday?

Look at the shape of the traffic, not only the volume. Card testing shows as a spike in failed payments and 402 errors, many distinct cards from one IP or device, and clusters of low-value payments with nonsensical names or emails. Real peak traffic raises orders and revenue along with declines.

Explore Chargeflow's automated chargeback recovery to organize evidence and manage supported dispute responses.