Doze checkouts, doze nomes para a mesma venda

Três números de integrações, e cada um mede outra coisa

A pergunta "com quantos checkouts a Leadlovers se integra" recebe três respostas da própria Leadlovers, e nenhuma delas diz catorze. A página institucional mostra 18 cartões na categoria de pagamento, sob o rótulo "Algumas de nossas integrações". A Central de Ajuda tem tutorial próprio para 12 checkouts e gateways. O motor de automação reconhece 5 baldes de evento. Os três números foram lidos em página viva em 23 de agosto de 2026, e os três estão corretos, porque medem coisas diferentes.

Os 18 cartões incluem Sympla e Eventbrite, que são bilheteria, Kobana, que é boleto, e Vindi e iugu, que são recorrência. A própria página divide a lista entre "Pagamento", com 10 cartões, e "Pagamentos", com 8, duas grafias para uma categoria só. O rótulo "Algumas" avisa que a lista não é exaustiva, e o conteúdo mostra que ela também não é uma lista de checkouts.

O artigo "Como usar um Produto de Integração" remete à relação completa de provedores com a frase "Veja a lista dos provedores disponíves aqui," e a frase termina em vírgula, sem link. O texto de abertura dos tutoriais confirma a natureza aberta da lista: "é preciso que você já tenha um produto criado em algum site de pagamento [Monetizze / eduzz / hotmart / pagseguro entre outros.]". Para quem compra, isso significa que o número 12 é um piso documentado, e o número 18 é uma vitrine.

O terceiro número é o que importa para quem automatiza. O motor reconhece cinco fatos: pós-venda, cobrança por boleto, pagamento atrasado, cancelamento e abandono de carrinho. O artigo de ações automatizadas, publicado em 8 de junho de 2026 e atualizado em 13 de julho de 2026, lista a cada balde as plataformas que o alimentam, e as listas não coincidem entre si.

O mesmo fato muda de nome dentro da própria Central de Ajuda

O problema de vocabulário aparece antes de qualquer plataforma externa. A ação "Cobrança por boleto" existe para as integrações externas. No checkout nativo da Leadlovers, o balde equivalente se chama "Ações para cobrança por Pix", com a instrução: "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 checkout nativo aceita cartão e Pix, então a ausência de boleto é coerente. O fato por trás dos dois nomes é o mesmo, uma cobrança emitida e ainda não paga, e a automação escrita para um balde não se reaproveita no outro.

O relatório de vendas do checkout enxerga dois fatos que o motor de automação não enxerga. A página "Como gerenciar as vendas" informa: "É possível filtrar as assinaturas pelo seguintes itens: Formas de pagamento: PIX e Cartão de crédito; Status: Ativa, Cancelada, Chargeback ou Reembolso." Nenhum dos cinco baldes de ação é reembolso ou chargeback. O painel registra o fato; a régua de automação não consegue reagir a ele.

• Hotmart, no tutorial da Leadlovers: "Compra Aprovada", com a instrução de marcar também "Aguardando pagamento" para liberar acesso na emissão do boleto.
• Braip, no mesmo tutorial: "Boleto Impresso", "Compra Efetuada", "Abandono de Checkout" como exemplos de evento e, três parágrafos depois, "se foi configurado um evento de 'Compra Aprovada' que insere o lead em uma determinado projeto". Dois nomes para o mesmo fato na mesma página.
• Eduzz: "Neste nosso exemplo, o evento foi: Compra realizada."
• Doppus: "Compra Aprovada". Kiwify: "Atualmente essa integração é válida somente para o evento 'Compra aprovada', então marque apenas ele."

São três nomes para compra aprovada, "Compra Aprovada", "Compra Efetuada" e "Compra realizada", dentro de uma única Central de Ajuda, e nenhum deles é a string que o webhook envia. Por baixo dos rótulos há três modelos mentais. Na Hotmart e na Braip o usuário escolhe um evento. Na Eduzz a integração é cadastrada como entrega de produto: "Dentro do produto localize a aba Entrega e clique em Adicionar entrega. Clique em Outros. Dentre as opções que irão aparecer, escolha leadlovers." Na Monetizze informa-se a URL de postback, sem escolher evento algum. Evento, entrega e postback único são três desenhos incompatíveis, e a Central documenta os três sem nomeá-los como tais.

