Idempotent Postbacks: Why Finance Teams Care About Double Counting
A postback that is safe to retry is the difference between a number finance will sign and a number finance will argue about. What idempotent means, why operators send the same event more than once, and what affiliates should see in the wallet when they do.
Finance teams do not hate postbacks. They hate totals they cannot replay. If the same first-time deposit can appear twice because a request timed out and was sent again, the month cannot close. Someone will spend Friday afternoon with two CSVs and a highlighter. Idempotent postbacks are how that Friday gets cancelled.
This is a capability post. AFFILIFY counts a conversion once, even when the operator sends it more than once. How we recognise the duplicate is not a public checklist. What you need to know is the shape of the problem, what to put on the wire, and what the affiliate wallet is supposed to do when a retry lands.
If you want the wider tracking picture, postbacks versus pixels versus image tags is the comparison. This is the finance-facing slice of S2S.
What idempotent means here
Idempotent means you can apply the same event twice and the stored result does not change. Send FTD #84102. Send it again because your queue did not see the 200. There is still one FTD. There is still one commission. The second request is not an error and it is not a second player.
The opposite is a counter that increments on every HTTP request. That counter will agree with your retry log. It will not agree with the operator's player database, or with the affiliate who only sent one person.
Retries are not a bug. Networks fail. Load balancers time out. A 200 is lost. A serious integration treats "send until acknowledged" as the happy path, which is only safe if the receiver can swallow the duplicate. That is the whole product requirement.
What operators should send
You already have a click id. You already have an event type: registration, FTD, deposit, and whatever else the deal needs. Send a stable identifier for that event so a retry is the same object rather than a new one. The exact field names live in the postback docs, not here.
Three rules save the month-end.
Retry the same payload. Do not increment a nonce, do not mint a new event id, do not "fix" a timeout by sending FTD-2. The second send should be the first send again.
Do not use HTTP success as the only ledger. Your side should record "we intended to send FTD #84102" before the request, and "they acknowledged FTD #84102" after. If you only record the request, a timeout looks like a hole and you will send a different event to fill it.
NGR is a period, not a ping. A deposit event can be idempotent per deposit. A monthly NGR figure is a statement about a range of dates. Send it as a statement about that range, not as a stream of tiny increments you hope will add up. NGR and negative carryover is the affiliate-facing version of why those deductions have to be stable.
Pixels cannot do this well. A pixel that fires twice in the browser is two fires. Image tags the same. S2S is the default in 2026 because it is the only one of the three that a finance team can stand to replay. That is the capability claim in postbacks versus pixels.
What affiliates should see
One player, one FTD, one CPA line. If you open the conversion you should see the brand, the click, the GEO, the sub-ids, the timestamp. You should not see a twin.
If a deposit is later reversed, that is a different event, not a duplicate. Chargebacks, bonus abuse, a cancelled payment: those land as adjustments, they can put money on hold, and they can pull a pending commission back. They are not retries. How payouts work covers pending, available, held and under review. Payouts themselves are counted once on the way out, for the same reason postbacks are counted once on the way in.
When something looks doubled, do not start in the wallet. Start at the link. A broken click id produces missing conversions, not extras. QA the tracking link first. Then look at whether two landings, two sub-ids or two brands created two real clicks. Two real clicks from one person can be two events. That is not a double count. That is two clicks.
Why this is a selling point for operators
An affiliate programme that double-counts will overpay, then claw back, then spend the relationship. An affiliate programme that drops retries will under-count, then argue, then spend the relationship the other way. Idempotent S2S is the boring third option: send it, send it again if you must, the total does not move.
It is also why AFFILIFY can show a conversion as a line item rather than as a bucket. The line is the event. A retry leaves the total where it was.
On the affiliate side the same rule is why the 15th can close. Pending becomes available on a total that does not change because a queue caught up at 14:58. KYC still gates the withdrawal. The level still counts qualifying deposits once. None of that works if the FTD itself is a coin toss against the retry log.
If you are wiring this as an operator, start at the docs, use your own click parameter, and treat "send until acknowledged" as normal. If you are an affiliate, you should never have to think about it, which is the point. When you do have to think about it, something upstream is sending two different events and calling them one. That is an integration bug, not a retry.
Frequently asked questions
What does idempotent mean for a postback?
The same event can be sent more than once and only counts once. Timeouts and retries are expected. A second HTTP request is not a second FTD and not a second commission. If the payload changed and a new event id was minted, that is a new event, not a retry.
Will I see duplicate FTDs in my AFFILIFY wallet if the operator retries?
No. A retry of the same event does not add a second line and does not add a second CPA. If you do see two lines, you had two events: two clicks, two deposits, or two different event types. That is worth unpacking with the brand, not assuming the platform counted twice.
Is this the same as payouts being idempotent?
Same idea, other direction. Incoming conversions count once even when retried. Outgoing payouts credit once even when a payout provider is asked twice. Both exist so finance can close a month without a highlighter. [How payouts work](/blog/how-affilify-payouts-work) is the outgoing side.
Do pixels need this too?
Pixels and image tags fire in the browser and will fire however many times the page loads. They cannot be made safe to retry in the way a server postback can. That is one of the reasons S2S is the default and pixels are a fallback for people who cannot send a server event yet. Prefer S2S.
