Stripe is live. Here is exactly how it works.

02 · Production state

Source of truth: artifacts/soldi-completion-2026-07/COMPLETION_TRACKER.md rows P1 (GREEN) and P2 (IN_PROGRESS), with receipts under artifacts/soldi-completion-2026-07/shots/. Live QA re-probe 2026-07-06: POST /api/v1/payments/deposit → 409 stripe_checkout_required; POST /api/v1/wallet/checkout → mode:"stripe_live" + checkout.stripe.com URL.

03 · How to operate

Add funds (buyer wallet top-up)

• Stripe absent (local dev, no secrets): Billing's Add Funds hits POST /payments/deposit → instant fixture credit.
• Stripe configured (production): the same call returns 409 stripe_checkout_required; the client calls POST /wallet/checkout and redirects to hosted Checkout. Webhook credits the wallet; the return URL /billing?checkout=success refreshes once and cleans the query.

Webhook idempotency

Every funding event claims a row in processed_stripe_events via INSERT … ON CONFLICT(event_id) DO NOTHING; a replay/resend that changes 0 rows is acknowledged but credits nothing. Safe to resend from the dashboard at any time.

Card management + refunds

Cards: POST /wallet/portal → Stripe Billing Portal (the local POST /payment-methods is 410-gone). Refunds are wallet-ledger refunds, not card refunds: buyers file via RefundModal; admins decide via GET /admin/refunds + POST /admin/refunds/:id/decide (app/worker/routes/admin-refunds.ts L84/L114; replay of a decision 409s).

bunx wrangler secret list --config app/wrangler.jsonc
bunx wrangler secret put STRIPE_SECRET_KEY --config app/wrangler.jsonc
bunx wrangler secret put STRIPE_WEBHOOK_SECRET --config app/wrangler.jsonc

04 · Testing recipes

Test mode only. Never complete a live-mode charge from QA. Do not create new Stripe Customers for the demo account — reuse is the invariant under proof.

• Test cards: 4242 4242 4242 4242 (success) · 4000 0000 0000 9995 (decline) · 4000 0025 0000 3155 (3DS challenge). Any future expiry / any CVC.
• Dashboard resend: Developers → Webhooks → endpoint → pick the event → Resend. Expect 200 and no double credit (check wallet_transactions).
• Gate probe (no money moves):

curl -sL -c jar -X POST https://app.soldi.cc/api/v1/auth/login \
  -H 'content-type: application/json' \
  -d '{"email":"demo@soldi.cc","password":"soldidemo"}'

# fixture path must 409 while Stripe is configured
curl -sL -b jar -X POST https://app.soldi.cc/api/v1/payments/deposit \
  -H 'content-type: application/json' -d '{"amountCents":1000}'

# live gate: expect mode "stripe_live" + checkout.stripe.com URL
curl -sL -b jar -X POST https://app.soldi.cc/api/v1/wallet/checkout \
  -H 'content-type: application/json' -d '{"amountCents":1000}'

An unvisited Checkout session simply expires — creating one is a safe, non-destructive probe.

05 · Open decision — P2 duplicate Customer

Stripe test mode holds two historical Customers for demo@soldi.cc; the older one predates the PR #123 reuse fix. The app persists and reuses cus_UouKZd8WGskgex. Post-fix proof shows no third Customer is ever created. Pick one:

Option A — delete the duplicate

• In the authenticated Stripe dashboard (test mode), search Customers for demo@soldi.cc.
• Delete only the customer that is not cus_UouKZd8WGskgex.
• Re-run the portal probe (POST /wallet/portal) and confirm exactly one Customer remains → mark P2 GREEN in the tracker.

Option B — accept as documented artifact

• Say so explicitly; the tracker terminal becomes PARKED_STRIPE_ACCEPTED with the decision packet (shots/p2-stripe-duplicate-decision-packet-20260703.txt) as the record.

Either option unblocks the final Zak wrap ("Text 2" — drafted in SHARE_WITH_ZAK.md, gated). Nothing else in the payment rail waits on this, and it does not block beta testers. Safe default if undecided: Option B posture. Beta note (recommendation, pending Cam's ratification): the rail stays in test mode for the beta — testers fund wallets with test cards; no real money moves. Full decision table: docs/plans/mvp-build-public-release/BETA_READINESS.md §5.

06 · Why not Clerk Billing

Reversal condition: only if Clerk ships a real wallet/payments product (arbitrary amounts, escrow/payout primitives, non-Clerk billing subjects). None exists as of 2026-07. Full ADR: docs/content/DECISIONS.md § 2026-07-06. Note: the original "Clerk" idea may have conflated Clerk with Stripe Billing/Connect.

07 · Future — seller payouts via Stripe Connect

Gated on Decision #0 (docs/content/prd/SUPPLY_SIDE.md §3): lead marketplace vs principal/committed-offer. No money-out rails are built, and none should be until Cam decides — payout semantics and seller-facing status promises both hang on it.

• Documented path: Stripe Connect with manual payouts (platform controls timing) and connected-account reserves (hold-back for refund risk).
• When Decision #0 lands, spec first (SUPPLY_SIDE PRD), then Express onboarding → manual payout schedule → reserve policy.

08 · Curated Stripe docs

• Checkout overview · Checkout quickstart
• Webhooks — incl. async signature verification for Workers-style runtimes (Soldi already implements the fetch httpClient + async verify pattern)
• Billing Portal · Refunds
• Connect · Manual payouts · Reserves
• Testing / test cards