Kort samengevat: card-testing-preventie met pre-auth velocity
- IP-rate velocity-regels zijn ontworpen voor één luie fraudeur en één statisch IP. Verspreide card testing wisselt IP's af met kleine bedragen, waardoor elke afzonderlijke poging onder je drempel blijft en de transactie-ML ze stuk voor stuk scoort.
- cside leest cursorbeweging, form-fill-timing, sessieritme en AI-agent-handtekeningen bij checkout voordat de authorisatie wordt ingediend, zodat een geblokkeerde card-testing-sessie nul chargeback-exposure oplevert. Gestolen credentials kwamen volgens Verizon DBIR 2026 voor in 39% van de breaches, en de stack loopt bij lek meteen door in CE 3.0-export.
- Draai je Stripe Radar en zie je alleen een post-authorisatiescore, voeg pre-auth sessiedetectie toe. Is je checkout echt laag volume en zonder automatiseringsrisico, blijf bij velocity-regels.
Software om card testing-fraude te voorkomen stopt geautomatiseerde pogingen om gestolen kaartnummers te valideren voordat er een betaling wordt voltooid. Testruns worden aangedreven door scripts en AI-agents, dus het signaal dat ze verraadt zit in het sessiegedrag bij de checkout: mechanische timing, ontbrekende cursorbeweging en AI-agentsignaturen die detectie in de browserlaag uitleest voordat de betaling afgaat.
Card testing-fraude is de praktijk waarbij geautomatiseerde transacties door de checkout van een merchant worden gestuurd om te controleren of gestolen kaartnummers actief zijn voordat ze voor grotere aankopen worden gebruikt. De aanvaller heeft een lijst met gestolen kaartnummers en weet niet welke nog actief zijn. Ze voeren kleine transacties uit (vaak $0.00 of $1.00) om elke kaart te testen bij een echte payment processor. De merchant draait op voor het volume aan chargebacks van de weigeringen, en de kaarten die slagen worden munitie voor grotere fraude.
Card testing richt op twee verschillende manieren schade aan. De directe schade is het volume aan chargebacks en de kosten van de processor die door mislukte testtransacties ontstaan. De indirecte schade is dat elke gevalideerde kaart vervolgens elders voor grotere aankopen wordt gebruikt, wat bijdraagt aan het bredere fraude-ecosysteem. De Verizon DBIR 2026 stelde vast dat gestolen inloggegevens in 39% van alle datalekken voorkomen, en gestolen kaartgegevens uit die lekken voeden card testing-operaties op grote schaal.
| Tool | Detectielaag | Betrapt AI-agent card testing | Detecteert vóór de transactie afgaat | Chargeback-bewijs | Gratis tier |
|---|---|---|---|---|---|
| cside | Browser (sessiegedrag + device fingerprint) | Ja | Ja | Ja (CE 3.0-export) | Ja (1,000 API-calls/mnd) |
| Stripe Radar | Transactie-ML (na autorisatie) | Beperkt | Nee (scoort na de transactie) | Geen sessiebewijs | Nee (alleen Stripe-klanten) |
| Velocity-regels | Rate limiting op verzoeken | Nee (verspreide testing omzeilt het) | Deels | Nee | Wisselend |
Waarom tools op transactieniveau verspreide card testing missen
Fraudescoringssystemen op transactiebasis zoals Stripe Radar beoordelen het risico van afzonderlijke transacties met machine learning die getraind is op historische betaalgegevens. Ze zijn effectief in het markeren van afzonderlijke verdachte transacties op basis van gedragspatronen van kaarten.
De beperking specifiek voor card testing is timing en spreiding. Moderne card testing-operaties verdelen tests over veel kaarten, veel kleine bedragen en soms veel merchant-accounts tegelijk. Afzonderlijke testtransacties zien er onopvallend uit omdat het bedrag klein is, de kaart echt is (alleen mogelijk gestolen), en de operatie traag genoeg verloopt om onder de velocity-drempels te blijven. Het patroon is alleen zichtbaar wanneer je over veel sessies in de tijd aggregeert, en dat vereist gegevens op sessieniveau die tools op transactieniveau niet verzamelen.
Velocity-regels (limieten op de transactiefrequentie per IP of per kaart) worden omzeild door IP's te rouleren en tests over de tijd te spreiden. Verspreide card testing-operaties zijn er specifiek op ingericht om onder de drempels te blijven die velocity-regels afdwingen.
cside: card testing-detectie in de browserlaag
Card testing wordt uitgevoerd door scripts en AI-agents in plaats van mensen, en dat verschil komt tot uiting in de checkout-sessie zelf, voordat er een transactie afgaat.
cside card testing-detectie verzamelt signalen in de browserlaag tijdens de checkout-sessie: cursorbeweging (of het ontbreken ervan), timing tussen het invullen van velden, sessieritme, AI-agentsignaturen en kenmerken van de device fingerprint. Een menselijke koper die een checkout-formulier doorloopt beweegt de cursor, pauzeert voordat hij de betaling bevestigt en vult velden in met natuurlijke variatie in timing. Een geautomatiseerd card testing-script vult velden in op berekende intervallen, beweegt de cursor in rechte lijnen of helemaal niet, en rondt de checkout af met een mechanisch consistente snelheid, ongeacht de complexiteit van het formulier.
De API geeft realtime een risico-oordeel terug voordat de betaalautorisatie wordt ingediend. Je checkout-flow gebruikt dit signaal om de sessie te blokkeren, een CAPTCHA-uitdaging te tonen of de transactie te markeren voor handmatige beoordeling. Een card testing-sessie die vóór autorisatie wordt geblokkeerd levert nul chargeback-aansprakelijkheid op. Het sessiebewijs (device fingerprint, een AI-agentoordeel, een score voor het sessiegedrag) is beschikbaar voor export in het formaat Visa Compelling Evidence 3.0 als een testtransactie toch wordt voltooid en een geschil oplevert.
Stripe Radar
Stripe Radar is een fraudescoringssysteem op basis van machine learning dat beschikbaar is voor Stripe-klanten. Het beoordeelt het transactierisico op basis van kaartgedrag, velocity en patronen binnen het Stripe-netwerk.
Voor het voorkomen van card testing geeft Stripe Radar een nuttig signaal over afzonderlijke verdachte transacties, maar het werkt pas nadat de betaalautorisatie is gestart. Het verzamelt geen signalen uit de browsersessie voordat de transactie afgaat, en het detecteert niet de AI-agent- of automatiseringskenmerken die een sessie als card testing herkennen voordat er een betaling wordt geprobeerd. Organisaties die Stripe Radar gebruiken om card testing te voorkomen werken met een model van reageren-achteraf in plaats van een blokkade vóór autorisatie.
Checklist voor kopers
- Detecteert het testsessies vóór autorisatie? Detectie vóór autorisatie is de enige manier om nul chargeback-aansprakelijkheid op testtransacties te bereiken.
- Betrapt het testing die door AI-agents wordt aangedreven? Moderne card testing gebruikt steeds vaker AI-agents die CAPTCHA passeren en er op netwerkniveau uitzien als mensen.
- Werkt het bij verspreide testing-operaties? Detectie op basis van één sessie die geen device fingerprints over sessies heen kan aggregeren, mist gecoördineerde aanvallen.
- Levert het bewijs op dat bruikbaar is in geschillen? Wanneer testtransacties toch worden voltooid, bepaalt bewijs in het CE 3.0-formaat of het geschil te winnen is.
- Integreert het op het niveau van de checkout-pagina? Server-side integratie op transactieniveau mist de sessiesignalen die testing-operaties identificeren.
