Voltar pro blog json-p.org

Pilar2 · Recuperação de vendas automática Publicado15 de setembro de 2026 AutorElton

Recuperar cartão recusado no WhatsApp: o fluxo que converte

Cartão recusado não é PIX pendente nem abandono: o comprador já tentou pagar e travou. O mecanismo, o texto por motivo, o timing e a condição de parada.

O cara viu o anúncio, entrou no checkout, digitou nome, CPF, número do cartão, CVV, escolheu 3x, apertou "finalizar compra". E a tela devolveu aquele aviso genérico de que não foi possível processar o pagamento. Ele tentou de novo, deu igual, e foi fazer outra coisa da vida. Você descobre isso à noite, olhando o relatório, quando já não adianta mais nada. Recuperar cartão recusado no WhatsApp é justamente o trabalho de não deixar essas horas passarem em branco.

O detalhe que quase todo mundo trata errado: esse comprador não é o mesmo do carrinho abandonado. Ele não fugiu na hora do preço, não está pesquisando concorrente, não está "em dúvida se compra". Ele decidiu, digitou o cartão e apanhou de uma coisa que não depende dele: limite estourado, antifraude do banco, cartão vencido, dado digitado errado, bloqueio pra compra online. A objeção dele não é comercial, é operacional.

Por isso a régua de recusa não pode ser a mesma de abandono com o texto trocado. Muda o gatilho, muda o obstáculo, muda o timing, muda o critério de parada e muda até o jeito de medir se funcionou. É isso que dá pra montar, com o que a plataforma realmente devolve.

A resposta curta

Cartão recusado é um estado de intenção alta e prazo indefinido. Trate assim: primeiro toque rápido (5 a 15 minutos, não em 30 segundos), texto que oferece um caminho alternativo de pagamento em vez de informar o problema, roteamento pelo status que a plataforma manda no webhook, teto de três toques em até 48 horas, e parada checada no instante do envio, nunca no agendamento.

A parte que ninguém conta: o motivo fino da recusa (limite, cartão vencido, saldo insuficiente) não chega no webhook. Chega um status. O resto do post é o que dá pra fazer com isso.

Por que cartão recusado é um estado diferente de PIX pendente

Os três estados de recuperação parecem primos, mas o obstáculo de cada um é de natureza diferente:

A diferença mais prática é a âncora de tempo. Na régua de PIX você conta o relógio ao contrário, do vencimento pra trás, como detalhei em PIX pendente não é carrinho abandonado. No cartão recusado não existe vencimento nenhum. Não tem código expirando, não tem prazo, não tem urgência natural pra invocar. O que existe é uma janela de intenção que fecha sozinha: em algumas horas ele esfria, resolve que "não era pra ser" ou compra a mesma coisa de outro produtor que apareceu no feed.

Ou seja: sem âncora externa, a régua de recusa é a mais rápida das três, e a mais curta.

O que a Hotmart devolve de verdade no webhook (e o que ela não devolve)

Primeira coisa que derruba a expectativa de quem vai implementar: não existe status DECLINED na lista da Hotmart. Os status possíveis de uma transação são APPROVED, BLOCKED, CANCELLED, CHARGEBACK, COMPLETE, EXPIRED, NO_FUNDS, OVERDUE, PARTIALLY_REFUNDED, PRE_ORDER, PRINTED_BILLET, PROCESSING_TRANSACTION, PROTESTED, REFUNDED, STARTED, UNDER_ANALISYS e WAITING_PAYMENT. Quem fica esperando um evento chamado "recusado" chegar fica esperando pra sempre.

O que chega é mais ou menos isso (payload mascarado e recortado):

{
  "data": {
    "purchase": {
      "transaction": "HP17********",
      "status": "NO_FUNDS",
      "payment": {
        "type": "CREDIT_CARD",
        "installments_number": 3
      },
      "price": { "value": 297.00, "currency_value": "BRL" },
      "order_date": 17********000
    },
    "buyer": {
      "name": "M***** S****",
      "email": "m***@***.com",
      "checkout_phone": "+55419****9999"
    },
    "product": { "id": 9******, "name": "Protocolo ***" }
  }
}

