Twee PSP’s koppelen aan één ERP: van routing tot menselijke vrijgave

Je hebt Mollie voor iDEAL en Stripe voor kaarten. De checkout werkt. Tot Finance vraagt waarom de bankpayout niet gelijk is aan de orders, welke provider een refund uitvoerde en of een retry misschien twee keer heeft geboekt. Dan blijken twee betaalproviders geen twee koppelingen te zijn, maar twee vocabularia voor één geldstroom.

Een canoniek transactiedossier verbindt routing, provider-ID’s, betalingen, payouts, refunds, chargebacks en fees met één interne betekenis. De providers mogen hun eigen statussen en rapporten houden. Je ERP krijgt één controleerbaar verhaal, met een eigenaar voor elk verschil.

Een multi-PSP-reconciliatie is het samenbrengen van betalingen uit meerdere betaalproviders in één financieel dossier. Dat dossier bewaart de routekeuze, alle lokale provider-ID’s, settlementcomponenten, fees, refunds, chargebacks, retries en ERP-referenties. Alleen exact verklaarde regels schrijven automatisch door; onzekere uitkomsten gaan naar menselijke vrijgave.

De productdetails, API-documentatie en prijsinformatie hieronder zijn gecontroleerd op 15 oktober 2026. De bedragen in het uitgewerkte voorbeeld zijn expliciet oefendata, geen tarieven van Mollie of Stripe.

Wat je nodig hebt voor één geldstroom

Begin met de vraag wie welk feit bezit. Een ERP is niet automatisch de bron van een betaalstatus en een PSP is niet automatisch de bron van je omzet. Als je die grens niet vastlegt, schrijft elke connector een stukje waarheid en moet iemand later raden hoe de stukjes bij elkaar horen.

Budgetorde voor implementatie en beheer

Voor één webshop, twee PSP’s, één ERP, één entiteit en EUR is dit, gecontroleerd op 15 oktober 2026, een bruikbare eerste begroting, exclusief btw. De eenmalige kolom omvat analyse, datamapping, bouw, testen, documentatie en livegang. Het jaarlijkse beheer omvat monitoring, updates, kleine correcties en incidentruimte, maar niet PSP- of ERP-kosten, connectorlicenties, hosting of migraties.

Dit zijn planningsordes, geen offertes. Een Nederlandse marktindicatie die op 20 april 2026 is bijgewerkt, noemt voor een middelcomplexe API-koppeling 60 tot 120 uur en 20 tot 30 procent van de bouwkosten per jaar voor doorlopende kosten; een tweede indicatie, bijgewerkt op 12 oktober 2026, noemt €5.000 tot €15.000 voor een standaardkoppeling en vanaf €15.000 voor een complexe integratie. Als extra rekenanker rapporteert het 2026-overzicht van Freelapp een mediaan van €95 per uur voor freelance software engineers. De tabel vertaalt die marktindicaties naar dit multi-PSP-scenario, waar één canonieke ledger, settlementcomponenten en gecontroleerde ERP-writes meer vragen dan een simpele A-naar-B-koppeling.

Voor de orkestratieroute publiceert een Nederlandse n8n-implementatieaanbieder vanaf €4.500 voor setup, vijf basisworkflows, training en één maand ondersteuning, terwijl managed hosting vanaf €450 per maand begint. Zie dit als een leveranciersindicatie, niet als marktgemiddelde; de actuele n8n Cloud-licentie staat verderop.

Bij PrestaShop 9 bevatten de resources voor order_payments onder meer orderreferentie, bedrag, valuta, betaalmethode en transaction_id. In order_details staan ook product_quantity_return en product_quantity_refunded. Die velden zijn bruikbaar voor de bronkoppeling, maar je eigen dossier moet de provider- en ERP-ID’s daarnaast bewaren. De actuele PrestaShop-documentatie beschrijft deze velden en het onderscheid tussen bestelde, geretourneerde en terugbetaalde aantallen (gecontroleerd op 15 oktober 2026).

De sleutelset

Maak één canonical_transaction_id per economische transactie. Daaronder hangen pogingen en geldgebeurtenissen. Gebruik bijvoorbeeld deze velden:

