Postbacks idempotents : pourquoi la finance se soucie du double comptage

Les équipes finance ne détestent pas les postbacks. Elles détestent les totaux qu'elles ne peuvent pas rejouer. Si le même premier dépôt peut apparaître deux fois parce qu'une requête a expiré et a été renvoyée, le mois ne peut pas clôturer. Quelqu'un passera le vendredi après-midi avec deux CSV et un surligneur. Les postbacks idempotents, c'est comme ça qu'on annule ce vendredi.

Ceci est un article de capacité. AFFILIFY compte une conversion une fois, même quand l'opérateur l'envoie plus d'une fois. Comment nous reconnaissons le doublon n'est pas une liste publique. Ce qu'il vous faut savoir, c'est la forme du problème, quoi mettre sur le fil, et ce que le portefeuille affilié est censé faire quand une reprise atterrit.

Si vous voulez le tableau tracking plus large, postbacks, pixels et tags image est la comparaison. Ceci est la tranche S2S tournée vers la finance.

Ce que idempotent veut dire ici

Idempotent veut dire que vous pouvez appliquer le même événement deux fois et que le résultat stocké ne change pas. Envoyez le FTD n°84102. Renvoyez-le parce que votre file n'a pas vu le 200. Il y a toujours un FTD. Il y a toujours une commission. La deuxième requête n'est pas une erreur et ce n'est pas un deuxième joueur.

Le contraire, c'est un compteur qui s'incrémente à chaque requête HTTP. Ce compteur sera d'accord avec votre journal de reprises. Il ne le sera pas avec la base joueurs de l'opérateur, ni avec l'affilié qui n'a envoyé qu'une personne.

Les reprises ne sont pas un bug. Les réseaux tombent. Les load balancers expirent. Un 200 se perd. Une intégration sérieuse traite « envoyer jusqu'à accusé de réception » comme le chemin heureux, ce qui n'est sûr que si le récepteur peut avaler le doublon. C'est toute l'exigence produit.

Ce que les opérateurs doivent envoyer

Vous avez déjà un identifiant de clic. Vous avez déjà un type d'événement : inscription, FTD, dépôt, et tout ce dont le deal a besoin. Envoyez un identifiant stable pour cet événement, pour qu'une reprise soit le même objet plutôt qu'un nouveau. Les noms de champs exacts vivent dans les docs postback, pas ici.

Trois règles sauvent la clôture de mois.

Relancez le même payload. N'incrémentez pas un nonce, ne frappez pas un nouvel identifiant d'événement, ne « réparez » pas un timeout en envoyant FTD-2. Le deuxième envoi doit être le premier envoi, encore.

Ne prenez pas le succès HTTP pour seul grand livre. Votre côté doit enregistrer « nous avions l'intention d'envoyer le FTD n°84102 » avant la requête, et « ils ont accusé réception du FTD n°84102 » après. Si vous n'enregistrez que la requête, un timeout ressemble à un trou et vous enverrez un autre événement pour le remplir.

Le NGR est une période, pas un ping. Un événement dépôt peut être idempotent par dépôt. Un chiffre NGR mensuel est une affirmation sur une plage de dates. Envoyez-le comme une affirmation sur cette plage, pas comme un flux de petits incréments que vous espérez voir s'additionner. NGR et report négatif est la version côté affilié de pourquoi ces déductions doivent être stables.

Les pixels ne font pas ça bien. Un pixel qui se déclenche deux fois dans le navigateur, c'est deux déclenchements. Les tags image, pareil. Le S2S est le défaut en 2026 parce que c'est le seul des trois qu'une équipe finance accepte de rejouer. C'est l'affirmation de capacité dans postbacks contre pixels.

Ce que les affiliés doivent voir

Un joueur, un FTD, une ligne CPA. Si vous ouvrez la conversion vous devez voir la marque, le clic, le GEO, les sub-ids, l'horodatage. Vous ne devez pas voir un jumeau.

Si un dépôt est ensuite annulé, c'est un autre événement, pas un doublon. Chargebacks, abus de bonus, un paiement annulé : ça atterrit comme des ajustements, ça peut mettre de l'argent en suspens, et ça peut ramener une commission en attente. Ce ne sont pas des reprises. Comment fonctionnent les paiements couvre l'en attente, le disponible, l'en suspens et l'en cours d'examen. Les paiements eux-mêmes sont comptés une fois à la sortie, pour la même raison que les postbacks sont comptés une fois à l'entrée.

Quand quelque chose a l'air doublé, ne commencez pas dans le portefeuille. Commencez au lien. Un identifiant de clic cassé produit des conversions manquantes, pas des extras. Faites la recette du lien de tracking d'abord. Puis regardez si deux landings, deux sub-ids ou deux marques ont créé deux vrais clics. Deux vrais clics d'une personne peuvent être deux événements. Ce n'est pas un double comptage. C'est deux clics.

Pourquoi c'est un argument de vente pour les opérateurs

Un programme d'affiliation qui compte en double surpaiera, puis clawback, puis usera la relation. Un programme d'affiliation qui jette les reprises sous-comptera, puis se disputera, puis usera la relation dans l'autre sens. Le S2S idempotent est la troisième option ennuyeuse : envoyez, renvoyez s'il le faut, le total ne bouge pas.

C'est aussi pourquoi AFFILIFY peut afficher une conversion comme une ligne plutôt que comme un seau. La ligne est l'événement. Une reprise laisse le total où il était.

Côté affilié, la même règle est la raison pour laquelle le 15 peut clôturer. L'en attente devient disponible sur un total qui ne change pas parce qu'une file a rattrapé à 14 h 58. Le KYC reste la porte du retrait. Le niveau compte toujours les dépôts qualifiants une fois. Rien de tout ça ne marche si le FTD lui-même est un pile ou face contre le journal de reprises.

Si vous câblez ça en opérateur, partez des docs, utilisez votre propre paramètre de clic, et traitez « envoyer jusqu'à accusé de réception » comme normal. Si vous êtes affilié, vous ne devriez jamais avoir à y penser, c'est tout l'intérêt. Quand vous devez y penser, quelque chose en amont envoie deux événements différents et les appelle un. C'est un bug d'intégration, pas une reprise.