PrestaShop naar Twinfield: deelrefunds, deelbetalingen en uitzonderingen

Een klant vraagt €44 terug voor één artikel uit een betaalde order. In PrestaShop is dat een deelrefund. In Twinfield moet het tegelijk een juiste creditnota, een passende btw-correctie, een nieuwe geldbeweging en een controleerbare aflettering worden. Als je alleen het refundbedrag doorstuurt, klopt één van die vier meestal niet.

De veilige inrichting is een keten waarin iedere stap naar het vorige bewijs terugwijst: orderregel, oorspronkelijke korting, refundbesluit, betaal-ID, creditnota, Twinfield-transactie en bank- of PSP-uitbetaling. Uitbetalingen, deelrefunds en chargebacks maken de geldstroom complexer. Na deze gids kun je die keten opzetten, deelbetalingen en kortingen juist verwerken, retries veilig maken en uitzonderingen naar een bevoegde medewerker sturen.

Ik heb de genoemde productdocumentatie, API-details en prijskaarten gecontroleerd op 26 september 2026. Waar een productversie of prijs in de tekst staat, geldt die datum als controlemoment.

PrestaShop-Twinfield-reconciliatie is het gecontroleerd verbinden van een PrestaShop-order en een wijziging op één orderregel aan een Twinfield-factuur, creditnota, betaling en matchbeslissing. Een refund is pas administratief klaar als bedrag, btw, referenties, resterende openstaande post en menselijke vrijgave samen aantoonbaar kloppen.

Wat je nodig hebt

Begin niet met de koppeling. Begin met de afspraak wie de bron is van elk financieel feit. PrestaShop bezit de order, orderregels, prijzen, kortingen en de status van teruggegeven of terugbetaalde aantallen. De betaalprovider bezit de feitelijke geldactie. Twinfield bezit de boeking, openstaande post en aflettering. Geen van die systemen mag voor de andere twee gaan raden.

Je hebt het volgende nodig:

• Een PrestaShop-shop met een gecontroleerde versie. De actuele documentatie is voor PrestaShop 9. Oudere shops kunnen dezelfde resources hebben, maar laat het geïnstalleerde versienummer en de aanwezige modules leidend zijn.
• Een aparte Webservice-sleutel. Geef de koppeling minimaal leesrechten op orders, order_details, order_invoices, order_slips, order_payments en order_histories. Geef geen schrijfrechten omdat een integratie ze toevallig vraagt. Een refundactie is een financieel besluit, geen normale synchronisatie.
• Een Twinfield-administratie met een benoemde eigenaar. Leg company code, kantoor, verkoopdagboek, bank- of tussenrekening, klantdimensie, artikel of grootboekrekening, btw-code en creditnotaprocedure vast. Vraag de accountant expliciet of creditnota’s via Classic sales invoicing of als financiële verkooptransactie worden geboekt.
• Een server-side Twinfield OAuth-client. Bij een toepassing met een backend hoort de authorization-code-flow. Bewaar client secret, refresh token en clusterinformatie in een geheimenkluis. Laat de browser nooit de rol van boekhoudkoppeling spelen.
• Een betaalprovider met een bruikbaar refund-ID. Ik gebruik Mollie als concreet voorbeeld. Je hebt minimaal het oorspronkelijke betaal-ID, het refund-ID, valuta, bedrag, status en de uitbetalingsreferentie nodig.
• Een duurzame verwerkingslaag. Dat kan een kleine database achter n8n, een eigen webapp of een bestaande integratie zijn. Bewaar bron-snapshots, sleutels, matchkandidaten, beslissingen, retries en foutmeldingen buiten vluchtige workflowgeschiedenis.
• Een testset. Neem minimaal één volledige betaling, één deelrefund op één regel, twee deelrefunds op dezelfde order, een gedeeltelijke betaling, een afgesproken korting, een bank- of PSP-fee, een dubbele webhook en een onbekende betaling op.
• Een bevoegdhedenmatrix. De medewerker die de retour inspecteert hoeft niet automatisch de persoon te zijn die een refund vrijgeeft. Noteer wie een creditnota, afboeking, korting en handmatige betaling mag goedkeuren.
• Een week aan uitzonderingen. Je hebt pas een bruikbaar ontwerp als je weet hoeveel regels niet uniek matchen, welke reden het vaakst voorkomt en hoe lang een medewerker nodig heeft om ze op te lossen.

