Modelleer een combinatie van pin en contant als twee betaalcomponenten bij één order. Leg per component het bedrag, de methode, de status en een eventuele providerreferentie vast. Verwerk de order pas als betaald wanneer de som van bevestigde componenten exact gelijk is aan het te betalen orderbedrag.
Splitsen is geen vrije tekstnotitie “deels contant”. Zo’n notitie kan niet betrouwbaar worden gecontroleerd, hersteld of doorgegeven. De software moet weten welk deel al via de terminal is bevestigd, welk deel nog door een medewerker moet worden geregistreerd en wat er gebeurt als één helft mislukt.
Start met een vaste rekenregel
Laat de medewerker één component invoeren en bereken de andere server-side als restbedrag. Wanneer een order 86,40 bedraagt en 50,00 wordt gepind, is het contante deel 36,40. Vergelijk in centen en accepteer geen negatieve of nulcomponenten. Herbereken opnieuw wanneer de order vóór de betaling nog mag veranderen.
Leg ook vast welke component eerst komt. Een terminalbetaling is extern en kan een onbekende tussenstatus krijgen. Contant geld is een handmatige bevestiging door een medewerker. Een begrijpelijke flow laat bijvoorbeeld eerst pinnen, toont daarna duidelijk het resterende contante bedrag en vereist een bewuste bevestiging dat dit bedrag is ontvangen.
| Gegeven | Pincomponent | Contante component |
|---|---|---|
| Bedrag | Vast bedrag in centen | Door server berekend restbedrag |
| Bewijs | Providerreferentie en actuele status | Bevoegde medewerker en tijdstip |
| Tussenstatus | Gestart, geslaagd, geweigerd of onbekend | Wacht op controle of ontvangen |
| Herstel | Provider opnieuw raadplegen | Handmatige stap hervatten |
| Betaalovergang | Alleen als bevestigde som exact gelijk is aan ordertotaal | |
Na die betaalovergang kan een fysieke order nog op “Processing” staan omdat picking of levering moet gebeuren. Gebruik “Completed” pas wanneer de fulfilment werkelijk klaar is volgens de gekozen WooCommerce-stroom. Daarmee blijven betalingsbewijs en operationele voortgang twee verschillende vragen.
Maak de tussenstatus expliciet
Na een geslaagde pinbetaling maar vóór de contante bevestiging is de order nog niet volledig betaald. Gebruik een eigen, herkenbare status en blokkeer fulfilment. Toon het reeds betaalde deel, het resterende deel en de volgende actie. Een medewerker die het scherm later opent, moet de flow kunnen hervatten zonder opnieuw een terminalbetaling te starten.
Bij annuleren is terugdraaien niet automatisch hetzelfde als verwijderen. Een bevestigde providerbetaling kan een aparte terugboekingsprocedure vragen; de software hoort dit niet zelf te interpreteren. Zij moet voorkomen dat de order stil wordt gewist en de beschikbare referenties tonen aan een bevoegde medewerker. Dit artikel geeft technisch procesadvies, geen financieel of boekhoudkundig advies.
Blokkeer inhoudelijke orderwijzigingen zodra één component is gestart. Een extra product of andere verzending verandert het totaal en daarmee het restbedrag. Als wijzigen noodzakelijk is, zet de flow in een controletoestand en begin niet automatisch opnieuw. De medewerker moet eerst zien welke betaling al extern is bevestigd en volgens de interne procedure bepalen wat er met het verschil gebeurt.
Fictief voorbeeld: een showroomklant betaalt in twee delen
Bij woonwinkel Veldhuis koopt een klant een kast. Hij wil een deel pinnen en het restant contant betalen. Medewerker Omar voert 300,00 als pincomponent in. De server berekent het resterende bedrag en toont beide delen vóór de terminal wordt gestart. De terminalbetaling slaagt, maar precies daarna ververst de tablet.
Wanneer Omar de order opnieuw opent, ziet hij de geverifieerde pinreferentie en de openstaande contante stap. De knop “opnieuw pinnen” is niet beschikbaar. Hij telt het contante bedrag, bevestigt dit met zijn eigen account en de ordercontrole vergelijkt beide componenten met het ordertotaal. Pas dan wordt de order betaald gemarkeerd.
De downstream-administratie ontvangt de definitieve order en afzonderlijke betaalinformatie volgens de afgesproken dataverantwoordelijkheid. Een koppellaag zoals Yindle Connect kan zulke order- en uitzonderingsstromen tussen webshop en bedrijfssoftware structureren.
Op de klantbevestiging kan Veldhuis de betaalwijzen en bedragen begrijpelijk samenvatten zonder technische providerdata te tonen. In beheer blijft meer detail beschikbaar voor controle. Dat onderscheid voorkomt dat een interne referentie op een bon terechtkomt en maakt tegelijk duidelijk dat de klant niet tweemaal voor hetzelfde deel heeft betaald.
Testgevallen voor gesplitst betalen
- Weiger nul, negatief en meer dan het ordertotaal.
- Controleer afronding op centen en verschillende belastingregels.
- Ververs de browser na ieder tussenmoment.
- Laat de terminalbetaling slagen, weigeren en onbekend blijven.
- Probeer dezelfde pincomponent tweemaal te bevestigen.
- Laat twee medewerkers tegelijk dezelfde order openen.
- Blokkeer fulfilment zolang een component openstaat.
- Controleer logging, rollen en de procedure voor correcties.
Houd de eerste implementatie beperkt tot expliciet ondersteunde combinaties. Meer methoden, fooien, cadeaubonnen of meerdere terminaldelen vergroten het toestandsmodel snel. Wanneer de praktijk daarom vraagt, ontwerp dan bewust een volgende versie. Zie ook hoe webshop en ERP betrouwbaar samenwerken.
Maak ten slotte rapportage niet afhankelijk van het uitlezen van vrije ordernotities. Exporteer beide componenten als gestructureerde gegevens met een gedeelde orderreferentie. Laat administratieve inrichting en verwerking vervolgens toetsen door de daarvoor verantwoordelijke deskundigen; de technische koppeling moet vooral volledig, traceerbaar en herstelbaar zijn.
Laat Yindle een controleerbare split-paymentflow voor jouw verkoopproces ontwerpen.