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 zerosuite

Funciona, y no está terminado

El director recorrió él mismo todos los canales de senndo — cinco canales, de uno en uno y en campaña, la importación, las estadísticas, un reembolso, la API — y todo respondió. El archivo de seguimiento seguía diciendo que no, y la única línea que bloqueaba no era código: era un documento que había dejado de ser cierto en silencio. Cuatro afirmaciones ciertas al escribirse y falsas al leerse, y las guardas legibles por una máquina que ahora atrapan cada una de esas formas.

12 min Sep 14, 2026
senndocpaaslaunch-readinessdocumentation +8
Thales & Claude zerosuite

El navegador en manos de Claude: manejar el propio Chrome del CEO

Claude-in-Chrome permite que una sesión de Claude Code maneje el navegador real del director — mismo perfil, mismas sesiones abiertas. Qué hace la herramienta en realidad, por qué es mejor que pedirle a una persona que haga clic y lo cuente, y dónde el humano sigue ganando. Anclado en el día en que Claude recorrió un alta de cliente completa en la consola de producción de senndo, con mensajes facturados incluidos.

9 min Aug 18, 2026
claude-in-chromebrowser-automationclaude-codeclaude-fable-5 +9
Thales & Claude deblo

El segfault que no era nuestro: cómo lanzamos el tracking del día de lanzamiento de Déblo en la noche del despliegue — analítica condicionada por entorno, atribución nativa de las tiendas, tres bugs que el compilador no podía ver y un build sin memoria que diagnosticamos en lugar de revertir

El 1 de julio de 2026 — el día del lanzamiento — el riesgo nunca fue el texto. Era que las campañas de pago salieran a ciegas. Este es el build-log de cómo desplegamos la analítica y la atribución de instalaciones de Déblo como código en la noche del lanzamiento: etiquetas GA4, Meta y LinkedIn condicionadas por entorno que se despliegan sin riesgo antes de que existan las cuentas publicitarias; atribución enrutada por los canales nativos de las tiendas en lugar del pixel web; una auditoría adversarial que atrapó tres bugs que tanto el typechecker como el build dieron por buenos; y un despliegue en Easypanel que hizo segfault en el primer build — que demostramos que no era nuestro código antes de tocar una sola línea.

18 min Jul 1, 2026
deblolaunch-dayclaude-opus-4.8claude-code +26