Betaaldiensten integreren: wat er werkelijk bij komt kijken
Een betaaldienst integreren is technisch niet moeilijk — de moderne diensten hebben goede documentatie en werkende voorbeelden. Wat het lastig maakt is alles rond het gelukkige pad: mislukte betalingen, terugbetalingen, terugboekingen, dubbele bestellingen en de vraag wat er gebeurt als de klant het tabblad sluit tijdens het betalen.
Deze gids behandelt de integratie zelf en, uitvoeriger, de randgevallen waar echt geld verloren gaat.
Kies de methoden die je markt gebruikt#
Betaalvoorkeuren zijn sterk regionaal. De verkeerde methoden aanbieden verliest verkoop bij het afrekenen, en dat is de duurste plek om iemand te verliezen.
| Methode | Waar het telt | Aandachtspunt |
|---|---|---|
| iDEAL | Onmisbaar in Nederland | Directe bevestiging, vrijwel geen terugboekingen |
| Creditcard | Internationaal, en zakelijk | Hogere kosten, terugboekingsrisico |
| Bancontact | België | Vergelijkbaar met iDEAL |
| PayPal | Internationaal, vertrouwde merknaam | Hogere kosten, eigen geschillenproces |
| Apple Pay en Google Pay | Mobiel, verhoogt conversie merkbaar | Vraagt HTTPS en domeinverificatie |
| Achteraf betalen | Populair in NL en DE | Aanbieder draagt risico, tegen een percentage |
| SEPA-overboeking | B2B en grote bedragen | Trage bevestiging; orders blijven hangen |
Begin met twee tot drie methoden die je markt werkelijk gebruikt. Elke extra methode is een afrekenkeuze meer en, subtieler, nog een pad dat je moet testen na elke platformupdate.
Hoe de integratie werkt#
De vorm is bij vrijwel alle moderne diensten hetzelfde, en het is de moeite waard hem te begrijpen omdat de faalwijzen eruit volgen.
- Je server maakt een betaalintentie aan met bedrag, valuta en bestelverwijzing.
- De klant wordt naar de betaalpagina van de dienst gestuurd, of vult een ingesloten formulier in.
- De klant autoriseert bij zijn bank of kaartuitgever, vaak met sterke authenticatie.
- De dienst stuurt de klant terug naar jouw retour-URL — die mag je nooit als bewijs van betaling gebruiken.
- De dienst stuurt een webhook naar je server met de definitieve status. Dít is de waarheid.
- Je server verifieert de webhookhandtekening, werkt de bestelling bij en verstuurt de bevestiging.
- Kaartgegevens raken je server nooit aan — dat houdt je buiten het zwaarste deel van PCI-compliance.
Stap vier en vijf zijn waar de meeste bugs zitten. De klant kan de browser sluiten voordat hij terugkeert; de webhook komt hoe dan ook. Bouw op de webhook, niet op de retour.
De randgevallen waar geld verloren gaat#
Deze verschijnen niet tijdens het testen en wel tijdens de eerste drukke week.
| Situatie | Wat er misgaat | Afhandeling |
|---|---|---|
| Webhook komt twee keer | Bestelling dubbel verwerkt, klant dubbel gemaild | Idempotentie: verwerk elke gebeurtenis-id één keer |
| Webhook komt vóór de retour | Race die de bestelstatus overschrijft | Statusovergangen expliciet maken, nooit terugdraaien |
| Klant sluit tabblad na betaling | Betaald, geen bestelling | Bestelling aanmaken op de webhook, niet op de retour |
| Betaling mislukt na voorraadreservering | Voorraad geblokkeerd door niets | Reservering laten verlopen na een vast venster |
| Deelterugbetaling | Boekhouding klopt niet | Terugbetalingen als eerste klas gebeurtenis modelleren |
| Terugboeking | Geld weg, product verzonden | Bewijs bewaren; risicoregels bij hoge bedragen |
| Dienst is offline | Nul omzet, niet minder omzet | Tweede methode als terugval |
Compliance en testen#
Een korte lijst die de dingen dekt die achteraf duur zijn wanneer ze ontbreken.
- Gebruik gehoste velden of een omleiding zodat kaartgegevens je server nooit raken — dat reduceert je PCI-omvang enorm.
- Sterke klantauthenticatie is verplicht in Europa; test het pad met een kaart die het afdwingt.
- Verifieer elke webhookhandtekening. Een niet-geverifieerde webhook is een openbaar eindpunt dat bestellingen als betaald kan markeren.
- Toon prijzen inclusief btw voor consumenten in Nederland, en maak verzendkosten zichtbaar vóór de laatste stap.
- Bewaar bestel- en betaalgegevens zolang de fiscale bewaarplicht vereist, en niet langer voor persoonsgegevens.
- Test terugbetalingen en deelterugbetalingen vóór de lancering, niet wanneer de eerste klant erom vraagt.
- Draai een echte transactie op productie met een echte kaart en betaal jezelf terug. Testmodus dekt niet alles.
Veelgestelde vragen
Welke betaaldienst moet ik kiezen?
Kies op basis van welke methoden hij in jouw markt ondersteunt, welke kosten hij rekent bij jouw omzet, en hoe goed hij in je platform integreert. Voor een Nederlandse shop is iDEAL-ondersteuning het eerste filter. Prijsverschillen tussen de grote aanbieders zijn bij bescheiden omzet klein genoeg om niet doorslaggevend te zijn.
Moet ik PCI-compliant zijn?
Ja, maar de omvang hangt volledig af van hoe je integreert. Gebruik je gehoste betaalvelden of een omleiding zodat kaartgegevens nooit je server raken, dan valt je verplichting terug op de eenvoudigste zelfbeoordeling. Verwerk je kaartgegevens zelf, dan ben je in een heel ander regime — vrijwel geen enkele webshop hoort dat te doen.
Waarom heb ik webhooks nodig als er een retour-URL is?
Omdat de retour-URL afhangt van de browser van de klant. Sluit hij het tabblad, valt zijn verbinding weg, of blijft hij hangen op de bankpagina, dan komt de retour nooit — maar het geld is wel afgeschreven. De webhook komt van de server van de dienst en komt hoe dan ook aan. Bouw de bestelling op de webhook en gebruik de retour alleen om de klant iets te tonen.
Hoe voorkom ik dubbele bestellingen?
Maak de webhookverwerking idempotent: bewaar de gebeurtenis-id van elke verwerkte webhook en negeer herhalingen. Diensten sturen webhooks meerdere keren als bevestiging uitblijft, dus dubbele afleveringen zijn normaal gedrag, geen storing. Zonder deze controle stuur je klanten twee bevestigingsmails en boek je twee keer af in je voorraad.
betaaldienst integrerenideal integratiebetaalprovider webshopwebhook betalingpci complianceonline betalingen