Compra aprovada tem doze nomes em quinze plataformas

Fora da Leadlovers a divergência cresce. O portal abriu, em 23 de agosto de 2026, a documentação pública de webhook de quinze plataformas: Hotmart, Eduzz, Kiwify, Cakto, Monetizze, Ticto, PerfectPay, Greenn, Stripe, Shopify, Pagar.me, Nuvemshop, Yampi, Asaas, iugu. A Braip ficou de fora: braip.com, ajuda.braip.com e ev.braip.com devolveram bloqueio ("Sorry, you have been blocked"), docs.braip.com pede senha e a documentação fica dentro do painel, em Ferramentas, Postback, Documentação. A Vindi ficou de fora porque a documentação exige chave de API. As duas entram nesta página como não verificáveis, e a marca "não existe" fica reservada a documentação aberta e lida.

O fato mais simples do ciclo, a compra aprovada, recebe doze nomes literais nas quinze: PURCHASE_APPROVED, myeduzz.invoice_paid, order_approved, purchase_approved, o código 2, authorized, paid, payment_intent.succeeded, orders/paid, order.paid, order/paid e o par PAYMENT_CONFIRMED com PAYMENT_RECEIVED. Três sintaxes convivem, o ponto, a barra com plural e a barra com singular, e "cancelado" se escreve cancelled em umas e canceled em outras.

A leitura por coluna diz mais que a leitura por linha. A coluna de compra aprovada está cheia, com quinze entradas e doze nomes. A coluna de chargeback tem quatro buracos. A coluna de renovação tem cinco nomes próprios, um código compartilhado e nove ausências. Quem integra só a primeira coluna acha que o problema é de tradução; quem precisa das outras descobre que o problema é de existência.

• 12nomes literais para compra aprovada nas quinze plataformas verificadas em 23 de agosto de 2026
• 4plataformas sem evento de chargeback: Monetizze, Pagar.me, Nuvemshop e Yampi
• 5plataformas com nome próprio para assinatura renovada: Kiwify, Cakto, Ticto, Shopify e iugu
• 2plataformas com dois dicionários vivos ao mesmo tempo: Ticto (v1 e v2) e Hotmart (v1 e v2), além da Kiwify, que assina num idioma e recebe em outro

A divergência de existência pesa mais que a de nome

Nome diferente se resolve com uma tabela de tradução. Evento que não existe não se resolve: a automação que depende dele fica muda para aquela plataforma, e ninguém recebe aviso. Contadas sobre a documentação das quinze, as ausências se concentram na segunda metade do ciclo, depois do dinheiro entrar.

O chargeback é o caso mais custoso, porque é o fato que mais pesa na conta do produtor e o que menos plataformas nomeiam. A Monetizze publica 17 códigos de evento e nenhum é chargeback. A Pagar.me publica 40 eventos e o chargeback não aparece na página de webhooks nem na de cobrança. A Yampi devolve zero ocorrências para "refund", "estorn" e "chargeback" no texto inteiro da documentação. A Nuvemshop tem nove eventos de pedido e nenhum de reembolso, chargeback ou recusa. Quem vende por essas quatro e quer reagir a um chargeback precisa de outro canal, e o webhook não vai avisar.

A compra recusada tem uma ausência mais sutil. A Hotmart não tem evento de recusa, só o campo purchase.payment.refusal_reason dentro de outro evento. A Shopify faz sucesso, falha e erro trafegarem no mesmo order_transactions/create, que, pela documentação, "Only occurs for transactions with a status of success, failure or error." Para saber que a venda foi recusada, o integrador lê um campo, e o nome do evento não diz nada.

