Een tweede PSP vraagt één canoniek transactiedossier

Een tweede PSP halveert je afhankelijkheid niet vanzelf. Zonder één financieel model verdubbel je vooral de plekken waar een betaling, payout, refund, chargeback of fee een eigen betekenis krijgt.

Mijn stelling is eenvoudig: een tweede betaalprovider maakt je pas onafhankelijker wanneer beide providers naar één canoniek transactiedossier schrijven. Routing, provider-ID’s, geldbewegingen, kosten en uitzonderingen horen daarin bij elkaar. Anders koop je redundantie aan de voorkant en extra onzekerheid aan de achterkant.

Een tweede PSP verlaagt afhankelijkheid alleen wanneer beide providers dezelfde financiële werkelijkheid kunnen vullen. Het canonieke dossier verbindt routing, payment, payout, refund, chargeback en fee met hun eigen provider-ID’s, tijdstippen en bewijs. Een afwijking gaat naar een uitzonderingsqueue en een mens geeft de financiële uitkomst vrij. Zonder die laag groeit vooral het aantal plekken waar geld en bewijs kunnen breken.

Het verkeerde telraam

De aantrekkelijke rekensom is bekend. Eén PSP valt uit, dus een tweede PSP houdt je checkout open. Eén provider verhoogt zijn prijs, dus je verplaatst volume. Eén account wordt beperkt, dus je hebt een uitwijkroute. Dat zijn legitieme redenen om meerdere providers te overwegen.

Alleen meet je daarmee beschikbaarheid, prijs en onderhandelingsmacht. Je meet nog niet of je administratie kan uitleggen wat er met het geld is gebeurd. Een tweede PSP voegt een tweede vocabulaire toe voor statussen, captures, refunds, chargebacks, reserves, settlementmomenten en kosten. De checkout ziet twee knoppen voor dezelfde keuze. Finance ziet twee soorten bewijs voor een gebeurtenis die uiteindelijk in één boekhouding moet landen.

Daar zit de ongemakkelijke kern: onafhankelijkheid is geen eigenschap van het aantal contracten. Het is een eigenschap van de financiële laag die onder die contracten ligt. Als die laag per provider verschilt, wordt je organisatie niet minder afhankelijk van systemen. Je wordt afhankelijk van vertalingen tussen systemen.

Eén betaling heeft meer dan één waarheid

Een order is niet hetzelfde als een betaling. Een betaling is niet hetzelfde als een payout. Een refund is niet hetzelfde als een chargeback. Een fee is geen afrondingsverschil. Dat onderscheid bestaat al met één PSP, maar met twee providers kun je het niet langer wegdrukken in een brede kolom status of transaction_id.

De documentatie van Adyen laat precies zien waarom. In een settlementrapport kan één transactie meerdere regels hebben. De combinatie van een PSP reference en een merchant reference identificeert de transactie, terwijl gross credit, net credit, commissie, markup, scheme fees en interchange afzonderlijk betekenis hebben. Een chargeback kan weer een eigen debit en extra kosten veroorzaken. Dezelfde payout sluit pas wanneer credits en debits per component naar het payoutbedrag leiden.

Stripe beschrijft een vergelijkbaar patroon in het payout reconciliation report. De itemized CSV bevat payments, refunds, disputes, fees en andere balance transactions die samen in één payout zitten. Dat is geen detail voor grote betaalplatformen. Het is het bewijs dat een bankregel nooit genoeg is om de onderliggende omzet, kosten en terugboekingen te verklaren. Een payout moet terugwijzen naar de afzonderlijke financiële regels die hem vormen.

Ik wil daarom in het canonieke dossier minstens kunnen terugvinden: de orderreferentie, de gekozen route, de provider en merchant account, het payment-ID, de capture, de valuta, de payout of settlement, refunds, chargebacks, fees, de relevante tijdstippen en het bewijs waarop een status is gebaseerd. Die velden zijn geen technische luxe. Ze bepalen of iemand later kan zien welke werkelijkheid er werkelijk is geraakt.

De praktische onderlaag is herkenbaar in een geldstroom waarin order, betaling, payout, fee, refund en chargeback met vaste bron-ID’s worden gekoppeld. Het verschil bij twee PSP’s is dat je die sleutelset niet per provider opnieuw mag uitvinden. De provider-ID’s blijven lokaal uniek, het interne dossier geeft ze één gedeelde betekenis.

Routing zonder dossier is alleen een doorgeefluik

Routing wordt vaak verkocht als het slimme deel van multi-PSP. Kies Provider A voor iDEAL, Provider B voor kaarten, stuur een mislukte poging door naar een tweede route en laat de checkout zo veel mogelijk betalingen redden. Ik begrijp die aantrekkingskracht. Een goede route kan conversie, beschikbaarheid en kosten beïnvloeden.

Maar routing zonder financiële registratie is alleen een doorgeefluik. Zodra een eerste autorisatie onzeker eindigt en een tweede provider wordt aangeroepen, moet je later kunnen bewijzen of er één poging, twee pogingen, één capture of twee geldacties zijn ontstaan. De routebeslissing hoort daarom naast het payment-ID te staan, niet ergens alleen in een logregel van de orkestratielaag.