Cortei o nome do evento de propósito. Ele varia conforme a versão do webhook e conforme o que a sua conta assinou no painel, e já mudou entre versões. A chave de roteamento confiável é o par transaction + status, não o nome do evento. Se você ainda não tem o mapa completo dos eventos, o post Webhook Hotmart: todos os eventos e o que fazer com cada um cobre isso. E antes de escrever qualquer regra, ligue o log do payload cru: uma semana logando é mais confiável que qualquer tabela, inclusive esta.

Como isso vira roteamento:

E o motivo granular? A Hotmart tem um relatório de motivos de recusa de cartão (fica em Minhas análises, no bloco de perdas), que mostra coisas como limite, cartão vencido e saldo insuficiente por transação. Só que isso é relatório de análise, não payload em tempo real. Então seja honesto com o desenho: o roteamento fino por motivo é probabilístico, feito com o que você tem em mãos no instante do evento (status, forma de pagamento, valor, número de parcelas), e o relatório serve pra calibrar depois, vendo qual motivo domina no seu produto.

O texto certo pra cada motivo

Regra número um: a mensagem não existe pra informar que o cartão foi recusado. Ele já sabe, ele viu a tela. A mensagem existe pra entregar um caminho alternativo que remove o obstáculo. Se o seu texto termina sem uma saída concreta, você só reabriu a ferida.

Regra número dois: nunca nomear a humilhação. "Seu pagamento foi recusado por falta de saldo" é tecnicamente correto e comercialmente suicida. "Não passou" resolve.

Limite ou saldo (NO_FUNDS), o caso mais comum. A alternativa é trocar o meio de pagamento ou diluir o valor:

Oi, Marcos. Aqui é do suporte do [produto]. O pagamento do seu pedido não passou no cartão, acontece bastante e não tem nada de errado com você. Deixei o link aberto pra tentar de novo: [link]. Se preferir, dá pra fechar no PIX (aprova na hora) ou dividir em mais vezes. Qual dos dois eu deixo pronto?

Antifraude ou bloqueio do banco (BLOCKED, ou recusa recorrente no mesmo cartão). Aqui não adianta oferecer "tentar de novo" mil vezes, porque o bloqueio está do lado do emissor. O trabalho é orientar a desobstrução e oferecer uma rota de fuga:

Oi, Marcos. Sua compra do [produto] foi barrada pelo banco, não pela loja. Normalmente resolve de dois jeitos: liberando a compra no app do banco (costuma aparecer como "autorizar transação") ou ligando no número do verso do cartão e pedindo a liberação. Se você não quiser esse rolo, mando o PIX e a gente resolve em 1 minuto.

Recusa genérica (CANCELLED), motivo desconhecido. Sem informação, o texto cobre as duas hipóteses mais prováveis (dado digitado errado e cartão vencido) sem acusar nenhuma:

Oi, Marcos. O pagamento do [produto] não foi concluído. Na maioria das vezes é bobagem: um número digitado errado, a validade do cartão ou o CVV. Refaz por aqui que já vai preenchido: [link]. Se der de novo, me chama que eu gero um PIX pra você.

Três coisas comuns aos três textos: o link vem sempre (mensagem de recuperação sem link é pesquisa de satisfação), sempre existe uma segunda via de pagamento, e a mensagem termina com pergunta, pra abrir conversa e não parecer robô fechando o assunto sozinho.

Timing: mais rápido que PIX, mas não em 30 segundos

Toda ferramenta de recuperação vende "mensagem em segundos". Só que disparar em 30 segundos tem um custo escondido: transação que está em UNDER_ANALISYS ou PROCESSING_TRANSACTION pode aprovar sozinha alguns minutos depois, e aí você avisou o cliente de um problema que não existia mais. Pior: ele para de tentar porque acha que já era.

O desenho que uso como ponto de partida:

Teto de três toques e janela de até 48 horas. Depois disso não é mais recuperação de recusa, é remarketing, e remarketing tem outro custo, outra régua e outra taxa de resposta. Diferente do PIX, você não tem um vencimento pra justificar o quarto toque, então insistir só aumenta a chance de bloqueio no seu número.

