Trocar de checkout sem perder a relação com o cliente

O aluno chega do outro lado sem passado

A troca de checkout é planejada como troca de fornecedor de cobrança. Exporta-se a base num arquivo, importa-se do outro lado, redireciona-se o link de venda e avisa-se a lista. A operação que nasce do outro lado tem os mesmos nomes e os mesmos e-mails. O que ela perde é o registro que fazia daquele nome um comprador.

A Hotmart descreve essa perda no artigo em que ensina a importar alunos por arquivo. O usuário que entra por importação existe na área de membros e não existe no relatório de vendas. Ele recebe o conteúdo, e a operação nova não consegue dizer quanto ele já pagou, quando, por qual oferta, nem se pediu reembolso alguma vez.

A consequência aparece no primeiro relatório do mês seguinte. Quem separava clientes por faixa de gasto, por recência de compra ou por número de produtos comprados perde os três critérios de uma vez, e a segmentação da automação passa a operar sobre uma lista plana. A régua de pós-venda dispara para quem já comprou de novo, e a oferta de entrada chega a quem tem quatro anos de casa.

Nenhuma das duas importações cria cobrança. Elas entram e-mail e liberam conteúdo, e por isso o assinante importado precisa comprar de novo para voltar a pagar. Essa recompra é a parte mais cara da virada.

Assinatura ativa não migra: o cliente recontrata

A cobrança recorrente já contratada não continua rodando na plataforma nova. Ela termina onde nasceu, e cada assinante precisa digitar o cartão outra vez, em checkout novo, para voltar a pagar. A Pagar.me explica o mecanismo com precisão: "Cada carteira é exclusiva de um lojista (Account). Desta forma, um lojista não tem acesso à carteira de outro mesmo que estejam dentro de um mesmo cliente (Merchant) no Pagar.me." O cartão não trafega nem entre duas contas da mesma empresa.

As demais confirmam o modelo pelo caminho que oferecem para trocar o meio de pagamento. Na Greenn, o produtor gera um link de checkout novo e o envia ao cliente, que executa a troca. A API da Eduzz cancela assinatura em massa e dispara o e-mail que pede o cartão ao cliente. Criar assinatura ela não faz. A plataforma não move o token: ela convoca o titular.

O efeito financeiro dessa etapa é imediato e assimétrico. A base de assinantes sai do relatório de receita recorrente no dia do corte e volta no ritmo da captação, com o custo de aquisição vigente aplicado a clientes que já eram seus no mês anterior. É esse valor que decide se a virada compensa, com peso maior que o da mensalidade da plataforma.

A norma do cartão não é o obstáculo

A explicação corrente para a assinatura não migrar é a norma do setor de cartões: dado de cartão é regulado, tokenizado, intransferível. A Stripe publica o procedimento de saída do cartão do cliente para outro processador, com requisitos nomeados e conferíveis, e abre a página com uma declaração de posição: "We believe our customers own the sensitive data they entrust to Stripe."

1. O processador que vai receber precisa ter certificação PCI DSS Level 1, e a Stripe declara que só transfere para quem a tem.
2. Ele apresenta o Attestation of Compliance vigente, ou comprova listagem no Visa Global Registry of Service Providers.
3. Ele publica uma chave pública PGP de 4096 bits ou mais, servida por HTTPS em domínio referenciado no próprio atestado ou na listagem da Visa.
4. A Stripe prepara um arquivo JSON criptografado com os dados do cartão, os endereços de e-mail e os metadados anexados.
5. As credenciais salvas via Link ficam de fora, e a exclusão está declarada na mesma página.

Certificação de nível 1, atestado de conformidade e chave pública de 4096 bits são requisitos que qualquer adquirente ou instituição de pagamento brasileira pode cumprir ou exigir. O que separa a Stripe das sete plataformas verificadas é ter um procedimento escrito, com contraparte nomeada e critério de aceitação. O obstáculo à portabilidade da recorrência está no que se publica. A norma do cartão já tem caminho aberto.

