28 okt 2026 Betalingen testen in je webshop: wat je controleert voordat de checkout faalt

In het kort: Bij betalingen testen controleer je of elke manier van betalen van begin tot eind werkt. Dus de betaling zelf, maar ook weigeringen, extra controles, late berichten van je betaalprovider, refunds en de orderstatus in je andere systemen. De meeste betaalproblemen zitten in die randgevallen. Automatiseer de vaste routes tegen de testomgeving van je provider en draai ze bij elke regressietest.

De checkout is de enige pagina waar een bug je meteen geld kost. Toch wordt de betaalkoppeling in veel webshops één keer getest, bij de lancering, en daarna niet meer. Dan verandert de provider iets, komt er een nieuwe betaalmethode bij of krijgt het ordersysteem een update. Niemand merkt het, tot klanten gaan bellen. Met goed betalingen testen hoor je het als eerste.

Wat is betalingen testen, en waarom gaat het mis na livegang?

Bij betalingen testen controleer je de hele keten, van de knop “betalen” tot een afgeronde order in je systemen. Die keten heeft meer schakels dan je denkt. Er is je webshop, en er is de betaalprovider: het bedrijf dat de betaling tussen je shop en de banken afhandelt. Dan volgen de bank of app van de klant, het statusbericht terug naar je shop, en je order-, voorraad- en mailsystemen. Elk van die onderdelen verandert in zijn eigen tempo. Je provider werkt zijn platform bij. Een bank past zijn app aan. Je team voegt een betaalmethode of kortingsregel toe. Elk van die wijzigingen kan de keten breken, zonder dat er één regel van je eigen checkoutcode verandert. Bij e-commerceklanten zien we dat vaak. Een nieuwe koppeling wordt één keer gecontroleerd en komt daarna nooit in de regressie- of sanitytests terecht. Betalen is daar het duidelijkste voorbeeld van.

Het resultaat is een stil soort fout. De betaling lukt, maar de order blijft op “in behandeling” staan. Of de klant betaalt twee keer, of een refund komt nooit bij de bank aan.

Wat test je in een betaalproces?

Test de randgevallen, niet alleen de route waarin alles goed gaat. Een geslaagde kaartbetaling op een laptop controleert iedereen. De incidenten komen uit wat eromheen gebeurt. Gebruik deze lijst als startpunt en leg hem naast de betaalmethoden die je aanbiedt.

• Elke methode op elk apparaat. iDEAL, creditcards, wallets en achteraf betalen, op desktop en mobiel.
• Weigeren en afbreken. Een geweigerde kaart, een klant die bij de bank stopt, een sessie die verloopt. De order moet onbetaald blijven, de voorraad moet terugkomen en de klant moet een duidelijke melding zien.
• Sterke klantauthenticatie. In de EU hebben de meeste online kaartbetalingen een extra controle nodig, zoals een code in de bankapp. De Europese regels voor sterke klantauthenticatie leggen dat vast. Voor kaarten loopt het via 3-D Secure. Test de extra controle, de route zonder controle en een mislukte controle.
• Statusberichten. Je provider stuurt je shop een bericht als een betaling lukt of mislukt. Test wat er gebeurt als dat bericht laat komt, dubbel of helemaal niet. Een dubbel bericht mag geen dubbele order opleveren.
• Refunds. Volledige en gedeeltelijke terugbetalingen, gestart vanuit je shop en vanuit het dashboard van de provider.
• Bedragen. Kortingen, verzendkosten, btw, valuta en afronding. Het afgeschreven bedrag moet gelijk zijn aan het ordertotaal.
• De keten achter de shop. Orderstatus, voorraad, factuur en bevestigingsmail na elke uitkomst.

Hoe automatiseer je betaaltests?

Je automatiseert betaaltests tegen de sandbox van je provider: een testomgeving die werkt als het echte platform, zonder dat er echt geld verschuift. Providers bieden testkaartnummers die een vaste uitkomst geven, zoals een geslaagde betaling, een weigering of een extra beveiligingscheck. Stripe en Adyen documenteren die bijvoorbeeld. Zo wordt elk geval uit de lijst hierboven herhaalbaar. Houd ook je eigen testdata onder controle. Bij e-commerceklanten falen geautomatiseerde tests vaak omdat testdata niet beheerd wordt, of steeds verandert in gedeelde omgevingen. De oplossing is een vaste, reproduceerbare set testklanten, producten en kortingscodes.

Niet elke check heeft een browser nodig. Statusberichten test je sneller op API-niveau, door de shop een nep-bericht dubbel of te laat te sturen. Houd daarboven één volledige UI-route per belangrijke betaalmethode, als onderdeel van de ketentest van je webshop. Draai de hele set bij elke regressietest, zodat een wijziging ergens in de keten de volgende ochtend zichtbaar is.

Twee kanttekeningen. Een sandbox is geen productie: sommige methoden gedragen zich net iets anders, en een echte goedkeuring in een bankapp automatiseer je lastig. Veel teams doen daarom na een grote release ook één kleine echte betaling. En automatisering vervangt geen mensen. Voeg je een nieuwe betaalmethode toe, laat een tester hem dan op een echte telefoon proberen, zoals een klant dat zou doen.

Wat betekent dit voor je team?

Betaaltests beschermen je alleen zolang ze blijven draaien. Providers passen hun testomgeving aan, testkaarten worden vervangen en er komen nieuwe methoden bij. Elke wijziging in je shop kan ook betekenen dat een test moet worden bijgewerkt. In veel webshopteams komt dat onderhoud terecht bij wie de tests heeft gebouwd. En het schiet erbij in zodra die persoon het druk heeft of vertrekt. Zo raakt betalen na één keer testen in de vergetelheid.

Met Test Automation as a Service bouwen we die betaaltests samen met je team. Ze draaien elke nacht mee met de rest van je regressietests, naast de checks op voorraad, ERP en levering die we bij e-commerce testen meenemen. Verandert je provider of je shop, dan houden wij de tests betrouwbaar. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt.

Een eerste stap voor vandaag: zet al je betaalmethoden op een rij. Kijk daarna welke gevallen uit de lijst hierboven je huidige tests echt afdekken.

Veelgestelde vragen

Wat is een sandbox van een betaalprovider?

Een sandbox is een testomgeving van je betaalprovider. Hij werkt als het echte platform, maar er verschuift geen echt geld. Met testkaartnummers roep je uitkomsten op, zoals een weigering.

Kun je betalingen in productie testen?

Alleen klein en gecontroleerd, bijvoorbeeld met één echte betaling na een grote release, gevolgd door een refund. Doe al het andere testwerk in de sandbox, zodat klanten en je boekhouding er niets van merken.

Hoe test je 3D Secure?

Gebruik de testkaarten van je provider die de extra controle oproepen. Test dan drie uitkomsten: de klant slaagt voor de controle, zakt ervoor, of krijgt hem niet.

Hoe vaak draai je betaaltests?

Automatisch bij elke regressietest, minstens elke nacht. Draai ze ook na elke wijziging aan je checkout, je providerinstellingen of je ordersysteem.