Twinfield is een betaalde administratie, geen gratis API-laag. De actuele prijslijst voor bestaande klanten noemt €58 per maand exclusief btw voor een extra boekhouden-abonnement, €78,50 voor MKB Boekhouden en €114,50 voor Compleet. Die bedragen zijn gecontroleerd op 26 september 2026 en staan los van een connector, beheer en bouwtijd. Voor een orkestratielaag noemt n8n op dezelfde controledatum €20 per maand bij jaarlijkse betaling voor Starter met 2.500 workflowuitvoeringen en €50 voor Pro met 10.000 uitvoeringen. Self-hosting vervangt de licentie niet door nul beheer.

0/8

• PrestaShop-versie en aanwezige betaalmodule vastgelegd
• Aparte Webservice-sleutel met alleen de benodigde leesrechten
• Twinfield company code, dagboeken, klantdimensie en btw-codes vastgelegd
• Server-side OAuth-client en geheimenkluis ingericht
• Order-ID, orderregel-ID, betaal-ID, refund-ID en creditnotanummer als vaste sleutels gekozen
• Testset met deelrefund, deelbetaling, korting, dubbele webhook en onbekende betaling
• Uitzonderingsqueue met reden, eigenaar, bewijs, deadline en status
• Eén persoon die de financiële vrijgave expliciet mag doen

De basisregel is simpel: een deelrefund verandert het bedrag, maar ook de relatie tussen een orderregel, een creditnota, een terugbetaling en de resterende openstaande post. Modelleer die vier relaties voordat je een scherm of workflow bouwt.

Concrete stappen

1. Maak de routekaart en sluit de rechten af

Teken één stroom met de systemen en de momenten waarop geld of administratie verandert:

Zet in PrestaShop eerst de Webservice aan onder Advanced Parameters, Webservice. Maak daarna een sleutel met een herkenbare beschrijving, een vervaldatum in je eigen register en alleen de resources die je werkelijk uitleest. De officiële PrestaShop 9-documentatie bevestigt dat de Webservice standaard uit staat en dat je per resource lees- en schrijfrechten kunt scheiden met een apart gegenereerde sleutel en fijnmazige permissies.

Test vervolgens een beperkte GET op orders en order details. Slaag die test niet, dan heeft het geen zin om Twinfield erbij te halen. Controleer ook dat je een order met meerdere regels en korting terugkrijgt, dus meer dan alleen de orderkop.

Aan de Twinfield-kant registreer je een OAuth-client en kies je bij een backend voor authorization code. Twinfield geeft bij die flow een kortlevende code, een access token en bij offline_access een refresh token. Het juiste cluster haal je na authenticatie op uit de tokenvalidatie. Sla het token niet op als onderdeel van een orderrecord. Het is een verbindinggeheim, geen bedrijfsdata.

Controlepunt: je kunt met een testaccount de PrestaShop-order uitlezen, met Twinfield de juiste administratie selecteren en beide resultaten in een log terugvinden zonder een boeking te maken.

2. Kies één sleutelset die de hele keten draagt

Maak voor iedere gebeurtenis een intern record met minimaal deze velden:

Gebruik de PrestaShop-orderreferentie niet als enige sleutel. Een e-mailadres, bedrag of datum op zichzelf is evenmin genoeg. Twee orders kunnen hetzelfde bedrag hebben en een klant kan meerdere betalingen op één dag doen. De combinatie van order-ID, orderregel-ID, refund-ID en doeltransactie is je audit trail.

Maak per soort gebeurtenis een unieke databasebeperking. Eén refundrecord mag bijvoorbeeld maar één psp_refund_id hebben. Eén creditnota mag maar aan één goedgekeurde refundactie hangen. Een herhaalde webhook wordt dan een statusupdate of een controle, geen tweede financieel object.

Controlepunt: je kunt vanuit een Twinfield-creditnota terugklikken naar de oorspronkelijke PrestaShop-orderregel en het betaalprovider-refund, en andersom.

3. Sla de oorspronkelijke orderregel vast vóór je rekent

