Como funciona o rastreamento de reembolsos no dia a dia
Na prática, códigos de reembolso de status são as informações que aparecem no painel do seu gateway de pagamento quando você ou o cliente solicita uma devolução. Cada plataforma tem os seus próprios códigos internos, mas a lógica geral é parecida: o sistema acompanha o fluxo desde o pedido até o dinheiro voltar para a conta do cliente. Já vi gente perder horas tentando conciliar esses status com os extratos do banco porque não entendia a diferença entre "em análise" e "aprovado". A maior confusão que eu vejo acontece na hora de interpretar os códigos. Você pode ter um reembolso marcado como concluído no painel da plataforma, mas o dinheiro ainda não entrou na conta do cliente. Isso não significa falha do sistema. O prazo bancário de compensação é completamente separado do processamento do gateway. Eu tive um caso recente em que um cliente cobrou porque o dinheiro não havia aparecido após 3 dias úteis. Quando verifiquei, o status já estava como "completado" há dois dias. O problema era apenas o ciclo de compensação do cartão de crédito, que nesse caso precisava de mais cinco dias. Não havia nada para fazer além de explicar.
O que são códigos de reembolso de status e como lê-los
Cada etapa do processo de devolução recebe um código específico. Esses códigos variam entre provedores, mas os mais comuns seguem uma lógica similar. Vou listar os que aparecem com mais frequência na maioria das plataformas brasileiras e internacionais. Pendente (PENDING) — O reembolso foi solicitado mas ainda não foi processado. Isso é normal nos primeiros minutos após a solicitação. Geralmente leva de alguns minutos até 24 horas para sair desse estado.
Em análise (UNDER_REVIEW) — O sistema ou uma pessoa está verificando a solicitação. Pode acontecer por diversos motivos: valor acima do limite automático, suspeita de fraude, ou simplesmente porque o gateway faz revisão manual para certos perfis de merchant. Esse estado pode durar de algumas horas até vários dias. É aqui que as coisas costumam travar. Aprovado (APPROVED) — A devolução foi autorizada pelo gateway e enviada para liquidação. O dinheiro já está a caminho. A confusão comum é achar que "aprovado" significa que o cliente já recebeu. Não significa. Significa que a operação financeira foi criada com sucesso.
Compensado (COMPLETED) — O reembolso foi liquidado. Para débitos em conta, isso pode levar de um a três dias úteis. Para cartões de crédito, o prazo varia conforme a bandeira e a operadora, podendo chegar a até cinco dias úteis após a confirmação de completado. Falhou (FAILED) — Algo impediu o processamento. Causas comuns incluem conta de destino inválida, limite excedido, conflito com estorno parcial anterior, ou bloqueio de segurança na operadora do cartão. Um caso que me marcou foi quando um reembolso falhou porque o cliente havia alterado o CPF no cadastro alguns dias antes da solicitação, e o gateway cruzou os dados e bloqueou. A solução foi atualizar o cadastro e remarcar manualmente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Estornado (REVERSED) — Significa que o reembolso foi desfeito. Isso pode acontecer se houver contestação do merchant, decisão de segurança, ou porque o estorno original foi identificado como indevido. É o cenário mais delicado porque gera atrito direto com o cliente.
Problemas práticos que ninguém conta nos tutoriais
A primeira coisa que precisa ficar clara é que esses códigos não são padronizados entre plataformas. O que o Mercado Pago chama de "pending" pode ser chamado de "aguardando" no PagSeguro, que é diferente do "em processamento" do Stripe. Se você integra com mais de um gateway, precisa manter uma tabela de mapeamento própria. Eu fiz uma planilha simples que converte os códigos entre os três principais provedores que usamos, porque confiar na tradução automática gera erros sérios na conciliação financeira. Outro ponto que causa prejuízo real é a diferença entre reembolso parcial e total. Quando um merchant processa um reembolso parcial, o status do reembolso original não muda. Ele continua como "completed". O novo reembolso parcial aparece como um registro separado. Se você está construindo um sistema de acompanhamento e consulta apenas o status do pedido original, vai achar que nada aconteceu. Eu perdi cerca de sessenta mil reais em conciliação errada antes de perceber esse detalhe. A solução foi criar uma query que junta todos os registros de reembolso vinculados ao mesmo pedido, independente de serem parciais ou totais.
Tem também a questão dos reembolsos por chargeback. Quando um cliente abre uma disputa diretamente no cartão, o código de status não é o mesmo de um reembolso voluntário. O sistema pode marcar como "chargeback" ou "dispute", e isso segue um fluxo completamente separado. Muitas vezes o merchant recebe uma notificação ambígua e trata como reembolso normal, o que gera duplicidade. O ideal é ter tratamento distinto para reembolsos voluntários e disputas, com mensagens diferentes no suporte e fluxos de atendimento separados. Uma limitação importante que merece ser dita abertamente: nenhum sistema de códigos de reembolso de status consegue prever o prazo exato de crédito na conta do cliente. Isso depende de fatores externos ao seu controle, como a operadora do cartão, o banco do cliente, e o tipo de transação. O melhor que você pode fazer é usar o status "completed" como referência e informar prazos conservadores. Recomendar prazos otimistas só gera reclamações depois.
Quando os códigos simplesmente não funcionam
Existem situações em que o código de status não reflete a realidade. Isso é mais comum em gateways pequenos ou em períodos de manutenção programada. Já vi status ficarem travados em "pending" por mais de uma semana porque o processador tinha um bug que não liberava os registros pendentes durante a virada do mês. Nesses casos, a única solução é entrar em contato com o suporte técnico do gateway e pedir a liberação manual. Documentar o ticket com o ID da transação economiza tempo na resolução. Se o seu volume de reembolsos é baixo, usar os relatórios padrão da plataforma resolve. A partir de cinquenta reembolsos por mês, vale a pena implementar uma rotina de reconciliação automática via API, cruzando os dados do gateway com o extrato bancário. A diferença no tempo gasto é enorme. O que leva uns trinta minutos manualmente vira poucos segundos processado automaticamente, e o erro humano praticamente desaparece.
