Design an affiliate payout workflow your partners can trust

Partner trust is built from predictable rules and traceable decisions. A partner should be able to understand which conversions are under review, which earnings entered a payment, why an exception occurred, and when the network actually sent the funds. Finance should be able to answer the same questions from records rather than memory.

The central design rule is simple: do not use one status to represent Conversion Status, Settlement Status, and Payment Status. Those are separate decisions made at different times, often by different people.

1. Separate Conversion Status, Settlement Status, and Payment Status

Conversion Status answers whether an attributed event counts under the commercial terms. Settlement Status answers whether the resulting earning is still available, reserved in a Payment, or finalized. Payment Status describes the Payment record as the operator reviews it and moves funds outside the platform.

What each conversion state should mean

• Pending: the event has been recorded, but the review window or validation work is not complete. It should not be payable yet.
• Approved: the event satisfies the current commercial rules and may become payout-eligible when every other condition is met.
• Rejected: the event does not qualify. Store a controlled reason category and reviewer evidence; do not merely remove the row.
• Refunded or adjusted: define this carefully. Some systems expose a refunded conversion status. Others, including OfferDaemon, can represent a refund as a separate negative event or accounting adjustment. A refund is therefore not always a simple fourth status, especially after the original conversion has already entered a closed payment.

That last distinction matters. Rewriting a settled sale from approved to refunded can destroy the history that supported an earlier payment. A negative refund event preserves both facts: the original earning was paid, and a later adjustment reduced the beneficiary’s subsequent balance.

CONVERSION STATUS
pending ────────────────► approved ───────────────► payout-eligible
   └───────────────────► rejected ───────────────► excluded

refund event ───────────► negative adjustment ───► later reconciliation

SETTLEMENT STATUS
unsettled ──────────────► locked ─────────────────► settled
                            │
                            └── cancel ───────────► unsettled

PAYMENT STATUS
requested ──────────────► approved ───────────────► processing ─────► paid
    │                         │                          │
    ├── cancel ──────────────► cancelled                │
    └──────── reject ─────────┴──────────────────────────┴───────────► rejected

A diagram is only useful when the transition rules are explicit. Record who may move each state, the allowed source states, the required evidence, and the effect on linked conversions.

2. Treat hold periods and review windows as operator policy

A hold period is not a feature toggle that makes a conversion trustworthy. It is an operating policy that creates time for advertiser validation, duplicate checks, lead-quality review, cancellations, and refund exposure. Choose the window from your contracts and risk profile rather than copying an arbitrary industry number.

Document the policy at the level partners can act on:

• which event date starts the clock: click, conversion, approval, delivery, or another contractual milestone;
• the cut-off date, time zone, and treatment of late postbacks;
• whether different offers or event types use different review windows;
• who can approve early, extend a review, or reopen an exception;
• how refunds and chargebacks arriving after payment become future adjustments;
• when partners receive validation results and when they may raise a query.

Policy test: two operators applying the written rules to the same conversion cohort should produce the same eligibility list.

Keep conversion approval separate from the payment itself. First decide which conversions are payable under your rules, then create and complete the payment as a separate process. Publish a review window that matches your refund rights, advertiser terms, partner agreements, and available funds.

3. Build payment requests from an eligible conversion set

A payment request should be the result of a repeatable query, not a manually typed balance. At creation time, select approved and unsettled conversions for one beneficiary inside the defined cut-off. Then calculate the requested amount, snapshot payment details, link the rows, and lock them together in one transaction.

Keep each beneficiary’s ledger independent

One advertiser event can create more than one payable record. The Publisher who drove the result, a Merchant who earns Merchant Commission, and a referral beneficiary may all have separate earnings. Do not infer that paying one settles the others.

Apply individual rates before settlement

Commercial terms may differ by partner. A per-publisher offer rate or override should be resolved when the conversion amount is created, with the applied basis preserved. Later rate changes must not silently recalculate historical earnings already reviewed or paid.

Before opening a request, verify:

1. the beneficiary identity and payment method are current;
2. the included conversions are approved, unsettled, inside the cut-off, and denominated consistently;
3. the applied offer rate and any individual override match the effective commercial terms;
4. refund events, manual corrections, and prior carry-forwards are present;
5. minimum payout, fee, and tax-document policies have been applied where relevant;
6. there is no other active payment locking the same conversions.

OfferDaemon supports beneficiary-initiated payment requests for its publisher and merchant surfaces, as well as admin-generated payments. Referral-beneficiary earnings remain independent and can be handled through the appropriate admin-driven flow.

4. Give every payment state one operational meaning

Rejecting is not cancelling

Use reject when the underlying Payment should not be honored. In OfferDaemon, rejecting a Payment sets its linked conversions to Rejected and returns them to Unsettled, preserving the business decision in the record. Use cancel for an operational withdrawal—such as incorrect payment details or a request that must be rebuilt. Cancellation unlocks the linked conversions without changing their Approved Conversion Status.