Gebruik ordernummer, e-mailadres, bedrag of datum nooit als enige sleutel. Een klant kan twee orders van €149,95 betalen. Een payout kan betalingen van meerdere dagen bevatten. De relatie tussen de sleutels is het dossier.

Toegang, testdata en bevoegdheden

Je hebt leesrechten op de webshop, beide PSP-accounts en het ERP nodig. Schrijfrechten geef je alleen aan connectoren die ze echt nodig hebben. Voor AFAS Profit is de Client credentials flow bedoeld voor machine-to-machine-koppelingen. Het access-token is één uur geldig, de app connector bepaalt welke Get- en UpdateConnectoren beschikbaar zijn en de client secret hoort in een geheimenbeheerder. AFAS beschrijft de flow en de rechtenverdeling in de actuele OAuth-documentatie (gecontroleerd op 15 oktober 2026).

Leg ook vast wie een refund voorbereidt, wie een chargebackdossier beoordeelt, wie een boeking mag vrijgeven en wie een periode mag sluiten. De persoon die een voorstel maakt, hoeft niet automatisch zijn eigen uitzondering te mogen goedkeuren.

Test minimaal met:

• één betaling via Mollie en één via Stripe;
• een mislukte eerste poging met een onzekere time-out;
• een volledige en een gedeeltelijke refund;
• een chargeback met aparte fee;
• twee payments met hetzelfde bedrag;
• twee payouts met verschillende settlementdata;
• een onbekende betaling zonder orderreferentie;
• een dubbele webhook;
• een ERP-write die na verzending een time-out geeft;
• een gesloten boekingsperiode.

0/8

• Bronhouder per financieel feit is vastgelegd
• Eén canonical_transaction_id en vaste provider-ID’s zijn gekozen
• Routebesluit, provider, merchant account en pogingnummer worden opgeslagen
• Clearingrekening per PSP, entiteit en valuta is benoemd
• Testset bevat refunds, chargebacks, retries, dubbele bedragen en onbekende betalingen
• AFAS, Twinfield of het gekozen ERP heeft een externe sleutel en read-back-route
• Uitzonderingsqueue heeft reden, eigenaar, bewijs, deadline en status
• Refund, chargeback en periodevrijgave hebben bevoegde rollen

De twee bestaande controles blijven nodig. PSP-fees reconciliëren van rate card naar herstelboeking behandelt de contractuele feecontrole. De maandafsluiting met bankfeed, payouts, refunds en chargebacks behandelt periode en clearing. Deze gids zet er de laag boven die beide PSP’s dezelfde betekenis geeft.

Concrete stappen: van routing naar ERP-read-back

Je brengt de twee PSP’s terug tot één controleerbare geldstroom: eerst leg je routing en pogingen vast, daarna vertaal je providerobjecten naar één schema, sluit je payouts op componentniveau, behandel je refunds en chargebacks apart en schrijf je alleen bewezen regels met read-back naar het ERP. Zo blijft elke financiële afwijking herleidbaar tot één dossier.

Volg deze zeven stappen in deze volgorde:

1. Leg de route vast voordat je een provider aanroept

Maak eerst een routeringsbesluit. Neem daarin de betaalmethode, land, valuta, bedrag, risicosignaal, beschikbaarheid van de provider en de regel voor fallback op. Geef het besluit een versie en een uniek ID. Schrijf het besluit vóór de eerste API-call naar Mollie of Stripe.

Een eenvoudig besluit kan bijvoorbeeld zeggen: Nederlandse iDEAL-betalingen gaan naar Mollie, kaartbetalingen naar Stripe, en een fallback mag alleen na een bevestigde mislukte poging. Een time-out is geen bevestigde mislukking. Bij een onzekere uitkomst haal je eerst de paymentstatus op of zoek je de bestaande objecten op. Pas daarna mag een nieuwe poging ontstaan.

Bewaar per poging canonical_transaction_id, attempt_no, gekozen provider, merchant account, request hash, idempotency key, provider-ID en eindstatus. Overschrijf de eerste route niet wanneer je naar de tweede PSP uitwijkt. Je moet later kunnen zien dat er twee pogingen waren, maar ook dat er maar één capture of één definitieve geldactie is ontstaan.

