PrestaShop-chargebacks: aparte geldstroom, bewijs, boeking en menselijke vrijgave

Een chargeback in PrestaShop is geen retour met een andere knop. De klant start hem via de bank of kaartuitgever, de PSP trekt geld en kosten uit je saldo en jij krijgt een bewijsdeadline die niets te maken heeft met de status van je order. Wie dat als één refund verwerkt, verliest precies de informatie die later nodig is voor boeking, verweer en controle.

Deze gids is voor een webshop met PrestaShop die chargebacks als een aparte geldstroom wil verwerken. Ik gebruik Mollie als concreet voorbeeld en zet Stripe ernaast waar de werkwijze verschilt. Op 5 oktober 2026 zijn de genoemde documentatie, productdetails en prijzen gecontroleerd. De route blijft bruikbaar als je AFAS Profit, Twinfield, Moneybird of Exact Online gebruikt. Let op: Mollie’s Dispute Portal en de bijbehorende responsevelden en meldingen waren op die controledatum beta en dus alleen zichtbaar voor geselecteerde accounts met toegang.

Een chargeback is een formele betwisting van een geslaagde betaling via de kaartuitgever of bank, waarbij de PSP het betwiste bedrag en vaak een afzonderlijke dispuutkost uit je saldo haalt. Een refund start jij zelf; een chargeback heeft een reden, een bewijsdeadline, een dossier en een uitkomst. Daarom horen beide gebeurtenissen in aparte statussen en boekingsregels.

Wat je nodig hebt vóór de eerste melding

Begin met eigenaarschap. PrestaShop kent de order, orderregels en klantcontext. De PSP kent het payment-ID, chargeback-ID, bedrag, reden, status, deadline en payout. Je boekhouding kent de rekening, periode en uiteindelijke boeking. Geen van die systemen mag ontbrekende informatie invullen op basis van alleen een bedrag.

Je hebt minimaal dit nodig:

Minimale vaardigheden zijn API- en webhookbeheer, idempotente verwerking, basiskennis van clearing en grootboekboekingen, en zorgvuldig omgaan met persoonsgegevens. Wijs vóór de bouw een proceseigenaar in Finance aan, een technisch eigenaar voor connectoren en opslag, een bewijs-eigenaar met vervanger en een accountant aan die de boekingspolicy goedkeurt. Gebruik als voorbeeld-SLA: nieuwe disputen binnen vier werkuren triëren, drie werkdagen vóór response_due_at escaleren, bewijs uiterlijk één werkdag vóór de providerdeadline laten goedkeuren en een uitkomst binnen één werkdag na de providerupdate boeken. Stel deze tijden schriftelijk vast; ze zijn een interne startnorm, geen Mollie-termijn.

Voor een eerste productieversie is dit een indicatieve budgetorde, gecontroleerd op 5 oktober 2026 en geen leveranciersofferte: opslag en logging €25–€100 per maand, implementatie €4.000–€12.000, testen met boekhouder en proefdata €750–€2.500 en beheer €250–€900 per maand. Neem in die raming ook back-ups, rechtenbeheer, monitoring en een jaarlijkse her-test van de boekingsregels op.

Bij PrestaShop maak je een aparte Webservice-sleutel met alleen de resources die je uitleest. Voor deze route zijn orders, order_details, order_payments, order_invoices, order_slips en order_histories een logisch begin. De actuele PrestaShop 9-resource voor orderbetalingen bevat onder meer bedrag, valuta en transactie-ID (documentatie gecontroleerd 5 oktober 2026). Schrijfrechten op orders zijn pas nodig als je bewust een status terugschrijft. Een chargebackdossier hoeft PrestaShop niet te veranderen om boekhoudkundig correct te zijn.

Gebruik in de voorbeelden Mollie als betaalprovider. De Mollie Chargebacks API laat je een dispuut ophalen met zowel het parent payment-ID als het chargeback-ID. Bij Stripe heet het object een dispute en zit dezelfde relatie tussen betaling, dispute en balance transaction. De namen verschillen, het datamodel niet.

De operationele basis voor betalingen, payouts en gecontroleerde vrijgave staat in de PrestaShop-AFAS-keten met vaste bron-ID’s. Voor Twinfield blijft een deelrefund per orderregel gekoppeld aan creditnota, betaling en match. De bredere periodieke controle tussen bankfeed, payouts, refunds en chargebacks loopt via een aparte close-keten.

