Wat is 3D Secure precies?
Kort antwoord
3D Secure is het protocol waarmee de bank van je klant een online kaartbetaling bevestigt, meestal via de bankapp. Het is de manier waarop kaartbetalingen voldoen aan sterke klantauthenticatie (SCA): de Europese eis dat een betaler zich met minimaal twee onafhankelijke factoren identificeert.
Iedereen die weleens online betaalt kent het moment: je vult je kaartgegevens in, en voor de bevestiging springt je bankapp open met een vraag om een vingerafdruk of pincode. Dat is 3D Secure. Voor de klant is het één extra handeling. Voor wie een webshop, platform of SaaS-product bouwt, is het een stuk ingewikkelder: het bepaalt hoe je betaalstroom eruitziet, welke betalingen mislukken, en wie er opdraait voor de schade als het misgaat.
In dit artikel leg ik uit wat sterke klantauthenticatie inhoudt, hoe 3D Secure dat technisch invult, wanneer je klant de stap juist niet te zien krijgt, en welke keuzes je in je eigen software moet maken om dit netjes af te handelen.
SCA: twee van de drie factoren, onafhankelijk van elkaar
Sterke klantauthenticatie komt uit de tweede Europese betaaldienstenrichtlijn, PSD2. De uitwerking staat in een aparte technische verordening, de RTS bij PSD2, die sinds 14 september 2019 van toepassing is. De kern: bij een elektronische betaling op afstand moet de betaler zich bewijzen met minstens twee elementen uit verschillende categorieën.
- Kennis: iets dat alleen de betaler weet, zoals een pincode of wachtwoord.
- Bezit: iets dat alleen de betaler heeft, zoals een geregistreerde telefoon of een kaartlezer.
- Inherentie: iets dat de betaler is, zoals een vingerafdruk of gezichtsscan.
De factoren moeten onafhankelijk zijn: het doorbreken van de één mag de ander niet aantasten. Een code per sms naar hetzelfde toestel waarop je ook de betaling doet, is daarom niet zonder meer voldoende. Dat is precies waarom banken zijn overgestapt op bevestiging in hun eigen app met biometrie — de app is het bezit, de vingerafdruk de inherentie.
Dynamic linking: de code hoort bij dit bedrag en deze ontvanger
Een detail dat in de praktijk vaak wordt onderschat: de RTS eist dat de authenticatiecode dynamisch gekoppeld is aan het bedrag en aan de begunstigde, en dat de betaler die twee bij het bevestigen ook echt te zien krijgt. Wijzigt het bedrag of de ontvanger, dan vervalt de code.
Voor je software betekent dat: je mag een geautoriseerd bedrag niet achteraf ophogen. Een nabestelling, een toeslag of een prijscorrectie is geen kleine aanpassing maar een nieuwe transactie die opnieuw langs de authenticatie moet. Wie dat niet in het ontwerp meeneemt, loopt vast zodra er variabele kosten in het spel komen — verzendkosten die pas bij het inpakken bekend zijn, of verbruik dat achteraf wordt afgerekend.
Een authenticatie geldt voor precies dit bedrag en precies deze ontvanger. Alles wat daarna verandert, is een nieuwe betaling.
Hoe een 3D Secure-transactie verloopt
3D Secure — officieel EMV 3-D Secure, beheerd door EMVCo — regelt de communicatie tussen drie partijen: de winkelier, het kaartnetwerk en de uitgevende bank. Vandaar de drie domeinen in de naam. Het verloop is in de kern altijd hetzelfde.
- De winkelier stuurt context mee: naast het bedrag gaat er een pakket gegevens mee over de bestelling, het apparaat, het afleveradres en de historie van de klant. Hoe rijker die gegevens, hoe beter de bank het risico kan inschatten.
- De bank beoordeelt het risico: op basis van die gegevens plus de eigen kennis van de klant besluit de uitgevende bank of er een bevestiging nodig is.
- Geruisloos of met een stap: bij een laag risico gaat de betaling zonder zichtbare onderbreking door. Bij twijfel krijgt de klant een bevestiging in de bankapp — de stap die iedereen kent.
- De uitkomst gaat terug: de winkelier krijgt te horen of de authenticatie is gelukt, en pas daarna volgt de eigenlijke autorisatie van de betaling.
Die eerste stap is de enige waar jij invloed op hebt, en hij wordt vaak verwaarloosd. Hoe meer betrouwbare context je meestuurt — een bestaand klantaccount, een eerder gebruikt afleveradres, een herkenbaar apparaat — hoe groter de kans dat je klant niets merkt. Een kassaproces dat gasten dwingt om anoniem af te rekenen, levert systematisch meer onderbrekingen op.
Wanneer SCA niet hoeft: de vrijstellingen
De regelgeving kent een reeks uitzonderingen. Belangrijk om te begrijpen: een vrijstelling is een verzoek. Jij of je betaaldienstverlener kunt erom vragen, maar de uitgevende bank beslist of ze hem honoreert. Reken er dus nooit op als vaststaand gegeven.
| Vrijstelling | Voorwaarde | Typisch gebruik |
|---|---|---|
| Lage bedragen op afstand | Transactie maximaal € 30, en sinds de laatste authenticatie hooguit € 100 cumulatief of vijf opeenvolgende betalingen | Kleine aankopen, losse credits |
| Contactloos aan de kassa | Transactie maximaal € 50, en sinds de laatste authenticatie hooguit € 150 cumulatief of vijf opeenvolgende betalingen | Fysieke kassa, pinnen zonder code |
| Risicoanalyse (TRA) | Lage gemeten fraudecijfers bij de betaaldienstverlener, met een bedragsgrens die daarvan afhangt | Grotere webshops via hun PSP |
| Terugkerende betalingen | Zelfde bedrag, zelfde begunstigde; authenticatie alleen bij opzetten of wijzigen | Abonnementen met een vast tarief |
| Vertrouwde begunstigde | De klant zet jou zelf op een lijst bij zijn eigen bank | Vaste leveranciers, herhaalaankopen |
| Beveiligde zakelijke processen | Betaalprocessen die alleen voor zakelijke betalers toegankelijk zijn | Inkoopkaarten, bedrijfsbetalingen |
De risicoanalyse-vrijstelling verdient toelichting, omdat er een misverstand over bestaat. De bedragsgrens waaronder je betaaldienstverlener hem mag inroepen, hangt af van zijn eigen gemeten fraudecijfer: bij ten hoogste 0,13 procent fraude op kaartbetalingen op afstand geldt een grens van € 100, bij 0,06 procent € 250 en bij 0,01 procent € 500. Die cijfers staan in de bijlage bij de RTS en worden per kwartaal berekend. Het is dus geen knop die je zelf omzet, maar een uitkomst van hoe schoon de portefeuille van je betaaldienstverlener is — en indirect ook van hoe schoon jouw verkeer is.
Werkt het eigenlijk? Wat de cijfers laten zien
De vraag of al die extra stappen iets opleveren, is inmiddels met data te beantwoorden. In hun gezamenlijke rapport over betaalfraude van december 2025 stellen de Europese Centrale Bank en de Europese Bankautoriteit vast dat transacties mét sterke klantauthenticatie duidelijk minder fraudegevoelig zijn dan transacties zonder — en dat het verschil bij kaartbetalingen het grootst is. Kaartfraude lag zeventien keer hoger wanneer de ontvangende partij buiten de Europese Economische Ruimte zat, waar de authenticatieplicht niet geldt.
Tegelijk laat datzelfde rapport zien dat de totale fraudeschade in de EER steeg van 3,5 miljard euro in 2023 naar 4,2 miljard euro in 2024, terwijl het fraudepercentage stabiel bleef rond 0,002 procent van de transactiewaarde. De aard van de fraude verschuift: waar authenticatie werkt, verplaatsen fraudeurs zich naar vrijgestelde transacties en naar het manipuleren van klanten om zélf een frauduleuze betaling goed te keuren. Een authenticatiestap beschermt namelijk niet tegen een klant die is overtuigd om hem uit te voeren.
Dat is precies de reden dat er in Europa alweer een volgende ronde regelgeving aankomt. Wat daarin verandert aan aansprakelijkheid en fraudebestrijding beschreef ik eerder in PSD3 en de PSR.
Wat dit betekent voor je software
Je betaaldienstverlener regelt het protocol, maar de gevolgen landen in jouw applicatie. Vier ontwerpkeuzes bepalen of dit soepel loopt of een bron van storingen wordt.
1. Een onderbroken betaling is een normale toestand
Zodra er een bevestiging in de bankapp nodig is, verlaat de klant je applicatie en komt hij later terug — of niet. Je betaling heeft daarmee een tussentoestand die minuten kan duren. Wie alleen "gelukt" en "mislukt" kent in zijn datamodel, krijgt dubbele bestellingen en spookorders. Behandel de betaalstatus als een levenscyclus die stuurt op de gebeurtenissen van je betaaldienstverlener, en verwerk die meldingen idempotent, want dezelfde melding komt met zekerheid een tweede keer binnen.
2. Een weigering wegens ontbrekende authenticatie is geen fout
Een bank kan een vrijstelling weigeren en alsnog om authenticatie vragen. Dat is een voorziene uitkomst, geen storing. Je software moet die netjes opvangen en de betaling opnieuw aanbieden mét authenticatie, in plaats van de klant een technische foutmelding te tonen. Bij abonnementen betekent dit dat je de klant terug moet kunnen halen om een afschrijving te bevestigen.
3. Onderscheid betalingen door de klant en door jou
Bij een transactie die jij start terwijl de klant er niet bij is — een verlenging, een nabetaling, een afrekening achteraf — is er per definitie niemand om te authenticeren. Zulke transacties moeten als zodanig gemarkeerd meegaan in het verzoek, met een verwijzing naar de oorspronkelijke, wél geauthenticeerde toestemming. Ontbreekt die markering, dan worden ze standaard geweigerd. Dit is de meestvoorkomende oorzaak van mislukte verlengingen bij terugkerende betalingen.
4. Bewaar wat er is geauthenticeerd
Leg per transactie vast of er authenticatie heeft plaatsgevonden, welke vrijstelling is aangevraagd en welke uitkomst de bank gaf. Dat heb je nodig zodra er een terugboeking binnenkomt: bij een geslaagde authenticatie ligt het risico van een betwiste transactie in de regel niet meer bij jou, maar dat moet je wel kunnen aantonen. Achteraf reconstrueren lukt zelden.
Valkuilen die ik het vaakst zie
- Te weinig context meesturen: alleen kaartnummer en bedrag doorgeven dwingt de bank tot voorzichtigheid. Stuur alles mee wat je legitiem hebt: het klantaccount, het afleveradres, de bestelhistorie.
- Achteraf het bedrag ophogen: de authenticatie hoort bij één bedrag. Verzendkosten of toeslagen die pas later bekend zijn, horen vóór de autorisatie vast te staan.
- Vrijstellingen als garantie behandelen: een aangevraagde vrijstelling kan worden geweigerd. Bouw altijd het pad waarin alsnog authenticatie volgt.
- Abonnementen zonder terugvalroute: verandert het bedrag van een abonnement, dan valt het buiten de vrijstelling voor vaste reeksen. Zonder een route om de klant om bevestiging te vragen, stopt de incasso stilletjes.
- De uitkomst niet bewaren: bij een geschil is de vraag of er is geauthenticeerd doorslaggevend. Bewaar die uitkomst bij de transactie, niet alleen in de logs van je betaaldienstverlener.
Mijn kijk op sterke klantauthenticatie
Toen de authenticatieplicht werd ingevoerd, was de vrees dat elke extra stap conversie zou kosten. Die vrees was terecht, maar de oplossing bleek niet te liggen in zo veel mogelijk vrijstellingen aanvragen. Ze ligt in de kwaliteit van wat je meestuurt. Webshops die hun klanten kennen — accounts, herhaalaankopen, vaste adressen — zien hun klanten veel minder vaak een bevestigingsscherm krijgen dan webshops waar iedereen anoniem afrekent. De regelgeving beloont dus precies wat je om andere redenen toch al zou willen bouwen.
Wat ik in projecten het vaakst tegenkom, is dat de authenticatiestap wél is ingebouwd maar de randgevallen niet. De gelukkige route werkt: klant betaalt, bevestigt, klaar. Wat ontbreekt is het pad waarin de klant de bankapp wegklikt, tien minuten later terugkomt, en ondertussen ook nog een tweede keer op "betalen" heeft gedrukt. Dat is geen zeldzaamheid — dat is dagelijkse kost zodra je volume krijgt.
En dan de bredere beweging. De betaalwereld schuift op richting bevestiging met biometrie in een vertrouwde app, precies zoals inloggen dat doet met passkeys. Voor wie software bouwt is dat goed nieuws: de klant kent het gebaar al. De uitdaging zit niet meer in de techniek van de authenticatie zelf, maar in de administratie eromheen — welk bedrag, welke toestemming, welke uitkomst, en wat je doet als het misloopt.
— Jasper
Zo helpt Coding Agency hierbij
Wij bouwen betaalstromen in webshops, platformen en SaaS-producten waarin de authenticatie geen losse stap is maar onderdeel van een doordacht model: een volledige statusmachine per transactie, geverifieerde en idempotent verwerkte meldingen, markering van transacties die jij zelf start, en vastlegging van elke authenticatie-uitkomst. Of je nu werkt met Mollie, Stripe of een andere betaaldienstverlener — het patroon eronder is hetzelfde.
Loop je tegen mislukte verlengingen aan, of wil je je bestaande webshop of platform laten doorlichten op de betaalstroom? Neem contact op voor een vrijblijvend gesprek.
