Compromiso 1
Un único punto de acceso claro
Los comercios dejan de tener que comprender modos de integración diferentes para cada plataforma, mientras que las plataformas conservan sus propias responsabilidades de negocio.
Qué resuelve este diseño
Unifica los puntos de acceso de los comercios a WebPay Inbox, BPS, Zero Confirmation y futuras plataformas de pago y, al mismo tiempo, permite responder con claridad a cada solicitud: quién accede, desde dónde, qué puede hacer, a qué destino debe enviarse y cómo limitar el impacto cuando surge un problema.
Compromiso 2
Permisos inequívocos
Cada clave API queda vinculada explícitamente a una red de origen y a las operaciones permitidas; no se conceden por defecto accesos que no se hayan declarado.
Compromiso 3
Las fallas no se propagan sin control
El sistema no reenvía indiscriminadamente las solicitudes de escritura de pagos a otra región para mejorar la disponibilidad; la consistencia de las transacciones sigue siendo responsabilidad de la plataforma de pago.
Compromiso 4
Cambios y riesgos trazables
Los permisos, las redes de origen, el enrutamiento y los bloqueos de emergencia tienen límites claros de publicación y auditoría, lo que facilita la investigación y la revisión posterior.
Compromiso 5
Incorporación estandarizada de futuras plataformas
Una plataforma nueva se incorpora registrando su ruta, sus permisos y su lista de validación; no necesita reescribir las reglas centrales de autenticación y seguridad.
Cómo se entrega una solicitud de forma segura y controlada
Muestra solo la cadena de responsabilidades: las reglas se publican antes de la solicitud y la evidencia se conserva después. Los detalles de caché, bases de datos y regiones permanecen en sus páginas temáticas.
flowchart TB
RULES["Reglas publicadas<br/>Quién puede acceder · A dónde enviar · Denegación de emergencia"]
subgraph REQUEST["Una solicitud del comercio"]
direction LR
MERCHANT["Sistema del comercio<br/>Envía una solicitud protegida"] --> GATEWAY["Puerta de enlace API unificada<br/>Acceso confiable · Decisión de permisos · Entrega según política"] --> PLATFORM["Plataformas de pago<br/>WebPay Inbox · BPS · Zero Confirmation"]
end
AUDIT["Auditoría y observabilidad<br/>Trazabilidad · Alertas · Revisión"]
RULES -.->|"Vigentes antes de la solicitud"| GATEWAY
GATEWAY -.->|"Registra resultados clave"| AUDIT
classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px
classDef gateway fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:2px
classDef support fill:#EDF8F3,stroke:#16835E,color:#124D3B,stroke-width:1.5px
class MERCHANT,PLATFORM external
class GATEWAY gateway
class RULES,AUDIT support
style REQUEST fill:#F8FBFF,stroke:#B8CDEA,stroke-width:2px
Decisiones que aún debemos confirmar conjuntamente
Este es un diseño propuesto, no una declaración de preparación para producción. Las siguientes decisiones requieren información factual compartida de los equipos de negocio, plataforma y operaciones.
Capacidades de la plataforma
Confirmar las rutas de cada plataforma, la semántica de lectura y escritura, la capacidad de idempotencia, los tiempos máximos de espera y las restricciones de conmutación por error.
Integración de comercios
Confirmar las condiciones de red de salida de los comercios, quién es responsable de crear las claves y cómo se aprueban los permisos de alto riesgo.
Infraestructura
Confirmar las regiones de producción, la residencia de los datos, la protección existente del punto de entrada, la gestión de claves y las capacidades de distribución de mensajes.
Tolerancia al riesgo
Confirmar el mecanismo de prueba de posesión usado para las escrituras de pago y los límites aceptables para las lecturas y la conmutación por error.
Lee según tu función
No es necesario leer el documento de principio a fin. Cada página siguiente se ocupa de un límite de responsabilidad o de un tema de entrega claramente definido.
Indicada para: Responsables de negocio, producto y plataforma
Contexto y alcance
Explica por qué se necesita un punto de acceso unificado, qué problemas de negocio debe resolver y qué responsabilidades no corresponden a la puerta de enlace.
Indicada para: Equipos de arquitectura, plataforma, redes y seguridad
Arquitectura del sistema
Partiendo de los límites generales de responsabilidad, explica cómo una solicitud entra de forma segura en una región apta y qué responsabilidad corresponde a cada tipo de componente.
Indicada para: Equipos de seguridad, operaciones de comercios y desarrollo de plataformas
Acceso y seguridad
Desarrolla las claves API, las redes de origen, los ámbitos de permisos, la protección contra ataques de repetición y la protección de registros, y define reglas de autorización con denegación por defecto.
Indicada para: Equipos de desarrollo de la puerta de enlace, plataformas de pago y pruebas
Ejecución de solicitudes
Explica cómo las solicitudes autorizadas atraviesan la protección de tráfico, los controles de seguridad para escrituras y las llamadas al backend, conservando una semántica externa estable.
Indicada para: Equipos de arquitectura, plataforma, operaciones y cumplimiento
Enrutamiento de tráfico
Explica cómo la cadena de publicación de configuración entrega las políticas y cómo estas guían tanto la selección de la región de entrada como la selección del backend después de la autenticación.
Indicada para: Equipos de consola de administración, SRE y operaciones de seguridad
Configuración y operaciones
Explica los límites de responsabilidad de la fuente de verdad de la configuración, las interfaces administrativas, las instantáneas locales por región, los bloqueos de emergencia y la coherencia de caché.
Indicada para: Equipos de SRE, gestión de riesgos, pruebas y gestión de proyectos
Fiabilidad y validación
Se centra en las evidencias de auditoría, los objetivos de servicio, los datos de capacidad y los controles de validación, y define cómo demostrar la fiabilidad del sistema antes de pasar a producción.
Indicada para: Responsables de proyecto, revisores de arquitectura y responsables de decisión de negocio e ingeniería
Implementación y decisiones
Reúne las fases de implementación, los riesgos conocidos, las cuestiones pendientes de confirmar, los registros de decisiones de arquitectura y las conclusiones de la revisión conjunta.