Back to 0fee
0fee

Por qué construimos un orquestador de pagos desde cero

Por qué construimos 0fee.dev, un orquestador de pagos que cubre más de 53 proveedores en más de 200 países. Por Juste Thales Gnimavo y Claude, desde Abiyán.

Juste Thales Gnimavo & Claude | March 27, 2026 8 min 0fee
EN/ FR/ ES
payment-orchestrationfintecharchitectureglobal-payments

Si alguna vez has intentado aceptar pagos a nivel global, conoces el dolor. Stripe cubre tarjetas en 46 países. PayPal funciona en más de 200, pero excluye la mayor parte de África. El dinero móvil -- el método de pago dominante para más de 500 millones de personas -- requiere integraciones separadas con MTN MoMo, Orange Money, Wave, M-Pesa y docenas de proveedores regionales. Cada proveedor tiene su propia API, su propio flujo de autenticación, su propio formato de webhook y su propio calendario de liquidación.

Construimos 0fee.dev para resolver este problema de una vez por todas: una API, un SDK, un panel de control -- y cubres el mundo.

El problema: fragmentación de pagos

Considera este escenario. Estás construyendo un producto SaaS en 2026. Tus clientes están en Estados Unidos, Francia, Nigeria, Kenia y Costa de Marfil. Así es como se ve tu integración de pagos sin un orquestador:

PaísMétodo preferidoProveedorEsfuerzo de integración
Estados UnidosTarjetas de crédito/débitoStripe1-2 días
FranciaTarjetas + SEPAStripe1-2 días
NigeriaTarjetas + transferencia bancariaPaystack3-5 días
KeniaM-PesaPawaPay o Safaricom5-7 días
Costa de MarfilOrange Money, WaveHub2 o PaiementPro5-7 días

Son cinco integraciones separadas, cinco contratos de API diferentes, cinco manejadores de webhooks, cinco procesos de conciliación. Y solo estamos cubriendo cinco países. Escala eso a 50 países en cuatro continentes y estarás ante meses de trabajo de integración, un equipo completo dedicado al mantenimiento de pagos y un sistema frágil donde el cambio de API de un proveedor puede romper tu flujo de checkout.

Qué hace un orquestador de pagos

Un orquestador de pagos se sitúa entre tu aplicación y los proveedores de pago. Expone una API única y unificada que abstrae la complejidad de enrutar transacciones al proveedor correcto según país, moneda, método de pago y disponibilidad.

Tu aplicación
       |
       v
   API de 0fee.dev (una sola integración)
       |
       +---> Stripe (tarjetas, global)
       +---> PayPal (billeteras, global)
       +---> Hub2 (dinero móvil, África francófona)
       +---> PawaPay (dinero móvil, 21+ países africanos)
       +---> Paystack (Nigeria, Ghana)
       +---> Flutterwave (30+ países africanos)
       +---> BUI (África Occidental)
       +---> PaiementPro (África Occidental + tarjetas)
       +---> ... 45+ proveedores más

Cuando tu cliente en Costa de Marfil quiere pagar con Orange Money, 0fee enruta la transacción a Hub2 o PaiementPro. Cuando tu cliente en EE. UU. paga con una tarjeta Visa, 0fee enruta a Stripe. Tu código no cambia. Tu manejador de webhooks no cambia. Tu panel de conciliación muestra todo en un solo lugar.

La visión: cinco líneas de código

Desde el principio, queríamos que la experiencia del desarrollador fuera absurdamente simple. Instala el SDK, configura tu clave de API y comienza a aceptar pagos en todo el mundo:

typescriptimport { ZeroFee } from 'zerofee';

const zf = new ZeroFee({ apiKey: 'zf_live_...' });

const payment = await zf.payments.create({
  amount: 5000,        // $50.00 en centavos
  currency: 'USD',
  country: 'US',
  method: 'PAYIN_CARD',
  customer: {
    email: '[email protected]'
  },
  returnUrl: 'https://yourapp.com/thank-you'
});

// payment.checkoutUrl -> redirige al cliente
// payment.id -> rastrea el estado mediante webhooks

