BloxClips docs

Appearance

Status note (2026-09-25): Dated payout research and unresolved provider gates. It is evidence and a proposed plan, not proof of live transfer capability or current implementation. Verify current backend money sources, tests, product decisions and provider outcomes before use.

BloxClips payout architecture research ​

TL;DR: research and plan for outgoing creator payouts (Whop ledger transfers); incoming campaign funding is a separate boundary handled elsewhere. Evidence and proposal, not proof of live transfer capability — provider gates were unresolved at the time of writing.

Incoming campaign funding and client invoices are a separate money boundary. See the campaign funding and invoices handoff. The payout material below remains the historical and current plan for outgoing creator credits; it does not authorize importing payout/transfer logic into invoice funding.

The incoming campaign-invoice workflow is staff-managed: verified live Whop company owners create and send invoices, Whop remains authoritative for invoice status, verified net payment makes a campaign eligible, and an authorized administrator launches manually. Its current implementation state, provider evidence, fee-quote blocker, worktree bases, PR sequence, and test status are maintained in the linked handoff above. The outgoing payout plans below remain separate and are not live campaign-funding implementation.

Research date: 2026-09-01 (Asia/Manila)
Scope: repository and provider research only; no payout business logic, schema, route, or data was changed.

Executive conclusion ​

BloxClips does not currently have one immutable source of truth for creator earnings. Two live payout generations calculate mutable submission totals differently, reserve money incompletely, and can race or repeat external sends. Campaign spend is recalculated from current submissions and creator RPM-like values rather than recorded as immutable CPM budget debits. This is not safe to connect to another money rail.

The owner has confirmed that creator credits will be funded from BloxClips' Whop business balance. The proposed primary rail is therefore a Whop Current API ledger transfer debiting that business's biz_… account or its resolved ldgr_… balance and crediting a separately verified creator user_… balance. Official documentation and installed @whop/sdk 1.0.14 types describe that shape. It is not yet sandbox-confirmed or production-capability-confirmed for the configured BloxClips business, so implementation must begin with the provider-capability gate in 05-sandbox-validation.md, not with application money movement.

The Whop Payouts API is not the creator-credit rail: it withdraws an account or user's existing Whop balance to that same owner's saved external payout method. BloxClips should credit the Whop balance; the creator should initiate any later external withdrawal in Whop.

The target boundary is:

text
approved metrics and local policy
  -> immutable BloxClips earning + campaign-budget journals
  -> finality and eligibility
  -> durable scheduled payout reservation
  -> idempotent Whop ledger transfer
  -> signed webhook plus API reconciliation
  -> immutable local payout and audit history

BloxClips remains authoritative for campaigns, review, views, CPM budget depletion, RPM selection, earnings, finality, eligibility, payout state, audit, and reconciliation. Whop owns only balance custody/movement, provider transfer state, compliance controls it applies, and the creator's later withdrawal experience.

Required gates before implementation ​

  1. Whop must confirm that this BloxClips business is approved to originate ledger transfers to user_… recipients, including geography, verification, balance, reserve, and permission requirements.
  2. A clearly isolated sandbox must prove account identity, recipient discovery, transfer behavior, idempotency, retrieval, and webhooks. The current workspace cannot safely prove any of these.
  3. Owners must resolve the choices in 07-open-decisions.md, especially hold period, threshold, creator fee, corrections, and group-membership overlap.
  4. The replacement ledger must pass its invariants and shadow comparison before either legacy send route is disabled and before any Whop dispatch is enabled.

Document map ​

Evidence vocabulary ​

  • Repository-confirmed: directly observed in the checked-out code, schema, migration, manifest, lockfile, or configuration shape.
  • Owner-confirmed: product/business policy explicitly supplied by the owner; here, the transfer source is BloxClips' Whop business balance.
  • Officially documented: stated in a linked current Whop or Content Rewards first-party source accessed on 2026-09-01.
  • SDK type-confirmed: present in installed official @whop/sdk 1.0.14 generated types.
  • Sandbox-confirmed: directly observed using an isolated Whop sandbox. There are no such findings in this audit.
  • Recommendation/inference: a BloxClips design decision or conclusion drawn from evidence; not a claim about Whop internals.

Highest-priority unresolved provider questions ​

  • Which exact biz_… business and backing ldgr_… represent the owner-confirmed BloxClips source balance, and is direct credit from it to a creator user_… enabled, or does Whop require connected biz_… recipients?
  • Which exact current permission/capability set is required in the BloxClips dashboard? The current versioned create-transfer page describes accepted authentication but does not display an operation permission; the older endpoint labels payout:transfer_funds.
  • Does the sandbox currently implement ledger transfers even though its guide says payout functionality is unavailable? The wording does not distinguish external Payouts from ledger Transfers.
  • What production funding, reserve, fee, settlement, verification, geography, velocity, and recipient restrictions will apply to this account?