Billing launch loose ends: stale Stripe events, a live prepay, two pricing decisions #195

Smaller follow-ups noticed during the billing launch (follows #139). Most of them need the owner.

• Two old live customer.updated events still show "pending" at Stripe, because their endpoints were deleted. Billing already handled them through the replay, so just confirm that Stripe gives up on them.
• Prepay was never exercised live. With the owner's OK, do a small live prepay and refund, then reconcile the ledger's top_up and tax_and_fees against the Stripe balance.
• Owner decision: the $5 month-end minimum. Reword it or drop it.
• Owner decision: is a prepaid balance refundable during the 30-day restore window?

Update the billing docs to match each decision.

Billing safety rules (non-negotiable)

Billing has been live on Stripe since 2026-10-15 and takes real money from real customers.

• Never run fixtures, seeds or the sandbox harness against the production Stripe account. Test only with the separate Stripe sandbox key and a local billing Worker (target/billing-audit). Its .dev.vars loads automatically, and --env-file does not bind secrets. The harness is scripts/ops/billing-sandbox.mjs (phases: protocol, seed, run, cleanup, lifecycle, enterprise, complimentary). Ask the owner for the sandbox key's location.
• Never print or commit secrets. Writing Worker secrets is the owner's job: hand them the exact command, in Git Bash syntax with single quotes and forward slashes.
• Any live charge, refund or change to a Stripe object needs the owner's explicit OK for that specific action.
• Pushing to main deploys production, migrations first and then the Workers. Every migration must be safe against the code already running.
• Billing's own API requests stay pinned to Stripe API 2025-02-24.acacia. The live webhook's events are listed in services/billing/src/webhooks.rs EVENTS.
• The owner's billing audit notes (docs/audits/2026-10-14-billing.md, local and ignored by Git) hold the "LIVE" section and the remaining launch gates. Ask for them if you don't have them.

Validation for every change

cargo test -p g1t-billing --lib (and -p g1t-repos for storage); cargo check of the workspace and of the changed services for wasm32-unknown-unknown; node --test --test-isolation=none conformance/*.test.mjs; the TypeScript checks and tests for anything touching apps/ or packages/; npm run test:deploy; build the actual billing Worker before running sandbox phases; git diff --check; and inspect what is staged for secrets and artifacts. Get an independent review of money-path changes before they are pushed. Report what was verified live and what was verified only in the sandbox.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.