Chargebacks en storneringen: terugboekingen opvangen in je software.

Wat is een chargeback precies?

Bijna elk platform dat betalingen verwerkt loopt er vroeg of laat tegenaan: er verdwijnt geld dat je al als omzet had geboekt. Een klant betwist een creditcardbetaling, een consument boekt een incasso terug, of een abonnement wordt maanden later alsnog ongedaan gemaakt. In de boekhouding is dat een correctie. In je software is het een gebeurtenis waar je op moet reageren — en juist dat wordt bij het bouwen zelden ingepland.

In dit artikel zet ik uiteen wat er technisch en juridisch gebeurt bij een terugboeking, hoe de termijnen per betaalmethode verschillen, en hoe je je applicatie zo inricht dat een chargeback geen brandje is maar een normale statuswijziging.

Chargeback of stornering: twee verschillende werelden

In het dagelijks spraakgebruik heet elke terugboeking een "chargeback", maar er lopen drie verschillende mechanismen door elkaar. Ze hebben elk hun eigen spelregels:

• Chargeback (kaartbetaling): de kaarthouder betwist de transactie bij zijn eigen bank. Die bank start een dispute via het kaartnetwerk. Jij krijgt een reden te horen ("goederen niet ontvangen", "transactie niet herkend") en mag met bewijs reageren.
• Stornering (SEPA-incasso): de betaler laat een automatische incasso terugdraaien via zijn eigen bank. Er is geen inhoudelijke beoordeling en geen verweerprocedure — het geld gaat gewoon terug.
• Refund (door jou): jij betaalt zelf terug. Dit is de enige route bij iDEAL en Wero, en meestal ook de goedkoopste oplossing bij een klacht.

Het verschil is niet academisch. Bij een chargeback heb je invloed op de uitkomst en heb je bewijs nodig. Bij een stornering heb je die invloed niet en verschuift het probleem naar je debiteurenbeheer: de vordering staat gewoon weer open.

Een chargeback win of verlies je met bewijs dat je maanden eerder had moeten vastleggen.

De termijnen per betaalmethode

De belangrijkste ontwerpbeslissing in je software volgt uit één vraag: hoe lang kan een betaling nog omkeren? Dat bepaalt hoe lang je gegevens bewaart, wanneer je een order als definitief beschouwt en wanneer je veilig kunt uitbetalen aan een derde partij.

Kaartbetalingen

Bij een creditcardbetaling kan de kaarthouder de transactie tot ongeveer 180 dagen na de aankoop of de levering laten terugdraaien, meldt Mollie in zijn documentatie over chargebacks. Het bedrag plus de chargebackkosten worden van je saldo afgeschreven zodra de claim binnenkomt — nog vóórdat er een oordeel is. Stripe beschrijft dezelfde volgorde: het bedrag en de disputekosten worden meteen ingehouden, je hebt afhankelijk van het kaartnetwerk zeven tot eenentwintig dagen om bewijs aan te leveren, en de uitspraak van de uitgevende bank volgt daarna nog eens tientallen dagen later. Een dispute is dus geen incident van een middag, maar een dossier dat maanden open kan staan.

Automatische incasso

Voor SEPA-incasso liggen de termijnen vast in het rulebook van de European Payments Council: bij de standaard Europese incasso mag de betaler tot acht weken na afschrijving terugboeken zonder enige reden op te geven. Ontbreekt een geldig mandaat, dan loopt die termijn op tot dertien maanden. De zakelijke Europese incasso kent dat terugboekrecht niet: de debiteur doet er expliciet afstand van. Dat verschil is voor B2B-software vaak doorslaggevend.

iDEAL en Wero

iDEAL is een overboeking die de klant zelf bij zijn eigen bank goedkeurt. Er zit geen kaartnetwerk tussen dat geld kan terughalen, dus een chargeback bestaat er niet. Wil je terugbetalen, dan doe je dat zelf. Voor wie in Nederland verkoopt is dat een groot voordeel — en meteen de reden dat de overgang naar Wero, die ik eerder beschreef in iDEAL wordt Wero, ook voor je risicoprofiel relevant is.

Wat je software moet vastleggen

Een dispute win je met bewijs dat de klant heeft besteld en gekregen wat hij bestelde. Dat bewijs moet er al zijn op het moment dat de claim binnenkomt — met terugwerkende kracht reconstrueren lukt vrijwel nooit. Leg daarom bij elke transactie automatisch vast:

• Bestelcontext: tijdstip, IP-adres, user agent en het account waarmee besteld is. Dit weerlegt de meestgebruikte reden: "ik herken deze transactie niet".
• Akkoord op de voorwaarden: welke versie van je algemene voorwaarden en welk annuleringsbeleid de klant heeft geaccepteerd, met datum. Bewaar de versie, niet alleen een vinkje.
• Levering: het track-and-trace-nummer en de afleverstatus bij fysieke producten, of de logs van eerste inlog en gebruik bij een dienst of licentie.
• Communicatie: bevestigingsmails, supportberichten en eventuele eerdere restitutieaanbiedingen. Een klant die drie maanden ongestoord gebruikmaakte van je platform, is zichtbaar in je eigen logs.
• Mandaatgegevens: bij incasso het mandaatkenmerk, de datum van ondertekening en het bewijs van de vooraankondiging. Zonder geldig mandaat sta je dertien maanden lang zwak.