Stripe adviseert voor de meeste nieuwe integraties inmiddels Checkout Sessions met de Payment Element. Gebruik je toch de Payment Intents API, dan hoort doorgaans één PaymentIntent bij één winkelmand of sessie en moet je dezelfde intent kunnen hergebruiken. Stripe adviseert een idempotency key om dubbele PaymentIntents te voorkomen en laat metadata meestromen naar rapporten, zodat je een order-ID aan de providertransactie kunt koppelen. Die actuele Stripe-aanwijzingen staan in de Payment Intents-documentatie (gecontroleerd op 15 oktober 2026).

2. Bouw per provider een adapter naar hetzelfde schema

Laat je ERP nooit rechtstreeks de afwijkende velden van Mollie en Stripe raden. Een adapter vertaalt ieder providerbericht naar één intern schema en bewaart daarnaast de ongewijzigde bronpayload.

Mollie adviseert in de create-payment-documentatie een unieke identifier in de description, juist om een betaling aan je backoffice te koppelen. De API kan ook metadata bewaren, tot ongeveer 1 kB. Die velden zijn onderdeel van de actuele Mollie Payment API (gecontroleerd op 15 oktober 2026). Zet er alleen technische sleutels in, geen volledige persoonsgegevens.

Maak provideradapters klein en testbaar. Een adapter mag een statusnaam vertalen, maar mag niet zelf bepalen of een refund definitief geboekt wordt. Dat besluit hoort in de canonieke domeinlogica, waar beide providers dezelfde regels volgen.

3. Gebruik webhooks als wekker en haal de status opnieuw op

Een webhook zegt dat er iets veranderde. Hij is niet automatisch het bewijs van de nieuwe status. Sla de ruwe payload, ontvangsttijd en event-ID op, antwoord snel en haal daarna het volledige object op bij de provider.

Mollie stuurt voor veel webhooksoorten alleen het ID van het gewijzigde object. De actuele documentatie noemt onder meer paymentstatussen, refundstatussen en chargebacks. Mollie verwacht HTTP 200 binnen 15 seconden, probeert een mislukte webhook maximaal tien keer opnieuw en stopt na ongeveer 26 uur. Onbekende ID’s mogen volgens de documentatie met HTTP 200 worden beantwoord, waarna je eigen controle bepaalt of er een ontbrekende import is. De officiële webhookregels zijn gecontroleerd op 15 oktober 2026.

Gebruik in je eigen eventlog een samengestelde sleutel, bijvoorbeeld provider + raw_event_id + object_id. Verwerk een statuswijziging opnieuw als een controle, niet als een nieuwe betaling. Bewaar de overgang van authorized naar paid, van paid naar refunded en van paid naar chargeback_open als aparte gebeurtenissen.

Voor Stripe geldt dezelfde ontwerpregel. Een PaymentIntent kan meer dan één Charge hebben wanneer er meerdere betaalpogingen zijn. Bewaar dus PaymentIntent, Charge en balance transaction apart. Een geslaagde webhook betekent nog steeds dat je de bronstatus, het bedrag en de parent-relatie moet read-backen.

4. Splits iedere payout op in settlementcomponenten

Maak voor ieder PSP-account een clearingrekening per entiteit en valuta. De bankregel is het eindpunt van een payout, niet de inhoud ervan. Een settlementrecord krijgt een ouder-kindstructuur:

• payout of settlement als ouder;
• payments en captures als positieve regels;
• refunds en chargebacks als negatieve geldbewegingen;
• fees per type en fee-ID;
• reserves, correcties en teruggedraaide refunds als eigen regels;
• bankreferentie en bankboekdatum op de payout, niet op elke orderregel.

Gebruik minimaal deze controle:

beginstand clearing + payments + captures - refunds - chargebacks - fees + correcties - payout = eindstand clearing

De eindstand mag tijdelijk positief of negatief zijn. Een verschil zonder reden mag niet automatisch naar omzet, afronding of bankkosten.

Mollie verdeelt een Settlement Report in revenue, deductions en costs. Payments en captures staan bij revenue, refunds en chargebacks bij deductions, en payment method fees, refund fees, chargeback fees en andere kosten bij costs. Kosten en rolling reserves kunnen per settlement geaggregeerd zijn. De Settlements API biedt naast totalen ook details op payment-, refund-, chargeback- en capture-niveau. De actuele Mollie Settlement Report-documentatie is gecontroleerd op 15 oktober 2026.

