Fluxo de pagamento em resumo
- Carregue o script do Payment Element no navegador.
- Crie uma instância de Elements com sua chave pública.
- Monte o campo de cartão hospedado.
- Envie via
elements.submit(...). - Seu back-end cria
POST /v2/transactions. - O SDK trata 3DS automaticamente ou retorna
requires_action. - Seu back-end finaliza o pedido por webhooks e reconciliação.
Exemplo de front-end
O que elements.submit() faz
Quando existe um card element montado, elements.submit():
- cria uma sessão de Elements se ainda não existir
- associa a sessão ao campo de cartão
- tokeniza o cartão
- chama o seu callback
createTransactioncom os dados tokenizados - inspeciona o payload da transação devolvido
- continua 3DS automaticamente se
next_actionexistir e o auto modal estiver habilitado - caso contrário, retorna
requires_actionpara o seu código chamarPagou.handleNextAction(...)
elements.submit() espera que o callback createTransaction devolva o objeto da transação em si, com status e next_action no topo.
Exemplo de back-end
Regras do contrato de back-end
Seu back-end deve:- criar a transação com suas credenciais secretas
- devolver um shape que o front-end consiga usar diretamente
- preservar
id,statusenext_action - armazenar o ID da transação para reconciliação
next_action antes de o navegador recebê-lo.
Tratamento de resultados
Trate o resultado imediato do navegador como resultado de integração, não como decisão de liberação.| Resultado no navegador | Significado | O que fazer |
|---|---|---|
error | submit ou tokenização falhou | mostrar UI de nova tentativa |
requires_action | continuação manual é necessária | chamar Pagou.handleNextAction(...) |
estado de transação como pending ou authorized | o fluxo avançou, mas pode não ser final | mostrar UI de pendência |
succeeded no challenge handling | o challenge terminou | ainda espere um estado final confirmado pelo back-end |
failed, canceled, timed_out no challenge handling | o challenge não foi concluído com sucesso | permitir nova tentativa e reconciliar se preciso |
Modelo de liberação
Seu back-end deve ser o dono da decisão final do pagamento. Regra recomendada:- o navegador inicia o pagamento
- o webhook confirma o estado final seguro para o negócio
- a reconciliação cobre atrasos ou incertezas de webhook
Padrão de webhook
Checklist de produção
- desabilite submit duplicado enquanto o fluxo estiver em andamento
- use um
external_refestável por tentativa de pedido - armazene o ID da transação da Pagou
- preserve
next_actionpara o navegador - libere pedido apenas por estados finais confirmados pelo back-end
- reconcilie resultados incertos com
GET /v2/transactions/{id}

