1. Objetivo comercial
¿Qué problema debe resolver el stack: entrar a un mercado, mejorar aceptación, agregar redundancia, acelerar payouts, cambiar settlement o reducir dependencia de un provider?
PaymentsNova Architecture Tool
Payment Architecture Brief
Una arquitectura de pagos debería empezar con un brief de decisiones, no con una lista de integraciones. Esta plantilla organiza la información que un equipo necesita antes de seleccionar o conectar providers.
2. Mercados y clientes
Países prioritarios, monedas, segmentos, comportamiento de pago y restricciones operativas.
3. Métodos y rails
Tarjetas, transferencias, APMs, métodos locales, Open Banking, instant payments, crypto o stablecoin rails que deben evaluarse.
4. Provider landscape
Providers actuales, candidatos, cobertura real, underwriting, límites, dependencias y ownership de cada relación.
5. Routing y redundancia
Rutas primarias, alternativas, triggers de failover, reglas por mercado/método y puntos únicos de falla.
6. Funds flow y settlement
Cómo entra, se mueve, convierte y liquida el dinero; monedas/activos, frecuencia, fees y dependencias de tesorería.
7. Riesgo y compliance
KYB/KYC, fraude, chargebacks, screening, límites, jurisdicciones y criterios de provider approval.
8. Reconciliación y reporting
Fuentes de verdad, IDs, estados, fees, refunds, payouts, settlement y proceso de cierre.
9. Operación
Monitoreo, alertas, escalación, ownership, soporte y procedimiento durante incidentes.
10. Decisiones pendientes
Qué debe verificarse, cotizarse, probarse o aprobarse antes de ejecutar la arquitectura.
Solicitar Architecture Review →
Payment Architecture Checklist →