Bij Stripe is het Payout reconciliation report bedoeld voor automatische payouts. Selecteer de periode rond de verwachte aankomstdatum, niet alleen rond de dag waarop de bank de storting boekt. Download de Itemized CSV. Die bevat payments, refunds, disputes, fees en andere balance transactions en kan custom metadata meenemen. Instant payouts vallen buiten deze automatische koppeling, omdat Stripe daar niet kan bepalen welke transacties in de payout zitten. De Stripe-documentatie is gecontroleerd op 15 oktober 2026.

De onafhankelijke Payrails-uitleg onderscheidt fee mismatch, FX drift, partial refund en timing difference als terugkerende klassen. Dat is een bruikbare indeling voor je queue, maar het percentage dat Payrails voor zijn eigen matching noemt is geen algemene norm. Gebruik de categorieën, niet de marketingclaim. De practitioner-uitleg is geraadpleegd op 15 oktober 2026.

5. Verwerk refunds en chargebacks als verschillende geldstromen

Een refund start vanuit je eigen proces. Een chargeback start bij de klant, bank of kaartuitgever. Beide kunnen het saldo van de PSP beïnvloeden, maar ze hebben een ander bewijs, een ander besluit en vaak een ander kostenmoment. Maak dus aparte records en aparte statussen.

Een refundrecord verwijst naar canonical_transaction_id, orderregel-ID, oorspronkelijke payment-ID, bedrag, valuta, reden, creditnota en idempotency key. Een chargebackrecord bevat daarnaast dispuut-ID, reden, response deadline, evidence version, uitkomst, fee-ID en beslisser. Blokkeer een automatische refund als op hetzelfde payment-ID al een open chargeback of onzekere refund staat.

Mollie waarschuwt specifiek voor dubbele partial refunds. Dezelfde Idempotency-Key voorkomt dat een retry binnen één uur als een nieuwe opdracht wordt behandeld. De API vergelijkt bij hergebruik ook endpoint en parameters, en adviseert exponential backoff bij tijdelijke fouten. De actuele Mollie idempotency-documentatie is gecontroleerd op 15 oktober 2026.

Stripe ondersteunt idempotency keys op POST-aanroepen. Bij API v1 bewaart Stripe het resultaat minimaal zolang de key niet is verwijderd, waarbij de documentatie meldt dat keys automatisch na minstens 24 uur kunnen worden verwijderd. Dat is geen vervanging voor je eigen duurzame opdrachtledger. De Stripe-regels voor idempotente requests zijn gecontroleerd op 15 oktober 2026.

Een retry-regel is daarom altijd: zoek eerst op je eigen idempotency_key, provider-ID en doelobject. Bestaat het object, lees de status opnieuw. Bestaat het niet en is de eerste uitkomst werkelijk definitief mislukt, herhaal dan exact dezelfde opdracht. Een nieuwe sleutel betekent een nieuwe financiële handeling.

6. Beperk ERP-writes tot bewezen beslissingen

Gebruik drie fasen voor iedere ERP-mutatie:

1. Voorstel: het canonieke dossier bevat bron-ID’s, bedrag, valuta, rekening, periode en gewenste boeking.
2. Vrijgave: een regel gaat automatisch door als de match exact en uniek is. Een refund, chargeback, feeverschil, onbekende betaling of gesloten periode vraagt de bevoegde rol.
3. Write en read-back: de integratie schrijft met een vaste externe sleutel en leest daarna het ERP-object terug op sleutel, bedrag, valuta, periode, rekening en status.

Bij AFAS leg je de benodigde Get- en UpdateConnectoren vast in de app connector. Bij Twinfield is een financiële match een eigen XML Web Service. De actuele Twinfield-documentatie ondersteunt matchvalue voor gedeeltelijke betalingen en writeoff met types zoals currency, writeoff en discount. De voorbeelden voor volledige betaling, deelbetaling en korting staan in de Twinfield-documentatie (gecontroleerd op 15 oktober 2026).