A frase que interessa ao cronograma está na mesma página: "Esse processo permite aceitar e cobrar novos clientes na Stripe e continuar cobrando os clientes atuais com o processador atual até que a migração seja concluída. Seus clientes não incorrem em nenhum tempo de inatividade." Mesmo sem transferência de credencial, a arquitetura de dois checkouts em paralelo é reproduzível em qualquer plataforma, e resolve de saída a janela de risco que o corte seco abre.

Cinco eventos, sete vocabulários diferentes

A integração entre checkout e automação se apoia em cinco eventos: compra aprovada, reembolso, chargeback, assinatura cancelada e carrinho abandonado. Trocar de checkout sem reconstruir a automação depende de os cinco existirem dos dois lados, com nome próprio e payload estável. Esse vocabulário mínimo não é universal.

A leitura por linha mostra quatro plataformas cobrindo os cinco eventos. A leitura por coluna mostra onde a reconstrução acontece. Chargeback tem evento próprio em quatro das sete, e a Nuvemshop deixa de fora reembolso, chargeback e carrinho abandonado de uma vez, com o carrinho acessível apenas por consulta periódica ao recurso de checkout abandonado.

Deduplicação separa quem publica de quem cala

Endpoint que recebe o mesmo evento duas vezes dispara a mesma automação duas vezes. O cliente recebe o e-mail em duplicata, a etiqueta é aplicada de novo, o contador de vendas sobe sozinho. Evitar isso depende de duas coisas publicadas pelo emissor: uma chave estável que identifique o disparo e uma política de retentativa que diga quantas vezes ele volta.

A assimetria é o achado da tabela. Publicar política de entrega é escolha editorial do fornecedor, e o contraexemplo está na mesma coluna: a Nuvemshop publica tempo de espera, curva de retentativa, teto de tentativas, janela total, cabeçalho de assinatura e a advertência de que a ordem não é garantida. A Greenn não publica nem a chave.

Ter a chave também não basta, e a Monetizze mostra por quê. Ela declara a semântica de entrega repetida, nomeia o campo certo e garante que o reenvio traz o mesmo identificador, e ainda assim não diz quantas vezes reenvia nem por quanto tempo. Sem esse prazo, quem recebe não sabe por quanto tempo precisa lembrar de um disparo já processado, e acaba guardando o histórico inteiro para sempre.

O tempo que cada emissor espera pela confirmação define quanto trabalho cabe dentro do tratador. Três segundos exigem responder antes de processar, com fila própria do lado de quem recebe. Quarenta segundos toleram um processamento síncrono simples. Migrar entre plataformas com esperas diferentes obriga a reescrever essa parte, além de remapear nomes de campo.

O modo de falha mais duro na virada está na Eduzz. Três erros seguidos colocam a configuração em modo de backup, com tentativas a cada minuto por dois dias, e ao fim desse prazo, na frase da própria documentação, "a mesma será inativada e os eventos em backup serão apagados". Endpoint novo que sobe torto durante a migração não deixa fila para reprocessar depois.

A ponte entre contato e comprador quase sempre é o e-mail

Ligar o contato que está na automação ao comprador que está no checkout exige um campo comum aos dois lados. Documento e telefone seriam candidatos melhores que o e-mail, porque mudam menos ao longo da vida do cliente. A documentação das sete plataformas mostra por que raramente é assim que funciona.

Duas das sete publicam um campo para o identificador do seu próprio sistema, o que permite carimbar cada pedido com a chave que a sua base já usa. Nas outras cinco, a ponte entre o contato e o comprador é o e-mail, ou não existe. E o e-mail é justamente o campo que o cliente troca ao mudar de emprego, de provedor ou de celular.

A Hotmart explicita a condição que agrava o problema. O objeto do comprador só chega ao webhook com o que foi pedido na página de pagamento, e quem pede menos campo converte mais. Quem enxugou o checkout para ganhar conversão migra, anos depois, com uma base que tem só e-mail.