Je boekhouder moet vóór productie één keuze goedkeuren: komt een chargeback eerst op een tussenrekening voor betwiste bedragen, of direct op een kosten- of verliesrekening? Dat hangt af van je administratie, rapportage en de kans dat je wint. De techniek kan beide uitvoeren. Zij mag die boekhoudkundige policy niet zelf verzinnen.

Concrete stappen: van dispute-ID naar menselijke vrijgave

1. Splits de gebeurtenissen voordat je een koppeling bouwt

Maak eerst twee routes. Een refund is een actie van jou, vaak na een retour of klantafspraak. Een chargeback is een formele betwisting via de kaartuitgever. Een refund kan requested, processing, succeeded of failed zijn. Een chargeback kan bijvoorbeeld response_required, under_review, won of lost zijn. Zet refunded nooit als synoniem voor chargeback_lost in één statusveld.

Dat verschil is financieel belangrijk. Bij een refund weet je wie de actie startte, welk bedrag je bewust terugstuurt en welke creditnota erbij hoort. Bij een chargeback kan het betwiste bedrag door de PSP uit je saldo worden gehaald terwijl je nog moet kiezen tussen accepteren en verweren; de fee volgt volgens de provider en de uitkomst. Stripe beschrijft die balance-impact van disputes, terwijl de uitkomst van het verweer later volgt.

Maak in je interne model daarom ten minste deze records:

• payment: de oorspronkelijke betaling en de koppeling naar PrestaShop;
• refund: een door jou gestarte terugbetaling, met eventueel orderregel en creditnota;
• chargeback: het dispuut, de reden, het betwiste bedrag, de deadline, een eventuele PSP-hold en de uitkomst;
• chargeback_fee: de afzonderlijke kostenregel van de PSP of kaartketen;
• evidence_submission: de bewijsversie, indiener, datum en providerrespons;
• release_decision: de menselijke beslissing over acceptatie, verweer en boeking.

De eerste controle is simpel: zoek op één payment-ID alle refunds en chargebacks. Als een chargeback op een betaling met een nog lopende refund staat, moet de route blokkeren voordat er een tweede compensatie ontstaat.

2. Leg de volledige sleutelset vast

Een ordernummer is niet genoeg. Eén order kan meerdere betaalpogingen hebben, een payout bevat meerdere orders en een chargeback kan maar een deel van een betaling raken. Sla daarom deze sleutelset op:

Leg unieke beperkingen aan op psp_payment_id + chargeback_id en op evidence_version. Een dubbele webhook mag een ontvangstlog toevoegen, maar geen tweede chargebackrecord. Dezelfde regel geldt voor een herhaalde boekingsopdracht.

3. Gebruik de webhook alleen als wekker

De klassieke Mollie-webhook stuurt het ID van het gewijzigde object. Je haalt daarna zelf de actuele status op. De webhook kan binnenkomen voor een betaalstatus, refundstatus of chargeback. Mollie beschrijft expliciet dat je het object opnieuw moet ophalen en dat de webhook maximaal vijftien seconden krijgt om met HTTP 200 te antwoorden. Sla het ontvangen ID op, antwoord snel en verwerk de zware logica buiten de HTTP-aanroep.

De verwerkingsvolgorde wordt dan:

1. Ontvang het object-ID en sla tijdstip, headers en ruwe payload op.
2. Zoek het ID op in je eigen sleutelregister.
3. Haal het payment-, refund- of chargebackobject opnieuw op bij de PSP.
4. Vergelijk de nieuwe status met de laatst bekende status.
5. Maak of wijzig alleen het bijbehorende record.
6. Zet een statuswijziging met deadline in de queue.

Een onbekend ID is geen reden om de webhook eindeloos opnieuw te laten sturen. Registreer het als onbekende bron, geef HTTP 200 terug volgens de providerinstructie en laat een aparte controle bepalen of er een orderimport ontbreekt.

4. Maak de bewijsdeadline leidend

Zet nooit een algemene regel als dertig dagen in je systeem. De termijn hangt af van de betaalmethode, reden en provider. Bij Mollie staat de exacte deadline op het dispute als Response due date. De termen Response required, Defend en Accept horen bij de nieuwe Mollie Dispute Portal. Die portal was op 5 oktober 2026 beta voor een select aantal accounts met toegang; presenteer deze UI en rechten dus niet als de universele Mollie-route. De Mollie-responseflow beschrijft de portalstatussen, de per-betaalmethode afwijkende termijnen en de gevolgen van missen (gecontroleerd 5 oktober 2026).

