Een webshopstatus is nog geen betaling: van PrestaShop-order tot Shopify-refund

Een webshopstatus kan groen zijn terwijl er op je bankrekening nog geen bewezen geldbeweging staat. Een order kan op betaald staan voordat de payout is verwerkt. Een retour kan ontvangen zijn terwijl de terugbetaling nog pending is.

Mijn stelling is eenvoudig: een status in je webshop bewijst geen ontvangen of teruggestort geld. Alleen de herleidbare keten van order of retour, betaaltransactie, payout of refund en boeking maakt de financiële gebeurtenis betrouwbaar.

De eerste vergissing: een scherm is geen geldrekening

Software gebruikt statusvelden om een proces bestuurbaar te maken. Dat is nuttig. Een magazijnmedewerker moet weten of een order door kan. Een klantenservicemedewerker moet zien of een retour is geregistreerd. Finance moet weten of een bedrag is ontvangen, teruggestuurd en juist verwerkt.

De PrestaShop-documentatie maakt zichtbaar waarom dat misgaat. De PrestaShop-documentatie is daar duidelijk over: de orderstatus hangt af van de gekozen betaalmethode en betaalmodule, en kan automatisch veranderen wanneer de betaalmodule meldt dat de betaling is gedaan. Sommige modules laten een order wachten op een handmatige statuswijziging. De status is dus een uitkomst van een proces in de shop, niet automatisch een bankafschrift of payoutbewijs.

Shopify benoemt hetzelfde onderscheid nog explicieter. Het bestaan van een Refund-object bewijst niet dat het geld al bij de klant is aangekomen. De werkelijke geldverwerking zit in de gekoppelde ordertransacties, die nog pending, processing, success of failure kunnen zijn. Shopify zet daarmee zelf een streep tussen het administratieve refundrecord en de feitelijke geldactie.

Een webshopstatus is een signaal van een applicatie, geen bewijs van een financiële gebeurtenis. Een orderstatus zegt wat de shop denkt dat er met de order gebeurt. Een betaaltransactie, refund of payout zegt wat de betaalinfrastructuur heeft uitgevoerd. Een boeking is pas betrouwbaar wanneer die bronnen met vaste sleutels, bedragen, valuta en statussen naar elkaar verwijzen.

PrestaShop: betaald is nog geen payout

Neem een PrestaShop-order van € 121. De klant rondt de checkout af en de order krijgt een betaalde status. Voor de operatie kan dat voldoende zijn om de bestelling te verwerken. Voor de financiële administratie is het slechts één schakel. Je moet nog weten welke betaaltransactie erbij hoort, of de provider het bedrag werkelijk heeft geaccepteerd, in welke payout het bedrag terechtkomt en welke kosten of refunds die payout verlagen.

Dat laatste wordt vaak onderschat. Een payout is geen grote order. Het is een bundel van geldbewegingen. Mollie beschrijft een Settlement Report als een uitsplitsing van alle transacties, kosten en inhoudingen in één payout. Stripe groepeert in zijn payoutrapport eveneens charges, refunds, disputes en fees binnen dezelfde uitbetaling. Het bedrag op de bankregel is daardoor een nettoresultaat, geen directe omzetregel.

Wie paid uit PrestaShop rechtstreeks naar een boekhoudpakket schrijft, slaat die betekenislaag over. Een fee kan dan als ontbrekende omzet eindigen. Een refund die al van het PSP-saldo af is, kan in de verkeerde periode landen. Een onbekende betaling kan worden toegewezen aan de eerste order met hetzelfde bedrag. De software doet dan precies wat de koppeling opdraagt, maar de boeking vertelt niet meer wat er werkelijk is gebeurd.

Bij een PrestaShop-stroom naar Twinfield moet je daarom orderregel, refund, creditnota en aflettering afzonderlijk traceerbaar houden. Een deelrefund van één artikel is niet hetzelfde als een ontvangen retour, niet hetzelfde als een creditnota en ook niet hetzelfde als een geslaagde terugbetaling. Vier gebeurtenissen kunnen bij elkaar horen zonder één gebeurtenis te zijn.

