Back to 0fee
0fee

Sistema de entrega y reintento de webhooks

Cómo 0fee.dev entrega webhooks con firmas HMAC-SHA256, reintentos con backoff exponencial y desactivación automática tras fallos. Por Juste A. Gnimavo y Claude.

Juste A. Gnimavo (Thales) & Claude | March 27, 2026 2 min 0fee
EN/ FR/ ES
webhooksretryhmacexponential-backoffreliability

Cuando un pago se completa en 0fee.dev -- ya sea a través de la página de checkout de Stripe, el USSD push de Hub2 o el flujo de redirección de PaiementPro -- el comerciante necesita saberlo. No pueden consultar la API continuamente. La solución son los webhooks: solicitudes HTTP POST enviadas desde 0fee.dev al servidor del comerciante cada vez que ocurre un evento de pago. Pero la entrega de webhooks es más difícil de lo que parece. Los servidores de los comerciantes se caen. Las redes fallan. Los firewalls bloquean solicitudes. El sistema de webhooks debe manejar todo esto de manera confiable.

Cada entrega de webhook se firma con HMAC-SHA256 para que el comerciante receptor pueda verificar que la solicitud genuinamente provino de 0fee.dev. El formato de firma t=timestamp,v1=signature sigue la convención popularizada por Stripe. Incluir el timestamp en el mensaje firmado previene ataques de repetición.

El sistema genera webhooks en cada punto significativo del ciclo de vida del pago: payment.created, payment.completed, payment.failed, payment.expired, payment.cancelled, refund.created, refund.completed, refund.failed, checkout.completed, checkout.expired.

Cuando una entrega falla, el sistema reintenta con backoff exponencial: inmediato, 1 minuto, 5 minutos, 30 minutos, 2 horas, 8 horas. La ventana total de reintento abarca aproximadamente 10 horas y 36 minutos.

Si el endpoint de webhook de un comerciante falla 10 veces consecutivas en cualquier evento, el sistema desactiva automáticamente la entrega de webhooks para esa aplicación y notifica al comerciante por email. Pueden reactivarlo desde el panel después de corregir el problema subyacente.

Cada intento de entrega se registra en la tabla webhook_deliveries, sirviendo tres propósitos: depuración, visibilidad en el panel y analíticas.


Este artículo es parte de la serie "Cómo construimos 0fee.dev". 0fee.dev es un orquestador de pagos que cubre más de 53 proveedores en más de 200 países, construido por Juste A. GNIMAVO y Claude desde Abiyán sin ningún ingeniero humano. Sigue la serie para conocer la historia completa de construcción.

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Thales & Claude deblo

El Step Zero no bastó: cómo validar un constructor pero no el runtime tumbó cada sesión de voz de Déblo la hora en que enviamos streaming de cámara en tiempo real

La Fase 14 envió Déblo Eyes — streaming de cámara en tiempo real por LiveKit hacia Gemini Live native audio. El primer despliegue tumbó cada sesión de voz en producción en noventa segundos porque nuestro Step 0 había validado el constructor sin ejercitar el runtime. El build log de cómo Déblo obtuvo ojos, lo que costó un pre-vuelo incompleto, y qué pulidos enviamos versus aplazamos.

33 min May 20, 2026
debloclaude-opus-4.7claude-codegemini-live +25
Thales & Claude deblo

La raya que mató producción: cómo un eslogan de marketing en un encabezado HTTP tumbó el chat de Déblo durante 24 horas

Dos días antes del envío a la App Store, todo el producto de chat de Déblo se rompió en silencio. Sin spinner, sin toast, sin error en la UI — solo aire muerto. La interrupción de 24 horas se reducía a una sola « é » en el valor de un encabezado HTTP que lanzaba UnicodeEncodeError antes de que cualquier petición a OpenRouter saliera del backend. El post-mortem de una falsa hipótesis, una traza de Sentry, y un fix de seis líneas que desbloqueó el lanzamiento.

29 min May 19, 2026
debloclaude-opus-4.7claude-codeincident +19
Thales & Claude deblo

Seis horas, de página en blanco a Apple Review — Cómo enviamos Déblo a la App Store, en vivo

Recorrido en vivo del envío de Déblo a la App Store iOS en seis horas: lo que rechazaron los validadores de Apple (un superíndice Unicode), lo que corregimos (un Promotional Text desperdiciado en marcas de terceros), y los mecanismos del ASO de iOS que casi todos se pierden.

30 min May 13, 2026
debloclaude-opus-4.7claude-codeapp-store +16