Schrijf nooit rechtstreeks een onbekende payout op omzet. Schrijf een fee niet weg als afronding omdat het bedrag klein is. Laat een recoveryclaim op claim_pending staan totdat de providercredit of formele bevestiging bestaat. Lees bij een time-out eerst terug. Een nieuwe ERP-write met een nieuwe sleutel kan de dubbele boeking creëren die de retry juist had moeten voorkomen.

7. Richt de uitzonderingsqueue in als besluitlijst

Een queuekaart bevat minimaal:

Gebruik vaste redenklassen: route_uncertain, duplicate_attempt, payment_unmatched, settlement_missing, fee_mismatch, refund_parent_missing, chargeback_open, erp_write_unknown, period_closed. Sorteer op financiële waarde, deadline en ouderdom. Een chargeback met een bewijsdeadline staat boven een afrondingsverschil van €0,01.

Draai dagelijks drie controles: nieuwe providergebeurtenissen zonder canoniek dossier, payouts die niet op componentniveau sluiten en ERP-writes zonder read-back. Test wekelijks een replay van een oude webhook en een time-out na een write. Zo test je herstel, niet alleen de groene route.

Na deze zeven stappen zie je waarom twee PSP’s niet eindigen bij twee webhooks. Je hebt een routeringslog, een gedeelde sleutelset, twee adapters, twee settlementmodellen, één clearinglaag en een queue nodig die onzekerheid niet wegpoetst.

Valkuilen die je administratie stil laten ontsporen

Je overschrijft de route bij een fallback

Wat er misgaat: de tweede PSP staat als enige provider in het dossier, waardoor een reviewer de eerste autorisatie of time-out niet meer ziet.

Mitigatie: bewaar iedere poging onder hetzelfde canonieke dossier met eigen provider, merchant account, attemptnummer, request hash en uitkomst. De routebeslissing is een gebeurtenis, geen overschrijfbaar veld.

Je matcht op bedrag en datum

Wat er misgaat: twee providers leveren dezelfde bedragen aan en een payout bevat meerdere dagen. Een bedragmatch kan de verkeerde order sluiten.

Mitigatie: match eerst op provider-ID, merchant account, parent-relatie en settlement-ID. Gebruik bedrag, valuta en datum als controles.

Je gebruikt de webhook als boekingsbewijs

Wat er misgaat: een dubbel event of een vervalste call laat een orderstatus of refund vooruitlopen op de provider.

Mitigatie: antwoord snel, haal het object opnieuw op bij de PSP, controleer de parent payment en maak de verwerking idempotent.

Je maakt één kolom fee

Wat er misgaat: payment fee, refund fee, chargeback fee, FX, reserve en maandcorrectie verdwijnen in één totaal. De payout lijkt te sluiten, maar je kunt de marge of claim niet verklaren.

Mitigatie: bewaar fee-ID, fee-type, parent payment, valuta, rapportversie en settlement-ID apart. De feecontrole uit het aparte PSP-feeproces blijft naast cashreconciliatie bestaan.

Je boekt de payout als omzet

Wat er misgaat: een netto bankbedrag bevat ook refunds, disputes en providerkosten. De order- en btw-administratie raakt los van de cash.

Mitigatie: boek de economische transactie op de orderbron, laat payouts via clearing lopen en sluit de payout op componentniveau.

Je koppelt de refund aan de orderkop

Wat er misgaat: een deelrefund op één regel crediteert de hele order of gebruikt een actuele catalogusprijs.

Mitigatie: gebruik orderregel-ID, oorspronkelijke korting, btw-code, parent payment-ID en een onveranderlijke snapshot. De PrestaShop-Twinfield-route voor deelrefunds laat dezelfde grens zien tussen orderregel, creditnota, geldactie en match.

Je schrijft te veel naar het ERP

Wat er misgaat: een connector maakt bij ieder event een boekingsobject, ook wanneer de providerstatus nog pending is of de payout nog niet is uitgesplitst.

Mitigatie: scheid voorstel, menselijke vrijgave, write en read-back. Schrijf alleen de financiële feiten die je met bron-ID’s kunt bewijzen.

Je verwart een providerretry met een eigen retry

Wat er misgaat: de PSP stuurt dezelfde webhook opnieuw en jouw workflow maakt een tweede refund, fee of ERP-transactie.

