O checkout conhece a compra; a automação precisa conhecer o cliente

Cada fato da venda pede uma mensagem, e o fato nem sempre chega

O checkout sabe o que aconteceu com o dinheiro. O webhook conta isso em fatos discretos: a compra foi aprovada, o boleto foi emitido e não pago, o carrinho foi abandonado, o cartão recusou, o cliente pediu reembolso, o banco abriu chargeback, a assinatura renovou, a cobrança atrasou. A automação de marketing recebe esses fatos e precisa transformá-los em comunicação com uma pessoa: entregar o acesso, cobrar o Pix pendente, recuperar o carrinho, tentar outro cartão, segurar o cancelamento, cortar a oferta. A qualidade da régua pós-venda depende de dois elos que costumam ser assumidos como garantidos: o fato precisa chegar, e o fato precisa carregar o dado que a mensagem usa.

Este artigo é o par de Doze checkouts, doze nomes para a mesma venda, que mediu os nomes que cada plataforma dá aos mesmos fatos. Aqui a pergunta muda de lado: dado que o fato chegou, com o nome que for, o que a automação faz com ele, o que ele carrega dentro do payload e o que acontece com a régua quando o fato simplesmente não existe naquela plataforma. A base é a mesma: a documentação pública de webhook de quinze plataformas, mais as páginas da Central de Ajuda da Leadlovers sobre ações automatizadas.

As contagens da figura vêm da tabela comparativa que o portal montou sobre as quinze documentações e foram refeitas hoje, coluna a coluna. Elas mostram o desnível que sustenta a tese: todo checkout conta que recebeu o dinheiro, e vai ficando calado à medida que a régua avança para o pós-venda. A metade final do ciclo, reembolso em dois tempos, disputa, renovação, inadimplência, é exatamente onde a comunicação com o cliente decide receita, e é onde menos plataformas emitem o fato.

• 15 de 15plataformas nomeiam a compra aprovada, na contagem refeita pelo portal em 23 de agosto de 2026
• 9 de 15nomeiam o carrinho abandonado; na Kiwify o evento chega sem o campo que o identifica
• 5 de 15dão nome próprio à assinatura renovada: Kiwify, Cakto, Ticto, Shopify e iugu
• 1 de 12plataformas alimentam o balde de pagamento atrasado no motor da Leadlovers: a Hotmart

A régua fato a fato: da aprovação à recusa

O fato "aprovada" dispara a parte boa da régua: liberar o acesso, apresentar o produto, marcar o início do onboarding. É também o fato mais bem servido do mercado, presente nas quinze documentações com nomes como PURCHASE_APPROVED na Hotmart, order_approved no payload da Kiwify e o código 2 na Monetizze. A única plataforma que pede leitura fina aqui é o Asaas, que divide a aprovação em dois fatos, tratados na próxima seção. Antes da aprovação, porém, existe um fato mais barato de aproveitar: o pagamento aguardando.

Boleto emitido e Pix gerado são vendas decididas à espera de um gesto, e a mensagem de cobrança funciona melhor quando carrega o próprio código de pagamento. O checkout nativo da Leadlovers documenta exatamente essa régua: "Configure ações para clientes que geraram código Pix e que ainda não efetuaram o pagamento. Você pode usar as tags [CODIGOPIX], [QRCODEPIXA], [EXPIRAPIX] nos seus e-mails de comunicação. O código pix tem a duração de 24 horas após gerado." O prazo de 24 horas faz parte do fato: a régua de Pix precisa terminar antes de o código expirar, e a tag [EXPIRAPIX] existe para colocar essa urgência dentro do e-mail.

O fato "abandonada" alimenta a régua de recuperação, e é onde o conteúdo do evento prega a primeira peça. Na Kiwify, o abandono se assina como carrinho_abandonado, e o payload que chega vem sem o campo que identifica o evento: a documentação avisa que "O parâmetro não é enviado no evento Carrinho abandonado." O servidor que roteia webhooks pelo campo webhook_event_type descarta justamente o evento de recuperação, sem erro nenhum no log. Na Pagar.me, o nome que parece abandono engana na direção contrária: checkout.canceled "Ocorre sempre que um pedido de checkout teve seu link de pagamento expirado", um fato de link, e uma régua de recuperação pendurada nele dispara tarde demais.