La misma estructura de código funciona ya sea que el cliente pague con tarjeta de crédito en Nueva York, una transferencia bancaria en Lagos u Orange Money en Abiyán. Lo único que cambia es country, currency y method.

Para pagos con dinero móvil en África, se ve así:

typescriptconst payment = await zf.payments.create({
  amount: 10000,       // 10.000 XOF
  currency: 'XOF',
  country: 'CI',       // Costa de Marfil
  method: 'PAYIN_ORANGE_CI',
  customer: {
    phone: '+2250700000000'
  },
  returnUrl: 'https://yourapp.com/thank-you'
});

El cliente recibe una notificación push en su teléfono, confirma el pago con su PIN y la transacción se liquida. Tu webhook se dispara con un payload estandarizado independientemente de qué proveedor procesó el pago.

Arquitectura multi-inquilino

0fee no es solo una pasarela de pago -- es una plataforma de orquestación multi-inquilino. Cada aplicación registrada en 0fee obtiene:

  • Credenciales aisladas: tus claves de Stripe, tus claves de PawaPay, tus claves de Hub2 -- almacenadas cifradas, nunca compartidas entre inquilinos.
  • Reglas de enrutamiento personalizadas: define qué proveedores manejan qué países para tu caso de uso específico.
  • Endpoints de webhook separados: cada app configura sus propias URLs de callback.
  • Límites de tasa independientes: un pico de tráfico de un inquilino no afecta a otro.
  • Analíticas por app: ingresos, tasas de éxito, rendimiento del proveedor -- todo limitado a tu aplicación.

La arquitectura soporta esto a través de un modelo de datos jerárquico:

Organización (tu empresa)
  └── Aplicación (tu producto)
       ├── Credenciales del proveedor (cifradas)
       ├── Reglas de enrutamiento
       ├── Endpoints de webhook
       ├── Claves de API (live + test)
       └── Transacciones
            ├── Pagos
            ├── Desembolsos
            └── Reembolsos

Esto significa que una sola organización puede ejecutar múltiples aplicaciones -- un producto SaaS, un marketplace y una tienda de comercio electrónico -- cada una con su propia configuración de pagos, todo gestionado desde un solo panel de control.

¿Por qué no usar una solución existente?

Evaluamos cada plataforma importante de orquestación de pagos antes de construir 0fee. Esto es lo que encontramos:

PlataformaSoporte ÁfricaDinero móvilPreciosAutoservicio
Stripe46 países, África limitadaNo2,9% + $0,30Sí
PayPalSoporte limitado en ÁfricaNo3,49% + tarifa fijaSí
AdyenAlgunos mercados africanosLimitadoPrecios personalizadosSolo empresas
Checkout.comNigeria, Kenia, EgiptoLimitadoPrecios personalizadosSolo empresas
SpreedlyBóveda + enrutamientoSin dinero móvil nativo$500+/mesSí
0fee.dev50+ países africanosMTN, Orange, Wave, M-Pesa0,99%Sí

La brecha era clara. Ningún orquestador existente trataba África como un mercado de primera clase. El dinero móvil no estaba soportado o estaba añadido como algo secundario. Y las soluciones empresariales requerían llamadas de ventas, incorporación prolongada y precios que excluían a startups y pequeñas empresas.

Las cifras

Después de 86 sesiones de desarrollo abarcando 80 días, esto es lo que 0fee cubre:

  • 53+ proveedores de pago integrados y probados
  • 200+ países con al menos un método de pago disponible
  • 117 métodos de pago incluyendo tarjetas, dinero móvil, transferencias bancarias, billeteras y cripto
  • 40+ monedas incluyendo XOF, XAF, KES, NGN, GHS, TZS, UGX, ZAR y todas las principales monedas fiat
  • 7 SDKs disponibles: TypeScript/JavaScript, Python, PHP, Ruby, Go, Java y C#
  • 90+ endpoints de API cubriendo pagos, desembolsos, reembolsos, webhooks, analíticas y administración

El motor de enrutamiento

