Social LiveDocumentationPLATFORM DOCS

Payout Rails

Cash-out corridors, clearing cycles, KYC gates, and risk holds for creator payouts.

Last updated Thu Jul 16 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

TL;DR -A proposed design for what happens after a withdrawal is approved: which payment networks the money travels on, a predictable weekly Monday batch, the identity/tax checks required first, and the fraud holds that can pause a payout. The one-line host contract: minimum $25, paid weekly on Mondays after approval.

Who this is for -Business & Operations: the rail table, clearing cadence, and the one-screen host contract. Security & Compliance: the KYC and risk-hold gates. Engineering: the batch job, idempotency, and failure handling.

Status: PROPOSED DESIGN -see the Creator Program overview. The withdrawal request flow (minimums, holds, admin review, status lifecycle) is shipped -see Withdrawals. This page designs what happens after "approved": how money actually leaves.

In plain terms

Getting a withdrawal approved is already built. This page is about the last mile: once an admin says "yes, pay this," how does the money actually reach the host's bank account?

The plan has four moving parts:

  • Rails -the payment networks money rides on. Stripe Connect first (US, EU/UK), then Payoneer for the rest of the world, then local bank transfers. Crypto is deliberately off the table.
  • A weekly batch -all approved payouts go out together every Monday morning. Predictable beats fast: "approved by Friday, paid next week" is easy to explain and easy to support.
  • KYC and tax gates -before your first payout you verify your identity; US hosts crossing $600/year fill out a W-9; everyone must be 18+.
  • Risk holds -large or first-time payouts, or hosts with high refund rates, get a manual fraud review before the money moves.

Current state

Withdrawal rows move requested → approved → paid via admin review, with Stripe Connect scaffolded as the only rail. Everything below extends that lifecycle; nothing changes upstream of "approved."

Rails by corridor

A "rail" is just the payment network that carries the money, and a "corridor" is which countries it can reach. The table shows which rail serves which regions, roughly what it costs, and the order they're planned to ship.

RailCorridorsCost profilePriority
Stripe Connect (scaffolded)US, EU/UK, ~45 countries~0.25% + fixed; KYC handled by Stripe onboardingPhase 1 -finish this first
Payoneer mass payoutGlobal incl. SEA, MENA, LATAM -where most live-streaming hosts are~$1.50–$3 per payoutPhase 2, when non-Stripe-country hosts appear
Local bank transfer (via regional PSP)Per-country, added on demandvariesPhase 3
Crypto / USDT--Deliberately not offered. Industry smaller platforms use USDT rails; the AML/sanctions surface and the "irreversible payout + reversible IAP funding" mismatch make it a net risk for us. Revisit only with counsel.

A host configures exactly one active payout method (PayoutMethod row: rail, masked destination, verification state). Changing the method imposes a 7-day payout freeze on new requests — the classic account-takeover play is "change payout destination, drain."

Clearing cycle

Rather than pay each approval the moment it happens, all approved payouts are submitted together once a week. The diagram traces one withdrawal from request, through admin approval, into Monday's batch, and to the funds landing (or failing and releasing the hold).

Industry ranges from TikTok's 3–5 business days to monthly cycles on small platforms. Design: weekly batch clearing.

Rendering diagram…
  • Predictable cadence beats speed for support load: "approved by Friday = money next week" is one sentence.
  • Batch submission gets one idempotency key per withdrawal (payout:<withdrawalId>) so a re-run after a partial batch failure can't double-pay -the same idempotency discipline as every other money movement.
  • Rail failures (closed account, mismatched name) mark the withdrawal reversed, release the diamond hold back to available, and notify the host to fix their payout method.

KYC & compliance gates

Before money can leave, a few legal checks must pass. These are the gates, what triggers each, and how it's enforced. Notably, the platform stores only the result of identity verification, never the underlying documents.

GateTriggerMechanic
Identity verificationBefore first payout, any amountRail-native onboarding (Stripe Identity / Payoneer KYC) -we store the verification state, never the documents
US tax (1099)US persons crossing $600/calendar yearW-9 collection before the crossing payout releases
Sanctions screeningEvery batchRail-side screening; failures surface as failed payouts for manual review
AgeProgram-widePayouts require 18+ verified via the KYC step

Risk holds (on top of the standard 72h settlement)

Even after the 72-hour settlement hold that every diamond goes through, certain payouts get an extra fraud pause. These catch the slower forms of abuse the 72h window would miss.

  • Velocity review: first-ever payout, and any payout > $500, routes to manual review with a fraud checklist (funding-source concentration, refund rate, device/IP overlap with gifters) even if auto-approvable.
  • New-host cap already shipped: ≤ $100/week for accounts < 30 days.
  • Refund-rate breaker: if a host's trailing-30-day IAP refund rate on received gifts exceeds 5% of gross, payouts pause pending review -the 72h hold catches fast refunds, this catches slow ones.
  • Every hold/release is a ledger row; support answers "where is my money" from the ledger page, not from tribal knowledge.

Host-facing summary (the one-screen rules)

Everything above exists to make this short paragraph true. This is the entire contract a host actually sees.

Minimum $25. Weekly payouts every Monday after approval. First payout needs identity verification. New accounts: $100/week for the first 30 days. Changing your payout method pauses payouts for 7 days.

That paragraph is the entire user-visible contract; everything else on this page is machinery to make it true.