Card testing and carding prevention at checkout
Stolen card numbers validated in bulk against a live checkout: the checkout is not the target, it is the oracle.
How card testing works at a checkout
The cheap version replays the checkout POST from a cloud host, card number swapped. The funded version drives a real browser through residential proxies.
How PrivCaptcha stops card testing
Four steps, with the numbers the server uses. Nothing here is configured by you.
The raw POST is what to close first
Card testers skip the page, so the handler must refuse submissions without a privcaptcha-response. Each token: one card, one verdict.
The driver is scored, per request
Bare client: 20, +40 bot user-agent, +15 no Accept-Language, +10 no Accept = 85, level 5: 19 bits. Driven browser: 20, level 2.
Solving buys the tester slack
Each wrong answer adds 8, capped at +40: five failures take 20 to 60, level 4. Solving subtracts 5, capped at -25.
Per-card cost
One proof-of-work per challenge, bits rising with the score. A nonce covers 3 attempts. Non-visual is a flat 22 bits, 4.2 million hashes.
Add PrivCaptcha to your checkout form in two lines of code
Script tag, container in front of the submit button, and your existing verify call. Already on reCAPTCHA or hCaptcha? That backend code stays exactly as it is.
In the checkout form with the card fields, above the pay button.
Read privcaptcha-response from the POST and verify it at /api/v1/siteverify before you call the processor.
Tokens are single-use: a declined customer needs a fresh widget.
What this does not solve about card testing
PrivCaptcha prices the attempt, it does not judge it: no card number, BIN or decline. Processor-side controls stay necessary.
Common questions about card testing
How PrivCaptcha prices card testing, and what it does not do about it.
Put PrivCaptcha in front of your checkout form
10,000 verifications a month are free, and the integration is the one you already have.