Mitigatie: maak event-ID, provider-object-ID, interne domeinsleutel en ERP-externe sleutel uniek. Houd de eigen opdrachtledger langer vast dan de provider-idempotentieperiode.

Beslis-kader: connector, orkestratielaag of maatwerk?

Voor twee PSP’s is een kant-en-klare connector per provider alleen voldoende als er ergens al een echte gedeelde transactielaag bestaat. Twee losse plugins die elk rechtstreeks naar AFAS of Twinfield schrijven, geven je twee boekingsroutes en geen canoniek dossier.

Kant-en-klaar met een gedeelde clearingrekening

Kies bestaande connectors als één entiteit, één valuta en eenvoudige volledige refunds je normale situatie zijn, de provider-ID’s in de boekhouding blijven staan en de connector beide payouts op componentniveau kan verklaren. Laat vóór aanschaf aantonen dat partial refunds, chargebacks, fee-types, retries en read-back worden ondersteund. Een productpagina met het woord refund is geen bewijs van orderregelcorrectheid.

Orkestratielaag met eigen ledger

Kies n8n Cloud of een vergelijkbare laag als de API-regels stabiel zijn, maar routing, webhooks, rapporten en meldingen uit meerdere bronnen samenkomen. Gebruik n8n voor aanvoer, planning, normalisatie en queue-notificaties. Bewaar het canonieke dossier, raw payloads, rapportversies, idempotency keys en vrijgavebesluiten in een eigen database.

Op 15 oktober 2026 kost n8n Cloud Starter €20 per maand bij jaarlijkse betaling voor 2.500 workflowuitvoeringen met onbeperkte stappen. Pro kost €50 voor 10.000 uitvoeringen. Starter heeft vijf gelijktijdige uitvoeringen en maximaal vijf minuten looptijd; Pro gaat tot vijftig gelijktijdige uitvoeringen en veertig minuten. De logretentie is volgens de actuele prijskaart maximaal zeven dagen voor Starter en dertig dagen voor Pro. De n8n-prijskaart is gecontroleerd op 15 oktober 2026. Dat is workflowcapaciteit, geen financieel auditspoor.

Maatwerk met adapters en menselijke vrijgave

Kies maatwerk als je meerdere merchant accounts, valuta of entiteiten hebt, routing na een onzekere poging moet kunnen herstellen, refunds per orderregel ontstaan, chargebacks bewijsdeadlines hebben of het ERP alleen beperkte en gecontroleerde writes mag ontvangen. Dan bouw je geen doorgeefluik, maar een klein transactiesysteem.

Mijn beslisregel: als een uitzondering niet in één kaart past met bron, bedrag, eigenaar, bewijs, deadline en uitkomst, is de standaardconnector te klein. Als de regels stabiel zijn en een technische eigenaar het eigen ledger beheert, past een orkestratielaag. Als de uitzondering zelf het normale proces bepaalt, kies je maatwerk.

Hoeveel providers, merchant accounts en valuta komen samen?

Twee PSP’s, één entiteit en één valutaMeerdere accounts, valuta of entiteiten

Uitgewerkt voorbeeld: Mollie en Stripe naar AFAS Profit

Dit is een fictieve oefencasus om de sleutelset en boekingsvolgorde te laten zien. De bedragen zijn geen actuele PSP-tarieven. De shop heet Noordlicht Home, draait PrestaShop 9 en verkoopt in EUR. iDEAL gaat volgens de routeversie route-v3 naar Mollie. Kaartbetalingen gaan naar Stripe. AFAS Profit ontvangt alleen bewezen financiële voorstellen.

De route en de orders

Het dossier voor order 10482 krijgt canonical_transaction_id = tx_demo_10482 en route_decision_id = rd_demo_10482_01. De route wordt niet opnieuw berekend wanneer een webhook later binnenkomt. De providerstatus bepaalt de volgende gebeurtenis, niet een nieuwe routebeslissing.

De geldgebeurtenissen

Order 10482 wordt betaald. Twee dagen later keurt een medewerker een refund van €44,00 goed voor één orderregel. Het refundrecord bevat orderregel-ID 7811, Mollie payment-ID tr_demo_m_10482, refund-ID re_demo_m_10482_01, de oorspronkelijke korting en de externe ERP-sleutel afas-refund-tx_demo_10482-01. Een time-out na de refundaanroep leidt tot een zoekactie op die sleutel, niet tot een tweede refund.

