Postbacks idempotentes: por que o financeiro se importa com contagem dupla

Equipes financeiras não odeiam Postbacks. Odeiam totais que não conseguem reproduzir. Se o mesmo primeiro depósito pode aparecer duas vezes porque uma requisição deu timeout e foi enviada de novo, o mês não fecha. Alguém vai passar a sexta à tarde com duas planilhas CSV e um marca-texto. Postbacks idempotentes são o jeito de cancelar essa sexta.

Este é um texto de capacidade. A AFFILIFY conta uma conversão uma vez, mesmo quando o operador a envia mais de uma vez. Como reconhecemos a duplicata não é uma lista pública. O que você precisa saber é o formato do problema, o que colocar no fio, e o que a carteira do afiliado deve fazer quando uma retentativa aterrissa.

Se quiser o retrato mais amplo de rastreamento, Postbacks versus pixels versus image tags é a comparação. Este é o recorte de S2S voltado ao financeiro.

O que idempotente significa aqui

Idempotente significa que você pode aplicar o mesmo evento duas vezes e o resultado armazenado não muda. Mande o FTD #84102. Mande de novo porque a sua fila não viu o 200. Continua havendo um FTD. Continua havendo uma comissão. A segunda requisição não é um erro e não é um segundo jogador.

O oposto é um contador que incrementa a cada requisição HTTP. Esse contador vai concordar com o seu log de retentativas. Não vai concordar com o banco de jogadores do operador, nem com o afiliado que só mandou uma pessoa.

Retentativas não são bug. Redes falham. Load balancers dão timeout. Um 200 se perde. Uma integração séria trata «mandar até o reconhecimento» como o caminho feliz, o que só é seguro se o receptor consegue engolir a duplicata. Esse é o requisito inteiro de produto.

O que os operadores devem enviar

Você já tem um click id. Já tem um tipo de evento: cadastro, FTD, depósito, e o que mais o deal precisar. Envie um identificador estável para aquele evento, para que uma retentativa seja o mesmo objeto em vez de um novo. Os nomes exatos dos campos ficam na documentação de Postback, não aqui.

Três regras salvam o fechamento do mês.

Retente o mesmo payload. Não incremente um nonce, não invente um event id novo, não «conserte» um timeout mandando FTD-2. O segundo envio deve ser o primeiro de novo.

Não use o sucesso HTTP como único livro-razão. O seu lado deve registrar «pretendíamos enviar o FTD #84102» antes da requisição, e «eles reconheceram o FTD #84102» depois. Se você só registra a requisição, um timeout parece um buraco e você vai mandar um evento diferente para preenchê-lo.

NGR é um período, não um ping. Um evento de depósito pode ser idempotente por depósito. Um NGR mensal é uma afirmação sobre um intervalo de datas. Envie como uma afirmação sobre aquele intervalo, não como um fluxo de incrementos minúsculos que você espera que some. NGR e carryover negativo é a versão voltada ao afiliado de por que essas deduções precisam ser estáveis.

Pixels não fazem isso bem. Um pixel que dispara duas vezes no navegador são dois disparos. Image tags, o mesmo. S2S é o padrão em 2026 porque é o único dos três que uma equipe financeira aguenta reproduzir. Essa é a afirmação de capacidade em Postbacks versus pixels.

O que os afiliados deveriam ver

Um jogador, um FTD, uma linha de CPA. Se você abrir a conversão, deve ver a marca, o clique, o GEO, os sub-ids, o timestamp. Não deve ver um gêmeo.

Se um depósito é estornado depois, isso é outro evento, não uma duplicata. Chargebacks, abuso de bônus, um pagamento cancelado: esses chegam como ajustes, podem colocar dinheiro em retenção e podem puxar de volta uma comissão pendente. Não são retentativas. Como funcionam os pagamentos cobre pendente, disponível, retido e em análise. Os pagamentos em si são contados uma vez na saída, pelo mesmo motivo que os Postbacks são contados uma vez na entrada.

Quando alguma coisa parece dobrada, não comece na carteira. Comece no link. Um click id quebrado produz conversões faltando, não extras. Faça o QA do link de rastreamento primeiro. Depois veja se duas landings, dois sub-ids ou duas marcas criaram dois cliques reais. Dois cliques reais de uma pessoa podem ser dois eventos. Isso não é contagem dupla. São dois cliques.

Por que isso é um argumento de venda para operadores

Um programa de afiliados que conta em dobro vai pagar a mais, depois fazer clawback, depois gastar o relacionamento. Um programa de afiliados que perde retentativas vai contar a menos, depois discutir, depois gastar o relacionamento do outro lado. S2S idempotente é a terceira opção chata: mande, mande de novo se precisar, o total não se mexe.

Também é por isso que a AFFILIFY consegue mostrar uma conversão como uma linha, e não como um balde. A linha é o evento. Uma retentativa deixa o total onde estava.

Do lado do afiliado a mesma regra é o motivo de o dia 15 poder fechar. Pendente vira disponível num total que não muda porque uma fila alcançou às 14:58. O KYC continua travando o saque. O nível continua contando depósitos qualificatórios uma vez. Nada disso funciona se o próprio FTD é cara ou coroa contra o log de retentativas.

Se você está ligando isso como operador, comece pela documentação, use o seu próprio parâmetro de clique, e trate «mandar até o reconhecimento» como normal. Se você é afiliado, nunca deveria ter que pensar nisso, que é o ponto. Quando tiver que pensar, alguma coisa a montante está mandando dois eventos diferentes e chamando-os de um. Isso é bug de integração, não retentativa.