Heeft je account geen beta-toegang, of valt de betaalmethode buiten de portal, volg dan de klassieke of per-betaalmethode-instructies van Mollie, de acquirer of de kaartketen. Sla de deadline en het werkelijke antwoordkanaal uit die melding of dat dossier op; neem niet aan dat er altijd een portal, dezelfde velden of dezelfde uploadlimieten zijn.

Maak voor iedere kaart in de queue drie tijden:

• received_at: wanneer je systeem het dispuut zag;
• response_due_at: de exacte deadline uit de PSP;
• escalate_at: je eigen interne alarm, bijvoorbeeld drie werkdagen eerder.

De provider zelf kan helpen, maar jij blijft eigenaar. Als de beta-portal voor je account is ingeschakeld, vervangen Mollie-notificaties de eerdere per-methode-disputemeldingen en ontvangen alleen gebruikers met DisputeWrite-rechten de actietaken. Zonder die beta-toegang of buiten de ondersteunde methode blijft de klassieke/per-betaalmethode-melding en responseflow leidend. De actuele meldingsuitleg noemt ook de kanalen en de herinneringen drie en één dag vóór de deadline (gecontroleerd 5 oktober 2026). Gebruik zulke meldingen als vangnet, niet als vervanging voor je eigen queue. Routeer de taak naar één persoon en één vervanger. Een gedeelde mailbox is geen eigenaar.

5. Bouw bewijs per reden op en laat een mens beslissen

Een goed dossier is geen map met alles wat je ooit van de klant hebt opgeslagen. Het is een korte keten die de betwiste claim beantwoordt. Voor een bestelling die volgens de klant niet is aangekomen, heb je bijvoorbeeld ordergegevens, verzendmoment, vervoerder, trackingstatus en klantcommunicatie nodig. Voor een fraudemelding zijn betaalauthenticatie en leveringscontext relevant als die gegevens werkelijk beschikbaar zijn. Gebruik geen bewijs dat de reden niet beantwoordt.

Neem per dossier op:

1. de claim van de klant en de providerreden;
2. de oorspronkelijke payment- en orderreferentie;
3. de relevante orderregels, factuur en leveringsgegevens;
4. een tijdlijn met order, betaling, verzending, contact en melding;
5. de voorgestelde actie: accepteren of verweren;
6. de naam van de beslisser en de bewijsversie;
7. de providerrespons na indiening.

Als je account toegang heeft tot de Mollie Dispute Portal en de betaalmethode daar wordt ondersteund, bevat het defense-formulier een vrije tekst van maximaal 5.000 tekens, een optionele voorgestelde deelrefund en bijlagen. Dat zijn beta-/per-betaalmethodevelden, geen universele Mollie-eisen. In de klassieke of per-betaalmethode-flow kunnen antwoordkanaal, velden, bestandstypen en limieten anders zijn. Na Submit is het portalverweer niet meer wijzigbaar; maak daarom evidence-v1 vóór indiening en bewaar de exacte tekst en bestanden buiten de PSP. Mollie koppelt die velden en beperkingen aan de specifieke betaalmethode (gecontroleerd 5 oktober 2026).

De kaartuitgever beoordeelt het verweer volgens de regels van de betaalmethode. Mastercard benadrukt in de op 24 januari 2024 gepubliceerde merchant-uitleg dat de merchant de claim met passende transactiedetails en bewijs moet beantwoorden, niet met een algemeen verhaal. De categorie van de betwisting bepaalt welke informatie de issuer kan beoordelen.

6. Boek bedrag, fee en uitkomst als aparte events

Gebruik een clearingrekening per PSP, valuta en entiteit. Het settlementrapport is de brug tussen de PSP en de bank, niet de oorspronkelijke omzetboeking. Mollie toont in een Settlement Report afzonderlijke categorieën voor payments, refunds, chargebacks en kosten, waaronder chargeback fees. De actuele rapportage kan per payout tot op transactieniveau worden uitgesplitst (gecontroleerd 5 oktober 2026).

Een PSP kan een bedrag direct van je beschikbare saldo afhalen, of volgens zijn contract tijdelijk reserveren als hold. Leg hold_status, hold_amount en de vrijgavedatum apart vast. Een hold is nog geen definitief verlies en mag daarom niet automatisch op dezelfde rekening landen als een verloren chargeback.

