Unusual submission velocity
A sudden burst of attempts from a narrow set of sessions, devices, addresses, or newly created accounts may deserve review, especially when normal customer demand does not explain it.
Payment fraud education
What is account testing fraud?
Account testing fraud is an automated or repeated attempt to learn whether stolen or generated payment-card details are valid. It is also commonly called card testing or account enumeration. Attackers may submit many payment attempts or card-verification requests, then use the responses to identify credentials that appear usable elsewhere.
How account testing reaches a merchant
A merchant can become an unintended testing point when a checkout, donation form, account-registration flow, saved-card feature, or payment endpoint accepts rapid automated submissions. The attacker is not necessarily trying to buy the merchant's product. The immediate goal may be to distinguish valid card details from invalid ones by observing authorization or verification responses.
Stripe's current card-testing documentation identifies account testing and enumeration as common names for this activity and explains that scripts may test large sets of card information. Visa's merchant guidance similarly describes scalable, programmatic testing of payment fields. The exact traffic pattern varies by site and provider, so a single declined payment is not proof of an attack.
Patterns worth investigating
Repeated validation failures
Many failed authorizations or verification checks with changing card details can indicate testing, but ordinary customer mistakes and issuer declines must remain part of the investigation.
Low-context checkout activity
Attempts that skip normal browsing behavior, reuse identical order details, or target a low-friction payment flow can be a signal when seen alongside other anomalies.
Why layered controls matter
No single rule can reliably separate every attacker from every legitimate customer. A blunt block may interrupt real buyers, while a weak control may let automated testing continue. Visa recommends a layered approach that can include monitoring, velocity controls, bot detection, risk-based authentication, and review of transaction anomalies. Which controls are available depends on the merchant's checkout, gateway, processor, fraud tools, and application architecture.
Controls should be tuned with current business traffic in mind. For example, a ticket release, fundraising campaign, or seasonal sale may create a legitimate burst that looks unusual compared with an ordinary day. Teams should combine several signals, document exceptions, and review provider-specific guidance instead of treating a public threshold as universally correct.
A practical response sequence
- Preserve evidence: record timestamps, redacted transaction references, affected endpoints, response categories, traffic volumes, and relevant system alerts.
- Notify the right providers: use established support or incident channels for the payment gateway, processor, hosting platform, fraud service, or security team involved.
- Contain abusive traffic: apply available rate limits, bot challenges, velocity rules, or temporary endpoint protections with care for legitimate customers.
- Review exposed workflows: check payment, card-save, account-creation, guest checkout, donation, and other low-friction forms for repeated automated submissions.
- Watch after changes: confirm whether suspicious activity declines, legitimate checkout remains usable, and the attacker shifts to another route.
- Document the outcome: retain the timeline, provider responses, control changes, and follow-up owner under the business's incident process.
Avoid risky shortcuts
Do not publish exact detection thresholds, detailed fraud-rule logic, or live system responses where attackers can use them to tune their scripts. Do not send complete card numbers, security codes, passwords, secret API keys, or unredacted customer records through an ordinary email or contact form. Use secure provider channels and share only the information requested for the investigation.
Account testing guidance is operational, not a promise that a particular tool or setting will stop every attack. Response requirements can differ by provider and incident. If there is evidence of unauthorized access, exposed data, or continuing abuse, follow the organization's incident plan and obtain qualified security and provider guidance.
Prepare an incident-ready summary
Before contacting a payment or security provider, gather the affected route, first and last observed timestamps, approximate attempt volume, redacted examples, response categories, recent site changes, and controls already applied. Payments Max can help organize payment-workflow questions, but incident containment and configuration decisions should be confirmed with the providers and security professionals responsible for the affected systems.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US