Pending to Approved, Rejected or Reversed, with hold windows, frozen payout and revenue, review queues and recorded reasons.
Recording a conversion and paying for a conversion are two different events, and putting a gap between them is what makes an offer network solvent. In Offer Capsule every conversion starts as Pending and moves to Approved, Rejected, or Reversed. Approval is what funds it. That gap is your scrub window: time to see whether the advertiser confirms it, whether the traffic looks real, and whether the order sticks - before anyone is owed anything.
The statuses are a fixed set, not free text, which is why reports can group revenue and payout by status and mean the same thing every time.
Each offer carries a hold window in days. A conversion on an offer with a hold window sits Pending until that window elapses; a conversion on an offer with no hold window is eligible immediately. A background sweep runs continuously and approves the conversions and leads that have become due, so a no-hold offer settles within minutes and a seven day offer settles on the eighth. Auto-approve is a per-offer setting: leave it on and the sweep handles everything, turn it off and due conversions wait for a person.
The moment a conversion is recorded, the payout owed to the affiliate and the revenue owed by the advertiser are snapshotted onto the row. Changing an offer's terms tomorrow does not retroactively reprice anything recorded today. This is the single most important property in the whole lifecycle: what you owe and what you are owed on any given conversion is fixed by the terms that were live when it happened, and it stays that way through approval, reversal, and every report that reads it.
Conversions and CPL leads have their own admin queues. From either you can approve early, reject, or reverse an already-approved row, and every decision records a reason. Approving funds the payout; rejecting moves no money; reversing voids both the revenue and the payout legs, which is how a chargeback or an advertiser scrub is handled. The reason is stored on the row, so six weeks later the record answers the question rather than a person having to.
The state machine guards itself. Only a Pending row can be approved, so a conversion can never be funded twice - not by a double click in the queue, not by the sweep racing an operator, not by a retried job. Only an Approved row can be reversed, so nothing that never funded can be clawed back. A settled row that gets asked to settle again does nothing. In a system where a state transition creates transaction legs, this is what stands between you and duplicate payouts.
A second conversion on the same click is blocked as a duplicate and logged with that reason, unless the offer explicitly allows multiple conversions per click. Some offers legitimately do - subscription upgrades, repeat purchases in a session - and it is a per-offer setting rather than a global one.
Conversions recorded as tests never bill, never fire a postback, and are excluded from every report, so an advertiser can validate an integration against production without touching anybody's numbers.
CPL leads carry identical lifecycle columns and run through the same record, hold, approve, reject, and reverse sequence as conversions. One state machine, two record types, no divergent behaviour to remember. Conversions credited through a coupon code follow it too.
Related: conversion tracking for how conversions arrive, billing and payouts for what approval creates, and affiliate postbacks for how affiliates are told.
See Offer Capsule running against your own offers. We will follow up to arrange a walkthrough.