Een klant rondt de betaling af en keert terug naar de winkel, maar de bevestigingspagina wordt niet geladen. Of de betalingsprovider verstuurt dezelfde melding meerdere keren. In beide gevallen kan de winkel een status tonen die niet overeenkomt met wat er bij de provider is gebeurd. Dit risico wordt niet opgelost door meer te vertrouwen op de retourpagina: er moet onderscheid worden gemaakt tussen het antwoord van de browser, de werkelijke betalingsstatus en de status van de bestelling.
Een betalingsbevestiging in WooCommerce moet worden behandeld als een verificatie- en reconciliatieproces, niet als een opdracht om opnieuw af te schrijven. Het doel is dat elke poging een eigen identiteit heeft, herhaalde meldingen geen dubbele effecten veroorzaken en afwijkingen worden gecontroleerd voordat de bestelling wordt gewijzigd of vervolgacties worden gestart.
Waarom een late reactie de bestelling niet zelfstandig mag wijzigen
De terugkeer van de klant naar de site en meldingen van de provider hebben verschillende functies. De terugkeer helpt de klant te informeren, maar is afhankelijk van de browser, verbinding en sessie. Een melding van de provider — bijvoorbeeld een webhook — komt vanuit het betalingssysteem en kan vertraagd of herhaald worden verzonden. Geen enkel afzonderlijk signaal mag worden geïnterpreteerd zonder de herkomst, de relatie met de betalingspoging en de betekenis ervan voor de winkel te controleren.
Een vertraging betekent ook niet dat een betaling is mislukt. Als de winkel opnieuw afschrijft omdat er niet onmiddellijk een reactie is ontvangen, kunnen er twee afschrijvingen ontstaan. Omgekeerd kan de bestelling als betaald worden gemarkeerd alleen omdat de klant een succespagina heeft bereikt, waardoor toegang wordt verleend of de verzending wordt gestart zonder bevestigde transactie.
Houd drie resultaten van elkaar gescheiden: de status van elke betalingspoging, de ontvangen gebeurtenissen van de provider en de operationele status van de bestelling in WooCommerce. Een bestelling kan in behandeling blijven terwijl een poging wordt gecontroleerd; een eerdere poging kan mislukken en een latere slagen. Door deze volgorde vast te leggen, wordt voorkomen dat alles wordt teruggebracht tot één label dat moeilijk te onderzoeken is.
Betalingspoging, melding en bestelstatus scheiden
De bestelling vertegenwoordigt de aankoop en de commerciële afhandeling ervan. De betalingspoging vertegenwoordigt een concrete transactie bij de betaalgateway. De melding is een bericht over een gebeurtenis, zoals autorisatie, capture, weigering of terugbetaling. Deze entiteiten zijn aan elkaar gerelateerd, maar zijn niet onderling uitwisselbaar. Elke poging moet de ID bij de provider, het bedrag, de valuta, de datum en het bekende resultaat bewaren.
Voordat een nieuwe poging wordt gestart, moet de workflow controleren of er voor die bestelling al een poging loopt of een betaling is bevestigd. Als een transactie bij de gateway opnieuw wordt geprobeerd, gebruik dan bij voorkeur een idempotency key die door de provider wordt ondersteund. Zo kan een technische herhaling van hetzelfde verzoek als dezelfde transactie worden herkend en niet uitmonden in een tweede afschrijving. De beschikbaarheid en werking van deze sleutels zijn afhankelijk van de integratie en de provider; ga er niet zomaar van uit dat ze beschikbaar zijn.
Een melding moet worden gekoppeld aan een event-ID en aan de bijbehorende transactie- of pogings-ID. Als de provider geen betrouwbare unieke ID biedt, moet op basis van de beschikbare gegevens een passende deduplicatiestrategie worden gedefinieerd en moeten de beperkingen ervan worden gedocumenteerd. Dedupliceren op basis van alleen de bestelling is niet verstandig: voor één bestelling kunnen meerdere legitieme pogingen bestaan.
Geldige statusovergangen definiëren en gebeurtenissen in verkeerde volgorde verwerken
Bepaal voordat bestellingen worden bijgewerkt welke statusovergangen geldig zijn voor elke betaalmethode. Een poging in behandeling kan bijvoorbeeld overgaan naar bevestigd of mislukt; een oude melding dat de poging nog in behandeling is, mag een al bevestigde poging niet terugzetten. Autorisatie en capture kunnen ook verschillende statussen zijn: een autorisatie betekent niet altijd dat het bedrag is geïncasseerd.
De integratie moet de binnenkomende gebeurtenis vergelijken met de geregistreerde status en de bijbehorende transactie. Als een al verwerkte gebeurtenis opnieuw binnenkomt, wordt die herkend en wordt er geantwoord zonder neveneffecten opnieuw uit te voeren. Dit kan gaan om voorraad verlagen, e-mails versturen, toegang verlenen of een extern systeem informeren. Zorg dat de statuswijziging en de registratie van de verwerkte gebeurtenis op elkaar zijn afgestemd. Zo wordt de kans verkleind dat een tussenliggende fout de bestelling wel bijwerkt maar de gebeurtenis niet als verwerkt markeert, of andersom.
Voor gebeurtenissen die in de verkeerde volgorde binnenkomen, is een expliciete regel nodig, geen eenvoudige vergelijking van servertijdstempels. Gebruik de semantiek van de providerstatussen en raadpleeg zo nodig via de API de actuele status van de transactie. Als geen veilige overgang kan worden vastgesteld, behoud dan de bekende status en stuur de zaak ter beoordeling door in plaats van zelf een resultaat af te leiden.
Valideren, registreren en traceerbaar bijwerken
Controleer of de melding daadwerkelijk van de provider afkomstig is door het gedocumenteerde mechanisme voor die integratie te volgen, zoals handtekeningvalidatie. Controleer ook of de account of omgeving bij de winkel hoort en of bedrag, valuta, referentie en bestelling overeenkomen met de verwachtingen. Accepteer een bericht niet alleen omdat het een geldige ID bevat of naar een moeilijk te raden URL wordt gestuurd.
Sla een bruikbaar logboekrecord op voordat wijzigingen worden toegepast: event-ID, referentie bij de provider, gekoppelde bestelling en poging, eventtype, validatieresultaat, ontvangsttijd en genomen beslissing. Bescherm inloggegevens en persoonsgegevens: registreer wat nodig is voor onderzoek, maar geen volledige kaartnummers of geheimen. Vermijd gevoelige gegevens in debuglogs die toegankelijk zijn voor meer mensen dan noodzakelijk.
Een afwijking tussen WooCommerce en de provider wordt niet opgelost door een nieuwe transactie aan te maken. Raadpleeg de status van de transactie in de tool of API van de provider en vergelijk die met de winkelgegevens. Als de betaling is bevestigd, werk de bestelling dan bij via de workflow die door de betaalgateway wordt ondersteund en controleer of vervolgacties slechts eenmaal worden uitgevoerd. Als de uitkomst onduidelijk blijft, markeer de bestelling dan niet als betaald en start geen nieuwe afschrijving voordat de situatie is opgehelderd.
Een beoordelingswachtrij voor uitzonderingen inrichten
Bepaal welke gevallen menselijke beoordeling vereisen: afwijkende bedragen of valuta, een referentie zonder gekoppelde bestelling, een ongeldige handtekening, meerdere bevestigde betalingen voor één aankoop, een onverwachte terugbetaling of een status die geen overgang toestaat. De wachtrij moet de benodigde referenties, de laatst bekende status en de reden voor de uitzondering tonen, met passende toegangsrechten voor onderzoek.
De beoordeling moet vaste, herhaalbare stappen volgen: de transactie bij de provider raadplegen, de bestelling en bijbehorende pogingen controleren, beslissen of bijwerken, terugbetalen of escaleren nodig is, en vastleggen wie de beslissing heeft genomen. Los afwijkingen niet op door gegevens te verwijderen of statussen rechtstreeks in de database te wijzigen; daardoor gaat context verloren en kunnen extensies of vervolgprocessen niet meer synchroon lopen.
Vertragingen, duplicaten en gedeeltelijke storingen testen
Test in een gecontroleerde omgeving de situaties die de normale workflow verstoren: de browser keert vóór of na de webhook terug, meldingen worden gedupliceerd, gebeurtenissen komen in de verkeerde volgorde binnen, er treedt langdurige vertraging op, de handtekening is ongeldig of de winkel valt uit tijdens de verwerking. Neem ook gedeeltelijke storingen mee, zoals het opslaan van de status en het verliezen van de verbinding voordat er aan de provider wordt geantwoord, om te controleren of een nieuwe poging geen acties dupliceert.
Controleer ook of een mislukte poging gevolgd door een geslaagde poging duidelijk wordt weergegeven, een oude melding de status niet terugzet en een herhaald betalingsverzoek geen extra transactie aanmaakt. Gebruik de testmogelijkheden van de betaalgateway en niet-productiegegevens; test geen scenario's door echte bestellingen geforceerd te laten betalen. Controleer het resultaat zowel in WooCommerce als in het dashboard of de API van de provider.
Operationele checklist bij een mogelijke afwijking
- Identificeer de bestelling, elke poging en de referenties bij de provider; neem niet aan dat de ene referentie gelijkstaat aan de andere.
- Raadpleeg de actuele status van de transactie bij de gezaghebbende bron en vergelijk bedrag en valuta.
- Controleer of de gebeurtenis is geauthenticeerd, al is verwerkt of in de verkeerde volgorde is ontvangen.
- Controleer of de bestelling vervolgacties heeft gestart, zoals toegang verlenen, e-mail versturen of de verzending voorbereiden.
- Schrijf niet opnieuw af zolang er een poging is waarvan de uitkomst nog niet is opgehelderd.
- Documenteer de beslissing en escaleer onduidelijke gevallen; volg bij twee afschrijvingen de terugbetalingsprocedure van de provider en informeer de klant over de uitkomst.
Een betrouwbare workflow vereist niet dat elke reactie op tijd binnenkomt: wel dat vertragingen, duplicaten en onzekere statussen niet blindelings tot onomkeerbare acties leiden. Door pogingen van de bestelling te scheiden, elke gebeurtenis te valideren, idempotente statusovergangen toe te passen en uitzonderingen te beoordelen, kan op basis van bewijs onderzoek worden gedaan en wordt het risico op dubbele afschrijvingen verkleind.
