O fluxo de pagamento de uma oferta: do clique no botão à liberação do acesso

Quem olha de fora acha que pagamento é só um botão e uma tela de obrigado. Na prática, entre o clique e o cliente usando o produto existe um fluxo inteiro, e cada etapa mal resolvida vira venda perdida, suporte lotado ou acesso liberado sem pagamento.

As etapas

1. Clique no botão de compra. Os parâmetros de origem (UTMs, fbclid) precisam ir junto.
2. Checkout. Dados do cliente, forma de pagamento, order bump.
3. Criação do pedido. O pedido existe, mas ainda não está pago.
4. Pagamento. Cartão é aprovado ou recusado na hora. Pix e boleto ficam pendentes.
5. Confirmação. O gateway avisa o seu sistema que o pagamento foi aprovado, quase sempre por webhook.
6. Entrega. Acesso liberado, e-mail enviado, área de membros, nota fiscal.
7. Pós-venda. Upsell, reembolso, chargeback, renovação de assinatura.

O erro mais comum: confiar na página de obrigado

Muita oferta libera o acesso, dispara o evento de compra ou envia o e-mail de boas-vindas quando o cliente chega à página de obrigado. Isso quebra de dois jeitos:

• quem não chega à página (fechou a aba, pagou o Pix pelo celular e não voltou) fica sem acesso, mesmo tendo pago;
• quem chega sem pagar (gerou o Pix e não pagou, ou o cartão foi recusado e redirecionou) recebe acesso de graça.

A página de obrigado serve para orientar o cliente. Quem decide se a venda existe é a confirmação do gateway.

Onde entra o webhook

O webhook é a mensagem que o gateway manda para o seu servidor quando algo acontece com o pedido: aprovado, recusado, reembolsado, chargeback. É a partir dele que você:

• libera ou bloqueia o acesso;
• envia a compra para a API de Conversões do Meta e para o Google;
• atualiza o CRM e a planilha de vendas;
• dispara e-mails e mensagens.

Eu detalho isso em Webhooks de pagamento: onde entram no fluxo.

Pix e boleto pedem atenção especial

Com cartão, a resposta vem em segundos. Com Pix, pode levar minutos. Com boleto, dias. O fluxo precisa:

• mostrar ao cliente que o pagamento está pendente, com o QR Code ou o boleto à mão;
• liberar o acesso automaticamente assim que o pagamento cair, sem depender de alguém;
• tentar recuperar quem gerou e não pagou. Veja Recuperação de vendas.

O que deixa o fluxo de pagamento confiável

• Uma fonte da verdade: o status do pedido vem do gateway, não da tela.
• Processamento idempotente: se o mesmo webhook chegar duas vezes, o acesso não é liberado duas vezes. Veja Como receber webhooks com segurança.
• Registro de tudo: cada evento recebido fica salvo, para você conseguir explicar qualquer pedido.
• Monitoramento: se os webhooks param de chegar, alguém precisa saber na hora, e não quando o suporte encher.

Um fluxo de pagamento bem feito é invisível para o cliente: ele paga e recebe. É exatamente isso que você quer.