Cada solicitud de API a 0fee.dev pasa a través de un stack de middleware antes de llegar a un manejador de ruta. Este stack maneja tres preocupaciones: verificar que el llamador está autorizado, asegurar que no está excediendo su límite de tasa y prevenir pagos duplicados cuando problemas de red causan reintentos. Estas no son funcionalidades opcionales para una plataforma de pagos -- son la base de confianza entre la plataforma y sus comerciantes.
Autenticación por clave API
0fee.dev usa claves API con prefijos que codifican información de entorno y tipo directamente en la cadena de la clave: sk_live_ para claves secretas de producción, sk_sand_ para sandbox, pk_live_ para claves publicables de producción y pk_sand_ para sandbox publicable. La convención de prefijos fue tomada de Stripe por buena razón: permite a los desarrolladores distinguir instantáneamente entre tipos de claves.
El middleware de autenticación también soporta tokens de sesión para el panel (usuarios que se autentican con email/contraseña), con degradación elegante entre ambos mecanismos. Después de la autenticación, el middleware verifica si la cuenta del comerciante está suspendida por facturas impagas, usando el código de estado HTTP 402 (Payment Required).
Límite de tasa basado en Redis
El límite de tasa usa un algoritmo de ventana deslizante implementado en DragonflyDB. Cada clave API obtiene un presupuesto configurable: 1.000 solicitudes/minuto para claves secretas, 100/minuto para claves publicables y 500/minuto para sesiones. La decisión de diseño más importante es la degradación elegante: cuando DragonflyDB no está disponible, el limitador de tasa falla abierto -- las solicitudes pasan sin restricción, porque para una plataforma de pagos, un limitador de tasa temporalmente ausente es mucho menos dañino que bloquear solicitudes de pago legítimas.
Manejo de claves de idempotencia
Las claves de idempotencia previenen pagos duplicados. El comerciante incluye un encabezado Idempotency-Key con un identificador único. Si la misma clave se envía dos veces, la segunda solicitud devuelve la respuesta en caché de la primera -- no se crea ningún pago nuevo. Las claves expiran después de 24 horas, y como el límite de tasa, el manejo de idempotencia falla abierto cuando DragonflyDB no está disponible.
La cadena completa de middleware
Cuando llega una solicitud a 0fee.dev, pasa por esta cadena: extraer clave API o token de sesión, validar credenciales, verificar suspensión de facturación, verificar clave de idempotencia, verificar límite de tasa, manejador de ruta (lógica de negocio), almacenar respuesta de idempotencia, agregar encabezados de límite de tasa a la respuesta. Cada paso puede cortocircuitar la cadena. El orden es intencional: la autenticación es lo más barato (una comparación de hash), así que va primero. La lógica de negocio es lo más caro, así que va al final.
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.