El problema de pagos en África: por qué Stripe no es suficiente

África procesa más de 1 billón de dólares en transacciones de dinero móvil anualmente. Más de 500 millones de personas usan el dinero móvil como su instrumento financiero principal -- no como alternativa a las tarjetas, sino como reemplazo de todo un sistema bancario que nunca los alcanzó. Sin embargo, si intentas aceptar un pago de un cliente en Costa de Marfil, Senegal o Camerún usando Stripe, descubrirás que la plataforma de pagos más popular del mundo simplemente no funciona para la mayor parte del continente.

Este es el problema de pagos en África. Y es la razón principal por la que construimos 0fee.dev.

Las cifras que lo cambian todo

Considera estas cifras del informe Estado de la Industria de la GSMA:

El contraste es marcado. En Estados Unidos, más del 80% de los adultos tienen tarjeta de crédito o débito. En África subsahariana, menos del 5% la tienen. Pero el 85% tiene un teléfono móvil y casi la mitad de todos los adultos tiene una cuenta activa de dinero móvil. La infraestructura de pago no está ausente -- simplemente es fundamentalmente diferente.

Cómo funciona el dinero móvil

Para lectores no familiarizados con el dinero móvil, aquí está el flujo. No tiene nada en común con los pagos con tarjeta.

La experiencia del cliente

1. El cliente selecciona "Pagar con Orange Money" (o MTN MoMo, Wave, M-Pesa, etc.).
2. Ingresa su número de teléfono.
3. Recibe un USSD push o STK push en su teléfono -- un menú simple en su pantalla, no una notificación de app.
4. Ingresa su PIN para confirmar el pago.
5. La transacción se liquida. Ambas partes reciben una confirmación por SMS.

No hay número de tarjeta, ni CVV, ni 3D Secure, ni dirección de facturación. Toda la autenticación es número de teléfono + PIN. La "cuenta" es la tarjeta SIM en sí.

El flujo técnico

Desde la perspectiva de integración, el dinero móvil es asíncrono por naturaleza:

1. Comerciante -> API del proveedor: iniciar pago (teléfono, monto)
2. Proveedor -> Telco: enviar USSD/STK push al cliente
3. Cliente -> Teléfono: ingresar PIN para confirmar
4. Telco -> Proveedor: callback de confirmación
5. Proveedor -> Comerciante: notificación webhook (éxito/fallo)

Esto significa que tu integración debe manejar:

• Confirmación asíncrona: el cliente puede tardar 30 segundos o 5 minutos en confirmar.
• Manejo de timeout: si el cliente no responde, la transacción expira (típicamente 60-120 segundos para USSD).
• Validación de número telefónico: cada país tiene formatos específicos (+225 07XXXXXXXX para Costa de Marfil, +233 XX XXX XXXX para Ghana).
• Límites de sesión USSD: algunas telcos limitan las sesiones USSD concurrentes por número de teléfono.

El panorama de proveedores

Ningún proveedor único cubre toda África. Cada proveedor tiene su propia huella geográfica, métodos de pago soportados e integración técnica:

África Oriental

África Occidental (francófona)

África Occidental (anglófona)

Panafricano

Para aceptar pagos en toda África, necesitas como mínimo tres o cuatro integraciones de proveedores -- y probablemente más si quieres cobertura y redundancia óptimas.

La solución 0fee

0fee abstrae toda esta complejidad detrás de una API unificada. Cada método de pago de dinero móvil en cada país sigue el mismo formato de solicitud/respuesta:

typescriptimport { ZeroFee } from 'zerofee';

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

// Orange Money en Costa de Marfil
const paymentCI = await zf.payments.create({
  amount: 5000,           // 5.000 XOF
  currency: 'XOF',
  country: 'CI',
  method: 'PAYIN_ORANGE_CI',
  customer: { phone: '+2250700112233' },
  returnUrl: 'https://yourapp.com/callback'
});

// MTN MoMo en Ghana
const paymentGH = await zf.payments.create({
  amount: 50_00,          // 50,00 GHS en centavos
  currency: 'GHS',
  country: 'GH',
  method: 'PAYIN_MTN_GH',
  customer: { phone: '+233241234567' },
  returnUrl: 'https://yourapp.com/callback'
});

// M-Pesa en Kenia
const paymentKE = await zf.payments.create({
  amount: 1000_00,        // 1.000,00 KES en centavos
  currency: 'KES',
  country: 'KE',
  method: 'PAYIN_MPESA_KE',
  customer: { phone: '+254712345678' },
  returnUrl: 'https://yourapp.com/callback'
});

Tres países diferentes, tres proveedores de dinero móvil diferentes, tres telcos diferentes -- pero estructura de código idéntica. El motor de enrutamiento determina qué proveedor subyacente usar basándose en país, método y credenciales configuradas.

Convención de nombres de métodos de pago

Diseñamos una convención de nombres sistemática para cada método de pago en el sistema:

{DIRECCIÓN}_{MÉTODO}_{PAÍS}

PAYIN_ORANGE_CI    = Pago entrante vía Orange Money en Costa de Marfil
PAYIN_MTN_GH       = Pago entrante vía MTN MoMo en Ghana
PAYIN_MPESA_KE     = Pago entrante vía M-Pesa en Kenia
PAYIN_WAVE_SN      = Pago entrante vía Wave en Senegal
PAYIN_CARD_US      = Pago entrante vía tarjeta en Estados Unidos
PAYOUT_ORANGE_CI   = Pago saliente a Orange Money en Costa de Marfil
PAYOUT_BANK_NG     = Pago saliente a cuenta bancaria en Nigeria

Esta convención hace que la API sea autodocumentada. Un desarrollador puede entender inmediatamente lo que significa PAYIN_AIRTEL_UG sin leer documentación: es un pago entrante vía Airtel Money en Uganda.

La lista completa de métodos de dinero móvil africano en 0fee:

Y esto es solo un subconjunto. El catálogo completo incluye 117 métodos de pago en África, Europa, Norteamérica, Sudamérica y Asia.

El problema de los webhooks

Uno de los aspectos más dolorosos de la integración multi-proveedor es el manejo de webhooks. Cada proveedor envía callbacks en un formato diferente:

Webhook de PawaPay: ``json { "depositId": "dep_abc123", "status": "COMPLETED", "amount": "1000", "currency": "KES", "correspondent": "MPESA_KEN" } ``

Callback de Hub2: ``json { "transaction_id": "txn_xyz789", "statut": "SUCCESS", "montant": 5000, "devise": "XOF", "operateur": "ORANGE_MONEY" } ``

Webhook de Paystack: ``json { "event": "charge.success", "data": { "id": 123456, "status": "success", "amount": 50000, "currency": "NGN", "channel": "mobile_money" } } ``

Tres proveedores diferentes, tres nombres de campos diferentes, tres valores de estado diferentes, tres formatos de monto diferentes. En una integración directa, escribirías tres manejadores de webhook separados con tres pipelines de validación y normalización separados.

0fee normaliza todo esto. Tu aplicación recibe un formato de webhook estandarizado independientemente de qué proveedor procesó el pago:

json{
  "event": "payment.completed",
  "data": {
    "id": "pay_0fee_abc123",
    "status": "completed",
    "amount": 5000,
    "currency": "XOF",
    "country": "CI",
    "method": "PAYIN_ORANGE_CI",
    "provider": "hub2",
    "customer": {
      "phone": "+2250700112233"
    },
    "metadata": {},
    "created_at": "2026-03-27T10:30:00Z",
    "completed_at": "2026-03-27T10:30:45Z"
  }
}

Un manejador de webhook. Un enum de estados. Un formato de monto. Cada proveedor normalizado al mismo contrato.

OTP y USSD: autenticación sin tarjetas

Los pagos con tarjeta usan un modelo de autenticación bien entendido: número de tarjeta, vencimiento, CVV y opcionalmente 3D Secure. La autenticación del dinero móvil es completamente diferente y varía según la telco y el país.

USSD Push (más común en África Occidental): El proveedor envía un prompt USSD al teléfono del cliente. El cliente ve un menú basado en texto: "¿Pagar 5.000 XOF a [Comerciante]? Ingrese PIN:" -- esto sucede a nivel de SIM/telco, no dentro de una app.

STK Push (M-Pesa, África Oriental): El SIM Toolkit activa un prompt de pago directamente en el teléfono. El cliente ve una ventana emergente pidiéndole confirmar el monto e ingresar su PIN de M-Pesa.

OTP vía SMS (algunos proveedores): El cliente recibe un SMS con un código de un solo uso, que ingresa en la página de checkout del comerciante. Esto es más similar a 3D Secure pero usa SMS en lugar de la página de autenticación del banco.

Cada uno de estos flujos tiene diferentes características de timeout, diferentes semánticas de reintento y diferentes modos de fallo. 0fee maneja todos detrás del mismo flujo de pago asíncrono: crea el pago, espera el webhook, procesa el resultado.

Por qué esto importa para los desarrolladores africanos

Si estás construyendo un producto para usuarios africanos, los pagos no deberían ser la parte más difícil de tu stack. Pero hoy, un desarrollador en Abiyán que quiere aceptar pagos de Orange Money, MTN MoMo y Wave solo en Costa de Marfil necesita integrar al menos dos proveedores. Agrega Nigeria y Kenia, y estarás ante cuatro o cinco integraciones.

0fee reduce eso a una. Instala el SDK, configura tus credenciales en el panel de control y tu página de checkout funciona en todo el continente.

bashnpm install zerofee

Ese es el requisito previo completo de integración. Un paquete. Una clave de API. Cincuenta y tres proveedores. Doscientos países. África incluida desde el primer día -- no como algo secundario.

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.