Order 10484 krijgt een chargeback van €89,00. Het chargebackrecord heeft een eigen ID, deadline, evidence version en status chargeback_open. De chargebackfee van €15,00 staat als aparte oefenregel. Er wordt geen tweede refund aangemaakt. Een bevoegde medewerker kiest later defend of accept; beide uitkomsten hebben een eigen boekingspad.

De Mollie-settlement bevat de volgende oefenregels:

De som sluit: €149,95 + €89,00 + €19,95 - €44,00 - €89,00 - €15,00 - €0,57 = €110,33. De payout is dus cashmatig verklaard. De onbekende payment van €19,95 blijft toch in de uitzonderingsqueue, omdat een sluitende bankregel niet bewijst dat een order bestaat.

De Stripe-settlement bevat order 10483 voor €219,00 en een fee van €6,61. De payout is €212,39 met payout_id = po_demo_s_2026_10_15. De bank ontvangt in totaal €322,72, maar de boekhouding verwerkt de twee payoutdossiers eerst afzonderlijk tegen Mollie-clearing en Stripe-clearing.

De beperkte AFAS-write

De normale route schrijft de verkoop- en paymentvoorstellen tegen de juiste PSP-clearingrekening. De payout schrijft alleen een banktransactie tegen dezelfde clearingrekening. De €44,00 refund maakt een creditnota- en geldvoorstel met de orderregel en het Mollie-refund-ID. De €89,00 chargeback maakt een afzonderlijk dossier voor betwist bedrag en fee. De onbekende €19,95 krijgt geen omzetboeking.

Voor ieder voorstel geldt dezelfde volgorde:

1. Controleer canonical transaction, provider-ID, bedrag, valuta en status.
2. Controleer dat er geen bestaande AFAS-externe sleutel is.
3. Laat de bevoegde regel of exacte automatische match vrijgeven.
4. Schrijf via de gekoppelde AFAS UpdateConnector.
5. Lees het aangemaakte object terug.
6. Vergelijk bedrag, periode, rekening, externe sleutel en bron-ID.
7. Zet pas daarna de canonieke gebeurtenis op posted en de queuekaart op closed.

Als de AFAS-call na verzending een time-out geeft, blijft het voorstel write_unknown. De volgende run zoekt eerst op de externe sleutel. Bestaat het object al, dan wordt alleen de read-back opgeslagen. Bestaat het niet, dan herhaalt de workflow dezelfde payload.

Wat Finance vrijgeeft

Finance ziet drie verschillende uitkomsten:

• de Mollie-payout sluit op alle settlementcomponenten, maar de onbekende €19,95 blokkeert de ordertoewijzing;
• de Stripe-payout sluit op payment minus fee;
• de refund en chargeback zijn afzonderlijke geldstromen met eigen status en eigenaar.

Dat is een goede uitkomst. De bank is verklaard, de ERP-writes zijn beperkt en één onzekere payment blijft zichtbaar. Een dashboard dat alles groen maakt door €19,95 op omzet te zetten, zou minder betrouwbaar zijn dan deze gedeeltelijk open administratie.

Vergelijkingstabel: welke bouwroute past?

Prijzen en productdetails zijn gecontroleerd op 15 oktober 2026. De budgetorde hierboven omvat implementatie en beheer; PSP- en ERP-abonnementen, connectorlicenties en hosting komen daar nog bovenop.

De goedkoopste route is niet automatisch de kleinste licentie. Je betaalt ook voor bronversies, testdata, rechten, monitoring, retrygedrag en de tijd om een uitzondering uit te zoeken. Kies de route die de zwaarste echte uitzondering kan dragen.

De kern van multi-PSP is niet dat beide providers dezelfde API krijgen. De kern is dat een betaling na routing, settlement, refund, chargeback en ERP-read-back nog steeds naar één begrijpelijk dossier terugwijst. Zodra een afwijking zichtbaar blijft met bron, bedrag, eigenaar en besluit, is automatisering een controle geworden in plaats van een extra laag onzekerheid.