Beneficiaries should only be able to cancel their own payment while it is still requested. Administrative cancellation needs a reason and should remain unavailable after a payment is final. Never use cancellation to disguise a fraud or quality decision, and never use rejection just to correct a bank detail.

5. Link every Payment to the conversions that funded it

A Payment row with only a beneficiary and total cannot support a serious review. Store the exact conversion IDs included in the Payment. This link is what lets the system prevent double payment, explain the amount, settle only the correct rows, and reverse an incomplete request safely.

The payment should snapshot the fields that must not drift after approval:

• beneficiary and beneficiary type;
• payment method and destination details used for this cycle;
• requested amount, approved amount, fee, and expected sent amount;
• currency and cut-off period;
• the conversion membership list and any adjustment rows;
• operator notes, approval identity, and external transfer reference.

Creation, membership insertion, and conversion locking should succeed or fail together. If those operations are separate, concurrent requests can select the same available balance before either process notices the conflict.

6. Reconcile the commercial, platform, and cash records

Reconciliation is not a final glance at the total. It is a three-way comparison between the commercially valid conversion cohort, the affiliate platform’s payable records, and the amount actually sent by the external payment provider.

Investigate differences by cohort and identifier rather than editing the total until it matches. Common exception classes include a late validation file, a missing or duplicated conversion, an incorrect beneficiary mapping, a rate effective-date mismatch, a refund posted after cut-off, a rounding difference, or an external transfer fee applied in the wrong place.

Reconcile publisher, merchant, and referral earnings independently. Their records may originate from the same source event, but their rates, balances, requests, and payment dates can differ. Then tie the combined cash requirement back to the operator’s treasury record.

7. Preserve audit history and communicate before partners ask

Every manual state change should create an audit entry with the payment or conversion ID, previous and new state, actor, timestamp, reason, and relevant amount. Keep generated requests, approval notes, cancellations, rejections, external references, and settlement completion visible as one timeline.

Audit history protects both sides. It gives the partner a coherent explanation and gives operations a way to reconstruct the close without relying on chat messages or a mutable spreadsheet.

Publish a communication rhythm

• Before the period closes: remind partners of the cut-off, payment-detail requirements, and dispute deadline.
• After validation: expose approved, rejected, and adjusted results with reason categories that do not reveal sensitive fraud controls.
• At approval: share the period, conversion count, gross amount, fee, currency, and expected sent amount.
• During exceptions: name the affected cohort, owner, next review date, and evidence still required.
• After transfer: provide the paid date, amount, method, and a safe external reference or remittance record.

Partners should not have to chase the network to learn whether a decision is pending. A regular update about validation, payment timing, and open questions reduces support work and gives partners confidence that their earnings are being handled.

8. Know what OfferDaemon controls—and what remains outside

OfferDaemon affiliate network software organizes Conversion Status, eligible earnings, conversion-to-Payment membership, beneficiary Payment requests or admin-generated Payments, lifecycle actions, and Payment history. It is a control record for payment work, not a built-in payment processor.

This boundary is deliberate and should be reflected in your controls. Do not mark a payment paid when a file is exported or a transfer is merely queued. Mark it paid only after your team has evidence that the money was sent successfully.

If you are moving balances and history from another platform, use the affiliate network migration checklist to define the ledger cut-off, opening balances, identifier mapping, parallel reconciliation, and rollback plan. A payout workflow should not change meaning halfway through a migration.

Affiliate payout workflow FAQ

When does an approved conversion become payable?

Approval establishes commercial validity. Payability also requires the conversion to satisfy the operator’s cut-off and review policy, remain unsettled, belong to the correct beneficiary, and pass any documented payment requirements.

Should a refund change the original conversion status?

Not necessarily. A system may expose a refunded status, but a separate negative event or accounting adjustment can preserve a clearer history—especially when the original conversion has already been settled. OfferDaemon models refunds as negative events rather than adding Refunded to its Pending, Approved, and Rejected Conversion Status values.

What is the difference between locked and settled?

Locked means an approved conversion has been reserved in an active payment and cannot enter another one. Settled means the linked payment was marked paid after the external transfer completed.

Does OfferDaemon send affiliate payouts automatically?

No. OfferDaemon has no payout scheduler and no built-in payment processor. It manages Publisher- or Merchant-requested and admin-generated Payments and their linked records. The operator transfers funds externally, moves the Payment to Processing, and marks it Paid after completion.

Can one payment combine publisher, merchant, and referral earnings?

Treat each beneficiary as an independent settlement lifecycle. Even when earnings share the same source event, they should be requested, reconciled, approved, and paid through their own beneficiary records.

How should a team choose its payout schedule?

Work backward from advertiser validation timing, refund and chargeback rights, partner contracts, treasury capacity, and finance close requirements. Then publish the cut-off, review window, expected payment timing, and exception process. Software should enforce the policy; it should not invent it.