Sesión 2: panel de control, SDKs, widget de checkout y Celery en 60 minutos

La Sesión 001 produjo el backend. La Sesión 002, todavía el 10 de diciembre de 2025 -- el mismo día -- produjo todo lo demás que una plataforma de pagos necesita para ser usable: dos nuevos proveedores de pago, un panel completo en SolidJS, un widget de checkout embebible, tareas de fondo Celery y SDKs oficiales en TypeScript y Python. Sesenta minutos.

Lo que entregó la Sesión 002

Al final de la Sesión 002, 0fee.dev tenía 7 proveedores de pago, un panel frontend, un widget de checkout orientado al comerciante, procesamiento de trabajos en segundo plano y dos SDKs listos para npm y PyPI.

Fase 1: Dos nuevos proveedores

Proveedor BUI

BUI maneja dinero móvil en el África Occidental francófona. Su implementación requirió manejo especial para dos flujos distintos:

• Orange Money (Costa de Marfil): Validación basada en OTP. El cliente recibe un OTP en su teléfono, lo ingresa en el flujo de checkout y BUI lo valida.
• Wave: Flujo de redirección. BUI devuelve una URL de pago, el cliente es redirigido a la página de Wave y 0fee.dev consulta el estado hasta la finalización.

Proveedor PaiementPro

PaiementPro es un importante agregador de pagos para el África francófona, soportando Orange Money, MTN, Moov, Wave, Free, Airtel e incluso pagos con tarjeta. Su integración usa un flujo de redirección: el cliente es enviado a la página alojada de PaiementPro donde completa el pago.

Con BUI y PaiementPro, el conteo de proveedores llegó a 7 -- cobertura completa para el África francófona con múltiples opciones de fallback por país.

Fase 2: El panel SolidJS

El panel es la interfaz orientada al comerciante donde los desarrolladores gestionan sus aplicaciones, claves API, credenciales de proveedores y transacciones. Se construyó con SolidJS, elegido por su reactividad de grano fino y tamaño mínimo de bundle (7KB de runtime).

Páginas clave

Dashboard.tsx -- La página principal de resumen mostrando volumen de transacciones, tasas de éxito, ingresos y actividad reciente.

Apps.tsx -- CRUD completo para aplicaciones de comerciantes. Cada app tiene sus propias claves API, credenciales de proveedores y configuración de enrutamiento.

Transactions.tsx -- Una lista filtrable y paginada de todas las transacciones en todas las apps. Los filtros incluyen estado (pendiente, completado, fallido), proveedor, rango de fechas y rango de montos.

Settings.tsx -- Gestión de perfil, configuración de seguridad (cambio de contraseña, rotación de claves API), configuración de webhooks e información de facturación.

Fase 3: El widget de checkout

El widget de checkout -- checkout.js -- es una biblioteca JavaScript que los comerciantes embeben en sus sitios web. Abre un modal, presenta métodos de pago basados en el país del cliente, recopila detalles de pago y procesa el pago. Piensa en el stripe.js de Stripe pero para dinero móvil africano.

Flujo de múltiples pasos

El widget implementa un flujo de pago de cuatro pasos:

1. Selección de país. El cliente selecciona su país de una cuadrícula. Esto determina qué métodos de pago están disponibles.
2. Selección de método de pago. Basado en el país, el widget muestra operadores disponibles: Orange Money, MTN, Wave, Moov, Tarjeta, PayPal, etc.
3. Detalles del pago. Para dinero móvil, el cliente ingresa su número de teléfono. Para tarjetas, es redirigido a la página del proveedor de tarjetas.
4. Procesamiento y confirmación. El widget muestra un estado de procesamiento, consulta actualizaciones de estado y muestra éxito o fallo.

Fase 4: Tareas de fondo Celery

Tres categorías de tareas de fondo se ejecutan en Celery con DragonflyDB como broker:

Reintento de webhook

Cuando una entrega de webhook falla, la tarea encola un reintento con backoff exponencial. El cronograma de reintentos es: 1min, 5min, 30min, 2h, 8h, 24h.

Conciliación de pagos

Cada 5 minutos, una tarea programada verifica pagos atrapados en estado "pendiente" y consulta al proveedor su estado actual.

Procesamiento de liquidación

Una tarea diaria a las 00:30 UTC calcula los montos de liquidación para cada comerciante.

Fase 5: SDK de TypeScript

El SDK oficial de TypeScript proporciona un cliente con tipado seguro para la API de 0fee.dev:

typescriptimport { ZeroFee } from "zerofee";

const zf = new ZeroFee("sk_live_your_key_here");

// Crear un pago
const payment = await zf.payments.create({
    amount: 5000,
    payment_method: "PAYIN_ORANGE_CI",
    customer: {
        phone: "+2250709757296",
        name: "Amadou Diallo",
    },
});

console.log(payment.id);          // "txn_abc123..."
console.log(payment.status);      // "pending"
console.log(payment.provider);    // "paiementpro"

Fase 6: SDK de Python

El SDK de Python sigue los mismos patrones con modelos Pydantic para validación de tipos:

pythonfrom zerofee import ZeroFee

zf = ZeroFee(api_key="sk_live_your_key_here")

# Crear un pago
payment = zf.payments.create(
    amount=5000,
    payment_method="PAYIN_ORANGE_CI",
    customer={
        "phone": "+2250709757296",
        "name": "Amadou Diallo",
    },
)

print(payment.id)        # "txn_abc123..."
print(payment.status)    # "pending"
print(payment.provider)  # "paiementpro"

El balance de la Sesión 002

Dos sesiones. Dos horas en total. La plataforma tenía un backend completo, 7 proveedores de pago, un panel frontend, un widget de checkout embebible, procesamiento de trabajos en segundo plano y SDKs oficiales en dos lenguajes. La Sesión 003 agregaría un sitio web de marketing, 5 SDKs más y configuración de Docker -- en una sola sesión.

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.