Назад в блог
Операторам 23 сентября 2026 г. 3 мин чтения

Идемпотентные постбэки: почему финансам важен двойной счёт

Постбэк, который безопасно ретраить, — разница между цифрой, которую финансы подпишут, и цифрой, о которой финансы будут спорить. Что значит идемпотентность, почему операторы шлют одно событие больше одного раза и что партнёр должен увидеть в кошельке, когда это происходит.

Автор: AFFILIFY Проверено: 23 сентября 2026 г.
Финансы не ненавидят постбэки. Они ненавидят итоги, которые нельзя проиграть заново. Если один и тот же первый депозит может появиться дважды, потому что запрос ушёл в таймаут и его отправили ещё раз, месяц не закрывается. Кто-то проведёт пятницу за двумя CSV и маркером. Идемпотентные постбэки — как эту пятницу отменяют.

Это статья про способность. AFFILIFY считает конверсию один раз, даже когда оператор шлёт её больше одного раза. Как мы узнаём дубль — не публичный чек-лист. Что нужно знать — форма задачи, что класть на провод и что кошелёк партнёра должен сделать, когда приземляется ретрай.

Если нужна более широкая картина трекинга, сравнение — постбэки против пикселей и тегов-картинок. Это финансовый срез S2S.

Что здесь значит идемпотентность

Идемпотентность значит: одно и то же событие можно применить дважды, и сохранённый результат не изменится. Отправьте FTD #84102. Отправьте ещё раз, потому что очередь не увидела 200. FTD по-прежнему один. Комиссия по-прежнему одна. Второй запрос — не ошибка и не второй игрок.

Противоположность — счётчик, который растёт на каждый HTTP-запрос. Этот счётчик сойдётся с вашим логом ретраев. Он не сойдётся с базой игроков оператора и с партнёром, который отправил одного человека.

Ретраи — не баг. Сети падают. Балансировщики уходят в таймаут. 200 теряется. Серьёзная интеграция считает «шли, пока не подтвердят» счастливым путём, а это безопасно только если принимающая сторона умеет проглотить дубль. В этом всё продуктовое требование.

Повторно отправленный постбэк — всё ещё одна конверсия и одна комиссия

Что должны слать операторы

Идентификатор клика у вас уже есть. Тип события тоже: регистрация, FTD, депозит и всё, что ещё нужно дилу. Шлите стабильный идентификатор этого события, чтобы ретрай был тем же объектом, а не новым. Точные имена полей живут в документации постбэков, не здесь.

Три правила спасают закрытие месяца.

Ретрайте тот же payload. Не инкрементируйте nonce, не чеканьте новый идентификатор события, не «чините» таймаут отправкой FTD-2. Вторая отправка должна быть первой отправкой ещё раз.

Не делайте HTTP-успех единственным реестром. С вашей стороны должно быть записано «мы намеревались отправить FTD #84102» до запроса и «они подтвердили FTD #84102» после. Если вы записываете только запрос, таймаут выглядит дырой, и вы отправите другое событие, чтобы её закрыть.

NGR — период, не пинг. Событие депозита может быть идемпотентным по депозиту. Месячная цифра NGR — заявление о диапазоне дат. Шлите её как заявление об этом диапазоне, не как поток крошечных инкрементов, которые, как вы надеетесь, сложатся. NGR и перенос отрицательного баланса — партнёрская версия того, почему эти вычеты должны быть стабильными.

Пиксели это умеют плохо. Пиксель, который стрельнул в браузере дважды, — два выстрела. Теги-картинки то же. S2S в 2026 — дефолт, потому что из трёх только его финансы согласны проигрывать заново. Это заявление о способности в постбэках против пикселей.

Что должен видеть партнёр

Один игрок, один FTD, одна строка CPA. Если открыть конверсию, должны быть видны бренд, клик, GEO, sub-id, метка времени. Близнеца быть не должно.

Если депозит потом разворачивают, это другое событие, не дубль. Чарджбэки, бонусный абуз, отменённый платёж: они приходят как корректировки, могут поставить деньги на удержание и могут забрать комиссию из ожидания назад. Это не ретраи. Как работают выплаты закрывает «в ожидании», «доступно», «на удержании» и «на проверке». Сами выплаты на выходе считаются один раз — по той же причине, по которой постбэки на входе считаются один раз.

Когда что-то выглядит удвоенным, не начинайте с кошелька. Начните со ссылки. Сломанный идентификатор клика даёт пропущенные конверсии, не лишние. Сначала проверьте трекинговую ссылку. Потом посмотрите, не создали ли два лендинга, два sub-id или два бренда два настоящих клика. Два настоящих клика от одного человека могут быть двумя событиями. Это не двойной счёт. Это два клика.

Почему это аргумент для операторов

Партнёрская программа, которая считает дважды, переплатит, потом заберёт назад, потом потратит отношения. Партнёрская программа, которая роняет ретраи, недосчитает, потом поспорит, потом потратит отношения с другой стороны. Идемпотентный S2S — скучный третий вариант: отправьте, отправьте ещё раз, если надо, итог не двигается.

И поэтому AFFILIFY может показывать конверсию строкой, а не ведром. Строка — это событие. Ретрай оставляет итог там, где он был.

Со стороны партнёра то же правило — почему 15-е может закрыться. «В ожидании» становится «доступно» по итогу, который не меняется оттого, что очередь догнала в 14:58. KYC по-прежнему стоит перед выводом. Уровень по-прежнему считает зачётные депозиты один раз. Ничто из этого не работает, если сам FTD — монетка против лога ретраев.

Если вы это подключаете как оператор, начните с документации, используйте свой параметр клика и считайте «шли, пока не подтвердят» нормой. Если вы партнёр, вам об этом думать не придётся — в этом и смысл. Когда думать приходится, выше по потоку шлют два разных события и называют их одним. Это баг интеграции, не ретрай.

Частые вопросы

Что значит идемпотентность для постбэка?

Одно и то же событие можно отправить больше одного раза, и оно считается один раз. Таймауты и ретраи ожидаемы. Второй HTTP-запрос — не второй FTD и не вторая комиссия. Если payload изменился и чеканули новый идентификатор события, это новое событие, не ретрай.

Увижу ли я дубли FTD в кошельке AFFILIFY, если оператор ретраит?

Нет. Ретрай того же события не добавляет вторую строку и не добавляет второй CPA. Если вы видите две строки, у вас было два события: два клика, два депозита или два разных типа события. Это стоит разбирать с брендом, а не предполагать, что платформа посчитала дважды.

Это то же самое, что идемпотентность выплат?

Та же идея, другое направление. Входящие конверсии считаются один раз, даже при ретрае. Исходящие выплаты зачисляются один раз, даже если провайдера выплат спросили дважды. Оба существуют, чтобы финансы закрыли месяц без маркера. [Как работают выплаты](/blog/how-affilify-payouts-work) — исходящая сторона.

Нужно ли это пикселям тоже?

Пиксели и теги-картинки стреляют в браузере и выстрелят столько раз, сколько загрузится страница. Их нельзя сделать безопасными к ретраю так, как серверный постбэк. Это одна из причин, почему S2S — дефолт, а пиксели — запасной вариант для тех, кто ещё не может слать серверное событие. Берите S2S.

Ещё из этого кластера