A decisão que sai daqui vale mesmo sem virada nenhuma. Se a plataforma publica campo de identificador externo, use-o desde a primeira venda, com a chave que a sua base já adota. Se não publica, colete documento no checkout e trate a queda de conversão como prêmio de seguro, porque documento é o único campo de identidade que sobrevive à troca de e-mail.

A parcela tem a cauda mais longa da virada

Desligar o checkout velho é um ato de calendário, e o calendário não é o da migração de conteúdo. Depois do corte, continuam chegando pedidos de reembolso, contestações de bandeira e parcelas de compras antigas. Cada um desses eventos tem prazo próprio, e o mais longo deles passa de um ano e meio.

O prazo que mais engana é o do meio da lista. A Hotmart guarda o histórico de eventos de webhook por até 60 dias, e a disputa de transação recorrente tem 120 dias nas regras de Visa e de Mastercard. Quando a contestação chega, o evento que sustentaria a defesa já saiu da ferramenta que o emitiu.

A parcela, porém, tem a cauda mais longa de todas. Cancelar assinatura em massa para migrar não zera a cobrança do checkout velho quando o plano anual foi parcelado no cartão. As duas plataformas que publicam a regra dizem a mesma coisa, e o cliente vê duas cobranças no mesmo mês: a parcela antiga e a assinatura nova.

Na Pagar.me há um agravante para quem opera assinatura. O chargeback em cobrança de assinatura cancela a assinatura de forma automática, e "será necessário criar uma nova assinatura utilizando um novo cartão". O mesmo documento avisa que o chargeback muda o status da cobrança e não o do pedido, o que deixa cego quem reconcilia pelo pedido.

O que decidir antes de desligar o checkout velho

A decisão de virada depende de duas variáveis, e nenhuma delas é a mensalidade. A primeira é quanto da receita vem de assinatura ativa, porque é essa parte que precisa ser recontratada uma a uma. A segunda é quanto a plataforma de origem publica sobre entrega repetida, porque é isso que determina se a fila de eventos da transição pode ser reprocessada.

Os quatro quadrantes têm o mesmo primeiro passo, e ele não depende de plataforma. A base de eventos precisa morar em casa antes da virada, porque a documentação de webhook descreve notificação, e o armazenamento fica com quem recebe. A Hotmart escreve isso na própria página de boas práticas.

1. Guarde cada evento recebido num banco seu, com o identificador de disparo, o carimbo de tempo e o corpo completo. A Hotmart declara que "um sistema de Webhook não tem como objetivo servir de base de dados, consulta ou alteração de dados".
2. Exporte a base do checkout velho antes de qualquer aviso ao mercado, e confira coluna a coluna quais campos de identidade vieram preenchidos de verdade.
3. Confirme com a plataforma de destino se existe campo para o seu identificador externo, e passe a carimbá-lo em toda venda nova.
4. Mapeie os cinco eventos mínimos nos dois vocabulários, com a grafia copiada da referência de API, e teste chargeback e reembolso separadamente.
5. Escreva o consumidor idempotente antes de ligar o endpoint, e derive a chave do pedido quando a plataforma não publicar identificador de disparo.
6. Ligue o checkout novo para cliente novo e mantenha a recorrência antiga onde ela nasceu, na arquitetura de coexistência que a Stripe publica.
7. Combine com o atendimento a resposta para a fatura com parcela antiga e assinatura nova no mesmo mês, antes que a primeira ligação chegue.
8. Marque o desligamento da conta antiga pelo maior prazo aplicável ao seu meio de pagamento. O fim da migração de conteúdo chega cedo demais para servir de data.

