Bij een laat webhookbericht moet niet de laatst ontvangen payload automatisch winnen, maar de aantoonbaar nieuwste orderversie. Gebruik de webhook als aanleiding, haal de actuele order bij de bron op en vergelijk wijzigingstijden met de lokaal verwerkte versie. Zo voorkom je dat vertraagde bezorging van berichten een nieuwere betaalstatus, adrescorrectie of notitie terugdraait.
Ontvangstvolgorde is geen wijzigingsvolgorde
Netwerken, retries en plug-ins leveren webhooks niet gegarandeerd in de volgorde waarin de klant of webshop de wijzigingen maakte. Bericht B kan eerder aankomen dan bericht A, terwijl A ouder is. Een queue bewaart alleen de aankomstvolgorde. Wie iedere payload blind als nieuwe waarheid opslaat, maakt van transportvertraging een bedrijfsfout.
Leg daarom minimaal drie momenten vast: wanneer de bron zegt dat de order is gewijzigd, wanneer het bericht is ontvangen en welke bronversie lokaal al is verwerkt. Het wijzigingsmoment is leidend voor inhoud; het ontvangstmoment blijft belangrijk voor monitoring. Bij ontbrekende of onbetrouwbare tijdinformatie is opnieuw ophalen veiliger dan gokken.
Versheidsregels voor orderverwerking
- Gebruik winkel plus order-ID als identiteit, nooit alleen het zichtbare ordernummer.
- Haal na een bundelvenster de actuele bronorder op als de API beschikbaar is.
- Negeer inhoud die aantoonbaar ouder is dan de laatst verwerkte bronwijziging.
- Bewaar de genegeerde gebeurtenis als auditregel met reden “verouderde bronversie”.
- Laat een gelijk wijzigingsmoment niet automatisch opnieuw alle nevenacties starten.
- Zet tegenstrijdige versies zonder betrouwbare klok in een gecontroleerde vergelijking.
Deze regels zijn specifieker dan algemene synchronisatie. Ze horen in de orderingang van een WooCommerce-AFAS-koppeling, vóór de transformatie naar debiteur, verkooporder of factuur.
Fictief voorbeeld: oud adres arriveert als laatste
Fictief voorbeeld: klant Sara corrigeert om 14:20 haar huisnummer in order 6208. De update wordt meteen verwerkt en de actuele order krijgt bronwijziging 14:20. Door een retry arriveert om 14:24 alsnog een webhookpayload die om 14:18 is gemaakt en het oude huisnummer bevat.
De integratie registreert het late bericht, maar ziet dat de bronwijziging ouder is dan 14:20. Zij haalt order 6208 opnieuw op, bevestigt het nieuwe nummer en start geen adreswijziging naar AFAS of routeplanning. In de ordertijdlijn staat: “melding ontvangen om 14:24; inhoud overgeslagen wegens oudere bronversie”. De medewerker kan daardoor uitleggen waarom er niets gebeurde. Dit fictieve voorbeeld laat ook zien waarom alleen “laatst binnengekomen” een gevaarlijke definitie van actualiteit is.
Test de moeilijke randen
| Scenario | Gewenste keuze |
|---|---|
| Ouder wijzigingsmoment, later ontvangen | Audit bewaren, inhoud niet toepassen |
| Nieuw wijzigingsmoment, zelfde order | Actuele order ophalen en gecontroleerd verwerken |
| Gelijk moment, identieke inhoud | Geen dubbele externe acties |
| Klokken spreken elkaar tegen | Bron opnieuw lezen of handmatige aandacht |
| Bron tijdelijk niet bereikbaar | Retry van leesstap, niet schrijven met vermoedelijk oude payload |
Toon in Desk zowel de gekozen versie als de reden waarom een andere is overgeslagen. Daarmee kan operations een incident onderzoeken zonder ruwe logs. De technische stroom in Connect blijft ondertussen herhaalbaar: opnieuw lezen mag, een financieel of logistiek neveneffect wordt alleen gestart als de relevante toestand echt veranderde.
Let bij tijdvergelijking op normalisatie. Webshops en externe plug-ins kunnen lokale tijd, UTC of tekst zonder tijdzone aanleveren. Zet waarden bij de ingang om naar één formaat en bewaar ook de oorspronkelijke waarde voor onderzoek. Gebruik geen verwerkingstijd als vervanger voor een ontbrekend wijzigingsmoment; daarmee maskeer je precies de volgordefout die je wilt voorkomen. Maak voor kritieke velden eventueel een eigen monotone versie of inhoudshash. Dan kun je aantonen dat adres, betaalstatus of regels daadwerkelijk veranderden. Test rond zomertijd, netwerkretries en een handmatige correctie vlak na checkout. De acceptatietest is niet “de nieuwste webhook won”, maar “de uiteindelijk toegepaste gegevens komen overeen met de nieuwste geldige toestand in de bron”.
Voeg aan incidentrapporten steeds beide tijdlijnen toe: de zakelijke wijzigingsvolgorde en de technische ontvangstvolgorde. Dat maakt zichtbaar of het probleem in de bron, het transport of de verwerker ontstond. Zonder die scheiding lijkt een trage webhook al snel op een fout van de medewerker die de latere correctie invoerde.
Heb je last van orders die na een vertraging terug lijken te springen? Laat Yindle de versheidsregels van jouw orderstroom beoordelen.