Verwerk de betaling van een webshoporder pas nadat het actuele providerbedrag overeenkomt met het bedrag dat voor die order betaald moest worden. Een status “geslaagd” is op zichzelf niet genoeg. Controleer ook de providerreferentie, muntsoort en het bedrag in de kleinste geldeenheid, direct aan de serverkant.
Deze controle gaat over technische integriteit, niet over boekhoudkundig advies. Een verkeerde koppeling tussen terminalpoging en order, een gewijzigde cart of een afrondingsfout kan anders een order betaald laten lijken terwijl de ontvangen transactie iets anders vertegenwoordigt.
Vergelijk gehele bedragen zonder zwevende komma
Bewaar en vergelijk geld bij voorkeur in centen of de relevante kleinste munteenheid. Het ordertotaal van € 123,45 wordt dan 12345. Daarmee vermijd je binaire afrondingsverschillen van kommagetallen. Leg vast hoe valuta met een andere schaal worden behandeld en neem die logica op in tests.
Gebruik het actuele openstaande orderbedrag dat bij de betaalpoging hoort. Een medewerker mag niet tijdens een lopende terminalactie ongemerkt regels of verzending wijzigen. Als wijzigen toch nodig is, annuleer dan de poging, herbereken de order en start bewust een nieuwe transactie met een nieuwe referentie.
Leg het controlemoment vast. Het bedrag wordt gecontroleerd wanneer de providerbetaling wordt bevestigd, niet alleen toen het verzoek werd aangemaakt. Lees de order vlak daarvoor opnieuw, omdat een ander proces belasting, korting of verzending kan hebben aangepast. Koppel een poging aan een bevroren verwacht bedrag én vergelijk dat met de actuele order. Een verschil tussen die twee is al reden voor controle, zelfs voordat je naar de provider kijkt.
Bepaal een veilige uitkomst per verschil
| Waarneming | Technische reactie | Beheeractie |
|---|---|---|
| Status geslaagd, bedrag gelijk | Betaling eenmaal verwerken | Geen handmatige actie |
| Status geslaagd, bedrag lager | Niet automatisch betaald markeren | Transactie en order onderzoeken |
| Status geslaagd, bedrag hoger | Niet automatisch verrekenen | Volgens intern proces beoordelen |
| Valuta verschillend | Blokkeren als mismatch | Configuratie controleren |
| Providerreferentie onbekend | Niet aan order koppelen | Bron en logboeken nalopen |
| Betaling al verwerkt | Geen tweede betaalactie | Herhaald bericht registreren |
“Betaling ontvangen” is niet hetzelfde als “fulfilment voltooid”. De WooCommerce-betaalroute kan voorraad verwerken en de order naar “Processing” of “Completed” brengen, afhankelijk van wat nog geleverd moet worden. Ontwerp magazijn- en verzendacties daarom op de passende orderstatus, niet op een algemeen woord als “afgerond”.
Toon medewerkers geen cryptische foutcode als enige uitleg. Meld dat de betaling niet automatisch aan de order kon worden gekoppeld en dat de order niet opnieuw betaald moet worden vóór controle. Bewaar de technische referenties in beveiligde logging, zodat support gericht kan zoeken zonder gevoelige betaalgegevens te kopiëren.
Voorkom dat een beheerder het probleem met één ongedocumenteerde statusklik kan verbergen. Een handmatige vervolgactie hoort bevoegdheid, reden en tijdstip vast te leggen. Daarmee blijft achteraf zichtbaar dat de automatische controle bewust is doorbroken. Laat de software geen fiscaal of financieel oordeel geven; zij levert de gegevens waarmee het bevoegde team volgens zijn eigen procedure handelt.
Fictief voorbeeld: verzending wijzigt tijdens pinnen
Showroom Noord start een pinbetaling voor een order van 480 euro. Tijdens het wachten verandert een collega per ongeluk de verzendmethode, waardoor het ordertotaal stijgt. De provider bevestigt de oorspronkelijke transactie, maar de actuele order verwacht een ander bedrag. De integratie zet de order in een controletoestand en maakt geen tweede voorraad- of fulfilmentactie vrij.
Een beheerder ziet de providerreferentie, het betaalde bedrag en het verwachte orderbedrag naast elkaar. Het team volgt vervolgens zijn vastgelegde operationele procedure. De software beslist niet zelf hoe een verschil financieel moet worden opgelost; zij voorkomt dat de afwijking onzichtbaar wordt. Voor systemen die daarna orderstatus en betaalinformatie uitwisselen, is duidelijk dat “technisch ontvangen” en “zakelijk afgehandeld” verschillende toestanden kunnen zijn.
Bij een koppeling met administratie of ERP moet deze controletoestand ook herkenbaar blijven. Lees hoe een WooCommerce-AFAS-koppeling rondom de volledige orderketen kan worden ingericht.
Technische controlelijst
- Vergelijk bedragen in de kleinste munteenheid.
- Vergelijk altijd de verwachte en ontvangen valuta.
- Koppel de providerreferentie aan precies één betaalpoging en order.
- Vraag bij twijfel de actuele status rechtstreeks bij de provider op.
- Vergrendel de betaalovergang tegen gelijktijdige polling en webhooks.
- Laat bedragverschillen nooit stil doorlopen naar fulfilment.
- Maak de controletoestand zichtbaar voor een bevoegde beheerrol.
- Test betaalverwerking, belasting, korting en gewijzigde verzendkosten.
Documenteer ten slotte wie afwijkingen onderzoekt en welke informatie die persoon nodig heeft. Goede software levert bewijs en blokkeert een onveilige automatische stap; het interne team bepaalt het vervolgproces. Meer over verantwoordelijkheid in de keten staat bij webshop en ERP betrouwbaar koppelen.
Bespreek met Yindle hoe betaalcontroles in jouw integratie horen te werken.