Polling en webhooks mogen allebei een betaalstatus ophalen, maar slechts één keer de betaalovergang verwerken. Behandel beide kanalen als concurrerende boodschappers van dezelfde providerwaarheid. Laat ze dezelfde controles uitvoeren, vergrendel de kritieke overgang en lees de order vlak vóór de statuswijziging opnieuw.
Bij terminalbetalingen is deze race normaal. De browser vraagt om de paar seconden of de klant klaar is, terwijl de betaalprovider vrijwel gelijktijdig een bericht stuurt. Zonder coördinatie kunnen beide processen voorraad verminderen, e-mails verzenden of downstream-integraties starten. De oplossing is niet één kanaal uitschakelen: polling geeft directe feedback, de webhook vangt een gesloten browser op.
Maak de orderovergang idempotent
Definieer één overgang van “wacht op betaling” naar “betaling ontvangen”. Iedere verwerker controleert eerst of die overgang al is verwerkt. Daarna claimt hij kort het recht om haar uit te voeren, haalt zo nodig de actuele providerbetaling op en controleert referentie en bedrag. WooCommerce kan de order vervolgens op “Processing” zetten wanneer fulfilment nog nodig is, of op “Completed” wanneer het proces dat toelaat.
Een lock hoeft niet minutenlang te bestaan. Hij moet lang genoeg zijn om twee gelijktijdige requests uit elkaar te houden en vanzelf kunnen verlopen als een proces onverwacht stopt. Sla daarnaast de providerreferentie bij de order op. Daarmee is een herhaald bericht herkenbaar zonder te vertrouwen op timing.
Houd de lock zo lokaal mogelijk: bij voorkeur per order of betaalpoging, niet voor alle transacties. Een globale lock zou betalingen van verschillende klanten onnodig achter elkaar zetten. Gebruik een token zodat alleen de eigenaar zijn lock kan vrijgeven. Verwijder hem in een gegarandeerde opruimstap, maar vertrouw daarnaast op een eindtijd voor het geval het proces hard stopt.
Gebruik één beslisboom voor beide kanalen
| Controle | Polling | Webhook |
|---|---|---|
| Order bestaat en is betaalbaar | Verplicht | Verplicht |
| Providerstatus actueel ophalen | Ja | Bij voorkeur ook verifiëren |
| Referentie en bedrag vergelijken | Ja | Ja |
| Korte orderlock gebruiken | Ja | Ja |
| Al afgeronde order overslaan | Ja | Ja |
| Gebruikersfeedback tonen | Direct in browser | Via volgende statusweergave |
Laat de webhook niet blind het aangeleverde resultaat vertrouwen wanneer de provider een betrouwbare opvraagmogelijkheid biedt. Een bericht kan vertraagd, dubbel of buiten volgorde binnenkomen. De provider opnieuw raadplegen kost een extra request, maar geeft één consistente bron voor beide paden.
Definieer ook welke statussen monotone vooruitgang vormen. “In behandeling” mag een al bevestigde betaling niet terugzetten. Een latere terugbetaling of formele annulering is een nieuwe zakelijke gebeurtenis en verdient een eigen route, niet een simpele terugwaartse statuswijziging. Bewaar het verschil tussen providerstatus en WooCommerce-orderstatus; zij beantwoorden niet altijd dezelfde vraag.
Fictief voorbeeld: twee bevestigingen in dezelfde seconde
Fietswinkel Spaak start een terminalbetaling voor een afhaalorder. Om 14:07:12 ontvangt de server een webhook. Een fractie later vraagt de browsertab dezelfde status op. Het webhookproces verkrijgt de lock, leest de providerstatus en verwerkt de betaling. Het pollproces wacht kort, leest daarna de verse order en ziet dat geen tweede betaalovergang nodig is. De fiets moet operationeel nog worden klaargezet.
De klant krijgt één bevestigingsmail, voorraad wordt één keer verwerkt en het ERP ontvangt één ordergebeurtenis. Beide requests mogen wel een technische notitie schrijven dat zij de status zagen, zolang logboeken niet voor dubbele zakelijke acties zorgen. Een centrale integratielaag zoals Yindle Connect kan vervolgens ordergebeurtenissen en uitzonderingen beheersbaar naar andere systemen leiden.
Spaak test daarna een trage provideropvraag. Het eerste request houdt de lock langer vast dan verwacht; het tweede geeft geen foutieve betaaluitkomst maar probeert na een korte pauze opnieuw. Als de wachttijd wordt overschreden, blijft de browser eerlijk melden dat controle loopt. Zo wordt technische onzekerheid niet vertaald naar een gevaarlijke knop “betaal opnieuw”.
Race-test vóór productie
- Stuur hetzelfde providerbericht meerdere keren met dezelfde referentie.
- Laat polling en webhook exact tegelijk een geslaagde status verwerken.
- Onderbreek het eerste proces nadat de lock is verkregen.
- Controleer dat een verlopen lock herstel mogelijk maakt.
- Verwerk eerst “geslaagd” en daarna een ouder “in behandeling”-bericht.
- Controleer voorraad, e-mail, factuur en ERP-export op dubbele acties.
- Herhaal de test voor geannuleerd, geweigerd en onbekend.
- Maak in logging zichtbaar welk kanaal de overgang uitvoerde.
Monitor niet alleen fouten, maar ook herhaalde berichten die correct zijn genegeerd. Een plotselinge stijging kan wijzen op providerretries, trage responses of een verkeerd ingestelde pollingfrequentie. De basisprincipes gelden ook buiten betalingen; betrouwbare webshop-ERP-koppelingen hebben dezelfde behoefte aan gecontroleerde statusovergangen.
Laat Yindle een racebestendige betaal- en orderstroom ontwerpen.
De gedeelde beslisroute voor polling en webhooks hoort bij Yindle Terminal Payments, dat dezelfde geauthenticeerde verificatie gebruikt voor browserstatus, webhooks en herstel.