En el corazón de 0fee está el motor de enrutamiento. Cuando llega una solicitud de pago, el motor evalúa:

  1. País: ¿qué proveedores están disponibles en el país del cliente?
  2. Método de pago: ¿qué proveedores soportan el método solicitado (tarjeta, dinero móvil, transferencia bancaria)?
  3. Moneda: ¿qué proveedores pueden procesar la moneda dada?
  4. Salud del proveedor: ¿cuál es la tasa de éxito actual y la latencia de cada proveedor?
  5. Costo: ¿qué proveedor ofrece la tarifa de procesamiento más baja para esta transacción?
  6. Preferencias de la app: ¿el comerciante ha configurado prioridades o exclusiones de proveedores?

El motor puntúa cada proveedor elegible y selecciona el óptimo. Si el proveedor principal falla, el motor reintenta automáticamente con el siguiente mejor proveedor -- esto se llama failover inteligente.

python# Lógica de enrutamiento simplificada
async def route_payment(request: PaymentRequest, app: Application) -> Provider:
    eligible = await get_eligible_providers(
        country=request.country,
        method=request.method,
        currency=request.currency,
        app_id=app.id
    )

    scored = []
    for provider in eligible:
        score = calculate_score(
            success_rate=provider.metrics.success_rate_24h,
            latency=provider.metrics.avg_latency_ms,
            cost=provider.fee_schedule.get_fee(request.amount),
            priority=app.routing_rules.get_priority(provider.id)
        )
        scored.append((provider, score))

    scored.sort(key=lambda x: x[1], reverse=True)
    return scored[0][0]

Este motor de enrutamiento es lo que transforma 53 proveedores de pago separados en una plataforma de pagos cohesiva.

Qué viene a continuación en esta serie

Este artículo establece el escenario. En los artículos que siguen, profundizaremos en:

  • El problema de pagos en África -- por qué el dinero móvil es fundamentalmente diferente de los pagos con tarjeta y por qué la mayoría de los orquestadores se equivocan.
  • El mapa completo de proveedores -- cada proveedor, cada país, cada método de pago, con ejemplos de código.
  • Decisiones de arquitectura -- por qué elegimos Python, FastAPI, SolidJS y SQLite (y qué cambiaríamos).
  • Construyendo desde Abiyán -- la historia de 86 sesiones, un CEO, un CTO de IA y cero ingenieros humanos.

La brecha en infraestructura de pagos es real, especialmente para negocios que necesitan operar tanto en África como en el resto del mundo simultáneamente. Construimos 0fee para cerrar esa brecha.


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 Thales 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 prompt decía que lo anunciara. El modelo no lo hizo. Así que lo hizo el worker: cerrar un silencio de 15 segundos en Déblo Voice

Déblo Voice se quedaba en silencio unos 15 segundos cada vez que una pregunta difícil activaba una búsqueda profunda. El prompt ya exigía un anuncio, pero el modelo de audio nativo emite la llamada a la función como su primer token. Además, el silencio tenía dos partes, la ejecución de la herramienta y la latencia de la respuesta, así que ningún prompt podía cerrarlo. Llevamos la garantía al worker de LiveKit: un anuncio pregrabado con la voz y el idioma de la sesión, y un suave sonido de tecleo mientras el agente piensa. Probado en producción el 16 de octubre de 2026: 14 y 17,5 segundos de silencio del lado del modelo, unos 0,4 segundos percibidos por el usuario.

13 min Oct 16, 2026
deblodeblo-voicevoice-aigemini-live +17
Thales & Claude zerosuite

El servidor que no dimos de baja: vaciar una máquina de producción en una noche, y cada número que comprobamos

Una noche, seis aplicaciones migradas fila por fila, tres copias de seguridad vacías, una sin destino y un servidor cuyo futuro cambió tres veces.

19 min Oct 2, 2026
caspclaude-codeclaude-opus-5.5infrastructure +10
Thales & Claude zerosuite

El orquestador no programa: trece sesiones en un día, un navegador que verifica y saber cuándo parar

Un día, una plataforma privada de un cliente, trece sesiones headless de Claude encadenadas por un orquestador que nunca escribe código. Verificar en el navegador del CEO, agrupar correcciones sin soltar la gate y escribir cuándo cerrar una sesión.

19 min Sep 30, 2026
caspclaude-codeclaude-opus-5.5multi-session +12