O fato "recusada" pede a mensagem mais delicada da primeira metade do ciclo: avisar que a compra falhou e oferecer nova tentativa ou outro meio de pagamento, sem constranger. Dez das quinze plataformas o nomeiam, como compra_recusada na Kiwify, purchase_refused na Cakto e PAYMENT_CREDIT_CARD_CAPTURE_REFUSED no Asaas. A Hotmart está entre as que não emitem o fato: a recusa mora no campo purchase.payment.refusal_reason, dentro de outro evento. E a Stripe cobre recusa de cliente novo e falha de cobrança de assinante com o mesmo invoice.payment_failed, que dispara "due to either a declined payment, including soft decline, or to the lack of a stored payment method": a mensagem de retry para comprador novo, mandada nesse evento, chega também ao assinante em esteira de cobrança, com o tom errado.

Reembolso solicitado e reembolso concluído são duas mensagens

A Monetizze é a plataforma que documenta com mais clareza um desenho que a maioria das réguas ignora: o reembolso tem dois tempos. O código 9, Solicitação de Reembolso, é "disparado no ato do registro da solicitação"; o código 4, Devolvida, "continua sendo disparado apenas quando o reembolso é concluído". A própria documentação fecha a distinção: "O evento 9 não substitui nem antecipa o evento 4." Entre um e outro existe uma janela em que o cliente ainda tem o dinheiro em disputa e o produtor ainda tem a relação, e é nessa janela que a mensagem certa muda o desfecho.

O Asaas aplica o mesmo princípio de dois tempos ao lado bom do ciclo. A documentação separa PAYMENT_CONFIRMED, "Cobrança confirmada (pagamento efetuado, porém, o saldo ainda não foi disponibilizado)", de PAYMENT_RECEIVED, "Cobrança recebida. (Valor disponível na conta Asaas)". Para a régua de entrega, o primeiro fato basta: o cliente pagou e espera o acesso. Para a régua financeira do produtor, saque, repasse a coprodutor, o que importa é o segundo. Nenhuma das outras catorze documentações abertas faz essa distinção, e qualquer normalização que traduza os dois para um único "aprovada" joga fora a informação.

O chargeback é o fato que encerra a conversa. A Hotmart o define pelo canal: "O chargeback acontece quando o cliente, sem entrar em contato com a Hotmart ou com o Produtor, solicita o cancelamento da transação diretamente na administradora do cartão". A partir desse fato, a régua tem duas obrigações e uma proibição: cortar o acesso, registrar o caso para a defesa da disputa, e nunca mandar oferta, porque a comunicação comercial com quem contestou a compra no banco agrava a relação e não recupera o dinheiro. A Ticto mede a diferença de consequência: o reembolso "Não impacta o índice de chargeback", o chargeback "Impacta diretamente a taxa". E a Kiwify publica o teto que transforma esse fato em risco de negócio: "Se a sua conta tem uma taxa de chargeback acima de 1.5%, a plataforma pode ser obrigada a parar de processar pagamentos para você."

Esse fato de peso máximo é justamente um dos que menos viajam. Na contagem refeita pelo portal, 11 das 15 plataformas emitem chargeback; Monetizze, Pagar.me, Nuvemshop e Yampi ficam de fora, e a PerfectPay normaliza a disputa MED do Banco Central para o mesmo código 7 do reembolso a pedido, então a régua que deveria silenciar ofertas trata a disputa como devolução amigável. Quem vende por essas plataformas precisa monitorar a contestação por outro canal, porque a métrica que pode suspender a conta chega sem webhook.

Assinatura: o mesmo cliente atrasado em quatro dicionários