Lees de orderkop en iedere orderregel uit PrestaShop en maak een onveranderlijke snapshot. Bewaar product-ID, variant-ID, SKU, aantal, oorspronkelijke prijs, korting, prijs exclusief en inclusief btw, orderfactuur-ID, valuta, wisselkoers en verzendkostenverdeling. Bewaar ook de waarden voor product_quantity_return en product_quantity_refunded.

De PrestaShop 9-resource voor order_detail bevat precies die twee aantallen naast producthoeveelheid, productprijs en kortingsvelden zodat je retour en terugbetaling niet als hetzelfde veld hoeft te behandelen. Dat onderscheid is belangrijk. Een artikel kan ontvangen zijn maar nog niet vrijgegeven voor geld, of er kan een goodwillrefund zijn terwijl het product bij de klant blijft.

Bereken een deelrefund nooit opnieuw met de huidige catalogusprijs. Een prijs, bundelkorting of belastinginstelling kan sinds de order zijn gewijzigd. Neem de financiële feiten uit de oorspronkelijke order en verdeel een orderbrede korting volgens een vooraf gekozen regel. Leg afronding vast op regelniveau, zodat een creditnota niet ineens één cent hoger wordt dan de refund.

Zet de statussen los van elkaar:

• requested: verzoek geregistreerd;
• approved: bedrag en orderregel vrijgegeven;
• refund_pending: opdracht voorbereid, nog niet uitgevoerd;
• refund_confirmed: betaalprovider bevestigt de refund;
• credit_pending: creditnota nog niet in Twinfield;
• posted: creditnota en financiële boeking bestaan;
• reconciled: geld, bron en boeking sluiten;
• exception: een mens moet beslissen.

Controlepunt: je kunt voor iedere refund aantonen welke oude orderregel, korting en btw-bedragen zijn gebruikt.

4. Laat een mens de onomkeerbare beslissing nemen

Een refundknop is een financiële vrijgave. Laat hem daarom niet afgaan op alleen een PrestaShop-status als Refunded of op het binnenkomen van een retourmelding. Toon de medewerker de orderregel, ontvangen hoeveelheid, refundbedrag, btw, oorspronkelijke factuur, betaal-ID, eerdere refunds en eventuele voorraadbeslissing.

PrestaShop maakt gedeeltelijke refunds mogelijk zodra er een betaling aan de order is gekoppeld, ook na verzending. De beheeractie kan per order_detail een hoeveelheid en bedrag bevatten, plus een bedrag voor verzendkosten, een keuze voor voorraad en de optie om een credit slip te genereren. Dat maakt de actie geschikt als bron van een besluit, niet automatisch als opdracht om geld te sturen.

Laat een medewerker altijd bevestigen:

1. welke orderregel wordt gecrediteerd;
2. hoeveel stuks werkelijk meetellen;
3. welk deel van de korting op die regel hoort;
4. of verzendkosten worden terugbetaald;
5. welke voorraadactie is toegestaan;
6. welke betaalmethode het geld terugstuurt;
7. wie de beslissing heeft vrijgegeven.

Een gewone retour hoort eerst de fysieke status received, inspected of quarantine te krijgen. Een goodwillrefund kan rechtstreeks naar approved, maar noteer dan de reden. Bewaar bewijs bij de beslissing. Een lege opmerking met alleen akkoord is geen bruikbaar dossier.

5. Voer de geldactie uit met een vaste actiessleutel

Maak vóór de API-oproep één interne actiessleutel, bijvoorbeeld refund-10482-7811-1. Sla hem samen met de exacte regels en het bedrag op. Roep daarna de betaalprovider aan. Bij Mollie gaat een refund via POST /v2/payments/{paymentId}/refunds; het bedrag mag lager zijn dan het oorspronkelijke betaalbedrag en de API accepteert metadata naast het bedrag in de actuele referentie van de refundactie.

Gebruik in de metadata minimaal je orderreferentie, orderregel-ID en interne actiessleutel. Wacht na een time-out eerst op een bestaande refund met die sleutel of het bekende refund-ID. Maak geen nieuwe refund omdat de eerste HTTP-respons niet op tijd kwam. Behandel queued, pending of processing als tussenstatus, niet als ontvangen geld.