Bij Mollie geldt volgens de op 5 oktober 2026 gecontroleerde fee-uitleg een belangrijk tijdsverschil: de chargeback fee wordt pas retroactief geboekt wanneer het dispute definitief Lost is. Een dispuut in Response required of Under review en een Won-dispuut hebben daar geen fee. Het bedrag en de structuur hangen af van de betaalmethode; boek dus pas de fee wanneer de provider die in het settlement- of statementdetail toont. Lees de actuele Mollie fee-uitleg.

De technische boekingslogica ziet er zo uit:

De precieze grootboekrekening, btw-behandeling en periode laat je door je accountant vastleggen. Wat je niet doet: een chargeback op de retourrekening zetten omdat er toevallig geld teruggaat, of de fee in het verschil van de payout verstoppen. Het verschil moet verklaarbaar blijven.

Voorbeeldboekingen, €149,95, geen btw uitgewerkt. Dit is een uitvoerbaar rekenvoorbeeld met illustratieve grootboeknamen; laat je accountant de rekeningnummers en de gekozen tussenrekening goedkeuren. De oorspronkelijke betaling komt op PSP-clearing. Bij ontvangst verplaats je het betwiste bedrag naar een aparte tussenrekening. Daarna laat je de twee mogelijke uitkomsten zien. De payout-regels tonen ook hoe je de settlementcomponenten sluit.

De twee payoutregels zijn alternatieve scenario’s, niet allebei boekingen voor hetzelfde dispuut. In het Lost-scenario moet je eerst de €500,00 overige payments op clearing hebben geregistreerd; de netto bankontvangst is dan €335,05. In het Won-scenario komt €149,95 terug en wordt die recovery in de eerstvolgende payout meegenomen. Zo zijn zowel de €149,95, de fee, de uitkomst als de payout terug te vinden.

Stripe hanteert hetzelfde principe. De Payout reconciliation report van Stripe bevat een itemized CSV met payments, refunds, disputes, fees en andere balance transactions (gecontroleerd 5 oktober 2026). De payoutdatum kan afwijken van de dag waarop de bank het bedrag boekt. Bewaar dus chargeback_created_at, settlement_at, posted_at en accounting_period afzonderlijk.

7. Zet menselijke vrijgave achter de uitzonderingsqueue

Automatiseer het verzamelen, niet het oordeel. Een chargeback mag automatisch naar een dossier gaan, maar Accept, Defend, de boekingsperiode en de definitieve vrijgave horen bij een bevoegde rol. De EDPB adviseert unieke gebruikers, least-privilege-toegang, het verwijderen van oude rechten en regelmatige review; pas die uitgangspunten toe op order-, klant- en betaalgegevens (richtsnoer geraadpleegd 5 oktober 2026). NIST SP 800-53 Rev. 5, gepubliceerd in september 2020 en bijgewerkt met een 5.2.0-release in 2025, noemt voor auditrecords onder meer gebeurtenis, tijdstip, bron, uitkomst en identiteit. Gebruik dat als ontwerpchecklist, niet als Nederlandse wettelijke norm.

Laat het vrijgavescherm per kaart tonen:

• match tussen PrestaShop-order, payment-ID en chargeback-ID;
• betwist bedrag, valuta en afzonderlijke fee;
• response due date en resterende tijd;
• reden, bewijsversie en voorgestelde actie;
• eventuele refund op hetzelfde payment-ID;
• boekingsperiode, rekening en payoutreferentie;
• eigenaar, beslisser en laatste wijziging.

Meet vier waarden die rechtstreeks uit de werkstroom komen: matchpercentage, bewijsdeadline die op tijd is gehaald, uitzonderingsduur en goedkeuringsduur. Een goede start is 100 procent match op payment- en chargeback-ID, nul dubbele compensaties en geen kaart zonder eigenaar. Kies daarna je eigen grens voor uitzonderingsduur en goedkeuringsduur.

Na deze stappen zie je de echte omvang van de klus: de orderkoppeling is het korte deel. De waarde zit in de bewijsversie, de deadline, de dubbele-compensatiecheck en de boekingspolicy. Dat is precies waar een losse PSP-plugin meestal ophoudt.

Valkuilen die je chargebackstroom laten ontsporen

Je behandelt een chargeback als refund

Een refund komt uit jouw proces. Een chargeback start buiten je webshop en kan al geld uit je PSP-saldo halen voordat je een beslissing hebt genomen. Mitigatie: aparte records, statussen, eigenaren en boekingsregels. Blokkeer een refund op hetzelfde payment-ID zolang een chargeback of lopende refund nog niet is beoordeeld.

Je gebruikt een vaste deadline voor alle betaalmethoden

