Postback Not Firing? 12-Point Troubleshooting Checklist for Keitaro, Binom, and Voluum

A postback not firing is the quietest way to lose money in affiliate tracking: the network counted the conversion, the offer paid out, and your tracker shows nothing to optimize on. The failure is almost always mechanical: somewhere in the round trip the click ID never left, arrived broken, or was dropped on arrival. This checklist walks the chain from the cheapest checks to the log forensics, with the exact settings and error messages for Keitaro, Binom, and Voluum.

Postback not firing? Map the chain first

Before touching settings, know what a healthy round trip looks like. Names differ per tracker, but the chain is the same:

1. The traffic source appends its click ID to the campaign URL, and the tracker stores it (as {external_id} in Keitaro, {externalid} in Voluum).
2. The tracker generates its own click ID and appends it to the offer URL, so the network can return it with the conversion.
3. The conversion happens, and the network calls the tracker's postback URL, passing that click ID back.
4. The tracker records the conversion and, if configured, fires an S2S postback onward to the source.

The chain can break at any joint: the link was never installed, the click ID never reached the offer, the network returned garbage, or the receiving side rejected the request. Checks 1 through 9 cover the incoming leg, checks 10 through 12 the outgoing leg. For the MMP and CAPI layer around the tracker, see tracking stack: MMP + tracker + CAPI and server-side conversion delivery. If the chain still needs to be built, start with the Keitaro postback setup for Facebook and TikTok.

The 12-point postback troubleshooting checklist

Treat every postback not firing report as a broken round trip and prove each joint before moving to the next. The order is deliberate: the first checks eliminate the causes that are both dumbest and most frequent.

1. The postback URL is saved where it should be

Cause: the link never made it into the network's cabinet or the tracker's S2S tab. This is the most frequent postback not firing cause of all.

Check: in Keitaro, open Maintenance, then Logs, then Postbacks. An empty log with live traffic flowing usually means the URL was never installed on the network side.

Fix: copy the URL from Settings, then Postback URL, into the network's postback field. For the outgoing leg, a Keitaro campaign needs a source with an S2S link or an entry on the S2S Postbacks tab; in Binom, configure S2S at the traffic source or in the campaign's Advanced Settings (both set means both fire).

2. The URL, domain, and key are intact

Cause: a renamed tracking domain or a stale postback key.

Check: Keitaro logs Incorrect postback code when the key in the URL does not match the one in Settings, then Postback URL. A Voluum funnel breaks with a domain mismatch when the tracking domain changed but the landing page still points to the old one.

Fix: re-copy the exact URL and keep one tracking domain through the whole funnel, including the landing's click URL.

3. The click ID reached the offer

Cause: the tracker's click ID was never appended to the offer URL, so the network has nothing to return.

Check: the Keitaro Traffic log's Requested line shows the campaign launch URL and which parameters came in empty. The offer link must carry the tracker's token: sub1={clickid} for Binom, ?s2={clickid} for Voluum.

Fix: add the token to the offer link and click through the funnel once to confirm it resolves to a real value.

offer link (Binom):  network.example/offer?sub1={clickid}
offer URL (Voluum):  network.example/offer?s2={clickid}

4. The click ID came back in the postback

Cause: the mapping on the network side returns a literal or stale value instead of the real click ID.

Check: Keitaro logs Click for subid ... not found when the subid parameter arrives with a value that matches no click. In Binom the value travels back through cnv_id={sub1}, in Voluum through cid=#s2#.

Fix: correct the mapping in the network's postback settings so the network token holding your click ID feeds the tracker's subid parameter. A postback not firing with a correct mapping is network-side trouble, covered below.

5. Macros and tokens match the network

Cause: a template placeholder was left as-is or the wrong token name was used.

Check: every network has its own tokens, and Voluum templates contain REPLACE and OPTIONAL fragments that must be replaced with the network's tokens. Token names are case-sensitive: {clickid} is not {clickId}.

Fix: replace every placeholder with the concrete network's tokens, character for character.

6. URL-encoding is not mangling values

Cause: spaces and special characters break the parameter chain.

Check: a space inside a value becomes %20 and splits the parameters. Keitaro URL-encodes placeholder values by default; to pass a value raw, prefix the placeholder name with an underscore, for example {_text}.

Fix: strip spaces from values at the source, or switch to raw placeholders deliberately.

7. Status is present and mapped

Cause: the request arrived without a status, or with a status the tracker has never seen.

