Pedido, conta, valor, moeda e regras de negócio são definidos por um backend confiável.
Guia para desenvolvedores
Mantenha o contexto comercial no servidor. Exponha apenas o necessário ao navegador.
Um modelo de checkout baseado em sessão permite que seu backend estabeleça o contexto comercial, ative uma sessão limitada para o cliente e mantenha credenciais e detalhes específicos de provedores atrás do limite da plataforma.
01Criar sessão
02Ativar
03Limitar estado do navegador
04Carregar configuração
05Pagar
06Observar resultado
Limite de integração
Um limite controlado entre servidor e navegador
Um padrão de sessão comprovado em produção utiliza uma sessão criada no servidor, uma etapa de ativação e acesso limitado para o navegador antes de carregar a configuração de checkout e iniciar o pagamento. O princípio reutilizável é manter contexto comercial e de provedor no lado confiável e expor apenas o estado necessário à experiência do cliente.
Uma sessão limitada representa a jornada de pagamento voltada ao cliente.
O cliente recebe apenas o contexto necessário para renderizar e continuar o checkout.
Métodos de pagamento elegíveis e opções de experiência podem ser resolvidos para a sessão ativa.
O estado do pagamento volta ao ciclo transacional por padrões de resposta, evento e consulta de estado.
Padrão comprovado
Padrão de checkout baseado em sessão
Essa estrutura mantém loja ou aplicação móvel focada na experiência do cliente enquanto backend e plataforma preservam regras de negócio, conectividade de provedores e identidade transacional.
- Crie o contexto comercial em uma aplicação confiável no servidor.
- Ative uma sessão de checkout limitada para a jornada do cliente.
- Exponha estado limitado do navegador em vez de credenciais ou detalhes específicos de provedores.
- Carregue a experiência de pagamento a partir da sessão ativa e de seu contexto de elegibilidade.
- Conecte o pagamento resultante à mesma identidade transacional usada pelos sistemas posteriores.
Modelo conceitual de sessão — não é um schema atual 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 implementação
Por que esse limite importa
Estes padrões descrevem comportamentos de integração comprovados em sistemas de produção. Eles definem o modelo técnico; não prometem que a API atual da Zopio utilizará um endpoint, campo ou formato de contrato específico.
Independência de provedor
A aplicação cliente não precisa possuir credenciais ou detalhes de implementação de cada provedor.
Exposição controlada
O estado visível no navegador pode ser mais limitado que o contexto comercial e de provedor mantido no servidor.
Experiência reutilizável
Web e mobile podem reutilizar os mesmos conceitos sem se tornarem aplicações específicas de um provedor.
Resultado rastreável
O pagamento criado a partir da sessão continua dentro do mesmo ciclo transacional observável.
Continuar explorando
Falar sobre sua integração