Een vaste termijn maakt de queue overzichtelijk, maar kan de echte deadline overschrijden. Mitigatie: lees response_due_at uit het PSP-object, sla de bronwaarde op en maak je eigen alarm eerder. De termijn staat bij Mollie per dispuut en bij Stripe per dispute en betaalmethode.

Je vertrouwt op de webhookpayload

Een webhook kan alleen melden dat er iets veranderde. Hij vertelt niet automatisch de volledige actuele toestand en kan opnieuw binnenkomen. Mitigatie: sla het ID op, haal het object opnieuw op, maak de verwerking idempotent en geef snel een HTTP 200 terug.

Je boekt de fee weg in het payoutverschil

Een chargeback fee is geen afronding. Als je hem in een verzamelverschil stopt, verdwijnt het bewijs van de werkelijke kostprijs. Mitigatie: gebruik de fee-ID als afzonderlijke regel en laat de settlement op componentniveau sluiten.

Je dient bewijs in zonder versie

Mollie maakt een ingediend verweer niet meer wijzigbaar. Mitigatie: maak een dossier-snapshot vóór indiening, geef die een versienummer en bewaar tekst, bestanden, hash, indiener en providerrespons.

Je laat een robot accepteren omdat het bedrag klein is

Een klein bedrag kan deel uitmaken van een patroon, een belangrijke klantrelatie of een fout in je verzendproces. Mitigatie: maak een policy met bedrag, reden, klantwaarde en bewijssterkte. Laat de robot alleen een voorstel maken; laat de bevoegdheid bij een mens.

Je zet het chargebackevent in de verkoopperiode

De oorspronkelijke verkoop, PSP-settlement, bankboeking en chargebackmelding kunnen op verschillende dagen vallen. Mitigatie: bewaar alle relevante datums en laat de accountant de policy voor gesloten perioden vastleggen. Een nieuw dispute-event overschrijft de oude verkoop niet.

Je geeft te brede toegang

Een integratie die orders, refunds, boekingen en vrijgave tegelijk mag uitvoeren kan een fout door de hele keten trekken. Mitigatie: splits ingest, bewijs, boeking en release in rollen, connectoren en systeemgebruikers. Log elke vrijgave met actor en tijdstip.

Beslis-kader: kant-en-klaar, orkestreren of maatwerk?

De keuze volgt niet uit je aantal orders, maar uit je zwaarste uitzondering. Eén PSP met weinig disputen kan prima met een standaardkoppeling werken als die payment-ID, chargeback-ID, deadline, fee en bewijsstatus bewaart. Zodra je voor uitzonderingen een spreadsheet of gedeelde inbox nodig hebt, ben je al buiten de veilige kant-en-klaarroute.

Gebruik deze criteria:

• Eén bron of meerdere bronnen: één PSP en één administratie zijn eenvoudiger dan meerdere PSP's, entiteiten of valuta.
• Stabiele of wisselende uitzonderingen: een vaste mapping past bij een connector; verschillende bewijs- en periodekeuzes vragen een eigen queue.
• Boekingsrisico: chargebacks, deelrefunds en kosten vragen aparte records en een bevoegdheidsstap.
• Beheer: n8n of Make kan API's en meldingen verbinden, maar niet vanzelf je boekingspolicy, bronversies of eigenaarschap ontwerpen.
• Terugvindbaarheid: als een medewerker vanuit de boeking niet naar order, payment, dispute en bewijs kan klikken, is de route nog niet klaar.

Voor n8n geldt op 5 oktober 2026: Cloud Starter kost €20 per maand bij jaarlijkse betaling voor 2.500 workflowuitvoeringen met onbeperkte stappen. Pro kost €50 per maand voor 10.000 uitvoeringen. Er is ook een self-hosted Community Edition. De actuele n8n-prijspagina noemt deze grenzen en het feit dat per volledige workflowuitvoering wordt afgerekend. Die prijs koopt geen AFAS-inrichting, bewijsopslag of boekhoudkundige verantwoordelijkheid.

Uitgewerkt voorbeeld: één PrestaShop-chargeback door de hele keten

Dit is een fictief, provider-onafhankelijk oefenscenario met echte productnamen en oefendata. De webshop draait PrestaShop 9, gebruikt Mollie als API-context en boekt in AFAS Profit. De portalvelden zijn alleen van toepassing als het account beta-toegang heeft en de betaalmethode wordt ondersteund. De €15,00 fee in dit scenario is bewust een oefenbedrag, geen algemeen Mollie-tarief; Mollie rekent een fee pas bij definitief Lost, niet bij opening of tijdens Under review, en Won-disputen hebben geen fee. Zie de Mollie fee-uitleg, gecontroleerd 5 oktober 2026.