Dat geldt ook voor retries. Een webhook kan dubbel binnenkomen. Een API-call kan een time-out geven nadat de provider de opdracht al heeft uitgevoerd. Een payout kan pas later de definitieve fee of een refund laten zien. Wie dan een nieuwe providerreferentie of een nieuwe financiële sleutel maakt, verwart herstel met een nieuwe handeling. De veilige regel is dat een retry dezelfde zakelijke actie opnieuw vaststelt, met dezelfde sleutel en een controle op het bestaande doel. Financiële gebeurtenissen opnieuw vaststellen zonder dubbele boeking is daarom geen apart technisch randgeval, maar onderdeel van de multi-PSP-architectuur.

De tweede provider maakt die discipline zichtbaarder. Bij één PSP kun je een ontbrekende koppeling soms handmatig gladstrijken omdat je de eigenaardigheden van die provider kent. Bij twee providers wordt een stille aanname een structureel verschil. Je weet dan niet meer of een afwijking door routing, timing, feeclassificatie, een gedeeltelijke refund of een ontbrekende settlementregel komt.

Reconciliatie is het echte product

De meeste teams ontwerpen eerst de API-koppelingen en denken daarna na over reconciliatie. Dat is de verkeerde volgorde. Reconciliatie is niet de controle achteraf op een geslaagde betaalstroom. Het is de plek waar je bepaalt wat een geslaagde betaalstroom überhaupt betekent.

De PSP-documentatie maakt dat concreet. Adyen onderscheidt in zijn payoutreconciliatie een transaction-level breakdown, een volledige audit trail, een samenvatting van accountactiviteit en real-time status via webhooks. De provider benoemt ook dat een payout kan afwijken van recent settled sales wanneer toekomstige refunds of andere risico’s nog worden ingehouden. Een groene payoutstatus is dus niet hetzelfde als een complete financiële afwikkeling.

Mollie splitst een settlementrapport op in revenue, deductions en costs. Dat model is begrijpelijk, maar de namen en momentopnames zijn niet automatisch gelijk aan die van een andere PSP. De settlementdocumentatie van Mollie laat zien dat payment fees, refund fees, chargeback fees en andere kostencomponenten naast de opbrengst staan. Wie die regels in beide providers simpelweg fee noemt, heeft de data wel geïmporteerd en de betekenis verloren.

Daarom hoort een verschil niet direct naar een automatische boeking te gaan. Een payout die niet sluit, een fee die niet bij de rate card past of een refund zonder parent payment hoort in een uitzonderingsqueue. Daar staan eigenaar, bewijs, deadline en toegestane besluiten bij. Een mens hoeft niet iedere normale betaling goed te keuren. Een mens moet wel vrijgeven wat de software niet betrouwbaar kan bewijzen.

Ook de recente fee-reconciliatie van rate card tot herstelboeking past hier precies in. Een payout kan op de bank kloppen en toch een verkeerde fee bevatten. Met twee PSP’s moet je dus cashreconciliatie en contractreconciliatie per provider uitvoeren, waarna het canonieke dossier de verschillen vergelijkbaar maakt.

Om eerlijk te zijn: één PSP is vaak eenvoudiger

Het sterkste tegenargument is niet dat een tweede PSP nooit werkt. Het is dat één PSP voor veel bedrijven gewoon de verstandigste keuze is. Minder contracten betekent minder onboarding, minder rapportformaten, minder uitzonderingen en minder plekken waar een medewerker een route moet begrijpen. Als je volume klein is, je betaalrisico beperkt is en je provider voldoende betrouwbaar is, kan de extra complexiteit van een tweede PSP duurder zijn dan de afhankelijkheid die je ermee wilt verminderen.

Daar ben ik het mee eens. Ik zou geen tweede provider toevoegen omdat multi-PSP op een architectuurplaat volwassen klinkt. De tweede route moet een concreet risico afdekken dat groot genoeg is om een eigen canoniek dossier, testset, reconciliatiebeleid en menselijke vrijgave te dragen. Anders is een goede enkelvoudige integratie vaak de betere bedrijfsbeslissing.

De draai zit in de definitie van eenvoud. Twee losse koppelingen lijken eenvoudig zolang alles goed gaat. Eén gedeeld transactiedossier lijkt zwaarder voordat je begint, maar maakt een storing, feeverschil of chargeback tenminste uitlegbaar. Voor een bedrijf met meerdere markten, betaalmethoden, valuta’s of strakke uitbetalingseisen is juist die uitlegbaarheid een vorm van eenvoud.

Onafhankelijkheid begint bij de uitzondering

De tweede PSP bewijst zijn waarde niet op de dag dat de routering succesvol een betaling doorstuurt. Hij bewijst zijn waarde wanneer een betaling bij Provider A staat, de payout bij Provider B nog niet is aangekomen, een refund gedeeltelijk is uitgevoerd en Finance moet beslissen of een boeking mag worden vrijgegeven. Dan zie je of je twee providers hebt gekoppeld, of één financiële werkelijkheid hebt gebouwd.

Mijn grens is daarom helder. Beide providers mogen hun eigen API, rapporten, statussen en provider-ID’s houden. De bedrijfsadministratie mag die verschillen niet als twee waarheden bewaren. Daar hoort één canoniek dossier onder te liggen, met een uitzonderingsqueue voor onzekerheid en menselijke vrijgave voor financiële gevolgen die niet bewezen zijn.

Een tweede PSP is pas redundantie wanneer je ook kunt aantonen wat er níét dubbel is gebeurd. Dat is de maatstaf die ik zou gebruiken voor onafhankelijkheid: niet hoeveel routes je checkout kent, maar of je na een storing nog één verhaal over het geld kunt vertellen.