Dat onderscheid is ook praktisch. Een webshop mag een order operationeel vrijgeven zodra een betrouwbare betaalbevestiging binnen is. De financiële batch hoeft dan nog niet vrij te zijn. Een payout die morgen binnenkomt mag je magazijn vandaag niet blokkeren, maar je mag hem ook niet gebruiken als bewijs dat elke order in de batch juist is geboekt.

Shopify: retour, refundrecord en geldactie

De Shopify-casus lijkt anders omdat Shopify returns en refunds als eigen objecten modelleert. Toch zit daar dezelfde valkuil. Een retour beschrijft de intentie en de fysieke afhandeling van goederen. Een refund beschrijft de financiële correctie rond een order. De ordertransactie moet vervolgens laten zien of de geldactie is geslaagd.

Dat maakt een refundrecord waardevol, maar niet voldoende. Het record kan al bestaan terwijl de gekoppelde transactie nog niet succesvol is. Een medewerker kan een retour hebben goedgekeurd terwijl de betaalprovider de terugbetaling vertraagt, afwijst of via een andere route moet uitvoeren. Shopify koppelt een refund daarom aan de ordertransacties die de feitelijke geldtransfer afhandelen.

Stripe laat zien waarom je daar niet te licht over moet denken. In de refunddocumentatie zijn requires_action, pending, succeeded, failed en canceled verschillende toestanden. Een refund krijgt pas de status succeeded wanneer Stripe verwacht dat die bij de klant aankomt. Ook dat is nog geen uitnodiging om een willekeurig Shopify-label als eindbewijs te nemen. De bronhouder van de geldactie blijft leidend.

De boekhouding heeft bovendien een eigen vraag. Als een verkoop achteraf wordt verminderd of geannuleerd, moet de omzetcorrectie en de bijbehorende btw volgens het geldende beleid worden verwerkt. De Belastingdienst koppelt zo’n btw-teruggaaf aan het tijdvak waarin de prijsvermindering, kwijtschelding of verbreking plaatsvindt. Dat is een financiële beslissing met een bron en periode, geen simpele vertaling van return_status = closed.

Een Shopify-retour kan dus fysiek klaar zijn, terwijl de refund financieel nog niet klaar is. Andersom kan een goodwillrefund zijn uitgevoerd zonder dat er een retourpakket is ontvangen. Als je die gebeurtenissen in één statusveld stopt, verlies je precies de informatie die je nodig hebt om een uitzondering te verklaren.

De drie feiten die een boeking wél dragen

Ik kijk bij dit soort koppelingen naar drie afzonderlijke vragen. Niet omdat ieder proces meer schermen nodig heeft, maar omdat ieder antwoord een andere bron en een andere fout kan hebben.

1. Wie bezit het feit?

De webshop bezit de order, orderregels, kortingen, retourcontext en de zichtbare status. De betaalprovider bezit de betaalactie, het refund-ID, de payout of settlement en de bijbehorende providerstatus. De boekhouding bezit de boeking, creditnota, openstaande post en aflettering. Geen van die systemen mag de ontbrekende waarheid van een ander systeem invullen op basis van alleen een bedrag.

In een goede koppeling staat daarom niet alleen status = paid, maar ook welke bron die status heeft afgegeven en wanneer die bron opnieuw is gecontroleerd. De vraag is niet “staat hij op betaald?”, maar “welk betaalobject bewijst dit, en welke payout of settlement maakt het later controleerbaar?”

2. Welk geldobject hoort erbij?

Een ordernummer is een goede ingang voor een mens, maar een zwakke financiële sleutel. Gebruik de technische order-ID samen met orderregel-ID, betaaltransactie-ID, refund-ID, payout-ID en boekings-ID. Bij een deelrefund hoort ook vast te staan welke oorspronkelijke regel, korting en btw-context is geraakt.

Dat is geen overdreven administratie. Het is de enige manier om een time-out of dubbele webhook veilig te behandelen. Als de uitkomst van een schrijfactie onbekend is, zoek je eerst op het bestaande provider- of boekingsobject. Zonder duurzame relatie weet een retry niet of hij moet controleren of opnieuw uitvoeren. Dan wordt herstel zelf een nieuwe financiële gebeurtenis.

3. Welke beslissing mag de boeking worden?

