What it means
A small online shop suddenly sees hundreds of payment attempts, many of them failing and some using different cards from the same automation. Stripe describes card testing as using payment flows to validate card details, and attackers can exploit both small purchases and card-verification endpoints.
The merchant may face fees, disputes and service disruption. A high failure rate can be a signal, but it is not proof by itself, because an outage or checkout bug can also cause failures.
Combine volume, velocity, device and network patterns before labelling anything an attack. Some payment providers charge for attempts or impose penalties when abuse becomes severe, so review the current agreement; a small transaction value does not mean the incident is financially harmless.
Stripe's support guidance recommends controls suited to the payment flow, such as rate limits, bot defences and fraud rules. The right settings depend on traffic and provider capability, and attackers may rotate IP addresses and accounts.
A single-IP block can miss the pattern and affect shared networks, so layered controls are more resilient, and static rules need monitoring because attack patterns evolve. Map every route that can submit a card to the processor, including account creation, guest checkout and saved-card setup.
Protecting only the visible form is not enough, because attacks can continue through an API endpoint. Successful tests can also lead to larger fraud elsewhere, so coordinate with the payment provider when suspicious patterns appear rather than running your own card-number experiments.
Good monitoring distinguishes issuer declines, blocked fraud attempts and technical failures. Group events by the relevant signals without exposing full card data, because payment-security rules govern retention.
Never ask customers to send card numbers in chat while resolving a suspected attack; use approved payment rails and support processes. When an attack is active, document timing, endpoints and provider case IDs, apply controls and monitor outcomes.
Remove temporary rules carefully and keep a record of customer impact, because a rule that blocks a suspect range too broadly will stop legitimate buyers. Longer-term work can include secure integration, limited API keys, bot protection and anomaly alerts, tested regularly, with no promise that any one setting eliminates attacks.
In practice
Real-world examples.
Example
An online store sees rapid low-value attempts across many different cards from one automated source. It throttles that route through its approved provider settings, then checks that normal shoppers can still pay.
Example
A billing bug causes failures that resemble fraud until the team checks error codes. The fix is a software release, not a block list, which shows why context matters before acting.
Example
A digital-goods seller adds a simple CAPTCHA but attacks continue through an API endpoint. It secures that route, adds velocity checks and tests for false positives among legitimate new customers.
Formula
Calculation
Diagnostic failed-attempt rate = failed payment attempts / all attempts in the defined period x 100%
Worked example. A fictional subscription app records 1,200 payment attempts in one hour after a billing release, and 900 of them fail.
- Failed-attempt rate = 900 / 1,200 x 100% = 75%.
- A normal hour for the same app might show 60 failures from 1,000 attempts, a rate of 6%, so 75% is a strong signal that something has changed.
- The rate cannot say why. Error codes in this fictional case point to a software bug, not card testing, so a blanket block would have hurt real customers.
Investigate causes before labelling the pattern as card testing, and compare against a normal baseline for the same period.Case study
Seen in the real world.
In this fictional case, Elm Tickets sees a sudden burst of tiny purchases and issuer declines overnight. Its provider confirms an automated testing pattern, and the company adds temporary velocity controls while watching both abuse and legitimate checkout failures. It records the incident without handling raw card numbers. Elm then finds that an early rule blocked a shared office network where genuine buyers were trying to pay.
It narrows the rule after checking the evidence, which shows that security controls should be measured for both fraud reduction and conversion. In the weeks that follow, the team maps every card-submitting route, limits its API keys and keeps a short written checklist for the next incident. The illustrative lesson is that fast detection, narrow rules and honest measurement of customer impact matter more than any single clever setting, and that the finance team should see the fee and dispute costs alongside the security data.
Watch out
Common mistakes.
- Calling every high failure rate a fraud attack.
- Blocking only one IP while other payment endpoints remain open.
- Ignoring false declines after adding an emergency rule.
Questions
People also ask.
Are card tests always small purchases?
No. Verification and other low-value flows may be used.
Does a failed payment prove testing?
No. Look for patterns and rule out technical issues.
Who should help respond?
The payment provider and internal security and operations teams.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%