Conversion Hold Status: Which Conversions Belong in Your Pixel

Underneath every conversion hold status discussion lies a gap between two clocks: the network confirms your lead today but pays for it - or claws it back - weeks later, while the pixel wants to know about conversions on its own schedule. What you decide about that gap decides what your ad platform learns. Send everything immediately and you optimize on registrations that never pay; send only approved sales and you starve the algorithm during the lag; get the timing wrong entirely and the platform refuses the late ones. This guide walks the status pipeline end to end: who owns the hold, which statuses deserve events, how approval lag interacts with acceptance windows, and how to correct the record when a held conversion resolves the wrong way.

The transport side of the chain - postbacks, handoffs, and their break points - lives in the network postback to CAPI guide; this page is about the decision layer on top of it.

Who Owns the Hold: Networks and Trackers, Not Platforms

The hold is a payout-domain concept. Affiliate networks hold conversions while the advertiser's fraud filters, call centers, and refund windows run their course; only then does the money become yours. Your tracker models the same reality with statuses: Keitaro's postback contract requires a status on every conversion - lead, sale, rejected, registration, deposit, trash - and manages transitions between them in its conversion type settings (Keitaro postback documentation).

The ad platform never sees any of this. Its world is simpler: an event arrives or it does not, within an acceptance window or outside it. Everything about the hold - its length, its rules, its resolution - happens before the platform layer, which means the hold is entirely your policy decision to make. That is good news and bad news: no platform can mismanage your hold, and no platform will manage it for you either.

Three Policies for Held Conversions

Sending at lead time feeds the algorithm maximum data and is the right default for offers where approval is fast and near-certain. Waiting for approval protects the optimization from garbage but waits out the hold in full - the algorithm trains on fewer events, later. The split policy carries the most wiring: a lightweight event at registration, a separate purchase event carrying value at approval, two streams to keep mapped. It is also the policy that scales across mixed offers, which is why most buyers converge on it.

The platform-side wiring for the two-stream approach - custom event names included - is in Facebook CAPI custom conversions for affiliate offers.

What Each Status Deserves

Mapping statuses to platform actions:

1. Lead / registration. A real user action with unknown quality. As an event: yes, if your policy uses a lead stream; as a Purchase: never.
2. Approved / sale. Confirmed payout. This is the conversion your Purchase event exists for - carry the payout as value.
3. Hold. Not a status the platform will ever understand; it is a waiting room. The event fires when the waiting ends - as a Purchase on approval, as nothing on rejection.
4. Rejected / trash. Reports only. Sending rejected conversions as events teaches the platform to find more of exactly what you were not paid for.
5. Rebill / repeat payment. A new conversion with its own transaction identity, not an overwrite of the first - more on this below.

Keitaro makes the status the unit of delivery: each S2S postback you configure fires on a chosen conversion status, so the lead stream and the purchase stream are literally two postback rows with different statuses (S2S postback setup).

Approval Lag Versus the Acceptance Window

The platforms document how old an event may be at send time. Meta's Conversions API accepts event_time up to seven days in the past, and one stale event fails an entire request, processing none of it (using the API). Physical-store events - the offline confirmation path, with action_source set to physical_store - get a 62-day window instead (offline events).

The hold arithmetic follows directly. An offer whose advertiser confirms COD orders within three days leaves four days of headroom in Meta's seven-day window. A hold of two weeks cannot be sent as a regular web event at all - approval lands outside the window, and the only documented longer path is the offline physical-store one, which does not describe a web funnel. Buyers facing long holds therefore do the opposite of waiting: they send on a signal that arrives early - a verified registration, a deposit - rather than on the final payout confirmation.

Two timing notes complete the picture. The clock runs from event_time - see the attribution window entry -, the moment of conversion, not from your send moment - so a postback that itself arrived late has already spent part of the budget (where event delay comes from). And the infamous error for violating the window is documented in the 2804003 walkthrough.

Correcting the Record After Status Changes

Held conversions resolve in both directions, and the record has to move with them:

• In the tracker. Keitaro's postback contract handles corrections natively, keyed by the conversion ID of the original click: a new postback with the same subid but changed parameters overwrites the earlier conversion, and status transitions are validated - a conversion cannot jump to a state its configured transitions do not allow ("conversion cannot transition to sale" is a documented log entry with the fix in conversion type settings).
• At the platform. The platform received an event, and events do not unsend - Meta's documented deduplication pairs a browser pixel event with a server event, so two server events sharing an event_id are not merged (deduplication). Corrections therefore happen through the status policy itself: hold the event until confirmation changes the outcome, and keep corrected numbers in your tracker and reports rather than rewriting platform history.

The cross-system version of this problem - tracker, network, and platform disagreeing on the final number - is the subject of duplicate conversions across systems and the discrepancy guides in the cluster.

Choosing a Policy per Vertical

The decision inputs are vertical facts:

1. COD and call-center offers. Confirmation is slow and rejection is real. A split policy - lead at registration, Purchase on confirmed deposit - keeps the algorithm fed without teaching it to love unconfirmed registrations.
2. Trial and card-submit offers. Confirmation is fast; approval may still claw back at the refund window. Sending Purchase at confirmation with value works while the hold is short.
3. Nutra and sweepstakes-style flows. Rejection rates run high and late. Approval-only sending protects optimization at the cost of volume - affordable only with click volume to spare.

Whichever policy you pick, wire it as statuses in the tracker and let the delivery layer read statuses - not import your own convention into every campaign by hand. When numbers from the three systems disagree at reconciliation time, the postback troubleshooting checklist localizes whether it is a policy question or a plumbing one.

Conversion Hold Status: Frequently Asked Questions

Sources