Everflow postback not firing: a 9-step diagnosis checklist

Why postbacks silently fail

A broken S2S postback rarely throws a visible error. The end user sees a confirmation page, the CRM records the order, but the network never gets the conversion ping — so affiliates stop sending traffic and you stop scaling. By the time someone notices, you have a week of lost data and angry partners.

The good news: in 4+ years of running tracking QA for advertisers on Everflow, Konnektive, Sticky, and HasOffers, the failure is almost always one of nine things. Here is the order I check them in.

1. Click ID is not being captured

Open the offer URL in your browser with a test `?sub1=test123&transaction_id={transaction_id}` parameter. Land on the offer, complete a test conversion, and inspect the order record in your CRM. If the click ID column is empty, your landing page or checkout is stripping it. Common culprits: a redirect that drops query params, a form that does not forward hidden fields, or a Shopify theme that clears the cart query string on /cart.

2. Offer URL template is wrong

In Everflow, the offer's tracking link template must include the macro that matches your CRM's hidden field. If you store the click ID as `affid_clickid` in Sticky.io, your offer link must propagate `&affid_clickid={transaction_id}` — not the default `sub1`. Most broken postbacks I see come from a template that was edited once and never re-tested.

3. Postback URL is missing the conversion macro

Your CRM-side postback (the one you paste into Sticky, Konnektive, or your custom backend) must include the dynamic `{transaction_id}` (or whichever parameter Everflow expects). I have seen advertisers paste the Everflow base postback URL with no macros at all — Everflow then receives empty postbacks and silently discards them.

4. The wrong event is being sent

Everflow distinguishes between events (CPA, RevShare, custom). If your offer is configured to pay on `purchase` but your CRM is firing the `lead` event postback, no conversion lands. Verify the event type in the offer config matches the exact event slug your CRM is sending.

5. IP allowlist on the CRM-side webhook

Some CRMs (custom builds, hardened Konnektive setups) restrict outbound webhooks by destination. Confirm `postback.everflow.io` is allowed, and that there is no aggressive WAF stripping `?` query strings.

6. Duplicate transaction ID

Everflow deduplicates on `transaction_id`. If your CRM reuses the same order ID across test and live (or across two environments hitting the same network), the second postback is dropped. Add a unique prefix per environment.

7. Postback timing — fired before order is final

If you fire the postback on `order.created` but the order is not yet committed (still in `pending`), some advertisers later void it and the postback stands. Worse: a CRM rollback can fire a duplicate. Fire on the terminal status (`approved`, `captured`, `shipped` — whichever is final for your business).

8. Currency or value mismatch

When passing dynamic payout (`{payout}`) the value must be numeric and in the offer's configured currency. A postback firing with `amount=USD 49.00` instead of `amount=49.00` will be accepted but logged as 0, which surfaces as a conversion with no revenue.

9. Test mode vs production endpoint

If you configured a sandbox postback URL during integration and never swapped to production, you have postbacks landing in a sandbox account no one is watching. Last thing to check — and the one most likely to embarrass you.

How to verify in 10 minutes

• Send 1 test click with a unique sub1 value.
• Complete the conversion end-to-end.
• Confirm the click ID is in the CRM order record.
• Confirm the CRM fired the outbound postback (logs).
• Confirm Everflow logs the inbound postback under Reporting > Conversions.
• Confirm the conversion appears in the affiliate's report with the correct payout.