Comment fonctionne la livraison de webhook
Shopify déclenche un événement ORDERS_PAID dès que le paiement est capturé. L'événement arrive dans un topic Google Cloud Pub/Sub, le worker Alva tire le message, écrit les lignes Customer et Purchase dans PostgreSQL, puis envoie l'e-mail de livraison via Postmark ou MailerToGo. Le buffer Pub/Sub est ce qui rend cela fiable : si un déploiement est en cours ou que la base de données est brièvement lente, le message attend dans la file et est redélivré jusqu'à ce que le worker acquitte le succès.
Diagramme de pipeline horizontal simple avec cinq étapes étiquetées : Shopify ORDERS_PAID → topic Google Cloud Pub/Sub → worker Alva → PostgreSQL (Customer + Purchase) → envoi d'e-mail (Postmark / MailerToGo). Utiliser le bleu/turquoise de marque Alva. Aucune donnée client réelle.
Raisons courantes de délai
Charge importante sur la file Pub/Sub
Pendant les ventes flash, le topic peut contenir des milliers de messages en attente. Le worker Alva les vide dans l'ordre, donc une commande à l'arrière d'une file de 5 000 messages attend son tour. La latence ici est généralement inférieure à deux minutes.
L'anti-fraude retient l'e-mail
Lorsque les vérifications anti-fraude sont activées, le worker écrit la commande dans FraudCheckQueue et met en pause la livraison jusqu'à ce que l'API Risk de Shopify réponde. La plupart des vérifications se résolvent en quelques secondes ; les commandes routées vers une revue manuelle attendent jusqu'à ce que vous les approuviez. Les clés de licence ne sont jamais attribuées avant l'approbation anti-fraude.
Régénération de gros pack ZIP
Si le produit est un pack et qu'un de ses fichiers a changé depuis la dernière construction du ZIP en cache, Alva régénère l'archive dans R2 avant d'envoyer l'e-mail. Les packs de plusieurs gigaoctets peuvent prendre des minutes.
Paramètre d'e-mail par produit modifié en cours de route
Si vous activez/désactivez un modèle d'e-mail par produit ou désactivez les e-mails pour un produit pendant qu'une commande est en cours, le worker relit ProductEmailSettings à la prochaine tentative. La commande se termine quand même — l'e-mail utilise simplement la nouvelle règle.
Tentatives de webhook depuis Shopify
Shopify retente un webhook échoué jusqu'à 19 fois sur environ 48 heures, en espaçant les tentatives. Si la première livraison a atteint Alva pendant un déploiement, la commande peut ne pas apparaître avant la réussite de la prochaine tentative — généralement dans les 5 à 10 minutes.
Que faire si cela fait plus de 5 minutes
Cinq minutes couvrent la grande majorité des cas. Au-delà de cette fenêtre, parcourez cette checklist :
- Confirmez que la commande est payée dans Shopify — les commandes en attente ou autorisées ne déclenchent jamais
ORDERS_PAID. - Ouvrez la liste des commandes de l'admin Alva. Retenue signifie que l'anti-fraude bloque la livraison ; En cours signifie que le worker s'en occupe encore.
- Vérifiez Paramètres → E-mail pour confirmer que la livraison par e-mail est activée et qu'un expéditeur vérifié est configuré.
- Si la commande est entièrement manquante, repliez-vous sur Retrouver le lien de téléchargement d'un client pour redéclencher la livraison manuellement.
Questions fréquentes
Pub/Sub bufferise les webhooks pendant les déploiements, les pannes et les pics de trafic pour qu'une commande payée ne soit jamais perdue. Le worker n'acquitte le message qu'après l'écriture de la ligne Purchase.
Non. La page de remerciement utilise un jeton de téléchargement provisoire de l'extension de paiement, donc les fichiers apparaissent instantanément même lorsque le webhook ORDERS_PAID est encore en cours.
Jusqu'à 19 fois sur environ 48 heures, avec un backoff exponentiel. Tant qu'Alva finit par renvoyer un succès, la commande se traite normalement.
Voir aussi
Cet article vous a-t-il été utile ?
Dernière mise à jour 2026-05-06