# Payments

🟢 **Decided 2026-06-13.** Drop ThriveCart. Process payments **directly through
Stripe and PayPal** from the Super System's own Commerce module.

> Part of the [Commerce module](README.md). See also
> [reconciliation-with-bruce-kb.md](../03-architecture/reconciliation-with-bruce-kb.md)
> (Bruce's KB also calls for a custom cart → Stripe/PayPal).

---

## Decision
- **No more ThriveCart.** It's the rented checkout we're replacing.
- **Stripe = primary processor.** Apple Pay, Google Pay, Klarna, cards all arrive
  via Stripe.
- **PayPal = second processor**, offered alongside Stripe at checkout.
- Both run through **LAFF's own Stripe & PayPal accounts** — no middleman.

## Why this is the right call (grounded in current data)

Real split of paid revenue today (ThriveCart orders, `status=1`):

| Method (today) | Orders | Gross | Share |
|---|---|---|---|
| **Stripe** | 16,720 | ~$4.04M | ~51% |
| **ThrivePay** | 8,860 | ~$2.12M | ~27% |
| **PayPal** | 7,865 | ~$1.76M | ~22% |
| stripe_v2 | 1 | ~$260 | — |

- **Stripe is already the biggest channel (~$4M).** Going Stripe-first matches
  what customers already use and trust.
- **"ThrivePay" is ThriveCart's white-labelled processor — Stripe/PayPal
  underneath.** When ThriveCart goes, ThrivePay goes with it; that ~$2.1M of
  volume simply re-routes through **our own** Stripe/PayPal accounts. It is *not*
  a third gateway to build.
- ⇒ **Stripe + PayPal directly covers 100% of current payment behaviour.** No
  customer payment habit gets orphaned by the migration.

## What this means for the build (Commerce module)
- Integrate **Stripe** (Payment Intents; Apple/Google Pay & Klarna come free with
  Stripe's payment element) and **PayPal** (Orders/Subscriptions API).
- **Refunds from inside the system** (both processors support API refunds) — a
  stated requirement; ends logging into ThriveCart to refund.
- **Webhooks**: handle Stripe & PayPal event webhooks (payment succeeded/failed,
  refund, dispute) → write to our order ledger. This is the *only* inbound
  webhook traffic we keep (internal-by-default elsewhere).
- **One product, many pricing options** drives a unique checkout per option, one
  product underneath (see [business-requirements](business-requirements-from-bruce-kb.md)).

## Open sub-questions (don't block the decision)
- [ ] **Subscriptions / recurring?** Are any LAFF offers recurring (annual/
      lifetime add-ons exist)? If yes, we need Stripe Billing + PayPal
      Subscriptions (renewals, dunning, proration). If all one-time, much simpler.
      → see [open-questions.md](../00-index/open-questions.md).
- [ ] **Saved cards / tokens migration.** Can existing customers' saved payment
      methods move off ThriveCart, or do recurring/repeat buyers re-enter card
      details on first purchase in the new system? (Stripe supports importing
      tokens via a data-migration process; PayPal billing agreements are trickier.)
      → a real migration task to scope.
- [ ] **Currency** — all orders are USD so far; confirm single-currency.
- [ ] **PSP credentials/accounts** — confirm LAFF's own live Stripe & PayPal
      accounts (not ThriveCart-linked) and API keys (stored in env, per security).

## Migration safety (the $7.9M part)
- This is **Phase 3** (commerce cutover) — the highest-risk migration.
- **Dual-run:** keep ThriveCart live while the new checkout is built & verified;
  reconcile daily; flip the public "buy" buttons only after clean reconciliation;
  keep a one-click rollback. (See
  [../05-migration/strategy.md](../05-migration/strategy.md) and
  [../03-architecture/phasing.md](../03-architecture/phasing.md).)