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.
Quem vende com mais de uma plataforma de pagamento recebe um vocabulário diferente de cada uma. Em quinze delas, compra aprovada tem doze nomes, e quatro nunca avisam quando o cliente contesta a compra no cartão. Aqui está o que decidir antes de ligar o segundo checkout.
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 mesma régua de mensagens funciona numa e falha na outra. Este guia é para quem vende por mais de um checkout.
Toda venda vira um aviso que sai de um sistema e entra no outro. Esse aviso é o webhook (aviso automático que um sistema manda ao outro quando algo acontece). É ele que dispara a sua automação (mensagem que sai sozinha, no horário certo, sem você digitar).
- 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.
Três números de integração, e cada um mede outra coisa
A conta começa dentro da própria Leadlovers, que publica três números de integração de pagamento. Um é vitrine, outro é tutorial e o terceiro é o que a automação enxerga. Só o terceiro 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.
O balde de pagamento atrasado tem uma única plataforma habilitada. Uma operação em 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.
O painel de vendas do checkout filtra por Ativa, Cancelada, Chargeback ou Reembolso. Nenhum desses quatro estados vira ação automática, então o relatório vê o fato e a régua não reage a ele.
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 |
A leitura por coluna diz mais que a leitura por linha. A coluna de compra aprovada tem quinze entradas e doze nomes. A de contestação tem quatro buracos. A de 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 o problema é de existência, e esse não tem tabela que resolva.
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 se resolve. A automação que depende dele fica muda para aquela plataforma, e ninguém recebe alerta de que ela 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, quando 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.
A compra recusada some de um jeito mais discreto. A Hotmart não tem 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. O assinante está em cobrança e precisa de outro texto, com outro prazo.
O erro só aparece na resposta de quem recebeu. Nenhuma tela acusa nada, porque, para o sistema, os dois casos chegaram com o mesmo nome.
O mesmo desencontro de nomes pesa mais quando o fato em jogo é a contestação, porque ela mexe na conta que pode suspender o 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
A lei dá sete dias para o cliente desistir de uma compra feita fora da loja física, contados da compra ou do recebimento. O dinheiro volta de imediato, e a lei não conta esse segundo prazo em dias.
Cada plataforma publica uma janela diferente, e quase nenhuma manda esse prazo dentro do aviso. A Ticto é a exceção: nela o prazo viaja junto com a venda, 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, o prazo é um fato que mora na central de ajuda e não chega ao seu sistema. A mensagem que avisa o cliente de que a garantia termina amanhã precisa carregar esse número de fora.
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.
Nenhum padrão pronto nomeia a venda inteira
A saída natural seria 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 navegador. Depois do pagamento, só sobra o reembolso |
| 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 |
O GA4 e a Meta são justamente os dois que a sua equipe de marketing já usa. Os dois nomeiam a entrada do cliente e param ali. Depois do pagamento, o GA4 só tem reembolso, e a renovação da Meta aparece como circunstância de outro evento.
O schema.org existe, é aberto e descreve a entrega do pedido; o pagamento fica fora desse escopo. Menos de mil domínios usam a lista dele. O CloudEvents, que é o envelope mais usado, entrega o nome do aviso a quem emite.
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. É por isso que os padrões de medição param antes desses três fatos.
A tabela neutra vai existir de um jeito ou de outro. Ou ela nasce escrita, antes da segunda integração, ou nasce espalhada em regras soltas, depois da terceira. Escrever o vocabulário de eventos da casa antes que cada ferramenta imponha o seu é a fundação que Sistema operacional nativo de IA descreve.
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 um checkout só, o dicionário da plataforma serve. Com dois, 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
A tabela abaixo aplica o teste dos dois eixos aos dez fatos mais comuns de uma operação de venda.
| 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 de fatos, versões e campos que desempatam, sobra decidir em que ponto começar a preenchê-la de verdade.
O critério, e o que fazer hoje
O critério é o número de checkouts que a mesma automação lê. Com um, anote a versão do aviso e siga. Com dois ou mais, escreva a tabela antes de ligar o segundo.
A tabela custa dez linhas por plataforma. A alternativa custa um e-mail de cartão recusado enviado a quem já paga, ou uma régua de contestação que nunca dispara porque o aviso não existe.
Comece hoje pela coluna do que não existe, porque é a única que nenhuma plataforma anuncia. Escrita assim, a tabela vira o contrato de eventos do seu negócio, e trocar de checkout deixa de exigir reescrever tudo.
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.
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, e basta anotar qual versão do aviso você assinou. A tabela vale a pena quando a mesma automação passa a ler dois checkouts, porque é aí que a tradução vira parte da regra.
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.