Hoe webhook-bezorging werkt
Shopify stuurt een ORDERS_PAID-event op het moment dat de betaling wordt vastgelegd. Het event komt binnen op een Google Cloud Pub/Sub-topic, de Alva-worker pakt het bericht op, schrijft de Customer- en Purchase-rijen in PostgreSQL en stuurt daarna de bezorgmail via Postmark of MailerToGo. De Pub/Sub-buffer maakt dit betrouwbaar: zit een deploy halverwege of is de database even traag, dan wacht het bericht in de wachtrij en wordt opnieuw bezorgd tot de worker succes bevestigt.
Eenvoudig horizontaal pipelinediagram met vijf gelabelde stappen: Shopify ORDERS_PAID → Google Cloud Pub/Sub-topic → Alva-worker → PostgreSQL (Customer + Purchase) → E-mailverzending (Postmark / MailerToGo). Gebruik Alva-merkkleuren teal/blauw. Geen echte klantgegevens.
Veelvoorkomende oorzaken van vertraging
Veel belasting op de Pub/Sub-wachtrij
Tijdens flash sales kan het topic duizenden wachtende berichten bevatten. De Alva-worker verwerkt ze in volgorde, dus een bestelling achter in een wachtrij van 5.000 berichten wacht op zijn beurt. De latency hier is meestal onder de twee minuten.
Fraudecheck houdt de mail vast
Als fraudechecks aanstaan, schrijft de worker de bestelling in FraudCheckQueue en pauzeert de bezorging tot de Risk API van Shopify reageert. De meeste checks zijn binnen enkele seconden klaar; bestellingen die naar handmatige review gaan, wachten tot jij ze goedkeurt. Licentiecodes worden nooit toegewezen vóór fraudegoedkeuring.
Regeneratie van grote ZIP-packs
Is het product een pack en is een van de bestanden gewijzigd sinds de laatste gecachete ZIP werd gemaakt, dan regenereert Alva het archief in R2 vóór de mail wordt verstuurd. Packs van meerdere gigabytes kunnen minuten duren.
Per-product e-mailinstelling tijdens de verwerking gewijzigd
Schakel je een per-product-e-mailtemplate of zet je e-mail uit voor een product terwijl een bestelling wordt verwerkt, dan leest de worker bij de volgende poging ProductEmailSettings opnieuw. De bestelling wordt nog steeds afgerond — de mail gebruikt simpelweg de nieuwe regel.
Webhook-retries vanaf Shopify
Shopify probeert een mislukte webhook tot 19 keer opnieuw over ongeveer 48 uur, met wachttijd tussen pogingen. Kwam de eerste bezorging bij Alva binnen tijdens een deploy, dan verschijnt de bestelling pas wanneer de volgende retry slaagt — meestal binnen 5–10 minuten.
Wat je doet als het langer dan 5 minuten duurt
Vijf minuten dekt de overgrote meerderheid van de gevallen. Daarna werk je deze checklist af:
- Bevestig dat de bestelling in Shopify betaald is — bestellingen met status in afwachting of geautoriseerd vuren nooit
ORDERS_PAID. - Open de Alva-admin Bestellingenlijst. Vastgehouden betekent dat fraude de bezorging tegenhoudt; Bezig betekent dat de worker er nog mee bezig is.
- Controleer Instellingen → E-mail om te bevestigen dat e-mailbezorging aanstaat en er een geverifieerde afzender is ingesteld.
- Ontbreekt de bestelling helemaal, val dan terug op De downloadlink van een klant vinden om de bezorging handmatig opnieuw te triggeren.
Veelgestelde vragen
Pub/Sub buffert webhooks tijdens deploys, storingen en verkeerspieken, zodat een betaalde bestelling nooit verloren gaat. De worker bevestigt het bericht pas nadat de Purchase-rij is geschreven.
Nee. De bedankpagina gebruikt een voorlopige downloadtoken uit de checkout-extensie, dus bestanden verschijnen direct, zelfs wanneer de webhook ORDERS_PAID nog onderweg is.
Tot 19 keer over ongeveer 48 uur, met exponential backoff. Zolang Alva uiteindelijk succes retourneert, wordt de bestelling normaal verwerkt.
Zie ook
Was dit nuttig?
Laatst bijgewerkt 2026-05-06