Pedido, cuenta, importe, divisa y reglas de negocio se establecen desde un backend confiable.
Guía para desarrolladores
Mantén el contexto comercial en el servidor. Expón solo lo necesario al navegador.
Un modelo de checkout basado en sesión permite que tu backend establezca el contexto comercial, active una sesión acotada para el cliente y mantenga las credenciales y detalles específicos de proveedores detrás del límite de plataforma.
01Crear sesión
02Activar
03Acotar estado del navegador
04Cargar configuración
05Pagar
06Observar resultado
Límite de integración
Un límite controlado entre servidor y navegador
Un patrón de sesión probado en producción utiliza una sesión creada en servidor, un paso de activación y un acceso acotado para el navegador antes de cargar la configuración de checkout e iniciar el pago. El principio reutilizable es mantener el contexto comercial y de proveedor en el lado confiable y exponer solo el estado necesario para la experiencia del cliente.
Una sesión acotada representa el recorrido de pago orientado al cliente.
El cliente recibe solo el contexto necesario para mostrar y continuar el checkout.
Los métodos de pago elegibles y opciones de experiencia pueden resolverse para la sesión activa.
El estado del pago vuelve al ciclo transaccional mediante respuesta, evento y consulta de estado.
Patrón probado
Patrón de checkout basado en sesión
Esta estructura mantiene la tienda o aplicación móvil centrada en la experiencia del cliente mientras backend y plataforma conservan reglas de negocio, conectividad de proveedores e identidad transaccional.
- Crea el contexto comercial desde una aplicación de servidor confiable.
- Activa una sesión de checkout acotada para el recorrido del cliente.
- Expón estado limitado del navegador en lugar de credenciales o detalles específicos de proveedores.
- Carga la experiencia de pago desde la sesión activa y su contexto de elegibilidad.
- Conecta el pago resultante con la misma identidad transaccional utilizada por sistemas posteriores.
Modelo conceptual de sesión — no es un esquema actual de API
{
"session": {
"id": "checkout-session-id",
"reference": "your-business-reference",
"scope": "customer-checkout"
},
"experience": {
"eligible_methods": ["..."],
"options": ["..."]
},
"transaction": {
"id": "durable-transaction-id",
"state": "..."
}
}Modelo de implementación
Por qué importa este límite
Estos patrones describen comportamientos de integración probados en sistemas de producción. Definen el modelo técnico; no prometen que la API actual de Zopio vaya a utilizar un endpoint, campo o formato de contrato concreto.
Independencia de proveedor
La aplicación cliente no necesita poseer credenciales o detalles de implementación de cada proveedor.
Exposición controlada
El estado visible en el navegador puede ser más limitado que el contexto comercial y de proveedor mantenido en servidor.
Experiencia reutilizable
Web y móvil pueden reutilizar los mismos conceptos sin convertirse en aplicaciones específicas de un proveedor.
Resultado trazable
El pago creado desde la sesión continúa dentro del mismo ciclo transaccional observable.
Seguir explorando
Hablar sobre tu integración