El reto
Un SaaS B2B que se expandía de Norteamérica a APAC y EMEA necesitaba una infraestructura de pagos capaz de cobrar en cinco monedas, gestionar la facturación por suscripción, manejar los reintentos con elegancia y superar una revisión de seguridad. Habían superado una configuración de un solo procesador: los márgenes de cambio se comían el 1.8% de los ingresos, la liquidación tardaba varios días y su gestor de webhooks existente perdía eventos bajo carga. El CFO quería Airwallex por el cambio de divisas y las redes globales; el CTO quería conservar su stack FastAPI y no convertir los pagos en un servicio aparte que el equipo no pudiera operar.
El encargo: entregar en un solo trimestre una integración de Airwallex en producción sobre FastAPI + PostgreSQL, con una fiabilidad de webhooks a prueba de balas, una verdadera máquina de estados de suscripción, una arquitectura alineada con PCI-DSS y una operación limpia para que el ingeniero de guardia a las 2 a. m. no tenga que despertar al CTO.
Nuestra solución
Construimos una integración de Airwallex centrada en tres ideas de ingeniería: un modelo de dominio de pagos tipado, un pipeline de webhooks con patrón outbox y una máquina de estados para el ciclo de vida de la suscripción que el resto de la app puede leer, pero en la que solo el código de pagos puede escribir.
En el lado de la API, todos los datos de tarjeta se recogen con los elementos de pago alojados de Airwallex, de modo que el backend de la aplicación nunca toca un PAN — el alcance de PCI se mantiene en SAQ A. El servicio FastAPI expone una API de pagos pequeña y tipada (modelos Pydantic v2, documentada con OpenAPI) que consume el equipo de producto; las llamadas a la API de Airwallex se envuelven en un único cliente con claves de idempotencia, reintentos exponenciales y circuit breaker.
En el lado de los webhooks, cada evento de Airwallex llega a un endpoint firmado y verificado que hace una sola cosa: persistir el evento sin procesar en una tabla `inbox` dentro de una única transacción. Un worker independiente procesa el inbox en orden, con entrega al menos una vez y manejadores idempotentes. Este patrón por sí solo resolvió por completo el problema de eventos perdidos — incluso durante un pico de tráfico 4 veces mayor en el lanzamiento.
La máquina de estados de suscripción gestiona prueba, activa, vencida, reclamación de cobro, pausada, cancelada y reactivada, con transiciones permitidas explícitas y un registro de auditoría en cada cambio de estado. Los pagos fallidos ahora siguen un calendario inteligente de reintentos (no el retroceso exponencial por defecto) ajustado a los patrones del día de facturación del cliente, lo que produjo la reducción del 65% en la pérdida de clientes por pagos fallidos.
- Elementos de pago alojados de Airwallex — el backend de la aplicación nunca toca un PAN (PCI SAQ A)
- API de pagos FastAPI tipada con modelo de dominio Pydantic v2 y contrato OpenAPI
- Cliente de Airwallex idempotente con claves de idempotencia, reintento exponencial y circuit breaker
- Pipeline de webhooks con patrón inbox — verificación de firma, evento sin procesar persistido, vaciado ordenado por worker
- Máquina de estados de suscripción: prueba, activa, vencida, reclamación de cobro, pausada, cancelada, reactivada
- Calendario inteligente de reclamación de cobros ajustado a los patrones del día de facturación del cliente (no un retroceso ingenuo)
- Compatibilidad multimoneda: USD, CAD, GBP, EUR, AUD activas en el lanzamiento — otras añadidas en días
- Paneles de Datadog para retraso de webhooks, tasa de reintentos, embudo de reclamación de cobros y exposición cambiaria
- Manual de guardia real que cubre caídas de Airwallex, acumulación de webhooks y eventos con firma inválida