Card testing in je webshop: welke orders houd je tegen?

Je provider toont een reeks afgewezen kaartbetalingen, terwijl je winkel nauwelijks extra omzet heeft. Tussen de fouten staan enkele kleine bestellingen met ongewone klantgegevens. De eerste vraag is waar die pogingen ontstaan. Gaat het om betalen in de checkout, om een account dat nieuwe kaarten opslaat, of om een losse betaalpagina? Het antwoord bepaalt welke route je moet laten beperken. De voorraadlijst alleen geeft geen volledig beeld van de aanval.

Deze aanpak is voor een Nederlandse webshop die fysieke producten verkoopt. De officiële Stripe-documentatie en Mollie-risicocontroles zijn op 14 oktober 2026 geraadpleegd. Het is geen handleiding voor het uitproberen van kaartnummers. Je werkt met je eigen betaalmeldingen en laat de leverancier van je checkout onderzoeken wat de aanval bereikt. De gevolgen voor een uitbestede bestelling bespreek je met de uitvoerder, zonder hem de betalingsbeveiliging te laten beoordelen.

Waarom kan card testing plaatsvinden zonder nieuwe bestelling? #

Stripe beschrijft dat aanvallers zowel kaartregistratie als betalingen gebruiken. Een kaart toevoegen aan een account kan dus onderdeel van het patroon zijn. Kijk naast de orderexport naar de betaalpogingen en meldingen in het providerdashboard. Wanneer er geen order ontstaat, vind je de poging ook niet terug in je paklijst. Daardoor kan een rustige ochtend in het magazijn samengaan met veel activiteit op je betaalroute.

Vergelijk dezelfde perioden in beide systemen. Noteer hoeveel pogingen je provider laat zien, hoeveel daarvan geslaagd zijn en welke daadwerkelijk aan een order gekoppeld zijn. Gebruik je eigen normale patroon als vergelijking; een vast aantal pogingen dat voor elke webshop fraude zou bewijzen bestaat hier niet. Een storing kan eveneens veel fouten veroorzaken. Kijk daarom naar foutmeldingen, herhaalde patronen en afwijkingen voordat je alle betrokken klanten hetzelfde behandelt.

Een betaalpoging is bovendien geen verkochte eenheid. Tel afgewezen pogingen niet als omzet en stuur er geen orderbevestiging met verzendbelofte op uit. De enkele succesvolle pogingen verdienen juist een afzonderlijke controle, omdat daar een fysieke uitvoering achter kan zitten. Je technische incidentoverzicht en je werkelijke orderlijst hebben dus verschillende aantallen. Bewaar de koppeling waar die bestaat, zodat je geen succesvolle transactie uit het onderzoek verliest.

Welke combinatie van signalen vraagt om onderzoek? #

Stripe noemt een sterke stijging van mislukte of geblokkeerde betalingen als herkenningspunt. In technische logs kan een piek in 402-fouten zichtbaar zijn. Dat is een signaal om de betaalroute te onderzoeken, geen zelfstandig oordeel over een individuele klant. Vraag je beheerder om de gebeurtenissen aan jouw providertransacties te koppelen. Een losse schermafbeelding met fouten vertelt nog niet welke betalingen geslaagd zijn of welke orders mogen vertrekken.

Verzamel een beperkt overzicht voor de provider: startmoment, gebruikte betaalroute, foutpatroon en relevante transactiereferenties. Zet geen complete kaartgegevens in een spreadsheet of supportmail. Een referentie waarmee de provider de eigen gegevens kan terugvinden is bruikbaarder. Houd de oorspronkelijke meldingen intact en noteer daarnaast je beoordeling. Zo blijft een technisch feit te onderscheiden van jouw vermoeden over het gedrag.

Wat doe je eerst als de aanval nog loopt? #

Laat de betaalprovider en checkoutleverancier weten welke route geraakt wordt. Vraag om een maatregel die op die route aangrijpt en spreek af hoe je de werking controleert. Je kunt bijvoorbeeld de toegang tot een getroffen formulier laten beperken of de providerinstellingen laten beoordelen. Welke maatregel passend is hangt af van je integratie. Maak tijdens het incident geen algemene belofte dat een nieuwe plugin alle fraude stopt.

1. 1

   Baken de aanval af

   Leg het startmoment, betaalroute en relevante referenties vast; scheid geslaagde betalingen van afwijzingen.

2. 2

   Houd betrokken uitvoering tegen

   Markeer de concrete fysieke orders voor controle en bevestig met de inpakker dat ze nog niet vertrekken.

3. 3

   Beperk de getroffen route

   Laat provider of beheerder de controle invoeren op de route die kaartvalidatie of betalen mogelijk maakt.

4. 4

   Controleer geslaagde transacties

   Beoordeel ontvangst, orderkoppeling en vervolgstap afzonderlijk; behandel refunds via de provider.

5. 5

   Toets hervatting

   Controleer dat misbruik afneemt én dat echte klanten via de bedoelde route kunnen afrekenen.

