O cliente mostra o comprovante de um pagamento feito no site de vendas, e o pedido continua pendente na retaguarda. A sugestão de cobrar de novo e cancelar depois, se houver duplicidade, troca uma investigação por um risco, e o caso mostra como confirmar o pagamento e encontrar o ponto em que o resultado parou.
O relato e as evidências
O site de vendas gerou o pedido PED-0001, e o integrador chamou o serviço de pagamentos. O cliente mostra um comprovante, e o pedido continua pendente na retaguarda. Há três observações iniciais:
- o comprovante mostra o valor de R$ 50,00, um horário próximo ao do pedido e a referência PAG-0001;
- o log do integrador registra o pedido PED-0001, a criação do pagamento com o método POST e o código 201, com o corpo
{"id":"PAG-0001","status":"PENDING"}; - a tela da retaguarda mostra o pedido pendente, e o banco, a conta no serviço de pagamentos e o acompanhamento depois da criação ainda não foram conferidos.
Pelo contrato do serviço, o código 201 indica que o pagamento foi criado, e o estado PENDING pede acompanhamento. O comprovante e o horário, sozinhos, não ligam o pagamento ao pedido nem provam o recebimento. Continuam possíveis um pagamento ainda pendente, uma confirmação posterior que não chegou ao pedido, um comprovante de outra operação e uma tela desatualizada. Uma nova cobrança não distingue nenhuma dessas hipóteses.
A consulta do pagamento
A consulta ao serviço de pagamentos, na conta e no ambiente esperados, devolve:
{"id":"PAG-0001","pedido_id":"PED-0001","valor":50.00,"moeda":"BRL","status":"PAID"}
Pelo contrato, o estado PAID confirma o recebimento, e o pagamento está ligado ao pedido PED-0001. A resposta PENDING da criação e o PAID da consulta são momentos diferentes do mesmo pagamento, e não uma contradição. A investigação segue para o caminho do resultado até a retaguarda, sem nenhuma nova cobrança.
Outros resultados mudariam a decisão. Um pedido_id diferente impediria a associação, e um pagamento não encontrado pediria a conferência do identificador, da conta, do ambiente e do prazo de visibilidade.
O aviso que chegou e o pedido que não mudou
Pelo contrato, o receptor de eventos responde com o código 200 depois de guardar o aviso em uma fila, antes de atualizar o pedido. O evento EVT-0001, do pagamento PAG-0001, aparece na fila, e o serviço de pagamentos registra a entrega aceita. O banco da retaguarda, porém, ainda mostra PED-0001 pendente, e não há registro de que o EVT-0001 foi processado. O código 200 confirma só o recebimento do aviso, e não a atualização do pedido.
O próximo passo é localizar o EVT-0001 no histórico da fila e do processo que trata os avisos e conferir se o processamento começou, terminou, falhou ou ainda está em andamento. A falta de uma linha em um log parcial não basta para escolher uma causa.
A reconciliação
A equipe responsável usa a rotina prevista de reconciliação: a rotina consulta PAG-0001 de novo, mantém a associação e aplica o resultado ao pedido, com proteção contra aplicar o mesmo efeito duas vezes. O pedido passa ao estado de pagamento recebido, e o banco e a tela recarregada concordam, sem nenhuma nova cobrança. O histórico do EVT-0001 fica marcado como regularizado, sem apagar o registro do recebimento original.
A causa do atraso continua em aberto, entre o processo parado, um erro passageiro, a regra de associação e uma tentativa anterior com falha. A reconciliação dos pedidos do mesmo período, pela consulta do serviço de pagamentos, mostra se existem outros casos iguais, porque a correção de um pedido não comprova a situação dos demais.
O registro do atendimento
O registro mostra o resultado aplicado e o que ainda precisa de investigação:
- Ocorrência: o pedido PED-0001 continuava pendente, com o pagamento PAG-0001 confirmado como PAID na conta e no ambiente esperados, no valor de R$ 50,00;
- Evidências: o aviso EVT-0001 foi recebido e guardado na fila, sem a conclusão do processamento no material analisado;
- Correção: a rotina prevista de reconciliação aplicou o resultado existente ao pedido, sem nova cobrança;
- Pendências: a origem do atraso, pelo histórico do processo que trata os avisos, e o levantamento de outros pedidos pendentes do mesmo período.
No suporte
Diante de um pagamento confirmado e de um pedido pendente, a consulta do pagamento pela referência vem antes de qualquer cobrança. A investigação segue o caminho do resultado até o pedido, e a correção de um caso pede a conferência dos outros do mesmo período.
Para guardar
- O código 201 indica a criação do pagamento, e não o recebimento.
- O comprovante precisa ser ligado ao pedido pela referência, pelo valor e pela conta.
- O recebimento do aviso pelo webhook pode acontecer antes da atualização do pedido.
- A reconciliação aplica um resultado existente e dispensa uma nova cobrança.
- A correção de um pedido não comprova que os outros do período estão certos.
Se a consulta mostrasse PAG-0001 ligado a outro pedido, o que concluir?
Que o comprovante não pertence ao pedido PED-0001 ou que a associação foi feita errado. O pedido continua sem pagamento confirmado, e a investigação segue para a origem do comprovante e para a regra que liga os pagamentos aos pedidos.
Por que cobrar de novo e cancelar depois, se houver duplicidade, é uma má ideia?
Porque o pagamento já pode ter sido recebido, e a nova cobrança cria uma duplicidade real para o cliente, com um estorno e prazos próprios. A consulta do pagamento e a reconciliação resolvem o caso sem esse risco.