Back to 0fee
0fee

El patrón de callback intermediario: verificando cada pago

Cómo el patrón de callback intermediario de 0fee.dev verifica cada pago interceptando las redirecciones del proveedor antes de llegar al desarrollador.

Juste A. Gnimavo (Thales) & Claude | March 27, 2026 2 min 0fee
EN/ FR/ ES
securitycallbackspayment-verificationmiddleman-patternredirect-flow

En el procesamiento de pagos, el momento entre "el cliente dice que pagó" y "podemos confirmar que realmente pagó" es donde vive el fraude. Cuando un proveedor de pago redirige a un cliente de vuelta al sitio web del comerciante después del checkout, esa redirección no prueba nada. Cualquiera puede navegar directamente a https://tuapp.com/payment/success?status=paid. Sin verificación del lado del servidor, un usuario malicioso podría saltarse el pago completamente y llegar a la página de éxito.

Para 0fee.dev -- un orquestador de pagos manejando transacciones en nombre de miles de desarrolladores -- esto no es una preocupación académica. La Sesión 023 se dedicó completamente a resolver este problema en cada proveedor.

El patrón inserta a 0fee entre el proveedor de pago y la URL de éxito del desarrollador: 0fee almacena las URLs del desarrollador en el JSON de payment_flow, envía nuestra propia URL de callback al proveedor, verifica el pago llamando a la API del proveedor cuando llega la redirección, actualiza el estado de la transacción y solo entonces redirige al cliente a la URL del desarrollador. El desarrollador nunca necesita verificar el pago por sí mismo.

Cada proveedor tiene su propia función de verificación porque cada uno tiene una API diferente para verificar el estado del pago. Stripe confirma instantáneamente. PaiementPro necesita un retraso de 3 segundos más 3 reintentos porque su redirección ocurre antes de que el procesamiento se complete. PawaPay es usualmente rápido pero puede retrasarse.

Tanto el callback intermediario (inmediato, para retroalimentación de UI en tiempo real) como los webhooks (asíncronos, para actualizaciones de sistema backend) son necesarios. El callback proporciona retroalimentación instantánea al cliente, mientras el webhook proporciona notificación confiable al backend.

La Sesión 023 fue una de las sesiones más importantes en el desarrollo de 0fee. Cerró una brecha de seguridad que existía desde la Sesión 001, aplicando la corrección uniformemente en cada proveedor basado en redirección. El patrón es ahora obligatorio para cada nueva integración de proveedor.


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