O critério que resume tudo cabe numa frase de negociação. Antes de assinar a plataforma nova, peça o procedimento de saída dela, com prazo e escopo. Quem responde com um procedimento nomeado está vendendo um custo de troca conhecido, e quem responde que o assunto é tratado caso a caso está vendendo um custo de troca que só aparece no dia em que você quiser sair.

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. Hotmart, Central de Ajuda, "Como importar alunos para minha área de membros ou curso online?", com a exigência de nome e e-mail no arquivo e a declaração de que o usuário importado não aparece no relatório de vendas por não ter transação atrelada. Consulta em 23 de agosto de 2026.
2. Hotmart, Central de Ajuda, "Como funciona o relatório de vendas?", com as colunas de nome, e-mail, telefone e documento do comprador e os formatos CSV e XLS de exportação. Consulta em 23 de agosto de 2026.
3. Hotmart Developers, "Eventos de pedido" na versão 2.0.0 do webhook, com os nomes literais dos eventos, o campo de identificação única do evento e a advertência de que os dados do comprador dependem do que o produtor pediu na página de pagamento. Consulta em 23 de agosto de 2026.
4. Hotmart Developers, "Sobre Webhooks", com o histórico de eventos armazenado por até 60 dias. Consulta em 23 de agosto de 2026.
5. Hotmart Developers, tutorial de boas práticas de uso de Webhooks e APIs, com a declaração de que um sistema de webhook não tem como objetivo servir de base de dados. Consulta em 23 de agosto de 2026.
6. Hotmart, Central de Ajuda, "Como cancelar minha assinatura?", com a regra de que as parcelas restantes do ano atual continuam sendo cobradas na fatura até terminar o pagamento. Consulta em 23 de agosto de 2026.
7. Hotmart, Central de Ajuda, "Como ajustar o prazo de garantia do produto que criei?", com as opções de 7, 15, 21 e 30 dias e a regra de que em assinatura o prazo vale só para a primeira cobrança. Consulta em 23 de agosto de 2026.
8. Kiwify, Central de Ajuda, "Até quanto tempo depois da venda posso fazer um reembolso?", com os 7 dias corridos do art. 49 do Código de Defesa do Consumidor e os tetos de reembolso manual de 300 dias no cartão e 90 dias em boleto e Pix. Consulta em 23 de agosto de 2026.
9. Kiwify, Central de Ajuda, "Como adicionar ou remover alunos manualmente?", com o limite de 100 e-mails por importação em massa e o processo declarado em até dez minutos. Consulta em 23 de agosto de 2026.
10. Kiwify, documentação da API pública, endpoint de consulta de venda, com o objeto de cliente que traz e-mail, celular e o documento alternando entre os campos de CPF e de CNPJ. Consulta em 23 de agosto de 2026.
11. Eduzz Developers, Webhook, seção "Backup de eventos", com os três erros seguidos, a retentativa a cada 1 minuto por 2 dias e a inativação da configuração com apagamento dos eventos em backup. Consulta em 23 de agosto de 2026.
12. Eduzz, especificação OpenAPI pública, com o cancelamento em massa de assinaturas, a reativação e o envio de e-mail de troca de cartão, e sem rota de criação de assinatura. Consulta em 23 de agosto de 2026.
13. Eduzz, Central de Ajuda, "Como suspender ou cancelar a assinatura de um cliente?", com o exemplo do plano anual de R$ 1.200 em 12 parcelas de R$ 100 e a regra de que o cancelamento não interrompe as parcelas da compra anual vigente. Consulta em 23 de agosto de 2026.
14. Monetizze, documentação oficial de webhooks, com a declaração de que a plataforma não garante disparo único por evento, o campo de identificação exclusivo de cada disparo e a advertência de que a chave única identifica a conta e não serve para deduplicar. Consulta em 23 de agosto de 2026.
15. Monetizze, Central de Ajuda, "Como migrar meu curso, produto e alunos para a nova Membertizze", com o limite de 200 alunos por arquivo e a ressalva de que o tutorial não vale para produtos de recorrência. Consulta em 23 de agosto de 2026.
16. Monetizze, Central de Ajuda, "Relatório de vendas na Monetizze", com o status "Devolvida" reunindo estorno autorizado pelo produtor e chargeback. Consulta em 23 de agosto de 2026.
17. Greenn, Central de Ajuda, "Atualizando o Cartão do Cliente em uma Assinatura", com a instrução de enviar um novo link de checkout ao cliente para que ele mesmo faça a alteração. Consulta em 23 de agosto de 2026.
18. Greenn, API pública v1, webhook de checkout abandonado, com e-mail, CPF e telefone do lead declarados como campos anuláveis e a etapa do checkout em que o abandono ocorreu. Consulta em 23 de agosto de 2026.
19. Pagar.me, Guides, "Carteira de Cartões", com a declaração de que cada carteira é exclusiva de um lojista e de que um lojista não acessa a carteira de outro nem dentro do mesmo cliente. Consulta em 23 de agosto de 2026.
20. Pagar.me, "Chargeback: novo status na cobrança", com o cancelamento automático da assinatura, a exigência de criar assinatura nova com cartão novo e a advertência de que o status muda na cobrança e não no pedido. Consulta em 23 de agosto de 2026.
21. Nuvemshop, documentação de API, recurso Webhook na versão 2025-03, com o tempo de espera de 3 segundos, as quatro primeiras retentativas, o fator de 1,4 dentro de 48 horas, o teto de 16 tentativas e o cabeçalho de assinatura HMAC-SHA256. Consulta em 23 de agosto de 2026.
22. Nuvemshop, Central de Atendimento, "Como exportar minha lista de clientes na Nuvemshop?", com os campos do arquivo CSV e a ressalva de que CPF, CNPJ e telefone só vêm preenchidos quando houve compra finalizada. Consulta em 23 de agosto de 2026.
23. Nuvemshop, Central de Atendimento, artigo sobre anonimizar dados pessoais do cliente segundo a LGPD, com a espera de até 185 dias após a data da venda justificada pela possibilidade de reembolso. Consulta em 23 de agosto de 2026.
24. Nuvemshop, documentação de API, recurso Abandoned Checkout, com a consulta limitada a 30 dias, o apagamento definitivo aos 90 dias e o registro criado só a partir da segunda etapa do checkout. Consulta em 23 de agosto de 2026.
25. Stripe, documentação oficial, "Request a payment data export", com a exigência de PCI DSS Level 1 no processador receptor, o Attestation of Compliance ou a listagem no Visa Global Registry of Service Providers e a chave pública PGP de 4096 bits ou mais. Consulta em 23 de agosto de 2026.
26. Stripe, documentação oficial, "Solicite uma importação de dados de pagamentos", com a arquitetura de cobrar clientes novos na plataforma nova e manter os atuais no processador antigo até a migração terminar, sem tempo de inatividade para o cliente. Consulta em 23 de agosto de 2026.
27. Mercado Pago Developers, documentação de Webhooks, com o tempo de espera de 22 segundos pela confirmação e o reenvio a cada 15 minutos até receber resposta. Consulta em 23 de agosto de 2026.
28. Visa, "Visa Core Rules and Visa Product and Service Rules", edição de 18 de abril de 2026, com o prazo de 120 dias corridos para a disputa de transação recorrente cancelada, na condição 13.2. Consulta em 23 de agosto de 2026.
29. Mastercard, "Chargeback Guide, Merchant Edition", edição de 19 de maio de 2026, com os 120 dias corridos para contestação de transação recorrente contados da data de liquidação e os tetos maiores em motivos específicos. Consulta em 23 de agosto de 2026.
30. Brasil, Lei nº 8.078, de 11 de setembro de 1990, Código de Defesa do Consumidor, art. 49, com o prazo de 7 dias para desistir de contrato fechado fora do estabelecimento comercial. Consulta em 23 de agosto de 2026.
31. Portal Leadlovers 2026, artigo "O checkout conhece a compra, a automação conhece o cliente". Consulta em 23 de agosto de 2026.