Fluxo de Pagamento com Cartão
Siga os estados de compra, autorização, 3DS, revisão, captura, cancelamento e reembolso, sem misturar autenticação com o sucesso do pagamento.
Nesta página
Os pagamentos com cartão utilizam um processo de compra de um único passo ou um modelo de autorização e captura de dois passos. Consulte o valor atual em payment.data.status; se o pagamento estiver dentro da resposta do pedido, consulte order.payment.data.status.
Utilize esta página para o caminho específico do cartão. Para cada definição de status e transição direta permitida, consulte Fluxo e status de pagamento.
Compra e autorização#
A conexão configurada com o processador determina se a DEUNA realiza uma compra ou uma autorização. Um desafio 3DS pode preceder qualquer uma das operações.
| Estado | Significado | Ação do comerciante |
|---|---|---|
pending | O pagamento com cartão existe, mas o roteamento, a autenticação ou o processamento podem não ter começado. | Siga next_action quando presente e mantenha a execução bloqueada. |
pending_3ds | A autenticação do emissor está incompleta. | Complete o desafio e, em seguida, avalie o novo status do pagamento. |
processing | Uma solicitação de compra está em andamento. | Aguarde processed ou outro resultado autorizado. |
authorizing | Uma autorização de dois passos está em andamento. | Aguarde authorized ou outro resultado autorizado. |
processed | Uma compra foi concluída e os fundos foram coletados. | Aplique a política de execução; o pagamento ainda pode ser reembolsado. |
authorized | Os fundos foram reservados, mas não coletados. | Capture ou cancele dentro dos limites da conexão com o processador. |
3DS e OTP
A autenticação garante apenas a continuidade do fluxo de pagamento com o cartão. Não comprova que uma compra ou autorização foi bem-sucedida. Após o desafio, aguarde processed, authorizedou outro status de pagamento relatado.
Alguns adaptadores de processador usam pending_otp internamente. O processamento de pagamentos atual normaliza esse resultado para o público pending e fornece os metadados necessários para a próxima ação. Se um relatório ou filtro de pesquisa mais antigo contiver pending_otp, trate isso como uma espera pela ação do cliente – e não como um pagamento bem-sucedido.
Revisão de risco e tentativas#
manual_review para completar o pagamento até que uma decisão de risco produza um novo status de pagamento. Uma revisão aprovada pode prosseguir para processed ou captured; uma revisão rejeitada pode resultar em denied. Consulte Fluxo de trabalho e status de fraude para os campos e decisões de fraude separados.
denied descreve a tentativa malsucedida, mas a máquina de estados de Pagamentos pode rotear ou tentar novamente o mesmo pagamento para pending, pending_3ds, processing, ou authorizing. Não complete uma tentativa negada e não modele denied como um status de pagamento final.
Capture uma autorização#
Capture converte os fundos reservados em fundos coletados. O processador, o valor autorizado restante, os limites de tempo e a configuração do comerciante determinam quais operações de captura são elegíveis.
A máquina de estados também pode receber captured ou partial_captured diretamente, sem expor o status "em andamento". As notificações são snapshots autoritativos, não um evento garantido.
Para modos de captura parcial, suporte de concorrência, limites de tempo e final_capture, veja MPC — Múltiplas Capturas Parciais.
Anular uma autorização#
Anular libera os fundos reservados. Isso é diferente de um reembolso, que retorna fundos que já foram coletados.
O sucesso Anular API retorna HTTP 204 No Content. Quando o processador completa de forma assíncrona, use o estado de pagamento posterior como resultado.
Reembolsar fundos coletados#
Uma compra bem-sucedida, captura completa ou parcial pode ser reembolsada quando a conexão e o valor restante reembolsável permitem.
Um reembolso malsucedido pode restaurar processed, captured, ou partial_captured. Mantenha o pagamento bem-sucedido e a tentativa de reembolso malsucedida separadamente. Consulte MPR – Reembolsos Parciais Múltiplos para modos nativos e agregados da DEUNA, limites de tempo, concorrência e comportamento do saldo restante.
Lista de verificação de integração#
- Mantenha o pagamento bloqueado para
pending,pending_3ds,processing,authorizingemanual_review. - Trate a autenticação e a aceitação de solicitações como evidências intermediárias, e não como confirmação financeira.
- Armazene os valores confirmados e os identificadores das operações com cada atualização de status.
- Recupere o pagamento autorizado após um tempo limite ou resposta tardia do provedor.
- Use a referência de transição validada Ao lidar com tentativas ou caminhos de reconciliação que não estão no fluxo normal.