Als je een andere PSP gebruikt, gebruik dan diens eigen idempotentie- en webhookregels. Het principe blijft gelijk: dezelfde domeinactie krijgt bij een retry dezelfde sleutel, dezelfde regels en hetzelfde bedrag. Een nieuwe sleutel is een nieuwe financiële opdracht.

Controlepunt: een dubbele levering of time-out kan geen tweede refund of tweede creditnota maken.

6. Maak de creditnota uit de snapshot, niet uit de nieuwe order

Zodra de refund is goedgekeurd, maak je de creditnota met alleen de vrijgegeven regels. Neem de oorspronkelijke klant, valuta, btw-code, grootboekrekening, productomschrijving, korting en orderreferentie over. Voeg de PrestaShop-credit-slip of refundreferentie toe als extern bewijs.

De Twinfield API maakt een belangrijk onderscheid tussen een sales invoice en de onderliggende sales transaction. De actuele documentatie zegt ook dat de sales-invoice-webservice in de Classic sales invoicing module werkt en nog niet de nieuwe invoermodule aanmaakt waardoor je eerst moet vaststellen welke Twinfield-route jouw administratie gebruikt. Laat de accountant dit besluit vooraf maken. De koppeling hoort een bestaande boekingsafspraak uit te voeren, niet tijdens een refund een nieuw type boeking te verzinnen.

Een veilige creditnota bevat minimaal:

• het oorspronkelijke factuurnummer;
• de PrestaShop-orderreferentie;
• de specifieke orderregel en hoeveelheid;
• netto bedrag, btw-bedrag en totaalbedrag;
• de originele btw-code;
• het refund-ID en de datum van vrijgave;
• de Twinfield-transactiegegevens zodra de boeking is gelukt.

Boek een schade-afschrijving niet automatisch als klantrefund. Voorraadwaarde, omzetcorrectie, btw en geldterugbetaling zijn verschillende beslissingen. Een creditnota corrigeert de verkoop; een voorraadboeking corrigeert de voorraad; de betaalactie verplaatst geld.

7. Match betaling, deelbetaling, korting en refund apart

Behandel een betaling niet als bewijs dat een factuur volledig is gesloten. Een betaling van €119 op een factuur van €121 kan een deelbetaling zijn, een toegestane betalingskorting, een bankfee of een fout. Dat zijn vier verschillende uitkomsten.

Twinfield gebruikt voor matching een matchset met kantoor, matchcode, datum en transactieregels. De API ondersteunt matchvalue voor deelbetalingen en writeoff voor een koersverschil, afboeking of aftrek. Een verschil krijgt een type zoals currency, writeoff of discount in plaats van een brede regel die elk verschil stilzwijgend wegboekt.

Gebruik deze beslisvolgorde:

1. Match op een unieke betaalreferentie plus exact bedrag.
2. Match op een unieke PSP- of bankreferentie plus klant en bedrag.
3. Stel een deelbetaling voor als de betaling lager is en er geen kortingsbesluit bestaat.
4. Gebruik een korting of afboeking alleen als het beleid en de bevoegde vrijgave dat toestaan.
5. Stuur meerdere kandidaten, een onbekende referentie of een hoger bedrag naar de queue.

De refund zelf krijgt een eigen matchrelatie. Bij een volledig betaalde factuur koppel je de creditnota aan de uitgaande refund via de afgesproken refund- of PSP-tussenrekening. Bij een nog openstaande factuur kan de creditnota eerst de openstaande post verkleinen. Laat de administratie kiezen welke van die twee situaties bij jouw dagboekstructuur hoort.

8. Bouw een uitzonderingsqueue die iemand echt kan afwerken

Een rood bolletje is geen proces. Maak voor iedere uitzondering een kaart met:

Gebruik vaste redenen: ontbrekende_orderregel, dubbele_refund, meerdere_betaalkandidaten, deelbetaling, korting_niet_vrijgegeven, btw_afwijking, psp_status_onbekend, twinfield_429 en boekingsperiode_gesloten. Zo kun je na een week meten welke regels je moet verbeteren.

Een exception queue is ook een veiligheidsgrens. Alles wat niet uniek en exact matcht, blijft daar zichtbaar. Een medewerker kiest een uitkomst en motiveert die. Een automatische regel die de queue alleen leegmaakt door ruimere toleranties is geen verbetering.

