Postbacks idempotentes: por qué a finanzas le importa el doble conteo

Los equipos de finanzas no odian los postbacks. Odian los totales que no pueden volver a reproducir. Si el mismo primer depósito puede aparecer dos veces porque una petición dio timeout y se envió otra vez, el mes no puede cerrar. Alguien pasará el viernes por la tarde con dos CSV y un subrayador. Los postbacks idempotentes son cómo se cancela ese viernes.

Esta es una entrada de capacidad. AFFILIFY cuenta una conversión una vez, incluso cuando el operador la envía más de una vez. Cómo reconocemos el duplicado no es una lista pública. Lo que necesita saber es la forma del problema, qué poner en el cable, y qué se supone que hace la cartera del afiliado cuando aterriza un reintento.

Si quiere el mapa más amplio de tracking, postbacks frente a píxeles frente a etiquetas de imagen es la comparación. Esta es la rebanada de S2S de cara a finanzas.

Qué significa idempotente aquí

Idempotente significa que puede aplicar el mismo evento dos veces y el resultado guardado no cambia. Envíe el FTD #84102. Envíelo otra vez porque su cola no vio el 200. Sigue habiendo un FTD. Sigue habiendo una comisión. La segunda petición no es un error y no es un segundo jugador.

Lo contrario es un contador que incrementa en cada petición HTTP. Ese contador coincidirá con su registro de reintentos. No coincidirá con la base de jugadores del operador, ni con el afiliado que solo envió a una persona.

Los reintentos no son un bug. Las redes fallan. Los balanceadores dan timeout. Se pierde un 200. Una integración seria trata «enviar hasta el acuse» como el camino feliz, que solo es seguro si el receptor puede tragarse el duplicado. Ese es todo el requisito de producto.

Qué deberían enviar los operadores

Ya tiene un identificador de clic. Ya tiene un tipo de evento: registro, FTD, depósito, y lo demás que necesite el acuerdo. Envíe un identificador estable de ese evento para que un reintento sea el mismo objeto y no uno nuevo. Los nombres exactos de los campos viven en la documentación de postbacks, no aquí.

Tres reglas salvan el cierre de mes.

Reintente el mismo payload. No incremente un nonce, no acuñe un identificador de evento nuevo, no «arregle» un timeout enviando FTD-2. El segundo envío debería ser el primero otra vez.

No use el éxito HTTP como único libro mayor. Su lado debería registrar «pretendíamos enviar el FTD #84102» antes de la petición, y «acusaron el FTD #84102» después. Si solo registra la petición, un timeout parece un agujero y enviará un evento distinto para rellenarlo.

El NGR es un período, no un ping. Un evento de depósito puede ser idempotente por depósito. Una cifra mensual de NGR es una declaración sobre un rango de fechas. Envíela como una declaración sobre ese rango, no como un chorro de incrementos minúsculos que espera que sumen. NGR y arrastre negativo es la versión de cara al afiliado de por qué esas deducciones tienen que ser estables.

Los píxeles no pueden hacer esto bien. Un píxel que dispara dos veces en el navegador son dos disparos. Las etiquetas de imagen igual. El S2S es el valor por defecto en 2026 porque es el único de los tres que un equipo de finanzas aguanta volver a reproducir. Esa es la afirmación de capacidad en postbacks frente a píxeles.

Qué deberían ver los afiliados

Un jugador, un FTD, una línea de CPA. Si abre la conversión debería ver la marca, el clic, el GEO, los sub-ids, la marca de tiempo. No debería ver un gemelo.

Si un depósito se revierte después, eso es otro evento, no un duplicado. Contracargos, abuso de bonos, un pago cancelado: aterrizan como ajustes, pueden poner dinero en espera y pueden tirar atrás una comisión pendiente. No son reintentos. Cómo funcionan los pagos cubre pendiente, disponible, en espera y en revisión. Los propios pagos se cuentan una vez de salida, por la misma razón por la que los postbacks se cuentan una vez de entrada.

Cuando algo parece duplicado, no empiece en la cartera. Empiece en el enlace. Un identificador de clic roto produce conversiones que faltan, no de más. Haga QA del enlace de seguimiento primero. Después mire si dos landings, dos sub-ids o dos marcas crearon dos clics reales. Dos clics reales de una persona pueden ser dos eventos. Eso no es un doble conteo. Eso son dos clics.

Por qué esto es un argumento de venta para operadores

Un programa de afiliados que cuenta dos veces pagará de más, después hará clawback, después gastará la relación. Un programa de afiliados que tira los reintentos contará de menos, después discutirá, después gastará la relación por el otro lado. El S2S idempotente es la tercera opción sosa: envíelo, envíelo otra vez si hace falta, el total no se mueve.

También es por lo que AFFILIFY puede mostrar una conversión como una línea y no como un cubo. La línea es el evento. Un reintento deja el total donde estaba.

Del lado del afiliado la misma regla es por lo que el día 15 puede cerrar. El pendiente pasa a disponible sobre un total que no cambia porque una cola se puso al día a las 14:58. El KYC sigue cerrando el retiro. El nivel sigue contando los depósitos que cualifican una vez. Nada de eso funciona si el propio FTD es un cara o cruz contra el registro de reintentos.

Si está cableando esto como operador, empiece por la documentación, use su propio parámetro de clic, y trate «enviar hasta el acuse» como lo normal. Si es afiliado, no debería tener que pensar en ello, que es el punto. Cuando sí tenga que pensar en ello, algo río arriba está enviando dos eventos distintos y llamándolos uno. Eso es un bug de integración, no un reintento.