Na assinatura, a régua muda de natureza: em vez de reagir a uma compra, ela acompanha uma relação que se repete todo mês, e os fatos que importam são a renovação e o atraso. A renovação bem tratada é um recibo com continuidade, sem repetir o onboarding de cliente novo. O problema começa na emissão: só cinco das quinze plataformas dão nome próprio ao fato, subscription_renewed na Kiwify e na Cakto, extended na Ticto, subscription_billing_attempts/success na Shopify e subscription.renewed na iugu. Na Hotmart, a renovação chega como mais um PURCHASE_APPROVED, e o que separa o assinante antigo do comprador novo é o campo recurrence_number; na Stripe, é o billing_reason dentro de invoice.paid. A Monetizze usa o código 101 tanto para assinatura criada quanto para ativa, então nem a criação se distingue da continuidade pelo nome.

O atraso é o fato em que os dicionários mais se dispersam sobre a mesma pessoa. Um assinante com a cobrança falhada chama PURCHASE_DELAYED na Hotmart, subscription_late na Kiwify, PAYMENT_OVERDUE no Asaas e código 102, Assinatura Inadimplente, na Monetizze: quatro nomes em quatro dicionários para o mesmo cliente na mesma situação. A mensagem que ele deve receber tem tom próprio, de relação em curso com um problema de pagamento, e prazo próprio, porque cada dia sem resolver aproxima o cancelamento. Oito das quinze plataformas nomeiam esse fato; nas outras sete, a régua de inadimplência não tem gatilho nativo.

Do lado da Leadlovers, o motor de automação para integrações externas normaliza tudo isso em cinco baldes, e as listas de plataformas habilitadas em cada balde vêm publicadas na Central de Ajuda: pós-venda e cobrança por boleto atendem Hotmart, Monetizze, Kiwify e PagSeguro; cancelamento atende Hotmart, Monetizze, Digital Manager e Braip; abandono de carrinho atende Hotmart, PayT e Doppus; e o balde de pagamento atrasado atende só a Hotmart, com a instrução literal "Em caso de atraso, aplique ações ao contato para fazer a cobrança. Meios de pagamentos habilitados: Hotmart". Para quem monta a régua de inadimplência dentro da Leadlovers, a escolha do checkout decide se a régua existe.

O consumo é o dado que quase nenhum webhook carrega

Tudo até aqui descreve fatos da transação. A segunda venda, porém, depende de um dado de outra família: o consumo. Saber se o cliente acessou o produto, se avançou no conteúdo, se parou no primeiro módulo, é o que separa uma campanha de renovação bem endereçada de um disparo às cegas. E é exatamente o dado que os webhooks de checkout quase não transportam: nos enums transcritos das quinze documentações abertas pelo portal em 23 de agosto de 2026, nenhum nome de evento descreve acesso ao produto ou progresso de consumo depois da compra.

• Os enums abertos registram comportamento até o pagamento: e param ali. O Asaas emite PAYMENT_CHECKOUT_VIEWED e PAYMENT_BANK_SLIP_VIEWED, o cliente que abriu o checkout ou visualizou o boleto; a Cakto emite initiate_checkout. São sinais de intenção, úteis para a régua de cobrança, e param na fronteira da compra.
• Nenhum enum transcrito traz o que vem depois: primeiro acesso ao produto, módulo concluído, dias sem acessar. A régua de retenção que precisa desses fatos não os encontra no webhook do checkout de nenhuma das quinze, nos documentos abertos.
• Fica como não verificado o que está fora do webhook: os enums transcritos nas fichas cobrem os webhooks de compra, cobrança e assinatura. Recursos de área de membros das plataformas que também operam conteúdo, como a Hotmart, podem emitir eventos próprios em páginas que este levantamento não abriu; sobre eles, a posição honesta é "não verificado", e a marca "não existe" fica restrita ao que foi lido.

A consequência prática independe do que exista fora das páginas lidas: quem constrói hoje uma régua de segunda venda sobre os webhooks documentados tem fatos de transação em abundância e fatos de consumo em falta. O progresso do cliente dentro do produto precisa chegar por outra via, seja a área de membros com integração própria, seja um rastreio implantado pelo produtor, e essa via precisa ser verificada antes de a campanha de renovação prometer segmentar por engajamento. Braip e Vindi seguem a mesma regra deste levantamento inteiro: documentação inacessível em 23 de agosto de 2026, uma atrás de bloqueio e senha, outra atrás de chave de API, e por isso entram como não verificáveis em todas as contagens desta página.

