Skip to main content
Corresponde ao evento interno order.payment_declined. O comprador preencheu tudo, tentou pagar com cartão e a operadora ou o banco recusou. É o lead mais quente do funil: está a uma ação de converter (outro cartão, PIX, ligar para o banco).

Quando é disparado

  • O pedido está com status failed (cartão recusado) há 5 minutos sem nova tentativa. Se o comprador tentar de novo nesse intervalo, o relógio recomeça; se pagar, você recebe PURCHASE_APPROVED e este evento não sai.
  • Uma vez por pedido. Recusas seguintes no mesmo pedido não geram novo evento; o motivo mais recente fica no painel.
  • O envio acontece em lote, a cada 2 minutos, então chega entre 5 e 7 minutos após a última recusa.
  • Cartão de crédito, débito, dois cartões e cartão + PIX. PIX e boleto não falham, expiram (PURCHASE_EXPIRED).
  • Se o pedido continuar parado, aos 15 minutos sai também PURCHASE_CART_ABANDONED para o mesmo pedido. Os dois eventos são intencionais: este traz o motivo da recusa, o outro é a régua padrão de abandono. Deduplique por purchase.transaction se a sua automação já age aqui.
O status failed é reversível. O comprador pode voltar ao mesmo link e pagar; quando isso acontece o pedido passa a paid e você recebe PURCHASE_APPROVED com a mesma purchase.transaction. Use-a como chave para casar os dois eventos.

Payload

Mesmo envelope dos demais eventos de pedido, com o bloco extra data.payment_failure:

O bloco payment_failure

Valores de reason

Campos-chave

Combine reason com retry_url: uma mensagem “seu cartão foi recusado por saldo insuficiente, quer pagar com PIX? ” enviada por WhatsApp em minutos recupera boa parte dessas vendas. O buyer.checkout_phone já vem em E.164.
Não trate este evento como cancelamento definitivo. O comprador pode pagar depois: aguarde o PURCHASE_APPROVED antes de encerrar o pedido no seu sistema.