Reversals, status updates and adjustments

Conversions change after the fact: orders are cancelled or refunded, leads are qualified days later, a sale amount is corrected. TrackCrown updates the original conversion instead of adding rows, keeps a change history, fires the right partner postbacks and claws back money that was already paid.

Ways to change a conversion#

Reversal and status-update postbacks#

An S2S postback that targets a conversion that already exists updates it. The target is found by, in order:

1. conversion_id — the UUID TrackCrown returned (and that partners receive as {conversion_id});
2. txid (aliases adv_txid, order_id) of the same offer;
3. click_id + event, only for events that allow one conversion per click.

Duplicates are never targeted. Extra conversions of a multi-conversion event are matched only by conversion_id or txid.

# cancel / refund
curl -s "https://trackcrown.com/pb?txid=ORDER-1001&offer_id=SHOP01&status=rejected&token=YOUR_TOKEN"
# approve a lead the advertiser left pending
curl -s "https://trackcrown.com/pb?click_id=0192f3c1a2b4e1f0c9d84b2a7e6f5d3c&event=lead&status=approved&token=YOUR_TOKEN"
# partial refund: new sale amount
curl -s "https://trackcrown.com/pb?conversion_id=5f0c2a8e-1d3b-4c6e-9f7a-2b8d4e6f1a3c&amount=29.90&token=YOUR_TOKEN"

Response:

{"ok":true,"conversion_id":"5f0c2a8e-1d3b-4c6e-9f7a-2b8d4e6f1a3c","status":"rejected","reason":"postback_reversal","updated":true}

Rules#

• S2S only. Pixels can never change a conversion; a pixel with conversion_id is refused.
• Token. The token must be valid for the conversion's offer. Advertiser tokens may change conversions only while Advertisers may reverse conversions by postback is on (Settings → Conversion rules; on by default); otherwise: advertiser postbacks may not change existing conversions in this workspace.
• Money. amount and revenue from either token; payout only with the workspace token. A new amount re-runs the payout and revenue calculation (percentage payouts follow the new sale amount).
• Nothing changes (same status, same amounts) → the request is an ordinary duplicate.
• Network decisions win. An advertiser can always reject. But approving does not override your decisions: a conversion rejected for another reason than the advertiser's own postback (outside_window, cap_exceeded, fraud:…, rule:…, manual, …) or held / throttled (hold, throttled) keeps its status. Amount changes still apply to held conversions.
• IP allowlist. If the offer enforces the advertiser's IP allowlist, a request from another IP never changes a conversion (conversion_id requests answer 403).
• Unknown conversion_id → {"ok":false,"error":"unknown conversion_id"}.

Status reasons written#

Every change is recorded in the audit log (conversion.reversal or conversion.status_update, with old and new status and amounts, token kind, match method and IP) and shown in the conversion's Change history.

Partner postbacks after a change#

• Late approval (pending → approved, by postback, panel, API, CSV or the end of a hold): the partner's postbacks that fire on approved conversions are queued now. Each postback fires at most once per conversion, so a postback that already fired for this conversion is not repeated.

• Reversal: postbacks whose Fire on is Reversals (cancellations, refunds, amount changes) are queued when

  • an approved conversion is rejected — by advertiser postback, in the panel (single or bulk Reject), by API, by CSV import, by the advertiser in their portal, or by third-party fraud scoring;
  • the amount of an approved conversion changes by advertiser postback.

  They receive the normal macros (including {sub6}…{sub10}, {ip} and {user_agent} of the click) plus {old_status}, {old_payout}, {old_revenue}, {old_sale_amount} and {payout_delta} (new settled payout minus old; settled = payout when approved, else 0 — for example -6.00 for a full reversal). Each reversal postback fires once per conversion: a second reversal of the same conversion does not fire it again.

• Not reversals: rejecting a pending conversion, changes to duplicates, Adjust amounts… and amount changes by CSV import.

• Postbacks with custom statuses that include rejected fire when a change rejects the conversion (once).

Caps#

Status changes move cap counters in the period of the conversion: rejecting an approved or pending conversion frees its slot and payout; re-approving takes them again; a payout change moves the payout counter by the difference.

Statements and clawbacks#

A conversion already on a partner payout statement or an advertiser invoice keeps its statement. The money difference is recorded as an adjustment and appears as a Clawbacks & adjustments line on the partner's (or advertiser's) next statement in the same currency. The Adjust amounts… dialog cannot change money of a conversion already on a statement — only its note; use a postback or a status change instead.

Adjust amounts in the panel#

1. Reports → Conversions → row menu → Adjust amounts….
2. Change Payout, Revenue and/or Sale amount (each shows the old value) and add a note.
3. Save. The change is audited (Change history → "Amounts adjusted"), payout caps move by the difference, reports update after the next mirror cycle, and no postback is re-fired.

Approve or reject in bulk#

1. Reports → Conversions, filter (for example status Pending).
2. Select rows, choose Approve, Mark pending or Reject, optionally with a reason.
3. Up to 5,000 conversions per action. The reason becomes the status reason (default manual); the markers duplicate and multiple are kept. Duplicates can only be rejected.

Import a CSV#

Reports → Conversions → Import conversions (CSV) (max 5,000 rows, 2 MB; separators , ; or tab).

click_id,txid,event,status,payout
0192f3c1a2b4e1f0c9d84b2a7e6f5d3c,ORDER-1001,sale,rejected,
,ORDER-1002,,approved,7.50

Preview shows per line whether it will create, update, stay unchanged or fail (for example Matches more than one conversion — add the event or a click_id.). Applying runs each row in its own transaction. A txid without a matching conversion cannot create one — add the click_id.