Appearance
Open owner/product decisions
These seven choices materially alter policy, schema configuration, UI copy, or rollout. Provider capability questions are not repeated here; they are validation gates in the API and sandbox documents.
1. Finality hold and campaign-end metric grace
| Option | Tradeoff |
|---|---|
| 7-day rolling hold plus 24-hour result-ingestion grace (recommended) | Good initial protection against metric correction/fraud while providing a predictable weekly maximum delay. Each accrual finalizes seven days after both approval and metric observation; a final scrape observed before campaign cutoff may arrive for 24 hours. |
| 3-day hold plus 24-hour grace | Faster creator access, but less time to observe deletion/manipulation/fraud and closer operational dependence on scrape cadence. |
| 14-day hold plus 48-hour grace | Stronger risk window and easier late metric capture, but substantially worse creator cash flow. |
What changes: finalizesAt, campaign end scheduler, late-result eligibility, creator copy, risk operations, test fixtures, and payout forecasting. Decide whether an explicit risk hold can extend any automatic window (recommended: yes, with reason and notification).
2. Aggregate automatic transfer threshold
| Option | Tradeoff |
|---|---|
| USD 100 at launch (recommended) | Fewer provider operations and easier incident containment while fees/limits are unknown; slower for small creators. Review after 30–60 days of measured provider cost/failure data. |
| USD 20 | Matches the checked-in environment template and improves access, but increases operation volume and fee exposure. Current code's absent-env default is $100, so this is not a confirmed existing policy. |
| Fee-aware threshold with a fixed floor | Economically efficient but requires verified provider fees and more policy/UI complexity. |
What changes: payout-policy version, scheduler eligibility, UI “next payout” copy, forecast/alerts, and load tests. The threshold applies to aggregate payable balance, not submission review eligibility.
3. Additional creator/platform fee
| Option | Tradeoff |
|---|---|
| No additional creator fee for MVP (recommended) | Creator RPM is the promised payout; CPM minus RPM is BloxClips margin. Simplest and most transparent. |
| Preserve current 7% creator deduction | Retains current economics but must be explicitly disclosed, versioned, snapshotted, and shown separately; current Content Rewards public fee evidence is inconsistent and cannot justify it. |
| Campaign-configurable fee | Flexible but multiplies policy/versioning/support complexity and can confuse rate comparisons. |
What changes: earning snapshots, campaign/creator disclosure, UI breakdown, tax gross/net reporting, refund/recovery math, and shadow comparison. Never hide a provider transfer fee inside the creator's promised RPM.
4. Group membership overlap within a campaign
| Option | Tradeoff |
|---|---|
| At most one active group per creator per campaign (recommended) | Simple deterministic precedence and UI. Moving a creator ends one membership and starts another; past accruals retain old snapshots. |
| Multiple groups with explicit numeric priority | Supports layered programs but requires unique priorities, tie handling, and more difficult audits. |
| Multiple groups with lowest/highest RPM wins | Easy to state but can create surprising incentive or margin changes and administrative mistakes. |
What changes: database exclusion/unique constraints, group-member UI, resolveRate, membership history, and rate-change tests. Individual creator override still wins over the selected group.
5. Post-payment negative corrections and fraud recovery
| Option | Tradeoff |
|---|---|
| Record recovery due; offset future BloxClips earnings only after finance review and creator notice (recommended) | Preserves evidence and avoids an invented Whop clawback. Can leave unrecovered loss if the creator earns no more; requires terms and a bounded dispute process. |
| Write off every correction after provider success | Strong creator finality and simplest UX, but BloxClips absorbs all late fraud/metric loss. |
| Seek provider reversal/debit | Potential recovery, but no public Transfer reversal endpoint was found and unilateral debits may be legally/provider restricted. This option is unavailable unless Whop and counsel explicitly approve it. |
What changes: terms, RECOVERY_DUE/RECOVERED states, negative-balance eligibility, creator notices/appeals, finance roles, and accounting reports. No option permits editing/deleting the original paid entry.
6. Campaign funding commitment and BloxClips business-balance buffer
The debit source is no longer open: the owner confirmed that BloxClips pays creators from its Whop business balance. The remaining decision is how campaign commitments and aggregate liquidity are controlled against that single source.
| Option | Tradeoff |
|---|---|
Require full local campaign-budget commitment before LIVE; maintain a forecasted buffer in BloxClips' Whop business balance (recommended) | Campaign cannot promise more than its locally committed budget, while treasury funds the one business balance in aggregate. Requires forecasts/low-balance alerts; local campaign budgets are not falsely represented as provider-segregated funds. |
| Full local campaign commitment with just-in-time business-balance top-ups | Reduces idle provider balance but increases the chance a scheduled sweep fails because settlement/top-up funds are not yet available. |
| Allow unfunded campaign credit against the same business balance | Faster sales launch but permits total campaign promises to exceed committed funds and creates creator credit risk; not recommended for MVP. |
What changes: launch gate, CampaignBudgetEntry top-up semantics, treasury dashboard, low-balance buffer, and depleted/top-up lifecycle. Provider-origin strategy no longer varies: every payout operation references the configured BloxClips business origin. Also decide whether optional flat fees launch now; recommended default is disabled, and if enabled they consume committed campaign budget 1:1.
7. Earnings included in the first automatic sweep and tax gate
| Option | Tradeoff |
|---|---|
| Content-creator earnings only for first release (recommended) | Keeps the new ledger and Whop credit scope coherent. Existing affiliate commissions remain visible/separate and are not silently combined. Add them later as their own immutable earning source after accounting/tax review. |
| Content plus affiliate commissions | Preserves the current combined threshold behavior, but requires migrating/refactoring ReferralCommission, defining its finality/reversal, and reconciling two earning classes before launch. |
| All platform earnings | One creator payout experience, but expands scope to every future earning product and requires a more general ledger now. |
Tax owner action required for every option: counsel/finance must specify whether and when a Whop balance credit is reportable/withholdable, which users/countries require forms, whether credits must be blocked or merely reported, and how gross versus net is computed. The existing Stripe/PayPal/USDT preflight must not be copied without that ruling.
What changes: eligible source tables, threshold aggregation, DTO/UI breakdown, tax-year reporting, holds, referral status transitions, and rollout fixtures.
Decision record template
For each item, record: selected option, approver, date, rationale, policy effective timestamp, creator-facing disclosure, and whether existing not-yet-final earnings use old or new policy. Rate/fee/finality changes must be versioned; they cannot retroactively rewrite an accrual.