Payout Process

Purpose

The mechanics of actually getting money out of Paddle and into a real bank account — implementation detail behind Money Flow's "Instant Split vs. Bank Payout Timing."

Creator Payout

1. Background job (02. Background Jobs) periodically checks which creators have wallet_balance_cents >= 5000 ($50)
2. For each, trigger a Paddle payout to their linked bank account (mechanism unconfirmed — depends on Paddle for Platforms actually supporting per-creator payout the way Stripe Connect did; flagged as an open item in 02. Architecture Decision Log, not yet resolved)
3. On the payout-completed webhook, mark the Payout row as paid and notify the creator (01. Business Logic → Notification Logic)
4. On payout failure, retry per the Payout State Machine, and alert Admin if failures repeat

Merchant Payout

• Rides Paddle's own standard payout schedule (not a custom SellVia job) — simplest implementation, consistent with the "not threshold-gated" decision in Money Flow

Open Questions

• Exact batch frequency for the creator payout job (already flagged as open in 02. Background Jobs — not duplicating here, just noting the dependency)

Update (2026-08-23): Paddle Removed, Swich Confirmed

Founder decision: Pakistan-only market, no Paddle ("instead of paddle or anything"), Swich (swichnow.io) confirmed as the processor same day. Full reasoning: 02. Architecture Decision Log.

Creator Payout, revised:

1. Background job periodically checks which creators have wallet_balance_cents >= [PKR threshold — not yet re-specified for the currency change, flagged as an open item in 01. User Flows' 2026-08-23 update]
2. For each, the job calls Swich's payout/disbursement API — routed to whichever method the creator registered at onboarding (bank account, JazzCash, or EasyPaisa; Raast where Swich supports it for that route)
3. On Swich's payout-completed webhook, mark the Payout row paid and notify the creator (01. Business Logic → Notification Logic) — same trigger point as the Paddle-era design, different processor
4. On payout failure, retry per the Payout State Machine, same as before — Swich's own failure-webhook payload determines what "failure" means here; exact mapping not yet done (integration detail, not a design gap)

Merchant Payout/Billing, revised: there is no separate merchant payout under the current external-tracking model — merchants collect their own revenue via their own Shopify checkout. The money movement on the merchant side is SellVia billing the merchant through Swich (a payment request the merchant completes, not a payout SellVia sends them) — that flow lives in 05. Payment Flow's Billing Cycle mechanism, not here.

Creator bank/wallet-account collection: happens at Creator onboarding (§2.4 in FEATURE_LIST.md) — a plain form (bank account or mobile-wallet details) that feeds Swich's payee registration, replacing the old "Paddle seller onboarding — KYC, bank details" step. Exact fields Swich's payee-registration API actually requires are unconfirmed pending real integration — the schema in 03. Table Specifications is a working draft.

Not a Merchant of Record: Swich moves the money; it doesn't collect creator tax forms or handle withholding the way Paddle's own seller onboarding once implied it might. Whether any Pakistan-specific tax collection is needed at this same onboarding moment is still open — see 05. Tax Considerations.