9. Test herhaling, herstel en de eerste week

Test iedere belangrijke stap drie keer: één keer goed, één keer met een fout en één keer opnieuw. Gebruik bij het ophalen van PrestaShop een overlappend tijdvenster, zodat een late order niet tussen twee runs valt. Laat de unieke sleutels dubbelen tegenhouden.

Twinfield meldt bij overschrijding van request- of concurrencylimieten een 429. De actuele documentatie noemt ook een fout bij transacties met meer dan 1.000 regels zodat je retries, backoff en batchgrootte niet pas in productie ontdekt. Voor een webshop zijn 1.000 regels zelden het probleem, maar een onbegrensde inhaalrun kan wel tegen requestlimieten lopen.

Meet de eerste zeven dagen minimaal:

• het percentage unieke matches;
• het percentage regels met menselijke vrijgave;
• de ouderdom van open uitzonderingen;
• dubbele webhook- en retrypogingen;
• verschil tussen refundbedrag en creditnotabedrag;
• verschil tussen PSP-uitbetaling en Twinfield-tussenrekening;
• tijd tussen refundbevestiging en gereconcilieerde creditnota.

Pas na die week weet je of je een koppeling hebt of alleen een snelle manier om onduidelijkheid door te sturen.

Valkuilen

Je crediteert de hele order voor één regel

Wat er misgaat: omzet, btw en openstaande posten dalen met het volledige orderbedrag terwijl één artikel is terugbetaald.

Mitigatie: koppel refundregels aan order_detail_id en bewaar de resterende, nog terugbetaalbare hoeveelheid. Maak voor iedere regel zichtbaar hoeveel al is geretourneerd en terugbetaald.

Je gebruikt de actuele prijs uit de catalogus

Wat er misgaat: een prijswijziging, bundelkorting of wisselkoers maakt de nieuwe berekening anders dan het bedrag dat de klant werkelijk betaalde.

Mitigatie: maak bij de order een financiële snapshot. Verdeel kortingen volgens een vast beleid en rond pas op het laatste vastgelegde niveau af.

Je verwart retour, credit slip en refund

Wat er misgaat: een ontvangen pakket veroorzaakt direct een geldactie, of een PrestaShop-credit slip wordt aangezien voor bewijs dat geld al is teruggestuurd.

Mitigatie: houd fysieke ontvangst, financiële goedkeuring, creditnota, PSP-status en bankreconciliatie als aparte statussen. De ene status mag de volgende voorbereiden, maar niet stilzwijgend voltooien.

Je laat twee bronnen factureren

Wat er misgaat: de webshopconnector maakt de factuur en een betaalproviderconnector maakt nogmaals een factuur omdat hij dezelfde betaling ziet.

Mitigatie: laat PrestaShop de order en btw-regels leveren. Laat de PSP alleen betaling, refund en uitbetaling leveren. Laat Twinfield de financiële registratie en match bewaren. Dit is dezelfde bronkeuze als bij een algemene webshop- en betalingskoppeling naar de boekhouding, maar de deelrefund voegt er een tweede financiële stroom aan toe.

Je matcht op bedrag alleen

Wat er misgaat: twee openstaande posten van €44,00 lijken allebei goed, of een €119-betaling wordt als €121-factuur gesloten zonder te weten waarom.

Mitigatie: gebruik een sterke referentie, klant, valuta en bedrag samen. Zet een bedrag zonder unieke kandidaat op suggestion of exception, nooit op automatische vrijgave.

Je behandelt iedere webhook als een nieuwe gebeurtenis

Wat er misgaat: een retry na een time-out maakt een tweede refund of een tweede creditnota.

Mitigatie: leg delivery-ID, provider-ID en interne actiessleutel vast. Controleer vóór iedere schrijfactie of het object al bestaat. Bij onbekende uitkomst eerst ophalen, daarna pas opnieuw schrijven.

Je maakt een creditnota in de verkeerde Twinfield-laag

Wat er misgaat: de API-call is technisch geslaagd, maar de boeking belandt niet in de module of rapportage die de accountant gebruikt.