Monte a régua a partir do que o seu checkout emite

A régua ideal tem nove fatos, da aprovação ao atraso. A régua possível tem os fatos que o checkout contratado emite, e a distância entre as duas é medível antes de qualquer automação ser configurada: basta abrir a documentação de webhook e riscar da régua ideal os fatos ausentes. Quem faz o caminho contrário, desenha a régua ideal e depois procura os gatilhos, descobre as ausências em produção, quando a régua de chargeback nunca dispara ou quando a mensagem de recuperação de carrinho não sai porque o evento chegou sem o campo identificador. A decisão desta página é essa inversão de ordem: primeiro a lista de emissão, depois o desenho da régua.

A mesma lista de emissão serve de roteiro de compra. Antes de trocar de checkout, ou de contratar o primeiro, as perguntas abaixo custam uma tarde com a documentação aberta e evitam a descoberta em produção. Todas nascem de casos concretos deste levantamento.

1. Peça a lista literal de eventos do webhook, com o nome exato que chega no payload, e confira se ela distingue o que a sua régua distingue: solicitação e conclusão de reembolso, como os códigos 9 e 4 da Monetizze; pagamento efetuado e valor disponível, como no Asaas.
2. Confira, fato a fato da sua régua atual, se o candidato emite: aprovada, aguardando, abandonada, recusada, reembolso nos dois tempos, chargeback, criada, renovada, atrasada. Cada ausência é uma automação que morre na migração.
3. Pergunte o que o evento de abandono carrega e como se identifica, porque na Kiwify ele chega sem o campo de evento, e um roteador por campo o descarta em silêncio.
4. Pergunte se existe normalização entre o que o sistema registra e o que o webhook envia, como a da PerfectPay, que entrega disputa MED com o código de reembolso.
5. Verifique se a plataforma emite o atraso de assinatura com nome próprio e, se a automação roda na Leadlovers, confira em qual dos cinco baldes o checkout aparece, porque o de atraso atende só a Hotmart.
6. Pergunte onde vive o prazo de garantia: no payload, como o item.refund_deadline da Ticto, ou só na central de ajuda, caso em que a régua de fim de garantia precisa carregar as janelas por produto de fora.
7. Confirme a versão do webhook que será usada e o que muda entre versões, porque a Ticto mantém v1 e v2 com nomes incompatíveis e a Leadlovers recomenda fixar a v1 da Hotmart.

Perguntas que aparecem depois desta leitura

De onde vêm os números desta página

Cada dado abaixo tem origem nomeada e data de consulta. Número sem fonte publicada não entra no texto; quando a fonte não publica o valor, a página diz isso na frase.