De melding

Op 5 oktober 2026 komt een webhook binnen voor payment tr_abc123. De nieuwe status bevat chargeback chb_456, reden product_not_received, bedrag €149,95 en valuta EUR. In dit oefenscenario toont het providerbericht Response required en een Response due date van 19 oktober 2026 om 23:59. Op 5 oktober is er nog géén chargeback fee geboekt: de fee hoort pas bij de latere Lost-uitkomst.

De workflow doet het volgende:

1. Slaat het webhook-ID, tijdstip en ruwe bericht op.
2. Haalt het chargebackobject en parent payment opnieuw op.
3. Vindt PrestaShop-order 10482, orderregel 7811, factuur INV-2026-10482 en payoutreferentie stl_2026_1005.
4. Maakt exception_id = cb-2026-00456 met eigenaar Finance en alarm op 14 oktober.
5. Controleert of er al een refund op tr_abc123 bestaat. Dat is niet zo.
6. Blokkeert de financiële vrijgave van de order, zonder de operationele order terug te draaien.

Het bewijsbesluit

De order is op 28 september verzonden. Het vervoerdersportaal toont levering op 30 september om 14:16, met track-en-trace NL123456789. In de klantmail van 1 oktober vraagt de klant om een refund, maar de supportmedewerker heeft nog geen refund uitgevoerd. Het dossier bevat:

De finance-eigenaar kiest Defend, maakt evidence-v1 en dient vóór de deadline in. release_decision bewaart actor, tijdstip, reden en hashes van de bijlagen. De status wordt under_review. Er komt geen extra refund, want er is al een chargebackprocedure voor hetzelfde payment-ID.

De boeking

Op 5 oktober wordt alleen het bedrag als open betwist bedrag geregistreerd; de €15,00 fee staat nog niet in de administratie. De openstaande route is: debet Betwiste bedragen €149,95, credit PSP-clearing €149,95. De oorspronkelijke omzetboeking blijft gekoppeld aan de factuur. De exacte grootboekrekeningen komen uit de goedgekeurde policy.

Op 21 oktober meldt de provider Lost omdat het verweer niet is toegewezen. Dan verschijnt in dit oefenscenario de €15,00 fee retroactief in het statement. Boek het verlies als debet Chargebackverlies €149,95 / credit Betwiste bedragen €149,95 en de fee als debet Chargebackkosten €15,00 / credit PSP-clearing €15,00. Als er in dezelfde settlement €500,00 aan andere payments staat, is de voorbeeldpayout €335,05: €500,00 minus €149,95 en €15,00. De concrete debet/creditregels staan in Stap 6.

Ter controle blijft ook de alternatieve Won-tak getest: bij Won boek je debet PSP-clearing €149,95 / credit Betwiste bedragen €149,95, zonder fee, en sluit je de recovery in de eerstvolgende payout. Die tak is een testvariant van hetzelfde dossier; de feitelijke casus hierboven eindigt Lost.

De KPI's voor dit voorbeeld zijn: matchpercentage 100 procent, op tijd ingediend 1 van 1, uitzonderingsduur 16 dagen, goedkeuringsduur 2 werkdagen en dubbele compensaties 0. Dat zijn geen mooie dashboardcijfers naast het proces. Ze bewijzen of de geldstroom werkelijk te volgen is.

Vergelijkingstabel: welke bouwroute kies je?

Prijzen en productdetails zijn gecontroleerd op 5 oktober 2026. Een licentieprijs zegt niets over de uren voor mapping, testdata, boekhoudkundige goedkeuring en beheer.

Kant-en-klaar is een goede keuze wanneer je uitzonderingen zeldzaam en voorspelbaar zijn. n8n of Make past wanneer de regels vaststaan, maar je bronnen en meldingen uit meerdere systemen komen. Maatwerk is pas nodig als deadline, bewijs, boekingsperiode en menselijke bevoegdheid per dossier een wezenlijk onderdeel van de normale route zijn.

De volwassen chargebackketen eindigt dus niet bij Verweer indienen. Zij eindigt wanneer je jaren later nog kunt aanwijzen welke betaling werd betwist, welk bewijs is gebruikt, wie de beslissing nam, welke fee is geboekt en waarom het bedrag uiteindelijk wel of niet terugkwam. Dat is de grens tussen een losse betaalmelding en een geldstroom die je administratie vertrouwt.