Card testing prevention
Card testing is a bot running stolen card numbers through your checkout in rapid small charges to find which ones approve.
Step 1: Evaluate the payment action
Card testing happens at the charge, so protect the payment action. payment is a custom action: you evaluate it like any other, you just name it payment. Evaluate it when the user submits a charge and confirm the verdict on your server before you run the payment. If you haven't wired Rupt yet, start with the Quick start.
Step 2: Add the policies
A policy has a trigger (the event it runs on) and a verdict. Add these in your policies dashboard:
| Policy | Trigger | Conditions | Verdict |
|---|---|---|---|
| Verify a risky checkout | payment | is_new_ip, is_new_fingerprint, or event_count of payment over the last 10 min above 5 | Challenge |
| Block card testing | payment | is_simulator, is_emulator, a headless browser, the card on your card block list, or event_count of payment over the last 10 min above 10 | Deny |
Protect the real cardholder while stopping the tester. An unfamiliar IP or device might just be your customer on a new phone, so verify them with a challenge before the charge goes through. A simulator, emulator, headless browser, or a card you've already flagged has no business at checkout, so deny it. Card testing also gives itself away by pace: a handful of attempts in ten minutes earns a challenge, a flood gets blocked.
When you catch a tester, add the card to your card block list (a list of type card) so the next attempt with it is denied on sight.
Related
- Velocity: the
event_countspike behind the rate checks. - Anonymizing network: the IP and device checks behind this policy.
- Lists: the card block list.
- Need help? Contact support.
- Want to see Rupt in action? Request a demo.
- Questions? Talk to sales.
- Check out our changelog.
- Check our status page.
- LLM? Read llms.txt.