Money Flow

Purpose

Track the full lifecycle of a dollar from a sale to a creator's bank account.

REVERSED 2026-08-07: External-Site Tracking, Not SellVia-Hosted Checkout

This entire doc previously described SellVia-hosted checkout. That model is superseded. The founder made a deliberate, informed decision to switch to external-site attribution (customer buys on the merchant's own website), which reopens the money-collection problem the hosted-checkout model was specifically built to avoid. See 02. Architecture Decision Log for the full history of this reversal.

Confirmed Flow (2026-08-07)

Follower clicks creator's link
  ↓
SellVia records the click, redirects to the merchant's own website
  (tracking parameters attached, UTM-style)
  ↓
Customer completes purchase on the MERCHANT's own checkout —
  SellVia is not involved in this transaction at all
  ↓
Merchant's site reports the sale back to SellVia
  (webhook, tracking pixel, or integration — merchant-side dependency)
  ↓
Sale recorded as "reported" — NOT "verified" the way hosted checkout meant it.
  SellVia is trusting the merchant's report, not witnessing a payment directly.
  ↓
Commission + platform fee calculated and recorded as OWED, not split live
  (no live transaction exists for Paddle to split)
  ↓
Accumulates in a running ledger per merchant until the next billing cycle
  ↓
Periodically (weekly/monthly): SellVia charges the merchant's card on file
  for everything owed that cycle (commissions + platform fee, bundled)
  ↓
On successful charge: SellVia pays creators out of its own collected funds
  (creators still need Paddle accounts to receive payouts,
  just funded by SellVia's billing collection, not a live per-sale split)
  ↓
Receipt generated — shown to both parties, though it now reflects
  "reported and billed," not "instantly verified"

Why This Reopens the Trust Problem Hosted Checkout Was Built to Avoid

Worth being direct about this, since it's the actual cost of the decision: when SellVia processed payment directly, "verified" meant SellVia witnessed the payment succeed — no ambiguity, no trusting anyone's word. Now, SellVia is dependent on the merchant's own site correctly and honestly reporting sales. This reintroduces:

• Cookie/tracking reliability issues — Safari/Chrome increasingly block third-party tracking, which can break UTM/pixel-based attribution matching
• Merchant under-reporting risk — a merchant could (accidentally or deliberately) fail to report a sale to avoid owing commission; see 04. Fraud Prevention, which needs new rules for this specific risk that didn't exist under hosted checkout
• Integration dependency — attribution now depends on the merchant correctly implementing a webhook/pixel, not something SellVia fully controls end-to-end

Money Collection Mechanism: Billed Periodically (confirmed 2026-08-07)

Merchant's card on file is charged on a recurring cycle for all commissions + platform fee accumulated since the last billing cycle — not per-transaction, not pre-funded balance.

Creator Payout Sequencing: Bill First, Then Pay (working default, please confirm)

Between billing cycles, SellVia would technically owe creators commission on sales not yet billed to the merchant. Default: SellVia does NOT front this money — creators are paid only after the corresponding merchant billing charge succeeds. This is the lower-risk choice (SellVia never carries uncollected float), at the cost of creators waiting slightly longer for sales near the end of a billing cycle. The alternative (pay creators immediately, collect from merchant after) would mean SellVia absorbing real collection risk if a merchant's card fails or they dispute the charge — not chosen as the default, flag if this should be reconsidered.

Refunds Under This Model

A refund now has to be reported by the merchant too (SellVia has no direct visibility into the merchant's own checkout). The existing rule (creator never loses commission, per 01. Commission Engine) still applies — a reported refund reduces what's billed to the merchant in future cycles, or if already billed, becomes a credit adjustment on the next cycle rather than an instant Paddle transfer reversal (which no longer applies, since there's no Connect transfer to reverse).

Payout Threshold (creator side)

$50 still applies — creator balance accrues from successfully-billed commission, bank payout triggers once it crosses $50. Unchanged in principle, changed in what "accrues" means (post-billing, not per-sale-instant).

Open Questions

• Who can initiate a refund — merchant self-service, Admin-only, or both — still genuinely open

Update (2026-08-07): Merchant Integration Question RESOLVED

The "merchant integration mechanism" open question above is resolved: a universal onboarding tracking snippet (one script, installed once on the merchant's confirmation page), not a bespoke webhook or platform-specific integration. Full detail in 05. Payment Flow.

Update (2026-08-07): Billing Cycle Length RESOLVED — Monthly

Founder-confirmed: monthly billing cycles. Each BillingCycle spans one calendar month (or a rolling 30-day period from signup — exact anchor still to be decided during implementation, doesn't block the design). Removes this item from Open Questions.

Update (2026-08-07): CORRECTED — Refund Is a Billing Credit Request, Capped at 5/Month

Founder-confirmed, replaces the earlier "unlimited automatic refund reporting" framing above, which was wrong. The customer's actual refund happens entirely on the merchant's own site — SellVia is never involved in that. What "refund" means on SellVia's side is specifically: the merchant requesting a billing credit for a sale that was already tracked, billed, and paid out to the creator.

Same underlying reasoning as 05. Chargebacks' 5-dispute grace allowance: once a creator has been paid their commission, SellVia cannot claw it back (already locked in, 01. Commission Engine). So every credit SellVia grants a merchant for an already-paid-out sale is a direct loss SellVia absorbs itself — not something that can be passed back to the creator.

Rule:

merchant_profiles.monthly_refund_credits_used  (counter, resets each calendar month)

On refund credit request:
  if monthly_refund_credits_used < 5:
    SellVia issues a credit on the merchant's next billing cycle
    (SellVia absorbs the loss \u2014 creator commission already paid, non-recoverable)
    counter increments
  else:
    No credit issued \u2014 merchant already paid SellVia for this sale, that stands
    (merchant's own refund to their customer is unaffected either way \u2014
    this only controls what merchant owes SellVia, not what happened on their site)

Why monthly, not lifetime like the chargeback allowance: founder specified "5 times monthly" explicitly here, distinct from Chargebacks' lifetime counter — refunds are a more routine, expected part of running any e-commerce business (unlike chargebacks, which are adversarial), so a resetting monthly allowance fits better than a one-time lifetime grace.

What This Replaces

The earlier "automatic snippet-based refund reporting, unlimited" framing on this page is superseded — there's no automatic refund event to hook into in the way sale reporting works, because SellVia was never part of the refund transaction to begin with. This is a merchant-initiated billing credit request, capped, not an automated pass-through.

Open Questions (Update)

None — refund handling is resolved as a capped billing credit request (05. Refund Handling), not an automated pass-through.

Update (2026-08-23): MAJOR REVISION — Pakistan/PKR Only, Shopify Webhook Replaces Snippet, No Paddle

Founder decisions, full reasoning in 02. Architecture Decision Log. This corrects the Confirmed Flow diagram and every Paddle mention above.

Revised flow (replaces the Confirmed Flow diagram above):

Follower clicks creator's link
  ↓
SellVia records the click, redirects to the merchant's Shopify store
  (tracking parameters attached)
  ↓
Customer completes purchase on the MERCHANT's Shopify checkout —
  SellVia is not involved in this transaction at all
  ↓
Shopify fires an `orders/paid` webhook → SellVia (POST /webhooks/shopify-sales)
  — Shopify-only for MVP, not a generic snippet/pixel (reverses the 2026-08-07
  "universal onboarding snippet" resolution below)
  ↓
Sale recorded as "reported" — SellVia is trusting Shopify's webhook payload,
  not witnessing a payment directly. (Same trust posture as before; the
  mechanism reporting it is now Shopify's own webhook, more reliable than a
  JS snippet since it fires server-side.)
  ↓
Commission + platform fee calculated and recorded as OWED, in PKR
  ↓
Accumulates in a running ledger per merchant until the next billing cycle
  ↓
Monthly: SellVia's backend creates a Swich billing-cycle invoice/payment-link
  for everything owed that cycle (commissions + platform fee, bundled)
  ↓
Merchant pays through Swich (card, bank transfer, JazzCash, or EasyPaisa,
  whichever Swich's checkout offers) → Swich webhook confirms → cycle
  marked `charged`
  ↓
On confirmed charge: SellVia triggers a Swich payout/disbursement to each
  creator owed from that cycle (bank, JazzCash, EasyPaisa, or Raast,
  per the creator's registered payout method) — no Paddle account needed
  on either side
  ↓
Receipt generated — shown to both parties, in PKR, unchanged in spirit

Market/currency: Pakistan-only, PKR only — replaces any implicit USD framing above.

Merchant integration mechanism — RE-RESOLVED: the 2026-08-07 update below ("universal onboarding tracking snippet") is reversed for MVP. "For now we are just going with Shopify only" — the mechanism is Shopify's native orders/paid webhook, not a snippet. The snippet approach returns as the relevant mechanism only if/when SellVia supports non-Shopify merchants (Full Product Vision (Post-MVP)). Full detail: 05. Payment Flow (updated 2026-08-23).

Money collection mechanism — RE-RESOLVED (confirmed 2026-08-23, same day as the removal above): "Merchant's card on file is charged on a recurring cycle" (section above) no longer means Paddle — it means Swich. SellVia generates a billing-cycle invoice through Swich, the merchant completes payment through Swich's checkout, and a webhook confirms it. This is a real vendor with retry/failure webhooks of its own, not a manual admin-chases-a-bank-transfer process — the "who retries a failed billing attempt" gap the interim bank-transfer default left open is largely Swich's problem to signal, though SellVia's own escalation policy (auto-pause after N failures, matching the old Paddle behavior) still needs designing against Swich's actual failure-webhook shape — flagged in MVP Scope's Still-Open Items.

Creator payout: same bill-first-then-pay sequencing, same $50-equivalent threshold logic (though the $50 figure itself needs re-specifying in PKR — flagged as an open item in 01. User Flows, 05. Payout Process, 05. Wallet Design), now paid via Swich's payout/disbursement API instead of a Paddle payout trigger — explicitly marketed by Swich for "commission payouts," which is this exact use case.

Refunds: unchanged in mechanism (merchant-requested billing credit, capped at 5/month, creator commission never clawed back) — the credit now nets against a future Swich billing-cycle invoice instead of a Paddle charge, no other change.

Not a Merchant of Record: unlike Paddle, Swich is a payment processor/gateway — it moves money, it does not become the legal seller of record or absorb SellVia's tax obligations. See 05. Tax Considerations for what this means in practice.