Un mismo módulo de pagos, tres proveedores, cero lock-in.
El problema
El problema de tener integraciones de subscripciones, pagos one-time, billing con un solo proveedor es que no cubre lo suficiente o hay opciones mejores y distintas de hacerlo. por ejemplo:
(Esto se puede visualizar como 3 columnas simples con 1 línea cada una en vez de párrafo — más escaneable.)
- Stripe cubre todos los casos de manera completa y es uno de los mas utilizados por empresas y desarrolladores. pero no cubre la región de LatAm.
- Lemon Squeezy es muy recomendado por su diseño más simple y directo, como venta de productos digitales. sacandole una pequeña diferencia a Stripe.
- Mercado Pago es la alternativa a todo pero enfocado a LatAm, manejando las monedas de sus paises, seguridad, etc.
La idea es tener mismas funcionalidades pero a elección de proveedor para comodidad de desarrollo y necesidades.
Arquitectura y decisiones
- Cómo definiste una interfaz común (service/actions/types) que abstrae las diferencias de API entre los tres providers
- Decisión clave: qué es específico de cada provider (webhooks, checkout flows) vs. qué es genérico y compartido
- Cómo manejás edge cases distintos por provider (ej. MP no tiene el mismo modelo de subscriptions que Stripe)
¿Por qué abstraer? por qué cada uno maneja sus propios modelos de subscripciones y pagos one-time. configuraciones, keys, checkouts, errores, webhooks, etc.
Defini mismo formato de archivos y carpetas para que al momento de querer migrar o tener un proyecto con un proveedor diferente la curva de aprendizaje sea menor. cada uno tiene su propia lógica de negocio y no comparte con ningun otro módulo.
DX
Resultado
Cada funciondalidad de cada módulo ya viene listo con las funciones para importar, tipadas, listas para ampliar.
el tiempo que te lleva construir todo desde cero a integrar cada funcionalidad es de horas a minutos. incluido un SETUP para achicar curva de aprendizaje.