Card testing, also called enumeration, is the automated use of an online checkout to find out which stolen or generated card numbers still work. Bots submit large numbers of small or zero-value payments, keep the cards that succeed and sell or use them elsewhere. The merchant whose checkout was used pays the processing fees, absorbs the operational noise and, increasingly, carries scheme monitoring exposure.
3D Secure can make a checkout much less useful to card testers, but only on the paths where authentication actually sits in front of authorisation. Attackers look for the paths where it does not.
Why card testing now has a direct cost for merchants
Visa’s Acquirer Monitoring Program (VAMP) measures enumeration directly. Visa’s programme overview defines the VAMP Enumeration Ratio as the count of enumerated authorisation transactions, approved and declined, divided by all authorisation transactions, approved and declined. A merchant is in scope when that ratio reaches 2,000 basis points (20%) and the count of enumerated transactions reaches 300,000 in a month.
Two details matter for merchants. First, the measure is built on authorisation attempts, so a merchant can be exposed even when no fraudulent order is ever fulfilled. Second, declined attempts count as well as approved ones, so a checkout that simply declines bad cards is still contributing to the ratio. What counts is how many attempts reach authorisation, whatever their outcome.
Which checkout paths card testers use
Card testers want the cheapest, fastest response that tells them whether a card is live. They probe every path a merchant exposes, not just the main checkout. The table below sets out the paths most often worth reviewing.
In practice, the weakest path sets the level of exposure. Strong authentication on the main checkout does little if an old API endpoint still sends authorisations directly.
What 3D Secure changes when it sits in front of authorisation
In EMV 3DS, each attempt produces an authentication request that the 3DS Server sends through the scheme’s Directory Server to the issuer’s Access Control Server (ACS). The issuer sees the card, the transaction and the device and browser data collected during checkout before any authorisation is sent.
For a card tester, that makes each attempt harder and more visible:
- An ACS can return a challenge the bot cannot complete, or reject the attempt outright. If your checkout does not proceed to authorisation after a failed or rejected authentication, those attempts never become authorisation transactions.
- The issuer receives device and browser data that an authorisation-only flow never sends, and a stream of near-identical requests is what its risk engine is built to spot.
- You also learn what happened. EMVCo defines reason codes for unsuccessful outcomes, including values such as 04 (exceeds authentication frequency limit), 10 (stolen card) and 12 (transaction not permitted to cardholder). A sudden shift in the mix of these codes is an early warning that your checkout is being tested.
Genuine customers are not necessarily inconvenienced. When the issuer has enough data to be confident, it can authenticate them without a challenge.
Where 3D Secure does not help
Treating authentication as a bot defence leaves several gaps.
- Paths without authentication, such as the skip conditions and unprotected card storage in the table above, stay open until they are closed separately.
- Where your provider or scheme charges per authentication request, testing traffic that reaches the 3DS Server still costs money and adds load, even if it never reaches authorisation.
- If your checkout shows customers a different message for each authentication outcome, attackers can learn which cards are valid without completing a payment. Show a single generic failure message and keep reason codes in your logs.
- When an issuer or its ACS does not participate, the scheme may return an attempted authentication result, which involves no challenge and deters nobody.
- A bot that presents convincing device data with a genuinely live card may still be authenticated without a challenge.
Controls 3D Secure does not replace
Card testing is best handled in layers, with authentication as one of them:
- Edge and bot controls that block automated traffic before it reaches the payment page.
- Velocity rules by device, IP address, account, card number range and email, applied before authentication so that obvious attacks never generate authentication requests.
- 3D Secure on every path that can lead to an authorisation, including card storage.
- Monitoring of authorisation declines for patterns that suggest a path has been missed.
Screening before authentication keeps authentication cost and noise down, and authenticating before authorisation keeps attempts out of the count Visa monitors.
What to monitor
The signals that reveal card testing usually show up in authentication data before they show up in chargebacks:
- authentication requests rising much faster than completed orders
- a shift in reason codes towards frequency limits, invalid or stolen cards
- many distinct cards from a small number of devices or IP addresses
- authorisation declines on transactions that did not go through authentication, which points to a path you have not closed
- activity concentrated outside your normal trading hours
Frequently asked questions
Do failed 3DS attempts count towards Visa’s enumeration ratio?
Visa’s published definition counts authorisation transactions, approved and declined. It does not describe authentication requests as part of the ratio. Attempts stopped at authentication and never sent for authorisation should therefore fall outside it, but confirm how your acquirer reports enumeration for your merchant account.
Should merchants authenticate when a customer adds a card to their account?
Card storage is one of the most common card testing targets, so it should not be left unprotected. EMV 3DS supports non-payment authentication for this purpose, but issuer and scheme support varies. Check what your 3DS Server and acquirer support for card-add flows.
Closing the gaps
The practical first step is an inventory of every path in your estate that can send an authorisation, with a note of whether authentication sits in front of it. GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs and merchants. To review where authentication fits in your checkout, speak with a GPayments 3DS specialist.