Een tijdelijke blokkade hoort een eigenaar en evaluatiemoment te hebben. Anders kan een incidentmaatregel ongemerkt een permanente drempel voor je klanten worden. Leg op je eigen checkout begrijpelijk uit dat een betaling niet kon worden afgerond en hoe de klant hulp krijgt. Stuur niemand naar een losse betaalmethode die jouw normale ontvangstcontrole overslaat. Je moet ook tijdens het incident kunnen aantonen welke betaling bij welke order hoort.

Waarom zijn CAPTCHA en een IP-blokkade soms niet genoeg? #

Stripe schrijft dat CAPTCHA op de server moet worden gevalideerd en op alle verzoeken die kaartvalidatie of betaling mogelijk maken. Vraag je beheerder dus welke routes worden gecontroleerd. Alleen het zichtbare checkoutscherm voorzien van een extra stap vertelt je niet of een ander verzoek nog dezelfde betaalhandeling kan uitvoeren. De maatregel moet het doel beschermen, niet alleen de pagina waar een gewone klant begint.

Kies ook beperkingen die passen bij het waargenomen patroon. Een gedeeld IP-adres kan bij meerdere echte klanten horen, terwijl een aanvaller van bron kan wisselen. Laat daarom bekijken welke beschikbare signalen samen bruikbaar zijn. Stripes documentatie over geavanceerde fraudedetectie beschrijft aanvullende signalen uit de betaalintegratie. Bespreek met je leverancier welke daarvan jouw checkout werkelijk aanlevert en hoe dat aansluit op je privacy-informatie.

Test na de wijziging de volledige legitieme route: de klant rekent af, de provider bevestigt, de webshop verwerkt de juiste status en er ontstaat één uitvoerbare order. Een afname van fouten bewijst op zichzelf geen herstel; het kan ook betekenen dat niemand meer kan betalen. Vergelijk daarom betaalresultaten met echte checkoutpogingen. Gebruik uitsluitend de officiële testmogelijkheden van je provider voor technische controles.

Kunnen betrouwbare klanten je risicoblokkade omzeilen? #

Mollie documenteert twee lijsten: geblokkeerde en betrouwbare klanten. Een specifieke klantparameter kan voorrang krijgen boven een landparameter. Het beschreven voorbeeld is een vertrouwd e-mailadres dat wordt geaccepteerd ondanks een geblokkeerd IP-land. Voeg daarom tijdens een aanval niet elk e-mailadres toe waarvan iemand zegt dat het echt is. Een uitzondering kan het effect van je overige instellingen veranderen.

Controleer bestaande uitzonderingen en leg vast waarom een nieuwe nodig is. Mollie vermeldt daarnaast dat zijn screening op bekende consumentenfraude voorrang heeft boven je eigen lijsten. De uitkomst hangt dus niet uitsluitend af van jouw blokkade. Laat de provider de concrete transactie verklaren als een uitzondering anders werkt dan verwacht. Verander niet tegelijk allerlei landen, lijsten en acceptatieniveaus; dan kun je achteraf moeilijk bepalen welke wijziging het effect gaf.

Dit onderscheid is ook nuttig voor terugkerende klanten. Een herkenbaar e-mailadres is geen garantie dat de persoon achter een nieuwe bestelling dezelfde is. Beoordeel de nieuwe transactie op de beschikbare gegevens. Bewaar een korte reden voor vrijgave en herstel geen betaalstatus uitsluitend omdat de vorige bestelling probleemloos was. Je maakt daarmee een controle reproduceerbaar zonder elke klant als verdachte te behandelen.

Wat kost een kleine testbetaling als je er toch een pakket op verstuurt? #

Het bedrag van een geslaagde kleine betaling zegt weinig over de kosten van een onterecht uitgevoerd pakket. Je kunt goederen, verpakking en vervoer kwijt zijn. Voor een helder deelmodel gebruiken we alleen AirPost-constanten, geraadpleegd op 14 oktober 2026. De vervoerder en jouw productinkoop blijven buiten de som. Je krijgt dus een ondergrens voor twee uitvoeringsonderdelen, geen berekening van totale fraudeschade.

Bij één klein pakket is het platformdeel € 0,85 en de aanbevolen vergoeding voor de verzender € 2,25. Samen zijn die twee onderdelen € 3,10. Voor twee afzonderlijke kleine pakketten in hetzelfde rekenmodel is dat € 6,20. De afgesproken vergoeding kan afwijken. Deze bedragen betalen uitvoering; ze bevestigen geen kaartbetaling en bieden geen dekking voor een chargeback.

Bij AirPost voor webshops pakt een verzender orders uit jouw voorraad in en brengt ze weg. Houd de beslissing over verdachte klantbetalingen bij je webshop en provider. Stuur alleen gecontroleerde opdrachten door en spreek een stopprocedure af voor reeds vrijgegeven werk. De normale orderkosten kun je daarnaast bekijken met verzendkosten berekenen voor je webshop. Een geslaagde technische betaalpoging hoort niet zonder beoordeling een fysieke pakketbeweging te worden.