Mitigatie: leg vooraf vast of je sales invoice, sales transaction of een tussenrekening gebruikt. Test met een echte creditnota in een testadministratie en laat de accountant het grootboek, btw en openstaande post controleren.

Je verbergt verschillen met een ruime tolerantie

Wat er misgaat: bankkosten, korting, deelbetaling en een verkeerde betaling verdwijnen onder één regel verschil toegestaan.

Mitigatie: geef iedere afwijking een reden, eigenaar en grens. Alleen een herhaalbaar en laag-risicopatroon mag automatisch worden verwerkt. Een financiële afboeking vraagt een besluit.

Je vergeet btw over de grens

Wat er misgaat: de creditnota gebruikt de Nederlandse btw-code terwijl de oorspronkelijke verkoop onder een buitenlands tarief of OSS-stroom viel.

Mitigatie: neem de oorspronkelijke btw-code en landcontext over. De Europese factuurregels verlangen bij een creditnota een ondubbelzinnige verwijzing naar de oorspronkelijke factuur en de gewijzigde details in de actuele uitleg over btw-facturatie. Als een buitenlandse levering al in de aangifte stond en de klant de goederen terugstuurt, beschrijft de Belastingdienst aparte correcties met een creditfactuur voor de ICP-opgaaf en btw-aangifte. Laat grensoverschrijdende correcties door je accountant bevestigen.

Beslis-kader: connector, orkestratielaag of maatwerk?

Kies op de zwaarste uitzondering, niet op het gemiddelde aantal orders. Een shop met 200 simpele Nederlandse orders per maand kan met een connector uit de voeten. Een shop met 40 orders, drie btw-landen, veel deelrefunds en verplichte vrijgave heeft al snel een eigen transactielaag nodig.

Kies een kant-en-klare connector als één administratie, één betaalprovider, standaard btw en vooral volledige refunds je werkelijkheid zijn. Controleer vóór aanschaf of de connector orderregels, kortingen, creditnota’s, meerdere refunds op één order en jouw Twinfield-module ondersteunt. Een productpagina die refunds noemt is geen bewijs dat deelrefunds per regel correct worden geboekt.

Kies n8n of een vergelijkbare orkestratielaag als je de API’s al begrijpt en vooral een webhook, planning, melding en kleine uitzonderingsqueue nodig hebt. n8n rekent bij Cloud op volledige workflowuitvoeringen, niet op losse stappen. De officiële prijskaart noemt voor Starter €20 per maand bij jaarlijkse betaling, 2.500 uitvoeringen en vijf gelijktijdige runs; Pro kost €50 en biedt 10.000 uitvoeringen en twintig gelijktijdige runs. Bewaar financieel bewijs en idempotentiesleutels wel in een duurzame opslag. Een workflowgeschiedenis is geen boekhouding.

Kies maatwerk als de refund op orderregelniveau moet worden berekend, een medewerker geld en creditnota afzonderlijk moet vrijgeven, meerdere PSP’s samenkomen, Twinfield-deelbetalingen en afboekingen beleidsmatig verschillen, of je meerdere entiteiten en valuta bedient. Dan bouw je geen doorgeefluik maar een klein transactiesysteem. De bouwkosten hangen af van het bestaande datamodel, de boekingsafspraken, testomvang en beheer. Een vast bedrag verzinnen helpt je hier niet.

Mijn beslisregel: als je de uitzondering niet in één zin met bron, bedrag, eigenaar en uitkomst kunt beschrijven, is een simpele connector te klein. Als je dat wel kunt en het patroon vaak genoeg terugkomt, automatiseer je de regel. Alles daarbuiten blijft een menselijke beslissing.

Moet een refund per orderregel, korting en btw-bedrag worden berekend?

Nee, meestal volledige refundsJa, per regel en bedrag

Vergelijkingstabel: drie werkbare routes

De prijzen zijn geen totaalprijs voor de koppeling. Ze maken alleen de ondergrens van de software zichtbaar. Een goedkope workflow zonder herstelpad kan duurder worden zodra één dubbele refund een kwartaalcorrectie veroorzaakt.

Uitgewerkt voorbeeld: één refunddag bij een kledingwebshop