1. Leadlovers, Central de Ajuda, "Como configurar ações automatizadas", com os cinco baldes de ação e as plataformas habilitadas em cada um, atualizado em 13 de julho de 2026. Consulta em 23 de agosto de 2026.
2. Leadlovers, Central de Ajuda, "Como configurar ações na sua integração", do checkout nativo, com as tags [CODIGOPIX], [QRCODEPIXA] e [EXPIRAPIX] e a duração de 24 horas do código Pix. Consulta em 23 de agosto de 2026.
3. Leadlovers, Central de Ajuda, "Como gerenciar as vendas", com os filtros de status Ativa, Cancelada, Chargeback ou Reembolso do painel. Consulta em 23 de agosto de 2026.
4. Hotmart, documentação de desenvolvedores, webhook de compra 2.0.0, com PURCHASE_APPROVED, PURCHASE_DELAYED, PURCHASE_CHARGEBACK e o campo refusal_reason. Consulta em 23 de agosto de 2026.
5. Hotmart, central de ajuda, prazo de garantia, com as janelas de 7, 15, 21 ou 30 dias por produto e a regra da primeira cobrança em assinatura. Consulta em 23 de agosto de 2026.
6. Hotmart, central de ajuda, diferença entre chargeback e reembolso. Consulta em 23 de agosto de 2026.
7. Hotmart, central de ajuda, taxas da plataforma, com a regra de não cobrança em compra reembolsada ou negada. Consulta em 23 de agosto de 2026.
8. Eduzz, documentação de desenvolvedores, webhook, com invoice_refunded, invoice_waiting_refund e contract_created. Consulta em 23 de agosto de 2026.
9. Eduzz, central de ajuda, taxas, com a regra de que as taxas não são devolvidas em reembolso. Consulta em 23 de agosto de 2026.
10. Kiwify, documentação da API, criação de webhook, com o enum de triggers, os valores de webhook_event_type e a nota de que o parâmetro não é enviado no evento de carrinho abandonado. Consulta em 23 de agosto de 2026.
11. Kiwify, central de ajuda, "Como funciona o reembolso na Kiwify", com a contagem de 7 dias a partir da data da compra. Consulta em 23 de agosto de 2026.
12. Kiwify, central de ajuda, "O que são chargebacks", com o limite de 1.5% de taxa de chargeback. Consulta em 23 de agosto de 2026.
13. Cakto, documentação, conceitos de webhooks, com purchase_approved, pix_gerado, checkout_abandonment e initiate_checkout. Consulta em 23 de agosto de 2026.
14. Monetizze, documentação da API, webhook, com os 17 códigos, a distinção entre os códigos 9 e 4 de reembolso e os códigos 101 e 102 de assinatura. Consulta em 23 de agosto de 2026.
15. Ticto, documentação de webhook, versão 2, com authorized, subscription_delayed, extended e o campo item.refund_deadline. Consulta em 23 de agosto de 2026.
16. Ticto, central de ajuda, "Chargeback na Ticto", com o impacto do chargeback na taxa e a distinção frente ao reembolso. Consulta em 23 de agosto de 2026.
17. PerfectPay, documentação da API em JSON, com os códigos de status e a normalização do postback que entrega MED como reembolso. Consulta em 23 de agosto de 2026.
18. Greenn, central de ajuda, taxas, com a taxa de estorno de R$ 0 em até 30 dias e 4,99% após 30 dias. Consulta em 23 de agosto de 2026.
19. Stripe, referência da API, tipos de evento, com a descrição de invoice.payment_failed que cobre recusa e falta de meio de pagamento armazenado. Consulta em 23 de agosto de 2026.
20. Shopify, documentação da Admin GraphQL API, enum WebhookSubscriptionTopic, com subscription_billing_attempts/success e subscription_billing_attempts/failure. Consulta em 23 de agosto de 2026.
21. Pagar.me, documentação de webhooks, com a descrição de checkout.canceled como link de pagamento expirado. Consulta em 23 de agosto de 2026.
22. Nuvemshop, documentação da API, recurso webhook, com os nove eventos de pedido e sem eventos de reembolso, chargeback ou recusa. Consulta em 23 de agosto de 2026.
23. Yampi, documentação da API, introdução a webhooks, com order.paid, transaction.payment.refused e cart.reminder. Consulta em 23 de agosto de 2026.
24. Asaas, documentação, webhook para cobranças, com a distinção entre PAYMENT_CONFIRMED e PAYMENT_RECEIVED e os eventos PAYMENT_CHECKOUT_VIEWED e PAYMENT_BANK_SLIP_VIEWED. Consulta em 23 de agosto de 2026.
25. iugu, documentação de desenvolvedores, gatilhos de assinatura, com subscription.created e subscription.renewed. Consulta em 23 de agosto de 2026.
26. Presidência da República, Lei 8.078 de 1990, Código de Defesa do Consumidor, texto compilado, art. 49. Consulta em 23 de agosto de 2026.
27. Portal Leadlovers 2026, "Doze checkouts, doze nomes para a mesma venda", o artigo irmão sobre os nomes dos mesmos fatos. Consulta em 23 de agosto de 2026.
28. Portal Leadlovers 2026, "O checkout pode custar mais que todo o software", com as taxas publicadas das mesmas plataformas. Consulta em 23 de agosto de 2026.