Check: Keitaro requires subid and status on every postback. The log line Error in stage: FindConversionType with message: Postback status is not set means the parameter is missing; Conversion type not found means the status is unknown. If the network sends different parameter names (clickid, type, profit), teach Keitaro the aliases in Settings, then Postback URL, then Parameters.

Fix: create the missing status in Settings, then Conversion types, or train the nonstandard status in the postback link. For the outgoing leg, select the firing statuses ("Only with statuses") and remap names with {status:lead=0 sale=1 rejected=2}.

8. Payout values are correct

Cause: static and dynamic payout mixed up, or several postbacks overwriting each other.

Check: in a Voluum postback, payout=#price# takes the dynamic value while payout=0.6 is fixed. In Binom, several postbacks on one clickid overwrite the payout with the last one by default; the Upsell checkbox on the offer switches to summing.

Fix: pick one convention per offer, and enable Upsell only when multiple postbacks per click are legitimate.

9. Duplicates and overwrites behave as expected

Cause: repeated postbacks look lost because they were merged instead of added.

Check: in Keitaro, a repeated postback with the same subid but changed parameters overwrites the earlier conversion; with identical parameters it is processed, but the S2S postback does not go out a second time. Repeats without overwriting need a tid transaction ID, the same idea behind the event_id that deduplicates ad platform events. In Binom, disable_postback=1 in the postback URL silently disables the outgoing postback. Voluum sends one traffic source postback per conversion.

Fix: decide the deduplication rules up front and pass tid where repeats are real transactions.

10. The receiving side answers 2XX

Cause: the postback was sent, but the other server rejected it.

Check: the Keitaro S2S postbacks log shows the exact response the source returned for each subid, so a failed answer there is direct evidence. If an MMP sits in your stack, the report's Postback HTTP Response Code field does the same job, and the Original URL field shows which data was present in the click URL.

Fix: a non-2XX answer is a problem on the receiving server; hand the log line to whoever runs that endpoint.

11. Nothing is blocking the request

Cause: an allow-list, a toggle, or a scoping setting filters the postback.

Check: Voluum rejects requests with Postback IP is not whitelisted when the affiliate network element only accepts white-listed IPs, and logs Postback sending error when it cannot deliver to the source's URL or method. On the MMP layer, a disabled Activate partner toggle stops attribution and postbacks, and the "This partner only" scope plus per-event conditions decide who receives anything.

Fix: add the IP to the whitelist or relax the option, switch the toggle on, and align the event scope.

12. Fire a test conversion yourself

Cause: everything is configured, and you still cannot tell whether the pipe works.

Check: in Voluum, take a real click ID from Live events, then Live visits, insert it into the postback URL template in place of REPLACE, and activate it to generate a test conversion; campaign test mode exercises the funnel without polluting reports. In Keitaro, compose the postback URL with a real subid from the Traffic log and a known status, open it, and confirm the entry in Maintenance, then Logs, then Postbacks. In Binom, run a test click through the funnel and check the Leads and Conversions reports and the Clicklog tab.

Fix: if the manual test lands while live traffic does not, the postback not firing cause lives in the difference between the two requests.

Where the logs live in Keitaro, Binom, and Voluum

Diagnostics is mostly reading the right log. One Voluum trick from the error log documentation: append &param=NETWORKNAME to a network's postback URL, and the error log will name the network that sends broken requests.

When the postback is not sent by design

If an MMP such as AppsFlyer sits between the network and the tracker, several kinds of silence are documented behavior. Postbacks stop after the attribution Postback Window closes; the event itself stays recorded. With Advanced Privacy on iOS 14.5 and later, non-consenting users produce no user-level postbacks, and a partner without Advanced Privacy support receives no aggregated postbacks either. A disabled Activate partner toggle halts attribution and postbacks; the Security center Audit log shows when it changed. Scope matters too: "This partner only" versus "All media sources, including organic" decides who receives anything, event names are case-sensitive, and a per-event condition can filter the send. Details in the AppsFlyer troubleshooting guide for advertisers.

When to escalate a postback not firing case to the network

Half of every postback not firing case sits on the network's side, because their server composes and sends the request. Escalate when the mapping in their cabinet matches your tracker and the log still shows Click for subid ... not found with garbage values: that is the documented reason to involve the network. The same applies when the S2S log shows the source answering with an error. Attach the subid, the exact postback URL, the timestamp, and the response, and the ticket resolves in one round instead of five.

Postback not firing: FAQ

Sources