A figura explica por que a Leadlovers só consegue alimentar o balde de atraso com a Hotmart. O balde depende de um evento que oito das quinze plataformas emitem com nome próprio, e a Hotmart é a única entre as doze com tutorial que o emite como evento de compra, PURCHASE_DELAYED. A restrição do motor espelha a restrição dos emissores.

Sete jeitos de dois dicionários discordarem

Ao ler as quinze documentações lado a lado, as divergências caem em sete tipos, e cada tipo exige um conserto diferente. Os dois primeiros se resolvem com tradução. Os cinco seguintes exigem regra de negócio, e dois deles só aparecem depois que a automação já mandou a mensagem errada.

O quarto tipo merece ser visto inteiro, porque é o que mais engana quem configura pelo painel. A Kiwify oferece, para assinatura, o enum boleto_gerado, pix_gerado, carrinho_abandonado, compra_recusada, compra_aprovada, compra_reembolsada, chargeback, subscription_canceled, subscription_late e subscription_renewed. O payload que chega traz outro campo, webhook_event_type, com outros valores.

O mesmo desenho se repete em outras casas de outra forma. A Ticto mantém as versões 1 e 2 vivas: compra aprovada é paid numa e authorized na outra; boleto é billet_printed numa e bank_slip_created na outra. A Cakto mistura os idiomas dentro de um único enum, com purchase_approved ao lado de pix_gerado e openfinance_nubank_gerado. A Hotmart tem v1 e v2, e a Leadlovers recomenda a v1.

A normalização escondida tem duas direções. A PerfectPay achata antes de enviar: os códigos 18, 19 e 20, que incluem med e pre_med, chegam ao postback como o código 7 de refunded. Uma disputa aberta no Banco Central e um reembolso pedido pelo cliente viram o mesmo número. O Asaas faz o oposto e separa o que todas as outras fundem: "PAYMENT_CONFIRMED - Cobrança confirmada (pagamento efetuado, porém, o saldo ainda não foi disponibilizado)." e "PAYMENT_RECEIVED - Cobrança recebida. (Valor disponível na conta Asaas)". Um dicionário canônico que chame tudo de "aprovada" joga essa distinção fora.

Os erros de grafia fecham a lista porque viram contrato. O enum de status da Hotmart publica UNDER_ANALISYS. A documentação da Greenn publica o valor TRANSACTIOM para o tipo de produto e se declara atualizada em 9 de novembro de 2021. Quem casa a string precisa copiar o erro, e quem o corrige no próprio código deixa de receber o evento. A Monetizze acrescenta um aviso que vale para todas: "Não garantimos disparo único por evento."

O prazo de reembolso viaja no payload de uma e não existe em outra

Entre os fatos que precisam de nome, o prazo de reembolso é o que mostra melhor a diferença entre o que a lei fixa, o que a plataforma publica e o que o webhook transporta. O Código de Defesa do Consumidor, no art. 49, diz: "O consumidor pode desistir do contrato, no prazo de 7 dias a contar de sua assinatura ou do ato de recebimento do produto ou serviço, sempre que a contratação de fornecimento de produtos e serviços ocorrer fora do estabelecimento comercial". O parágrafo único completa: "os valores eventualmente pagos, a qualquer título, durante o prazo de reflexão, serão devolvidos, de imediato, monetariamente atualizados."

A lei fixa dois prazos distintos, e eles costumam ser confundidos. Sete dias é a janela para desistir. A devolução do dinheiro, depois da desistência, é "de imediato", sem número de dias. Quando uma plataforma publica uma janela de garantia maior que sete dias, ela está ampliando o direito de desistir; quando publica um prazo em dias úteis para o produtor devolver, está regulando o segundo prazo, aquele que a lei não mede em dias.

A Ticto é a única das quinze que coloca o prazo dentro do webhook, no campo item.refund_deadline. Para as outras, o prazo é um fato que existe na central de ajuda e não existe no payload: a automação que quer avisar o cliente de que a garantia termina amanhã precisa carregar esse número de fora. A Hotmart adiciona uma regra que muda o cálculo em assinaturas, a garantia vale só para a primeira cobrança, e a Ticto publica a mesma regra com outras palavras. Em nenhuma das duas esse limite chega como evento.

