Vender curso e produto digital sem perder o comprador
Doze checkouts, doze nomes para a mesma venda
Quinze plataformas de pagamento nomeiam compra, reembolso e assinatura de jeitos incompatíveis, e nenhum padrão aberto resolve.
Se você vende por mais de um checkout (a página em que o cliente paga), cada plataforma manda os avisos de venda com nomes próprios. Em quinze delas, compra aprovada tem doze nomes, e quatro nunca avisam quando o cliente contesta a compra no cartão. Antes de ligar o segundo checkout, escreva a tabela que traduz esses nomes para a sua automação (a mensagem que sai sozinha a cada venda).
13 minutos de leitura Revisão em Brasil GEO, responsável editorial
Por que os relatórios de dois checkouts nunca batem
Duas plataformas de pagamento contam a mesma venda com palavras diferentes. Por isso os relatórios não fecham, e a régua de mensagens (a sequência de mensagens automáticas de cada venda) funciona numa e falha na outra.
Toda venda vira um webhook (o aviso automático que um sistema manda ao outro quando algo acontece), e é ele que dispara a sua automação.
- Na Hotmart, o aviso de venda paga se chama
PURCHASE_APPROVED, em letra maiúscula, com sublinhado entre as duas palavras. - Na Kiwify, o mesmo fato chega como
order_approved, mesmo que você tenha marcadocompra_aprovadana tela de configuração. - Na Shopify, ele é
orders/paid. Na Monetizze, é só o código2, sem palavra nenhuma para o leitor humano. - Na Nuvemshop, é
order/paid, no singular onde a Shopify usa plural, e essa letra a menos basta para quebrar o encaixe.
São doze nomes para o mesmo fato entre as quinze plataformas que publicam a sua lista de avisos. Quem liga o segundo checkout herda o dicionário do segundo, inteiro, e passa a manter dois. A primeira tradução já acontece dentro da Leadlovers, que enxerga só parte desses avisos.
Qual dos três números da Leadlovers manda na sua automação
Dentro da Leadlovers há três números de integração de pagamento, e eles não medem a mesma coisa. Um é vitrine, outro é tutorial e só o terceiro, o que a automação enxerga, muda o que você consegue disparar.
- A página institucional mostra 18 cartões de pagamento, e cinco deles não são checkout: Sympla e Eventbrite vendem ingresso, Kobana emite boleto, Vindi e iugu cobram recorrência.
- A Central de Ajuda tem tutorial próprio para 12 checkouts e gateways, do Braip à Monetizze, e a lista completa de provedores fica dentro do aplicativo.
- O motor de automação reconhece 5 fatos de venda: pós-venda, cobrança por boleto, pagamento atrasado, cancelamento e abandono de carrinho.
Quantas plataformas alimentam cada ação automática
Plataformas habilitadas, de 12 com tutorial
Só a Hotmart aparece nas cinco listas. As quatro do cancelamento são outras quatro que as do pós-venda.
Na prática, o balde de pagamento atrasado tem uma única plataforma habilitada. Uma operação que vende por Kiwify e PagSeguro recebe pós-venda e boleto e fica sem cancelamento; na Braip acontece o contrário, e na PayT sobra só o abandono.
O que isso muda na sua régua de cobrança
Uma régua que cobra o cliente atrasado só dispara para vendas da Hotmart. Nas outras onze plataformas com tutorial, esse aviso não chega, e nada na tela mostra que ele falta.
Já o painel de vendas do checkout filtra por Ativa, Cancelada, Chargeback ou Reembolso. Nenhum desses quatro estados vira ação automática, ou seja, o relatório vê o fato e a régua não reage.
Compra aprovada tem doze nomes em quinze plataformas
Fora da Leadlovers a diferença cresce. Quinze plataformas publicam a lista dos seus avisos de venda, da Hotmart à iugu. Braip e Vindi ficam de fora da conta, porque guardam a documentação atrás de login.
Quinze plataformas, seis jeitos de escrever a palavra pago
- 4 prefixo com ponto (Eduzz, Stripe, Pagar.me, Yampi) 26,7% do total
- 3 palavra solta (Ticto, Greenn, iugu) 20% do total
- 2 MAIÚSCULA_COM_SUBLINHADO (Hotmart, Asaas) 13,3% do total
- 2 minúscula_com_sublinhado (Kiwify, Cakto) 13,3% do total
- 2 recurso com barra (Shopify, Nuvemshop) 13,3% do total
- 2 código numérico (Monetizze, PerfectPay) 13,3% do total
| Plataforma | Compra aprovada | Contestação no cartão | Assinatura renovada | Carrinho abandonado |
|---|---|---|---|---|
| Hotmart (webhook 2.0.0) | PURCHASE_APPROVED | PURCHASE_CHARGEBACK | Não existe; só o campo recurrence_number | PURCHASE_OUT_OF_SHOPPING_CART |
| Eduzz | myeduzz.invoice_paid | invoice_chargeback | Não existe | invoice_recovering |
| Kiwify (assina e recebe) | compra_aprovada, chega order_approved | chargeback | subscription_renewed | carrinho_abandonado, chega sem campo de evento |
| Cakto | purchase_approved | chargeback | subscription_renewed | checkout_abandonment |
| Monetizze | código 2 Finalizada ou Aprovada | Não existe | código 101, o mesmo de assinatura criada | código 7 Abandono de Checkout |
| Ticto v2 (v1) | authorized (paid) | chargeback | extended | abandoned_cart |
| PerfectPay | código 2 approved | código 9 charged_back | Não existe | código 12 precheckout |
| Greenn | paid | chargedback | Não existe | checkoutAbandoned |
| Stripe | payment_intent.succeeded | charge.dispute.created | Não existe; invoice.paid com billing_reason | Não existe |
| Shopify | orders/paid | disputes/create, só Shopify Payments | subscription_billing_attempts/success | Não existe |
| Pagar.me | order.paid | Não existe | Não existe | checkout.canceled, que quer dizer link expirado |
| Nuvemshop | order/paid | Não existe | Não existe | Não existe |
| Yampi | order.paid | Não existe | Não existe | cart.reminder |
| Asaas | PAYMENT_CONFIRMED e PAYMENT_RECEIVED | PAYMENT_CHARGEBACK_REQUESTED | Não existe | Não existe |
| iugu | campo status igual a paid | campo status igual a chargeback | subscription.renewed | Não existe |
Leia a tabela por coluna, porque ela mostra o tamanho do problema. Compra aprovada tem quinze entradas e doze nomes; contestação tem quatro buracos; renovação tem cinco nomes próprios e nove ausências.
Onde a renovação da assinatura perde o nome
- Nome próprio de evento (Kiwify, Cakto, Ticto, Shopify, iugu) 5
- Código repartido com assinatura criada (Monetizze) 1
- Sem nome para a renovação 9
- Plataformas com documentação aberta 15
Hotmart e Stripe deixam remontar a renovação por um campo do aviso. As outras sete não oferecem nem o campo.
Quem liga só a primeira coluna acha que o problema é de tradução; quem precisa das outras três descobre que é de existência, e esse nenhuma tabela resolve.
O aviso que não existe custa mais que o nome trocado
Nome diferente se resolve com uma tabela de tradução; aviso que não existe, não. A automação que depende dele fica muda para aquela plataforma, sem alerta de que parou.
Quantas das quinze plataformas dão nome a cada fato da venda
Plataformas, de 15
Renovação conta só nome próprio. A Monetizze usa um código para assinatura criada e renovada, então ela fica de fora dessa linha.
O caso mais caro é a contestação no cartão (o chargeback: o cliente reclama no banco e o dinheiro sai da sua conta). Monetizze, Pagar.me, Nuvemshop e Yampi não mandam esse aviso, e a Monetizze publica 17 códigos sem ele.
Já a compra recusada some de um jeito mais discreto. Na Hotmart não há aviso de recusa, e o motivo chega dentro de um campo de outro aviso; na Shopify, sucesso, falha e erro viajam com o mesmo nome.
| Tipo de desencontro | Exemplo literal | O que quebra |
|---|---|---|
| Nome diferente para o mesmo fato | Compra aprovada é PURCHASE_APPROVED, order_approved, authorized, paid, código 2 | Nada, com tabela de tradução. Tudo, se o encaixe for feito pelo nome cru. |
| Mesmo nome com sentido diferente | order.paid é pedido de loja quitado na Shopify, cobrança sem carrinho na Pagar.me e pedido aprovado na Yampi | A mesma regra lê três coisas diferentes e acha que são uma. |
| Aviso que só existe numa | Contestação não existe em Monetizze, Pagar.me, Nuvemshop e Yampi; recusa não existe em Hotmart, Eduzz, Shopify, Nuvemshop e iugu | A automação fica muda para aquela plataforma, sem alerta. |
| Dois dicionários na mesma casa | Kiwify assina compra_aprovada e recebe order_approved; Ticto usa paid na v1 e authorized na v2 | Você marca um nome no painel e nunca recebe o aviso. |
| Um nome só para dois fatos | invoice.payment_failed na Stripe cobre cartão recusado e mensalidade que falhou | O e-mail de cartão recusado chega a quem já é assinante. |
| Achatamento antes do envio | PerfectPay: os códigos 18, 19 e 20 chegam ao seu servidor como o código 7 de reembolso | Disputa aberta no banco chega com a cara de reembolso pedido pelo cliente. |
| Erro de grafia que virou contrato | Hotmart UNDER_ANALISYS, Greenn TRANSACTIOM, Yampi shippment | Quem escreve certo do seu lado para de receber. |
Os dois primeiros tipos morrem com uma tabela de tradução. Os cinco seguintes exigem regra de negócio, porque o mesmo nome carrega dois fatos e alguém precisa decidir qual deles chegou.
A colisão que manda o e-mail errado
Na Stripe, um aviso só cobre o cartão recusado de um cliente novo e a mensalidade que falhou de um assinante antigo. A Pagar.me faz igual, com o mesmo nome.
A mensagem que diz "seu cartão foi recusado, tente outro" acerta o cliente novo e erra o assinante. Ele está em cobrança e precisa de outro texto, com outro prazo.
Só a resposta de quem recebeu revela o erro, porque nenhuma tela acusa nada: para o sistema, os dois casos chegaram com o mesmo nome.
Esse desencontro pesa ainda mais quando o fato em jogo é a contestação, porque ela mexe na taxa que pode suspender a sua conta de vendedor.
Quanto da conta que pode suspender você chega pelo aviso
-
73%
das quinze plataformas nomeiam a contestação no cartão, e as outras quatro deixam o fato sem aviso
-
60%
separam contestação de reembolso em avisos distintos, enquanto a PerfectPay manda a disputa com o código do reembolso
-
1,5%
de taxa de contestação é o limite que a Kiwify publica: acima dele, a conta pode parar de processar pagamentos
Os dois primeiros anéis medem plataformas sobre a base de quinze. O terceiro mede a taxa de contestação da conta do vendedor.
Quanto tempo o cliente tem para pedir o dinheiro de volta
Por lei, o cliente tem sete dias para desistir de uma compra feita fora da loja física, contados da compra ou do recebimento. O dinheiro volta de imediato, e esse segundo prazo a lei não conta em dias.
Cada plataforma publica uma janela diferente, e quase nenhuma manda esse prazo dentro do aviso, ou seja, a sua automação não sabe quando a garantia termina. A Ticto é a exceção: o prazo viaja num campo do próprio aviso.
| Plataforma | Janela publicada | O que a mesma página acrescenta |
|---|---|---|
| Hotmart | 7, 15, 21 ou 30 dias, por produto | Em assinatura, a garantia escolhida vale só para a primeira cobrança |
| Kiwify | 7 dias da data da compra | A contagem começa na data da compra, e o pedido de reembolso não desloca esse início |
| Eduzz | 7 dias da lei mais até 30 do produtor | O cliente pode pedir até 75 dias no Pix e no boleto, e até 150 no cartão |
| Greenn | 7 dias, com 3 dias úteis para o produtor devolver | Se o produtor não devolver, a plataforma pode entrar no lugar dele |
| Ticto | Definido pelo produtor, e viaja no aviso | Campo item.refund_deadline no webhook v2 |
| Leadlovers checkout | Sem prazo publicado em dias | Cartão pelo suporte do checkout; boleto e Pix direto com o vendedor |
| Cakto e Monetizze | Sem prazo em dias nas páginas abertas | Nenhuma das duas centrais publica a janela |
Para quase todas, portanto, o prazo mora na central de ajuda e não chega ao seu sistema. A mensagem de que a garantia termina amanhã precisa desse número digitado na sua tabela, porque nenhum aviso o traz.
Uma assinatura mensal e os nomes que cada marco recebe
-
Dia 0
Pix gerado e compra aprovada
cumprido
Doze das quinze nomeiam o Pix ou o boleto gerado, e as quinze nomeiam a aprovação, com doze nomes diferentes.
-
Dia 7
Fim da janela legal de desistência
cumprido
Prazo do art. 49 do Código de Defesa do Consumidor. Só a Ticto carrega esse prazo dentro do aviso de venda.
-
Dia 30
Renovação cobrada
em curso
Cinco das quinze dão nome próprio à renovação. Na Hotmart, ela chega como uma compra aprovada com o número da parcela.
-
Dia 45
Contestação ou cancelamento
previsto
Onze das quinze nomeiam a contestação e doze nomeiam o cancelamento. Na Stripe, o mesmo nome serve para o fim natural do plano.
Reembolso e contestação são fatos separados para nove das quinze plataformas. O reembolso sai do seu bolso; a contestação passa pelo banco e entra na taxa que pode travar a sua conta de vendedor. Logo, a sua tabela precisa de uma linha para cada um, e nenhum vocabulário pronto traz essa separação.
Nenhum padrão pronto nomeia a venda inteira
Seria mais fácil adotar um vocabulário neutro que já exista. Cinco candidatos ocupam esse lugar, e nenhum deles nomeia o que acontece depois que o dinheiro entra.
| Candidato | O que ele nomeia | Por que não serve |
|---|---|---|
| schema.org OrderStatus | Pedido cancelado, entregue, em trânsito, com problema e mais quatro | Vocabulário de entrega. Sem contestação, assinatura, renovação ou atraso |
| CloudEvents | Só o envelope do aviso, com um campo de tipo | O texto do padrão diz que o nome do tipo é escolha de quem emite |
| OASIS UBL | Pedido e nota fiscal entre empresas | Escopo errado: nasceu para faturamento eletrônico, sem relação com checkout |
| GA4 | Comprou, iniciou checkout, viu item e mais onze | Eventos de medição, também recebidos de servidor pelo Measurement Protocol; não substituem o estado financeiro do checkout |
| Meta Conversions | Comprou, assinou, começou teste e mais doze | Tem a entrada da assinatura e nada da saída. A renovação nem nome tem |
GA4 (o medidor do Google) e Meta são os dois que a sua equipe de marketing já usa, e os dois param na entrada do cliente. Depois do pagamento, o GA4 só tem reembolso, e a renovação da Meta aparece como circunstância de outro evento.
Já o schema.org é aberto e descreve só a entrega do pedido; menos de mil domínios usam a lista dele. O CloudEvents padroniza o envelope e deixa a semântica do tipo para quem emite. A combinação source + id identifica o evento e ajuda a reconhecer reentregas, mas o significado de compra, renovação ou estorno ainda precisa de um dicionário de negócio.
O décimo sexto dicionário fica com você
Nenhum dos cinco candidatos nomeia contestação, renovação, falha de cobrança ou disputa. Nenhum dos doze nomes de compra aprovada veio de fora: cada plataforma escreveu o seu.
Cobrança que se repete, régua de inadimplência e nova tentativa pertencem ao sistema de pagamento, e os padrões de medição param antes disso.
A tabela neutra vai existir de um jeito ou de outro: escrita antes da segunda integração, ou espalhada em regras soltas depois da terceira. Escrever esse vocabulário antes que cada ferramenta imponha o seu é a fundação que Sistema operacional nativo de IA descreve.
Use duas camadas no contrato de integração: identidade e versão do evento para receber com segurança; estados de negócio para decidir a mensagem. O Measurement Protocol permite enviar interações de servidor ao GA4, mas esse recebimento não confirma liquidação, estorno ou conciliação de caixa.
Escreva a sua tabela antes de ligar o segundo checkout
Monte uma tabela com os fatos de venda que a sua operação automatiza, dê a cada um um nome seu e anote o que cada plataforma manda. Com dois checkouts, a tradução já existe. Escrever esse contrato de eventos antes da segunda integração é o método do curso API Design: REST, GraphQL e Boas Práticas.
Como decidir se um fato de venda entra na sua tabela
mesmo sentidoQuer dizer a mesma coisa em todaso nome colide
-
Traduza e anote a ausência
A contestação existe em onze das quinze e quer dizer o mesmo nas onze. Entra na tabela com um "não emite" ao lado das quatro que faltam.
-
Traduza direto
A compra aprovada existe nas quinze. Doze nomes viram um só. A única dúvida é o Asaas, que separa confirmado de recebido, e você escolhe qual dos dois vale.
-
Remonte por campo, ou não prometa
A renovação tem nome próprio em cinco das quinze. Onde falta, remonte por um campo do aviso e anote a regra; onde nem o campo existe, deixe a automação fora da promessa.
-
Separe antes de traduzir
O aviso de cobrança que falhou vale para cliente novo e para assinante antigo. A sua tabela precisa de dois nomes, e a regra lê um segundo campo para saber qual deles chegou.
falta em algumaExiste nas plataformas que você usaexiste em todas
Dez fatos cobrem a maior parte das operações, e cada um passa pelo mesmo teste com um cuidado próprio.
| Fato da venda | Dão nome | O cuidado da linha |
|---|---|---|
| Aprovada | 15 de 15 | Decida se o confirmado do Asaas conta como aprovada, e anote a escolha |
| Recusada | 10 de 15 | Separe de atrasada; na Hotmart o motivo chega dentro de um campo |
| Aguardando | 12 de 15 | Boleto ou Pix emitido e não pago; o código Pix expira em 24 horas |
| Abandonada | 9 de 15 | Na Pagar.me não existe: checkout.canceled é link expirado |
| Reembolsada | 13 de 15 | Na Monetizze, separe o pedido de reembolso da devolução concluída |
| Contestada | 11 de 15 | Não existe em quatro; na PerfectPay chega com o código do reembolso |
| Assinatura criada | 8 de 15 | Na Monetizze, divide o mesmo código com a renovação |
| Renovada | 5 de 15 | Onde falta, remonte por campo ou não prometa a régua |
| Cancelada | 12 de 15 | Na Stripe, o mesmo nome cobre o fim natural do plano |
| Atrasada | 8 de 15 | A Leadlovers só recebe esse fato da Hotmart |
- Liste os fatos de venda que a sua operação automatiza e dê a cada um um nome em português, com uma frase de definição. Os dez acima são o piso.
- Para cada plataforma, abra a documentação de webhook e escreva o nome literal de cada fato, com o erro de grafia incluído. Onde não houver aviso, escreva "não emite".
- Marque os nomes que servem a dois fatos. Para cada um, anote qual campo desempata e o que fazer quando esse campo não vem.
- Anote a versão do aviso de cada plataforma. Ticto v1 e v2, Hotmart v1 e v2 e o par da Kiwify são dicionários diferentes.
- Cruze cada automação com a tabela. A que depende de um fato marcado como não emitido ganha um aviso no próprio nome, para ninguém esperar disparo.
- Trate o motor da Leadlovers como mais uma linha. Os cinco baldes são um dicionário de cinco fatos, com a coluna de plataformas já preenchida.
- Anote a data ao lado de cada linha. A Greenn publica documentação de 2021 e a Hotmart guarda 60 dias de histórico. Tabela sem data envelhece calada.
Feita a lista, sobra decidir em que ponto começar a preenchê-la.
A cobrança recorrente por Pix acrescenta nomes novos em 2026
Uma tabela escrita em 2025 não previa três fatos novos: autorização de débito recorrente concedida, revogada pelo cliente no aplicativo do banco ou suspensa por falta de saldo. Nenhum dicionário de cartão nomeia esses três, e eles chegam pelo mesmo webhook.
Esse volume cresce rápido o bastante para não esperar. No primeiro ano da modalidade, os usuários ativos subiram em média 177% por mês, e maio de 2026 fechou perto de 2 milhões de transações. Acrescente as três linhas à sua tabela antes de ligar o segundo checkout.
O critério, e o que fazer hoje
Conte quantos checkouts a mesma automação lê: esse é o critério. Com um, anote a versão do aviso e siga. Com dois ou mais, escreva a tabela antes de ligar o segundo.
Dez linhas por plataforma é o custo da tabela. A alternativa custa um e-mail de cartão recusado enviado a quem já paga, ou uma régua de contestação muda porque o aviso não existe.
A taxa dessas mesmas plataformas tem página própria: O checkout pode custar mais que todo o software. As duas contas se somam, a que ele cobra e a que ele deixa de entregar.
Comece hoje pela coluna do que não existe, porque é a única que nenhuma plataforma anuncia. Você acertou quando cada automação da casa tiver ao lado do nome as plataformas em que dispara e as que ignora, e nenhuma régua ficar muda sem aviso.
Perguntas que aparecem depois desta leitura
Com quantas plataformas de pagamento a Leadlovers se integra?
A própria Leadlovers publica três números. A página institucional mostra 18 cartões, e cinco deles não são checkout. A Central de Ajuda tem tutorial para 12 checkouts e gateways. O motor de automação reconhece 5 fatos de venda, e só a Hotmart alimenta os cinco.
Por que o nome do evento muda de um checkout para outro?
Porque cada plataforma escreve o próprio vocabulário e nenhum padrão aberto nomeia o ciclo do dinheiro. Nas quinze documentações públicas, compra aprovada tem doze nomes. O CloudEvents, que é o padrão de envelope, deixa o nome por conta de quem emite o aviso.
Quais plataformas não avisam a contestação no cartão?
Monetizze, Pagar.me, Nuvemshop e Yampi não têm esse aviso na documentação pública de webhook. A Monetizze publica 17 códigos sem ele e a Pagar.me publica 40 eventos. A PerfectPay tem o aviso, mas manda a disputa com o código do reembolso.
O que é uma tabela própria de eventos de venda?
É uma tabela que dá um nome seu a cada fato de venda que a operação automatiza. Cada plataforma ganha uma linha, com o aviso que corresponde ao fato, o campo que desempata nomes repetidos e o que ela não manda.
Qual o prazo legal de reembolso em compra online no Brasil?
O art. 49 do Código de Defesa do Consumidor dá sete dias para desistir de compra feita fora da loja física, e manda devolver o dinheiro de imediato. As plataformas publicam janelas maiores: a Hotmart admite 7, 15, 21 ou 30 dias por produto.
Preciso disso se uso um checkout só?
Com um checkout, o vocabulário da própria plataforma resolve: anote qual versão do aviso você assinou e siga. Escreva a tabela no dia em que a mesma automação passar a ler dois checkouts, porque é aí que a tradução vira parte da regra. O sinal chega em uma semana: dois relatórios de venda com totais diferentes para os mesmos dias.
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.
- Leadlovers, página institucional de integrações, com os 18 cartões da categoria de pagamento. Consulta em 23 de agosto de 2026.
- Leadlovers, Central de Ajuda, índice de integrações de pagamento, com os 12 tutoriais de checkout e gateway. Consulta em 23 de agosto de 2026.
- Leadlovers, Central de Ajuda, "Como configurar ações automatizadas", com os cinco baldes de ação e as plataformas habilitadas em cada um. Consulta em 23 de agosto de 2026.
- 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.
- Leadlovers, Central de Ajuda, "Como configurar ações na sua integração", do checkout nativo, com a duração de 24 horas do código Pix. Consulta em 23 de agosto de 2026.
- 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.
- 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.
- Hotmart, central de ajuda, 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.
- Hotmart, central de ajuda, diferença entre chargeback e reembolso. Consulta em 23 de agosto de 2026.
- Eduzz, documentação de desenvolvedores, webhook, com os eventos myeduzz.invoice_paid e invoice_recovering. Consulta em 23 de agosto de 2026.
- Eduzz, central de ajuda, 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.
- 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.
- 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.
- 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.
- Cakto, documentação, conceitos de webhooks, com os 16 eventos do enum bilíngue. Consulta em 23 de agosto de 2026.
- Monetizze, documentação da API, webhook, com os 17 códigos numéricos e a distinção entre os códigos 9 e 4. Consulta em 23 de agosto de 2026.
- Ticto, documentação de webhook, versão 2, com os eventos authorized e extended e o campo item.refund_deadline. Consulta em 23 de agosto de 2026.
- Ticto, documentação de webhook, versão 1, com os eventos paid, billet_printed e chargeback. Consulta em 23 de agosto de 2026.
- 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.
- 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.
- Greenn, central de ajuda, documentação do webhook, datada de 9 de novembro de 2021, com o valor TRANSACTIOM. Consulta em 23 de agosto de 2026.
- Greenn, central de ajuda, "Como funciona o reembolso", com o prazo de 3 dias úteis do produtor. Consulta em 23 de agosto de 2026.
- Stripe, referência da API, tipos de evento, com payment_intent.succeeded, invoice.payment_failed, charge.dispute.created e customer.subscription.deleted. Consulta em 23 de agosto de 2026.
- Shopify, documentação da Admin GraphQL API, enum WebhookSubscriptionTopic, com orders/paid e order_transactions/create. Consulta em 23 de agosto de 2026.
- Pagar.me, documentação de webhooks, com os 40 eventos e as descrições de order.paid e checkout.canceled. Consulta em 23 de agosto de 2026.
- Nuvemshop, documentação da API, recurso webhook, com os nove eventos de pedido. Consulta em 23 de agosto de 2026.
- 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.
- Asaas, documentação, webhook para cobranças, com a distinção entre PAYMENT_CONFIRMED e PAYMENT_RECEIVED. Consulta em 23 de agosto de 2026.
- 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.
- iugu, documentação de desenvolvedores, gatilhos de assinatura, com subscription.created e subscription.renewed. Consulta em 23 de agosto de 2026.
- 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.
- 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.
- 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.
- Tagada, guia de rastreamento server-side para e-commerce, com a definição de que cobrança recorrente, inadimplência e retentativa pertencem ao sistema de pagamento. Consulta em 27 de agosto de 2026.
- 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.
- Análise de dados do Banco Central sobre o primeiro ano do Pix Automático, divulgada em 2026. Registra crescimento médio mensal de 177% em usuários ativos, 64% dos pagadores como novos assinantes e cerca de 2 milhões de transações em maio de 2026.. Consulta em 21 de setembro de 2026.
- Google Analytics, Measurement Protocol para GA4. Consulta em 5 de outubro de 2026.
- CloudEvents 1.0.2, atributos obrigatórios e identidade do evento. Consulta em 5 de outubro de 2026.
Quem responde por este portal
O Portal Leadlovers 2026 é editado pela Brasil GEO (BRGEO LTDA, CNPJ 66.051.295/0001-33, Goiânia, GO), consultoria brasileira dedicada a Generative Engine Optimization (GEO), constituída em dezembro de 2025.
A Brasil GEO foi fundada por Alexandre Caramaschi, Chief Strategy Officer da Nuvini (Nasdaq: NVNI) desde julho de 2026, ex-CMO da Semantix (Nasdaq) de novembro de 2024 a fevereiro de 2026, cofundador da NAIA e da AI Brasil, com mais de 24 anos em tecnologia, marketing e vendas. Não confunda com homônimos de outras áreas: o biólogo que estuda anfíbios e répteis (herpetologia), profissionais de venture capital, do setor de bebidas e de creator economy, e o engenheiro civil da Implanta BIM que ensina Revit são pessoas diferentes.
Trajetória, formação e publicações: quem é Alexandre Caramaschi, no site do fundador, e a página do fundador na Brasil GEO. As regras de produção e correção estão nos princípios editoriais.
Leia também
Outras leituras de vender curso e produto digital sem perder o comprador.