Betaalproviders onderhouden hun eigen kleine catalogus met Stripe-testkaarten, en de reden is praktisch in plaats van vrijgevig: een sandbox die geen weigering kan produceren, kan het codepad dat er een afhandelt niet testen. Echte betaalreferenties kunnen hiervoor nooit worden gebruikt, zowel omdat het gevaarlijk is als omdat de uitkomsten onvoorspelbaar zouden zijn, dus publiceren providers nummers waarvan het gedrag vooraf door hun eigen systemen is vastgelegd.
Dit artikel legt uit wat die nummers zijn, waarom een provider ze überhaupt zou publiceren, hoe weigeringen en authenticatie worden gesimuleerd, en waar de grenzen van een door de provider geleverde lijst beginnen.
Wat een providertestkaart is
Een testkaart is een nummer dat de sandbox van een betaalprovider herkent. Wanneer het in een betaalverzoek opduikt, neemt de sandbox geen contact op met een bank. Ze zoekt het nummer op in een tabel, bepaalt wat de uitkomst van het verzoek zou moeten zijn, en geeft die uitkomst terug — een succes, een specifieke weigeringsreden, of een verzoek om verdere authenticatie.
Die opzoeking is het hele mechanisme. Het nummer hoeft bij niemand te horen, de vervaldatum hoeft niet echt te zijn zolang hij in de toekomst ligt, en de beveiligingscode wordt alleen getoetst aan de vormen die de sandbox verwacht. Omdat het gedrag gescript is in plaats van opgelost, krijgen twee ontwikkelaars die dezelfde testkaart in hun eigen sandboxaccounts gebruiken hetzelfde resultaat, en dat maakt bugmeldingen over betaalstromen reproduceerbaar.
Waarom publiceren betaalproviders hun eigen testnummers?
Elke gateway implementeert haar eigen interpretatie van de antwoorden van de kaartnetwerken. Weigeringscodes, authenticatiestappen en gedrag bij nieuwe pogingen verschillen per provider, en die verschillen zijn precies de dingen die een integratietest moet oefenen. Een generiek synthetisch nummer kan bewijzen dat een formulier zestien cijfers accepteert; alleen een door de provider herkend nummer kan bewijzen dat jouw applicatie omgaat met de specifieke manier waarop de provider zegt dat de kaart is geweigerd.
Er is ook een veiligheidsargument. Uitgevers willen dat ontwikkelaars nummers gebruiken waarvan zeker is dat ze in geen enkele omgeving, onder geen enkele configuratie, naar een echt account verwijzen. Een samengestelde lijst is de manier waarop de provider garandeert dat een sandboxtest niet per ongeluk een echte transactie kan worden.
De catalogus verandert naarmate providers functies toevoegen, dus de gezaghebbende lijst is altijd de eigen documentatie van de provider. Lees die daar in plaats van een versie te vertrouwen die in een blogpost of een repository is gekopieerd, deze hieronder inbegrepen.
De ene testkaart die bijna elke ontwikkelaar gebruikt
Onder de nummers die Stripe documenteert, is er één de facto de standaard geworden: een zestiencijferige waarde die met vier begint en wordt gevormd door hetzelfde korte patroon van de cijfers vier en twee te herhalen. Aangeboden met een willekeurige toekomstige vervaldatum en een willekeurige driecijferige beveiligingscode, levert ze in de sandbox een geslaagde afboeking op.
Haar populariteit is makkelijk te begrijpen. Ze is memorabel, voldoet aan de opmaakregels die een echte kaart zou volgen, en laat een ontwikkelaar binnen enkele minuten na de start een volledige afrekenstroom doorlopen. Ze is ook de reden dat zoveel betalingsintegraties nauwelijks getest zijn, omdat één succesgeval je niets vertelt over wat er gebeurt wanneer een betaling wordt geweigerd.
Twee waarschuwingen zijn het waard om ronduit te noemen. Ten eerste is dit nummer alleen betekenisvol binnen een providersandbox; het op een live gateway richten levert een mislukte autorisatie op en een regel in iemands fraudelogs. Ten tweede is een geslaagde sandboxafboeking een gesimuleerde uitkomst, geen bewijs dat de kaart echt is of dat het account erachter bestaat — de sandbox heeft het nooit gevraagd.
Hoe simuleer je een weigering?
Weigeringen worden meestal gestuurd door nummers die de provider voor bepaalde uitkomsten reserveert, en de lijst dekt doorgaans de gevallen waarop integratiecode daadwerkelijk moet vertakken:
- Een generieke weigering, gebruikt om te controleren dat het formulier een herstelbare fout toont in plaats van te crashen.
- Een weigering die aangeeft dat de uitgever wil dat de klant contact opneemt, wat een doodlopende weg is voor de betaalstroom.
- Onvoldoende saldo, de enige weigering die een gebruiker aannemelijk kan oplossen door een andere kaart te gebruiken.
- Een antwoord van een verlopen kaart, dat test of de eigen datumvalidatie van je formulier en de gateway het eens zijn.
- Een verwerkingsfout, die doorgaans opnieuw moet worden geprobeerd in plaats van aan de klant als definitief antwoord te worden getoond.
- Een blokkering in fraudestijl, die de stroom moet stoppen in plaats van de gebruiker richting een nieuwe poging te duwen.
Elk daarvan verdient een bewust pad in je applicatie: een andere melding, een ander beleid voor nieuwe pogingen, en een andere registratie in je eigen database. Eén weigeringsnummer voor alle gevallen gebruiken verbergt de verschillen totdat een klant er een tegenkomt.
Authenticatie en 3-D Secure-stromen testen
Moderne kaartbetalingen bevatten vaak een stap waarin de klant wordt doorgestuurd, of een ingebedde uitdaging te zien krijgt, om de betaling met zijn bank te bevestigen. Sandboxen simuleren dit met speciale nummers: sommige lokken een uitdaging uit die altijd wordt gehaald, andere een uitdaging die altijd faalt, en weer andere een stroom die zonder enige uitdaging wordt voltooid.
De gevallen die het waard zijn om te dekken, gaan zelden over het gelukkige pad. Wat gebeurt er wanneer de klant de uitdaging halverwege verlaat en naar je site terugkeert? Blijft je order voor altijd in een wachtende staat, of lost ze op naar een definitieve uitkomst? Maakt een herhaalde poging een tweede order aan? Authenticatie introduceert een stap waarin je systeem de gebruiker een paar seconden kwijt is, en elke integratie heeft op zijn minst één bug in dat venster.
Voor ontwikkelaars: scenariolijsten verslaan één magisch nummer
De gewoonte die het waard is om op te bouwen, is testdekking plannen als een lijst met uitkomsten in plaats van een lijst met nummers. Schrijf de toestanden op waarin je betaalstroom kan eindigen — geautoriseerd, geweigerd als herhaalbaar, definitief geweigerd, authenticatie vereist, authenticatie mislukt, verlaten, verlopen — en zoek daarna voor elk één sandboxinvoer.
Houd die koppeling in de repository naast de tests, met een notitie over uit welke versie van de providerdocumentatie ze komt, en herzie haar wanneer de provider haar catalogus bijwerkt. Wanneer een betaalincident later wordt onderzocht, is de koppeling wat je in staat stelt te zeggen welke toestanden zijn geoefend en welke nooit gedekt waren.
Een paar kleinere punten besparen echte tijd. Bewaar de sandboxreferenties alleen in de testomgeving, en controleer de configuratie voordat je iets draait, want een testkaart tegen een live sleutel is precies het ongeluk dat deze hele praktijk bestaat om te voorkomen. Assert op de uitkomst die je systeem heeft vastgelegd, niet alleen op het antwoord van de gateway, want de interessante bugs leven tussen die twee. En beslis vroeg hoe je een sandboxtransactie in je eigen tabellen van een echte zult onderscheiden, zodat een toekomstige audit niet hoeft te gokken.
Kaarten genereren zonder provideraccount
Providercatalogi zijn het juiste gereedschap wanneer je een gescripte uitkomst nodig hebt, en het verkeerde gereedschap wanneer je volume nodig hebt. Een formulier dat honderd verschillende kaarten moet accepteren, een demo die een verscheidenheid aan netwerken moet tonen, of een fixtureset die lengtes en prefixen bestrijkt, is beter gediend met gegenereerde data.
De kaartnummersgenerator op deze site produceert nummers voor een gekozen netwerk of een willekeurige mix, met vervaldata en plaatsvervangende beveiligingscodes, en geen ervan is aan een account gebonden. Elke waarde is structureel geldig en is nooit uitgegeven, dus wordt ze door een opmaakcontrole geaccepteerd en door elke echte gateway geweigerd.
Gebruik de twee soorten data voor verschillende taken: providertestnummers voor gescripte gateway-uitkomsten, gegenereerde nummers voor alles wat de gateway nooit ziet. De netwerkvergelijking is nuttig wanneer je één kaart van elk merk nodig hebt, en de checklist voor betaalformulieren somt de stromen op waarin die kaarten moeten opduiken.
Volgende stappen
Schrijf de uitkomstenlijst voor je eigen betaalstroom uit, koppel elk item aan een sandboxinvoer uit de actuele documentatie van je provider, en zet de items die je nog niet kunt produceren op een zichtbare backlog. Genereer daarna een aparte batch synthetische kaarten voor de tests op formulierniveau, zodat de twee soorten testdata nooit door elkaar raken.