Reembolso e chargeback são fatos distintos para nove das quinze plataformas, que os separam por evento (Hotmart, Eduzz, Kiwify, Cakto, Ticto, PerfectPay, Greenn, Stripe, Asaas). A Hotmart define a diferença: "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… No caso do reembolso, o comprador pode solicitá-lo dentro do prazo de garantia". A Ticto mede a consequência: reembolso "Não impacta o índice de chargeback", e chargeback "Impacta diretamente a taxa". A Kiwify publica o limite: "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ê." Quatro plataformas não têm o evento, e a PerfectPay manda a disputa com o código do reembolso. Para essas cinco, a métrica que pode suspender a conta não chega pelo webhook.

O décimo sexto dicionário não existe em padrão aberto nenhum

A saída natural seria traduzir cada plataforma para um vocabulário neutro que alguém já tivesse publicado. O portal procurou esse vocabulário em cinco candidatos, todos abertos em 23 de agosto de 2026, e nenhum nomeia o ciclo financeiro do checkout. Cada um falha por um motivo diferente, e os motivos explicam por que o problema persiste.

Os dois candidatos de medição merecem uma leitura mais próxima, porque são os que uma equipe de marketing já usa. O GA4 publica catorze eventos recomendados para comércio, e o único que acontece depois do dinheiro entrar é refund. A Meta Conversions API publica Subscribe e StartTrial, e o outro lado do ciclo, a renovação, aparece apenas na descrição do campo action_source, que admite o valor system_generated com o exemplo de "uma renovação de assinatura". A renovação existe como circunstância de um evento e fica sem nome de evento. Um chargeback não tem onde entrar.

O schema.org mostra o outro limite. O vocabulário existe, está publicado e é aberto, e a página registra menos de mil domínios usando OrderStatus, com data de julho de 2026. Ser aberto não o tornou adotado, e os oito valores descrevem a entrega do pedido e param antes do pagamento. O CloudEvents, que é o padrão de envelope mais usado em infraestrutura, delega explicitamente o nome do evento ao produtor. Isso fecha o círculo: o único lugar onde um dicionário neutro poderia nascer decidiu, por especificação, que o nome é de quem emite.

Escreva o dicionário antes de ligar o segundo checkout

A decisão desta página é construir um dicionário próprio de eventos canônicos antes de ligar o segundo checkout, e mapear cada plataforma para ele, registrando por escrito o que ela não emite. A ordem importa: com um checkout só, o dicionário da plataforma serve; com dois, a primeira automação que usa os dois já precisa de uma tradução, e ela costuma nascer dentro de uma regra de automação, onde ninguém a revisa.

• Aprovada. O dinheiro entrou. Decida se "confirmada" (Asaas) conta, e anote.
• Recusada. A tentativa falhou e não há cobrança pendente. Separe de "atrasada".
• Aguardando. Boleto ou Pix emitido e não pago. O código Pix da Leadlovers expira em 24 horas, e esse prazo faz parte do fato.
• Abandonada. O checkout foi aberto e não concluído. Na Pagar.me não existe: checkout.canceled é link expirado.
• Reembolsada. Devolução a pedido ou por iniciativa do produtor. Na Monetizze, separe a solicitação (código 9) da conclusão (código 4).
• Contestada. Chargeback ou disputa iniciada pelo banco. Não existe em quatro das quinze; na PerfectPay, chega como reembolso.
• Assinatura criada. Existe em 8 de 15. Na Monetizze divide o código 101 com a renovação.
• Renovada. Nome próprio em 5 de 15. Onde falta, reconstrua por campo ou não prometa.
• Cancelada. Existe em 12 de 15. Na Stripe, customer.subscription.deleted também dispara no fim natural do período.
• Atrasada. Cobrança recorrente que falhou. Existe em 8 de 15, e a Leadlovers só a recebe da Hotmart.