De volgende oefencasus is fictief, maar de bedragen en sleutelkeuzes zijn bewust concreet. Nordlicht Kleding verkoopt vanuit PrestaShop aan Nederlandse consumenten, ontvangt via Mollie en boekt in Twinfield. De shop gebruikt 21% btw, één Twinfield-administratie en een aparte tussenrekening voor Mollie-uitbetalingen.

De oorspronkelijke order

Order 10482 heeft referentie QZABCD123:

De snapshot bewaart voor de eerste Trailshirt-regel order_detail_id=7811, hoeveelheid 2, terugbetaald 0, productprijs €49,00 en toegerekende korting €5,00 per stuk. De oorspronkelijke factuur in Twinfield is VRK-2026-145 voor €215,95.

Het refundbesluit

De klant stuurt één Trailshirt terug. De inspectie markeert de regel als verkoopbaar. De medewerker keurt één stuk goed voor €44,00, namelijk €49,00 minus €5,00 toegerekende korting. De creditnota bevat dus één stuk, €36,36 netto en €7,64 btw. Het windjack en de verzending blijven onaangeraakt.

Het systeem maakt refund-10482-7811-1 aan. Mollie krijgt het oorspronkelijke betaal-ID en een refundbedrag van €44,00. Het antwoord wordt opgeslagen als refund_pending; pas de bevestiging van het refund-ID verandert dit in refund_confirmed. Een time-out leidt tot een zoekactie op de interne sleutel, niet tot een tweede POST.

Daarna maakt de boekingslaag creditnota VRK-2026-198 aan met verwijzing naar VRK-2026-145, QZABCD123 en het refund-ID. De oorspronkelijke btw-code blijft staan. In de Mollie-tussenrekening ontstaat een uitgaande refund van €44,00. De creditnota en de uitgaande refund worden volgens de afgesproken Twinfield-match tegen elkaar gesloten.

Dezelfde dag: een deelbetaling met korting

Order 10483 levert een factuur van €121,00 op. De klant betaalt €119,00 en gebruikt de afgesproken betalingskorting van €2,00. De matcher ziet de unieke referentie en een exact bedrag van €119,00, maar sluit de factuur niet automatisch zonder beleid. De bevoegde medewerker kiest discount, waarna Twinfield de betaling met matchvalue=119,00 en een expliciete afboeking van €2,00 kan verwerken.

Een derde betaling van €18,00 staat in hetzelfde PSP-rapport maar heeft geen orderreferentie. De matcher vindt twee openstaande kandidaten en zet de regel op meerdere_betaalkandidaten. Er wordt geen factuur gesloten en geen afboeking geboekt. De medewerker krijgt het PSP-rapport, de tegenrekening, omschrijving, bedrag en twee kandidaten te zien.

De uitbetaling sluit pas aan het einde

Het PSP-rapport bevat na de refund deze drie relevante bedragen:

• €171,95 netto over order 10482 na de refund;
• €119,00 ontvangen voor order 10483 na de betalingskorting;
• €18,00 onbekend ontvangen bedrag.

Het totaal vóór kosten is €308,95. Na €6,23 betaalproviderkosten staat €302,72 klaar voor uitbetaling. De bankregel wordt pas vrijgegeven als €171,95, €119,00, €18,00 en €6,23 ieder een eigen status en bewijs hebben. De €18,00 mag voorlopig op een tussenrekening blijven staan. De bankregel zelf is dus niet het bewijs dat alle onderliggende verkopen kloppen.

Na de eerste dag zijn de controle-uitkomsten:

Dit is het gewenste eindbeeld: één refund verandert één regel, één creditnota en één geldactie. De rest van de order blijft staan. De onbekende betaling blijft zichtbaar totdat iemand haar kan bewijzen.

Slot: de keten moet uitlegbaar blijven

Een goede PrestaShop-Twinfield-koppeling maakt niet alles groen. Hij maakt zichtbaar waarom iets groen, geel of rood is. Wie de orderregel, het refundbesluit, de creditnota, de deelbetaling en de uitbetaling aan elkaar kan relateren, kan fouten herstellen zonder opnieuw te gokken. Wie die relaties niet bewaart, automatiseert vooral het moment waarop een kleine uitzondering uitgroeit tot een verkeerde btw-aangifte of een onverklaarbaar saldo.