Cómo funciona la entrega de webhooks
Shopify dispara un evento ORDERS_PAID en el momento en que se captura el pago. El evento aterriza en un topic de Google Cloud Pub/Sub, el worker de Alva extrae el mensaje, escribe las filas de Customer y Purchase en PostgreSQL y luego envía el email de entrega a través de Postmark o MailerToGo. El buffer de Pub/Sub es lo que hace esto fiable: si un deploy está a mitad de despliegue o la base de datos está brevemente lenta, el mensaje espera en la cola y se vuelve a entregar hasta que el worker confirma el éxito.
Diagrama horizontal simple de pipeline con cinco etapas etiquetadas: ORDERS_PAID de Shopify → topic de Google Cloud Pub/Sub → worker de Alva → PostgreSQL (Customer + Purchase) → envío de email (Postmark / MailerToGo). Usa el teal/azul de la marca Alva. Sin datos reales de cliente.
Razones comunes de retraso
Carga intensa en la cola de Pub/Sub
Durante ofertas relámpago el topic puede contener miles de mensajes pendientes. El worker de Alva los drena en orden, así que un pedido al final de una cola de 5.000 mensajes espera su turno. La latencia aquí suele estar por debajo de dos minutos.
Comprobación antifraude reteniendo el email
Cuando las comprobaciones antifraude están activadas, el worker escribe el pedido en FraudCheckQueue y pausa la entrega hasta que la Risk API de Shopify responde. La mayoría de comprobaciones se resuelven en segundos; los pedidos enrutados a revisión manual esperan hasta que tú los apruebes. Las claves de licencia nunca se asignan antes de la aprobación antifraude.
Regeneración de pack ZIP grande
Si el producto es un pack y uno de sus archivos cambió desde el último ZIP cacheado construido, Alva regenera el archivo en R2 antes de enviar el email. Los packs de varios gigabytes pueden tardar minutos.
Ajuste de email por producto cambiado en pleno vuelo
Si activas/desactivas una plantilla de email por producto o desactivas los emails para un producto mientras un pedido está en vuelo, el worker vuelve a leer ProductEmailSettings en el siguiente intento. El pedido aún se completa — el email simplemente usa la nueva regla.
Reintentos de webhook desde Shopify
Shopify reintenta un webhook fallido hasta 19 veces durante aproximadamente 48 horas, con backoff entre intentos. Si la primera entrega golpeó a Alva durante un deploy, el pedido puede no aparecer hasta que el siguiente reintento tenga éxito — normalmente en 5-10 minutos.
Qué hacer si han pasado más de 5 minutos
Cinco minutos cubren la mayoría de los casos. Pasada esa ventana, recorre esta lista:
- Confirma que el pedido está pagado en Shopify — los pedidos pendientes o autorizados nunca disparan
ORDERS_PAID. - Abre la lista de pedidos del panel de Alva. Held significa que el antifraude está bloqueando la entrega; Processing significa que el worker sigue trabajando en él.
- Comprueba Ajustes → Email para confirmar que la entrega de email está habilitada y un remitente verificado está configurado.
- Si el pedido falta por completo, recurre a Encuentra el enlace de descarga de un cliente para volver a disparar la entrega manualmente.
Preguntas frecuentes
Pub/Sub almacena en buffer los webhooks durante deploys, caídas y picos de tráfico para que un pedido pagado nunca se pierda. El worker solo confirma el mensaje después de escribir la fila Purchase.
No. La página de agradecimiento usa un token de descarga provisional desde la extensión del checkout, así que los archivos aparecen al instante incluso cuando el webhook ORDERS_PAID sigue en vuelo.
Hasta 19 veces durante aproximadamente 48 horas, con backoff exponencial. Mientras Alva acabe devolviendo éxito, el pedido se procesa con normalidad.
Ver también
¿Te ha resultado útil?
Última actualización 2026-05-06