Quantos toques valem e onde parar

A condição de parada é o que separa régua de automação de disparo em massa. Quatro cortes, todos obrigatórios:

  1. Status virou APPROVED ou COMPLETE. Cancela tudo. Mandar "seu pagamento não passou" pra quem já pagou é o erro que gera reembolso.
  2. Nova tentativa em curso (PROCESSING_TRANSACTION, UNDER_ANALISYS). Pausa, não cancela. Reavalia quando o estado assentar.
  3. Ele respondeu. Saiu da régua automática, entrou em atendimento. Automação que continua disparando por cima da resposta do cliente é o cheiro de bot que mata a conversão.
  4. Pediu pra parar. Fim, com opt-out permanente e marcado no registro do comprador, não só naquela transação.

E a regra que vale pra qualquer régua: verifique o estado no instante do envio, não no agendamento. Entre agendar o toque 3 e disparar o toque 3 passaram 24 horas, e muita coisa acontece em 24 horas. Marcar como enviado antes de chamar a API do WhatsApp também é obrigatório, senão um timeout vira mensagem duplicada. A mecânica completa disso está em idempotência em webhook, e vale ainda mais aqui, porque a Hotmart reenvia notificação e o mesmo transaction pode bater no seu endpoint várias vezes.

A parte chata: janela de 24 horas e template

Tem um detalhe de infra que decide se esse fluxo é viável do jeito que você imaginou. Quem comprou no checkout normalmente nunca te mandou mensagem no WhatsApp. Ou seja, não existe janela de atendimento aberta com ele.

Na API oficial (Cloud API), mensagem fora de janela aberta só sai como template aprovado, e a categoria certa aqui é utilidade, porque é notificação sobre uma transação existente. Desde 1 de julho de 2025 a Meta cobra por mensagem, com preço por categoria de template e por código de país do destinatário, e template de utilidade enviado dentro de uma janela de atendimento aberta não é cobrado. Vale conferir a tabela vigente antes de cravar custo por toque: a Meta pode reajustar até quatro vezes por ano (janeiro, abril, julho e outubro), e o faturamento no Brasil passou a ser localizado em julho de 2026.

Na Evolution API você não tem template nem essa cobrança, tem liberdade total e o risco todo do seu lado. Os três toques desse fluxo são mensagens transacionais pra quem tentou comprar de você, o que é o melhor cenário possível em termos de reputação, mas continua sendo mensagem ativa pra quem nunca te chamou. Volume alto, texto idêntico e número novo continuam sendo o combo que derruba chip.

Esse desenho inteiro (roteamento por status, pausa quando a transação está em análise, teto de três toques, parada checada no envio e opt-out no comprador) é o que o Recupera implementa por baixo do capô nos funis que eu opero. Mas nada aqui depende dele: um endpoint de webhook, uma fila com atraso e um cron de reavaliação fazem o mesmo trabalho, e o mais importante é você conseguir auditar cada decisão.

O que dá errado

Os tombos que eu já levei ou vi levarem nessa régua:

Fechando

Recuperar cartão recusado no WhatsApp não é escrever uma copy melhor. É entender que esse comprador já disse sim e travou numa engrenagem, e que o seu trabalho é oferecer outra engrenagem antes que ele esfrie. Roteie pelo status que existe de verdade no payload, não pelo motivo que você gostaria de ter, dispare rápido mas não antes da transação assentar, ofereça saída em vez de aviso, pare em três toques e meça com controle. Feito assim, é a régua com a melhor taxa de retorno das três, e a mais barata de manter.

Fontes primárias consultadas na escrita: central de ajuda da Hotmart (status possíveis de uma transação e relatório de motivos de recusa de cartão) e documentação de preços da WhatsApp Business Platform (cobrança por mensagem desde 01/07/2025, gratuidade de template de utilidade dentro de janela de atendimento aberta e calendário de reajustes). Confira sempre a versão vigente: as duas plataformas mexem nesses detalhes sem aviso.