1. Liste os fatos de venda que a sua operação precisa automatizar, e dê a cada um um nome canônico em português, com definição de uma frase. Os dez acima são o piso; uma operação sem assinatura fica com seis.
2. Para cada plataforma que você usa, abra a documentação de webhook e preencha uma linha por fato canônico com o nome literal do evento, copiado com o erro de grafia incluído. Onde não houver evento, escreva "não emite", e onde o fato vier por campo, escreva o campo e o valor.
3. Marque os nomes que colidem: um evento da plataforma que cai em dois fatos canônicos. Para cada colisão, escreva qual campo do payload desempata e o que fazer quando o campo não vem.
4. Registre a versão do webhook de cada plataforma ao lado do mapeamento. Ticto v1 e v2, Hotmart v1 e v2 e o par assina/recebe da Kiwify são dicionários diferentes, e a tabela precisa dizer qual deles você lê.
5. Liste, por automação, os fatos canônicos de que ela depende, e cruze com a tabela. Toda automação que depende de um fato marcado "não emite" em alguma plataforma fica com aviso explícito no nome, para que ninguém espere uma régua de chargeback disparar na Monetizze.
6. Trate o motor da Leadlovers como mais uma linha da tabela. Os cinco baldes são um dicionário de cinco fatos, e a coluna de plataformas habilitadas já vem preenchida pela Central de Ajuda. Pós-venda para quatro, atraso para uma.
7. Registre a data de consulta ao lado de cada linha. A Greenn publica documentação datada de 9 de novembro de 2021, a Hotmart retém 60 dias de histórico de webhook, e a Leadlovers atualizou a página de ações em 13 de julho de 2026. Dicionário sem data envelhece sem avisar.

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, página institucional de integrações, com os 18 cartões da categoria de pagamento sob o rótulo "Algumas de nossas integrações" e as duas grafias da categoria. Consulta em 23 de agosto de 2026.
2. Leadlovers, Central de Ajuda, índice de integrações de pagamento, com os 12 tutoriais de checkout e gateway, apurado pelo sitemap de 470 URLs. Consulta em 23 de agosto de 2026.
3. Leadlovers, Central de Ajuda, "Como configurar ações automatizadas", publicado em 8 de junho de 2026 e atualizado em 13 de julho de 2026, com os cinco baldes de ação e as plataformas habilitadas em cada um. Consulta em 23 de agosto de 2026.
4. Leadlovers, Central de Ajuda, "Como configurar ações na sua integração", do checkout nativo, com o balde "Ações para cobrança por Pix" e a duração de 24 horas do código. Consulta em 23 de agosto de 2026.
5. Leadlovers, Central de Ajuda, "Como gerenciar as vendas", com os filtros de status Ativa, Cancelada, Chargeback ou Reembolso. Consulta em 23 de agosto de 2026.
6. Leadlovers, Central de Ajuda, "Como integrar Braip e leadlovers", com os rótulos "Boleto Impresso", "Compra Efetuada", "Abandono de Checkout" e "Compra Aprovada". Consulta em 23 de agosto de 2026.
7. Leadlovers, Central de Ajuda, "Como integrar Hotmart e leadlovers", com a recomendação de usar a versão 1 do webhook e os eventos Compra Aprovada e Aguardando pagamento. Consulta em 23 de agosto de 2026.
8. Leadlovers, Central de Ajuda, perguntas frequentes do checkout, com a regra de reembolso por meio de pagamento e sem prazo em dias. Consulta em 23 de agosto de 2026.
9. Hotmart, documentação de desenvolvedores, webhook de compra 2.0.0, com os nove eventos de compra, o enum de status com UNDER_ANALISYS e a retenção de 60 dias. Consulta em 23 de agosto de 2026.
10. Hotmart, central de ajuda, artigo sobre prazo de garantia, com as janelas de 7, 15, 21 ou 30 dias e a regra da primeira cobrança em assinatura. Consulta em 23 de agosto de 2026.
11. Hotmart, central de ajuda, artigo sobre a diferença entre chargeback e reembolso. Consulta em 23 de agosto de 2026.
12. Eduzz, documentação de desenvolvedores, webhook, com os eventos myeduzz.invoice_paid, contract_created e demais. Consulta em 23 de agosto de 2026.
13. Eduzz, central de ajuda, artigo sobre prazos de reembolso, com os tetos de 75 dias para Pix e boleto e 150 dias para cartão. Consulta em 23 de agosto de 2026.
14. Kiwify, documentação da API, criação de webhook, com o enum de triggers em português e os valores de webhook_event_type em inglês. Consulta em 23 de agosto de 2026.
15. 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.
16. 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.
17. Cakto, documentação, conceitos de webhooks, com os 16 eventos do enum bilíngue. Consulta em 23 de agosto de 2026.
18. Monetizze, documentação da API, webhook, com os 17 códigos numéricos, a distinção entre os códigos 9 e 4 e o aviso de disparo não único. Consulta em 23 de agosto de 2026.
19. Ticto, documentação de webhook, versão 2, com os eventos authorized, extended, subscription_delayed e o campo item.refund_deadline. Consulta em 23 de agosto de 2026.
20. Ticto, documentação de webhook, versão 1, com os eventos paid, billet_printed e chargeback e suas descrições em português. Consulta em 23 de agosto de 2026.
21. Ticto, central de ajuda, "Chargeback na Ticto", com a distinção entre reembolso e chargeback e o impacto na taxa. Consulta em 23 de agosto de 2026.
22. PerfectPay, documentação da API em JSON, com os 20 códigos de status e a nota de normalização do postback. Consulta em 23 de agosto de 2026.
23. Greenn, central de ajuda, documentação do webhook, datada de 9 de novembro de 2021, com os valores de currentStatus e o valor TRANSACTIOM. Consulta em 23 de agosto de 2026.
24. Greenn, central de ajuda, "Como funciona o reembolso", com o prazo de 3 dias úteis do produtor. Consulta em 23 de agosto de 2026.
25. Stripe, referência da API, tipos de evento, com as descrições de payment_intent.succeeded, invoice.payment_failed, charge.dispute.created e customer.subscription.deleted. Consulta em 23 de agosto de 2026.
26. Shopify, documentação da Admin GraphQL API, enum WebhookSubscriptionTopic, com os 214 tópicos e as descrições de orders/paid, refunds/create e order_transactions/create. Consulta em 23 de agosto de 2026.
27. Pagar.me, documentação de webhooks, com os 40 eventos e as descrições de order.paid, checkout.canceled e checkout.closed. Consulta em 23 de agosto de 2026.
28. Nuvemshop, documentação da API, recurso webhook, com os nove eventos de pedido. Consulta em 23 de agosto de 2026.
29. Yampi, documentação da API, introdução a webhooks, com os 14 eventos e as descrições de order.paid e cart.reminder. Consulta em 23 de agosto de 2026.
30. Asaas, documentação, webhook para cobranças, com os 31 eventos e a distinção entre PAYMENT_CONFIRMED e PAYMENT_RECEIVED. Consulta em 23 de agosto de 2026.
31. iugu, documentação de desenvolvedores, gatilhos de fatura, com invoice.status_changed e os valores do campo de status. Consulta em 23 de agosto de 2026.
32. iugu, documentação de desenvolvedores, gatilhos de assinatura, com subscription.created e subscription.renewed. Consulta em 23 de agosto de 2026.
33. Presidência da República, Lei 8.078 de 1990, Código de Defesa do Consumidor, texto compilado, art. 49 e parágrafo único. Consulta em 23 de agosto de 2026.
34. schema.org, enumeração OrderStatus, com os oito valores e a nota de uso abaixo de mil domínios em julho de 2026. Consulta em 23 de agosto de 2026.
35. Google, documentação do GA4, referência de eventos recomendados, com os eventos de comércio e o refund como único pós-venda. Consulta em 23 de agosto de 2026.
36. Portal Leadlovers 2026, "O checkout pode custar mais que todo o software", com as taxas publicadas das mesmas plataformas sobre R$ 100 mil por mês. Consulta em 23 de agosto de 2026.