Una API de pagos sin SDKs es una API de pagos que los desarrolladores evitan. Nadie quiere hacer solicitudes HTTP a mano, analizar respuestas JSON y manejar códigos de error cuando una biblioteca cliente bien tipada puede hacerlo por ellos. En la sesión 002, construimos los SDKs de TypeScript y Python. En la sesión 003, añadimos Go, Ruby, PHP, Java y C#. Siete SDKs en dos sesiones.
El patrón
Los siete SDKs siguen el mismo patrón arquitectónico: Client (configuración, HTTP, auth) con Types (modelos, enums, errores) y Resources (Payments, Apps, Checkout, Webhooks). Esta consistencia significa que un desarrollador que conoce el SDK de TypeScript puede tomar el SDK de Go y encontrar todo exactamente donde lo espera.
Verificación de webhooks
Cada SDK incluye verificación de firma de webhook, que es crítica para la seguridad. La lógica de verificación es idéntica en todos los SDKs: extraer timestamp y firma del encabezado, construir el payload firmado, calcular HMAC-SHA256 con el secreto del webhook, comparar firmas usando comparación de tiempo constante, y verificar que el timestamp esté dentro de 5 minutos (protección contra replay).
Cómo construimos siete SDKs en dos sesiones
El proceso fue sistemático. La sesión 002 definió el contrato de interfaz y construyó TypeScript y Python como implementaciones de referencia. La sesión 003 usó el SDK de TypeScript como plantilla y tradujo el patrón siguiendo los idiomas de cada lenguaje: Go con cero dependencias y context.Context, Ruby con API fluida, PHP con PSR-4, Java con patrón builder, y C# con async/await.
La idea clave: una vez que tienes un SDK de referencia bien diseñado, traducir a otros lenguajes es mecánico. El contrato de API no cambia; solo la sintaxis y los idiomas cambian.
Garantías de consistencia
Mantenemos consistencia entre SDKs: nombres de métodos idénticos, nombres de parámetros en la convención del lenguaje, mismos códigos de error, mismas formas de respuesta, mismo algoritmo de verificación de webhook, timeout predeterminado de 30 segundos y 3 reintentos con backoff exponencial en todos los SDKs.
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 ingenieros humanos. Sigue la serie para conocer la historia completa de la construcción.