1
Identidade e tempo
idEvento identifica cada evento; referencia liga o ciclo da compra. Ambos são isolados por empresa. O horário real do pagamento permite conferir a ordem dos fatos.
Recuperação quente · E-commerce e infoprodutos · WhatsApp, e-mail e SMS
O que seu checkout precisa enviar para recuperar uma venda?
Eventos de carrinhos abandonados e pagamentos recentes pendentes, um caminho seguro para retomar a compra e consentimento comprovável. A Revenue opera a recuperação; a implantação é conduzida com o responsável técnico do checkout ou gateway.
Do checkout ao desfecho
Cinco eventos contam a história da compra.
O responsável técnico mapeia os estados da plataforma para este contrato.
Carrinho abandonado — carrinho_abandonado
Checkout iniciado, contato capturado e compra não concluída. O evento registra a oportunidade com link de retomada; o envio depende da elegibilidade e das regras do piloto.
Pagamento pendente — pagamento_pendente
Pedido ou pagamento criado e ainda não pago, com caminho válido para concluir a compra. Uma falha recente só entra após mapear o estado do fornecedor e confirmar que a compra continua retomável.
Pagamento confirmado — paga
Informa o horário real do pagamento em ocorridaEm e encerra a cadência. Para contar como recuperada, a mensagem precisa ter sido enviada antes do pagamento, dentro da janela, com valor verificado.
Pagamento vencido — expirada
Bloqueia novos envios e encaminha a exceção para revisão humana. Não gera nem envia automaticamente outro link de pagamento.
Estorno ou chargeback — estornada
Encerra a referência e retira a venda do total recuperado. Pagamento atrasado não reabre a recuperação.
Quatro conjuntos de dados para avaliar o fluxo.
2
Checkout retomável
checkoutUrl deve ser HTTPS, público, seguro e abrir a compra correta. Exige porta 443, sem credenciais na URL ou destinos locais/privados. Os domínios exatos precisam de aprovação por empresa antes do piloto.
3
Contato autorizado
Telefone não equivale a consentimento. É necessária prova com origem, data, base legal e finalidade de recuperação transacional. Sem prova válida, o evento pode ser registrado, mas o envio fica bloqueado.
4
Contexto e valor
Produto, oferta, valor informado, meio de pagamento e expiração ajudam a retomar a compra. O valor informado precisa ser confrontado com uma fonte financeira autorizada antes de entrar no relatório.
A Revenue assume a operação. A conexão tem responsáveis.
Cliente e responsável técnico
Identificam as fontes de abandono e pagamento, mapeiam os eventos, preservam a referência estável e fornecem checkout e prova de consentimento. Credenciais ficam no backend do integrador, nunca no navegador.
Operação da Revenue
Conduz a implantação, valida os domínios e opera o agente. No modo assistido, mensagens normais elegíveis saem automaticamente; risco, falta de consentimento, desconto excepcional ou erro seguem para tratamento humano.
Homologação conjunta
Em sandbox ou staging autorizado, confere retomada, opt-out, replay, eventos fora de ordem, pagamento e estorno. A autorização final do piloto continua dependente das evidências técnicas e dos termos comerciais.
O que precisa ser comprovado antes de conectar?
Como os eventos são autenticados?
A API exige token por empresa e assinatura HMAC-SHA256 do corpo exato, com timestamp recente. Isso autentica a origem e a integridade do evento; HMAC não comprova o valor liquidado. Segredos não devem ser enviados em formulários de avaliação.
E se a conexão cair ou o evento chegar duas vezes?
A API persiste o evento em uma inbox durável antes de responder 202. Esse aceite não significa mensagem enviada ou compra recuperada. Repetir idEvento com o mesmo payload é idempotente; reutilizar o ID com conteúdo diferente retorna conflito 409. Falhas definitivas vão para a fila de falhas (DLQ), com reprocessamento auditado após corrigir a causa.
Um carrinho atrasado pode reabrir uma compra paga?
Não. Eventos fora de ordem não devem regredir o estado nem duplicar efeitos. Um carrinho atrasado não rebaixa uma pendência de pagamento; eventos quentes não reabrem uma referência terminal. Esses cenários precisam ser ensaiados com as fontes do parceiro.
Ter um link HTTPS basta?
Não. A validação de entrada não acessa o link nem resolve DNS. A homologação deve comprovar que o domínio aprovado não leva a um destino privado e que o checkout retoma o pedido correto. Pagamento vencido exige o fluxo aprovado de tratamento humano.
Todo pagamento recebido conta como venda recuperada?
Não. A atribuição operacional exige prova de envio anterior e janela válida: 7 dias para carrinho abandonado e 72 horas para pagamento pendente, por padrão. Compra sem toque elegível é orgânica e não conta como recuperada; envio incerto aguarda reconciliação. O valor também precisa ser verificado. Atribuição não prova causalidade.
Basta colar uma URL no webhook do gateway?
Não necessariamente. A API canônica exige mapeamento e autenticação próprios; o payload nativo de cada fornecedor precisa ser avaliado. Importadores de contatos não substituem eventos quentes nem comprovam integração nativa.
Quais canais e condições entram no piloto?
A recuperação sai por WhatsApp, e-mail e SMS. Os planos começam em R$ 197/mês. A cobrança é só pelo plano mensal, sem comissão sobre as vendas; SLA e demais condições ficam no contrato.
Seu checkout fornece os eventos e as provas?
Comece pela plataforma usada e pelo fluxo de abandono e pagamento. O mapeamento do payload será avaliado em sandbox ou staging autorizado, sem enviar dados reais ou credenciais no formulário.
Solicitar avaliação do fluxo