publicKey de escopo restrito por sessão.
Existem dois modos principais:
- Sessão 1:1 (legado): quando
maxPaymentsnão é enviado na criação, a sessão segue o fluxo de um único pagamento. - Sessão 1:N: quando
maxPaymentsé enviado na criação, a sessão permite múltiplos pagamentos no mesmo link, com limite finito (1a99999) ou ilimitado (-1).
Utilizando as sessões
Para utilizar o serviço de Sessões, crie uma sessão definindo itens, valor, métodos de pagamento e, quando necessário,maxPayments. Depois, use a publicKey retornada na criação para chamar o endpoint de pagamento da sessão com uma chave de escopo restrito.
O fluxo conceitual desta seção se aplica a sessões 1:1 e 1:N. Em sessões 1:N,
cada chamada de pagamento aceita representa uma tentativa individual dentro da
capacidade configurada em
maxPayments.Criando uma sessão
Realize a criação usandoPOST /v1/sessions. A resposta completa retorna a sessão, a publicKey de escopo restrito e, quando aplicável, o objeto multiplePayments com a disponibilidade agregada do link.
Pagando uma sessão
Pague uma sessão usandoPOST /v1/sessions/{id}/charge. Use a publicKey retornada na criação da sessão no cabeçalho X-Api-Key.
Em sessões 1:N, a resposta deste endpoint representa a cobrança criada para uma tentativa de pagamento. Para acompanhar a disponibilidade agregada do link após o pagamento, consulte Recuperar detalhes de uma sessão.
Fluxo 1:N e acompanhamento de status
Em sessões 1:N, o status agregado do link não deve ser inferido apenas pela resposta de uma cobrança individual. Acompanhe a sessão completa porGET /v1/sessions/{id} e use o histórico apenas como trilha de eventos.
Um pagamento individual não encerra necessariamente uma sessão 1:N. Consulte
Recuperar detalhes de uma
sessão para obter o
estado agregado atualizado e Recuperar o histórico da
sessão para auditar
eventos.
Histórico da sessão
O endpointGET /v1/sessions/{id}/history expõe a trilha de auditoria da sessão, com os eventos mais recentes primeiro: criação, alterações de campos, tentativas de pagamento, confirmações assíncronas (Pix e boleto) e expirações por dueDate ou limite 1:N.
Cada item da resposta traz action, actions e um objeto diff com o detalhe da mudança. O campo status em cada linha segue a semântica de produto — expirações automáticas podem aparecer como disabled, enquanto cancelamento manual permanece canceled.
Consulte Recuperar o histórico da sessão para o catálogo completo de ações, exemplos de diff e diagrama do fluxo.
Integrando o MalgaCheckout com sessões
Para utilizar o Malga Checkout com o serviço de Sessões de uma maneira mais segura, crie uma sessão pelo seu back-end e use apublicKey de escopo restrito na aplicação front-end. Assim, você configura o checkout sem expor a publicKey de escopo mais amplo usada normalmente.
O fluxo com Malga Checkout vale para sessões 1:1 e 1:N. Em sessões 1:N, a
mesma sessão pode continuar disponível após uma tentativa aprovada, conforme o
limite configurado em
maxPayments e o estado retornado em
multiplePayments.Usando o MalgaCheckout com sessões
Depois de criar a sessão, use oid dela e a publicKey retornada para configurar o Malga Checkout. Para manter a integração segura, recomendamos que o front-end tenha acesso apenas à chave pública da sessão.