Een geslaagde betaling en een payout zijn bewijs voor verschillende financiële feiten. Een creditnota corrigeert de verkoopadministratie. Een refund verplaatst geld terug. Een bankregel bevestigt een storting van een bundel. Een matchbeslissing verbindt die gebeurtenissen aan elkaar. Pas daarna kan een boeking of aflettering verantwoord worden vrijgegeven.

De koppeling van PrestaShop aan AFAS met aparte betaal-, payout-, refund- en vrijgavemomenten laat precies die grens zien. De operationele orderroute en de financiële vrijgave hoeven niet op hetzelfde moment groen te worden. Dat is geen vertraging, maar een betere keuze over wat het systeem wel en niet mag aannemen.

Bij de maandafsluiting geldt dezelfde logica. Bankregel, payout, refund, chargeback en fee houden elk hun eigen bron en periode, waarna de clearing en de boeking met elkaar worden vergeleken. Wie de bankregel rechtstreeks als omzetbewijs gebruikt, maakt van reconciliatie een gok met een nette kleur.

Om eerlijk te zijn: statussen zijn wél nuttig

Het tegenargument is sterk. Niemand wil ieder ordertje met de hand controleren. Webshops en betaalproviders hebben juist statussen, webhooks en API’s gebouwd om volume automatisch te verwerken. Als je voor iedere verzending wacht op de uiteindelijke bankboeking, maak je de operatie onnodig traag.

Daar ben ik het mee eens. Een status is een uitstekend automatiseringssignaal. paid kan een order naar fulfilment sturen. return_received kan een medewerkerstaak openen. refund_succeeded kan een financiële correctie verder laten gaan. Mijn bezwaar gaat niet over automatisering, maar over het overslaan van de broncontrole tussen signaal en boeking.

De juiste vraag is dus niet of je statussen mag vertrouwen. De juiste vraag is waarvoor je ze vertrouwt. Een operationele status mag een proces starten. Een financiële status moet kunnen terugwijzen naar de betaaltransactie, de geldactie en de uiteindelijke settlement. Hoe hoger het financiële gevolg, hoe sterker het bewijs moet zijn.

Een bruikbaar bewijsmodel

Een controleerbare geldgebeurtenis bestaat uit vier lagen:

• Context: de oorspronkelijke order of retour, met regels, bedrag, valuta en relevante beslissing.
• Geldactie: de betaaltransactie of refund bij de provider, met een uniek ID en een actuele eindstatus.
• Settlement: de payout of settlementregel waarin het bedrag, de kosten, refunds en correcties terugkomen.
• Boeking: de factuur, creditnota, tussenrekening en matchbeslissing die de financiële administratie vastlegt.

Stripe noemt in zijn payoutrapport niet voor niets de oorspronkelijke charge-ID, refund- en payment-ID en de afzonderlijke fee- en nettobedragen. Een payout moet worden afgestemd met de batch transacties die hij vereffent.Ook bij PrestaShop met Mollie, Shopify Payments of een andere PSP moet de route van order naar geldactie en settlement zichtbaar blijven.

Als één laag ontbreekt, hoeft de order niet stil te vallen. Wel moet de financiële status dan pending of exception blijven, met een eigenaar en een reden. Dat is het verschil tussen verstandig automatiseren en een fout verbergen. Een rood of geel vak is geen mislukking. Een groen vak zonder bewijs is dat wel.

Slot: laat groen niet doorgaan voor waar

De gevaarlijkste status in een webshop is niet failed. Die status vraagt tenminste om aandacht. Het gevaar zit in paid, refunded of completed wanneer niemand meer kan uitleggen welk geldobject daarachter zit.

Een order is een afspraak over een verkoop. Een betaaltransactie is een geldactie. Een payout is een bundel die naar de bank gaat. Een refund is een teruggaande geldactie. Een boeking is de financiële interpretatie van die feiten. Wie die lagen samenperst tot één status, automatiseert vooral de zekerheid dat later niemand meer weet waarom het saldo niet klopt.

Ik wil dat een systeem snel kan werken én eerlijk kan zeggen wat het nog niet weet. Daarom is de beste webshopkoppeling niet degene met de meeste groene statussen, maar degene die iedere groene financiële uitkomst kan terugbrengen naar de order, de geldactie, de payout en de boeking. Pas dan is een status meer dan een geruststellend woord op een scherm.