Postback idempotenti: perché a finance importa il doppio conteggio

I team finance non odiano i postback. Odiano i totali che non possono ricalcolare. Se lo stesso primo deposito può comparire due volte perché una richiesta è andata in timeout ed è stata rinviata, il mese non si chiude. Qualcuno passerà il venerdì pomeriggio con due CSV e un evidenziatore. I postback idempotenti sono il modo in cui quel venerdì viene cancellato.

Questo è un articolo sulle capacità. AFFILIFY conta una conversione una volta, anche quando l'operatore la manda più di una volta. Come riconosciamo il duplicato non è una checklist pubblica. Quello che Le serve sapere è la forma del problema, che cosa mettere sul filo, e che cosa dovrebbe fare il portafoglio dell'affiliato quando atterra un ritentativo.

Se vuole il quadro più largo sul tracking, postback contro pixel e image tag è il confronto. Questa è la fetta rivolta a finance dell'S2S.

Che cosa significa idempotente qui

Idempotente significa che può applicare lo stesso evento due volte e il risultato memorizzato non cambia. Mandi l'FTD #84102. Lo mandi di nuovo perché la coda non ha visto il 200. C'è ancora un FTD. C'è ancora una commissione. La seconda richiesta non è un errore e non è un secondo giocatore.

Il contrario è un contatore che incrementa a ogni richiesta HTTP. Quel contatore sarà d'accordo con il Suo log dei ritentativi. Non sarà d'accordo con il database giocatori dell'operatore, né con l'affiliato che ha mandato una persona sola.

I ritentativi non sono un bug. Le reti falliscono. I load balancer vanno in timeout. Un 200 si perde. Un'integrazione seria tratta «manda finché non c'è conferma» come il percorso felice, e questo è sicuro solo se il ricevente sa ingoiare il duplicato. Tutto il requisito di prodotto è qui.

Che cosa dovrebbero mandare gli operatori

Ha già un click id. Ha già un tipo di evento: registrazione, FTD, deposito, e qualunque altra cosa il deal richieda. Mandi un identificativo stabile per quell'evento così un ritentativo è lo stesso oggetto invece di uno nuovo. I nomi esatti dei campi stanno nella documentazione dei postback, non qui.

Tre regole salvano la chiusura del mese.

Ritenti lo stesso payload. Non incrementi un nonce, non conii un nuovo event id, non «sistemi» un timeout mandando FTD-2. Il secondo invio deve essere di nuovo il primo invio.

Non usi il successo HTTP come unico registro. Dal Suo lato dovrebbe registrare «intendevamo mandare l'FTD #84102» prima della richiesta, e «hanno confermato l'FTD #84102» dopo. Se registra solo la richiesta, un timeout sembra un buco e manderà un evento diverso per riempirlo.

L'NGR è un periodo, non un ping. Un evento deposito può essere idempotente per deposito. Una cifra NGR mensile è una dichiarazione su un intervallo di date. La mandi come dichiarazione su quell'intervallo, non come un flusso di incrementi minuscoli che spera si sommino. NGR e riporto negativo è la versione rivolta all'affiliato del perché quelle deduzioni devono essere stabili.

I pixel non sanno farlo bene. Un pixel che parte due volte nel browser è due partenze. Gli image tag allo stesso modo. L'S2S è il default nel 2026 perché è l'unico dei tre che un team finance sopporta di ricalcolare. È la pretesa di capacità in postback contro pixel.

Che cosa dovrebbero vedere gli affiliati

Un giocatore, un FTD, una riga CPA. Se apre la conversione dovrebbe vedere il brand, il clic, il GEO, i sub-id, il timestamp. Non dovrebbe vedere un gemello.

Se un deposito viene stornato in seguito, è un evento diverso, non un duplicato. Chargeback, abuso di bonus, un pagamento annullato: quelli arrivano come rettifiche, possono mettere i soldi in fermo, e possono tirare indietro una commissione in sospeso. Non sono ritentativi. Come funzionano i pagamenti copre in sospeso, disponibile, trattenuto e in revisione. I pagamenti stessi si contano una volta in uscita, per lo stesso motivo per cui i postback si contano una volta in ingresso.

Quando qualcosa sembra raddoppiato, non parta dal portafoglio. Parta dal link. Un click id rotto produce conversioni mancanti, non extra. Prima il QA del link di tracking. Poi guardi se due landing, due sub-id o due brand hanno creato due clic veri. Due clic veri da una persona possono essere due eventi. Non è un doppio conteggio. Sono due clic.

Perché questo è un argomento di vendita per gli operatori

Un programma affiliati che conta due volte pagherà troppo, poi stornerà, poi consumerà la relazione. Un programma affiliati che perde i ritentativi conterà troppo poco, poi discuterà, poi consumerà la relazione dall'altro lato. L'S2S idempotente è la terza opzione noiosa: lo mandi, lo mandi di nuovo se deve, il totale non si muove.

È anche il motivo per cui AFFILIFY può mostrare una conversione come riga invece che come secchio. La riga è l'evento. Un ritentativo lascia il totale dove stava.

Dal lato affiliato la stessa regola è il motivo per cui il 15 può chiudere. In sospeso diventa disponibile su un totale che non cambia perché una coda si è accodata alle 14:58. Il KYC resta il cancello del prelievo. Il livello conta i depositi qualificanti una volta. Niente di tutto questo funziona se l'FTD stesso è un lancio di moneta contro il log dei ritentativi.

Se sta cablando questo da operatore, parta dalla documentazione, usi il Suo parametro di clic, e tratti «manda finché non c'è conferma» come normale. Se è un affiliato, non dovrebbe mai doverci pensare, ed è questo il punto. Quando deve pensarci, a monte sta arrivando qualcosa che manda due eventi diversi e li chiama uno. È un bug di integrazione, non un ritentativo.