Payouts

The Payouts section is where value leaves your campaign: the queue of rewards moving toward fulfillment, the prefunded balance that funds money rewards, and the manual-fulfillment queue for tier rewards a human delivers. For the reward model itself, see Rewards and payouts.

The payout queue

When a referral reaches validated, its reward is created automatically and enters the queue. Every payout moves through explicit states:

Failed provider deliveries retry automatically with exponential backoff. Every attempt stores the provider reference (for example a gift-card order ID), and deduplication guarantees one provider order per payout, no matter how many retries occur.

Approving and rejecting

Two things can gate a payout before anything is sent:

• Hold window — an optional vesting delay between validation and release, giving refund and chargeback signals time to surface. The fraud decision itself has already landed by then: a rejected referral's reward is never payable, and an approved one waits out the window before it can be released.
• Manual-approve gate — configurable per campaign, above a dollar threshold, or for all payouts. High-value payouts get a human look before funds leave the balance.

For each payout in the approval gate you can approve (releases it through the normal flow) or reject (cancels the reward, releases the balance hold, and reverses the referral to rejected — including a billing credit if it was already counted). Both actions record the actor and a reason code in the audit log.

Bulk actions apply the same decisions to a selection — select all payouts from one referrer and approve or reject in one step, with one reason code applied to all.

Manual fulfillment

Tier rewards that a human delivers — send a hoodie at 10 referrals, flip a flag in your own database — flow through the manual-fulfillment queue instead of automatic delivery. See reward configuration for setting these up.

When a referrer crosses the tier, a reward record is created in needs_fulfillment state and appears in the queue with the user, campaign, tier reached, promised reward, and when it was reached. Work the queue by marking each item fulfilled or dismissed, optionally with a note (a tracking number, "handled in our admin"). A nav badge counts outstanding items, and you can filter by campaign, tier, and status.

You do not have to watch the dashboard: tier crossings trigger owner alerts by email or Slack. (Dedicated tier webhook events are not yet part of the event catalog.)

The prefunded reward balance

Money rewards draw from a prefunded balance you top up in advance. Invitebase never custodies these funds — they sit in a funding account in your name at the payout provider; Invitebase keeps the ledger.

The balance panel shows three numbers:

• Current — total funds in the account
• Held — reserved for pending and in-review rewards
• Available — current minus held; what new payouts can draw on

Top-ups

• Manual top-up via Stripe checkout — the credit appears in the ledger on confirmation.
• Auto-reload — set a threshold and a reload amount against a saved payment method; failures alert you.
• Low-balance alerts at thresholds you configure, by email and in the dashboard.
• Payout-pause — if available balance can't cover a payout, payouts queue rather than fail, you are alerted, and everything resumes automatically on top-up. Your users' rewards are delayed, never silently dropped.
• Refunds — withdraw unused balance at any time; the ledger records the debit with the provider withdrawal reference.

Bank funding is free; card funding carries roughly a 3% provider fee — the checkout flow shows the tradeoff.

Payout history

The history view lists every payout with status, amount, method, destination, provider reference, timestamps, and the actor for any manual decision — filterable by campaign, user, method, and status. Each user's profile page shows the same history scoped to them.

In test mode, the Payouts screen shows sandbox payouts only. The full money lifecycle — validate, hold, order, delivered — is exercisable end to end with zero real funds, and the test banner stays loud on this screen.

What's next