Dit is precies waar een fatsoenlijke audit trail zich terugverdient. Niet voor de accountant, maar voor het moment waarop je binnen twee weken moet aantonen wat er een half jaar geleden gebeurde.

Terugboekingen verwerken zonder je administratie te slopen

De meeste schade bij terugboekingen ontstaat niet door het verloren bedrag, maar door de rommel die het achterlaat: een order die op "betaald" blijft staan, een abonnement dat doorloopt terwijl er niets meer binnenkomt, of een boekhouding die niet meer aansluit. Vier ontwerpkeuzes voorkomen dat.

1. Maak de terugboeking een expliciete status: een betaling heeft niet twee toestanden (open, betaald) maar een levenscyclus die ook chargeback_ontvangen, in_verweer, verloren en teruggewonnen kent. Zolang die statussen ontbreken, wordt elke terugboeking een handmatige correctie.
2. Luister naar de webhooks van je betaaldienstverlener: elke PSP stuurt gebeurtenissen bij een nieuwe dispute, een deadline en een uitkomst. Verwerk die geautomatiseerd en verifieer de handtekening, zodat niemand anders die status kan zetten.
3. Verwerk die webhooks idempotent: dezelfde melding komt bij herhaling binnen, zeker als je even traag antwoordt. Zonder idempotente verwerking boek je één chargeback twee keer af. Ken elke gebeurtenis een unieke sleutel toe en negeer duplicaten.
4. Koppel het door naar je boekhouding: een terugboeking is een creditering plus kosten, geen verdwenen factuur. Wie zijn webshop aan het boekhoudpakket koppelt, moet dit pad expliciet meenemen, anders sluit de bankmutatie nooit aan.

Draai je een platform waarop je uitbetaalt aan derden — een marktplaats, een bemiddelingsdienst, een verhuurplatform — dan komt er nog een keuze bij: hoe lang houd je geld vast voordat je doorbetaalt? Betaal je meteen uit en volgt er later een chargeback, dan draai je zelf op voor het verschil. Dat is geen technisch detail maar een bedrijfsrisico dat je in het model moet verwerken.

Valkuilen die ik het vaakst zie

• Bewijs pas verzamelen bij de claim: dan zijn sessiegegevens weg, is de koerier de zending vergeten en staat er niets meer vast. Verzamel bij de bestelling.
• Geen deadline-bewaking: reactietermijnen van zeven tot eenentwintig dagen zijn hard. Een dispute die in een gedeelde mailbox blijft liggen, verlies je automatisch.
• Toegang laten doorlopen: bij een teruggeboekt abonnement moet de toegang stoppen. Verrassend vaak blijft een account gewoon actief omdat niemand die koppeling legde.
• Alles willen betwisten: bij kleine bedragen is verweer duurder dan het bedrag zelf. Bepaal vooraf een grens waaronder je direct terugbetaalt en leg die regel in software vast.
• Vooraankondiging bij incasso overslaan: zonder tijdige aankondiging van bedrag en datum verrast je afschrijving de klant, en een verraste klant storneert.

Mijn kijk op terugboekingen

Ik merk dat terugboekingen bijna altijd pas ter sprake komen als ze er al zijn. Bij het ontwerp van een betaalstroom gaat de aandacht naar de gelukkige route: klant kiest, betaalt, order gaat door. De ongemakkelijke route — geld dat weer weggaat — belandt in de categorie "dat regelen we handmatig". Tot het er twintig per maand zijn.

Wat mij betreft hoort de terugboeking vanaf dag één in het datamodel. Niet omdat het vaak gebeurt, maar omdat het achteraf inbouwen betekent dat je bestaande orders, facturen en boekingen moet herzien. Dat is altijd duurder dan het meteen goed neerzetten.

En het tweede punt: behandel een chargeback niet als een aanval. Het merendeel van de claims die ik voorbij zie komen, zijn geen fraude maar onduidelijkheid — een onherkenbare omschrijving op het bankafschrift, een abonnement waarvan de klant vergat dat het doorliep, een levering die stilletjes vertraagde. Dat los je op in je communicatie, niet in je verweerprocedure. Een herkenbare betaalomschrijving en een mail vóór elke incasso schelen meer terugboekingen dan het beste dossier.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen betaalstromen in maatwerksoftware en SaaS-platformen waarin de terugboeking net zo serieus is ontworpen als de betaling zelf: geverifieerde webhooks, idempotente verwerking, een volledige statusmachine per transactie en automatische bewijsverzameling bij elke bestelling. Of je nu werkt met Mollie, Stripe of een andere betaaldienstverlener — het patroon eronder is hetzelfde.

Loop je vast op storneringen bij terugkerende betalingen, of wil je je bestaande betaalkoppeling laten doorlichten? Neem contact op voor een vrijblijvend gesprek.

Bronnen: European Payments Council (europeanpaymentscouncil.eu), Betaalvereniging Nederland (betaalvereniging.nl), Mollie Support en Stripe Docs.