Earning rules

How members earn: rates, release timings, segments, caps, budgets, expiry and refund behavior — all versioned.

Anatomy of a rule

A rule says: who earns, on what, how much, when it becomes spendable, and what happens on refunds. Rules are versioned — editing creates a new version, and every ledger entry permanently records the version that created it, so historic earnings always trace to the exact configuration that produced them.

Rates and scopes

The earn rate is a percentage of order value. A plain rule applies to every order; a category rule applies only to orders containing your chosen product tags (great for double-points weekends on one collection). Rules stack: when several match one order, each contributes.

When coins become spendable

Six release timings, per rule:

· Immediately at order · When paid · When shipped · On delivery (carrier events, with a configurable assume-delivered fallback) · After delivery + return window (value stays pending until the window closes — refunds inside it never touch spendable balance) · After manual approval — each earn waits in a queue until your team approves or rejects it, for high-touch programs or suspicious segments.

Customer segments

Scope any rule to first purchase only (acquisition), returning customers, lapsed customers (no purchase in 180 days — win-back), or members at/above a tier level. Segments are evaluated per order from real history.

Caps, budgets, expiry, refunds

Per-order, per-member-per-day and per-member-total caps clamp earnings at write time; a rule budget stops issuance when exhausted — all enforced by the engine, not by reporting. Expiry (in months) drives the portal's expiry warnings and your breakage. On refunds, a rule either claws back proportionally (partial refund → partial clawback) or lets members keep the value.

Next: Change governance →