The Money Path Is a Protected File.
My billing system was built almost entirely by AI agents, and no AI agent is allowed to touch it. That is not a contradiction. It is the architecture. Orbyt One is the unified account and payment layer across every Orbyt product, one Stripe integration underneath, and its money path is a protected surface no agent modifies unprompted.
Here is how the whole thing works, receipts included.
What is Orbyt One?
The answer customers see: one account, every Orbyt product. Sign in once and the plans, invoices, payment methods, add-ons, active sessions, security settings, and data export for Orbyt Jobs and Orbyt Intelligence live in a single dashboard. Nobody should manage three billing relationships with one company.
The answer under the hood: a single Stripe integration serving the whole family. One customer record, per-product subscriptions, shared invoice history, one place a card gets updated. Consolidating payments was the reason Orbyt One exists; the account layer grew around the money.
A product family without a unified account layer is not a family. It is three strangers with the same logo.
Why is Stripe the single source of truth?
Because two authorities on money will eventually disagree about money, and a billing disagreement is a support ticket with a lawyer attached.
So Orbyt One follows one rule everywhere: mirror, never own. All subscription and invoice state in my database is upserted from Stripe webhook events. The application can ask Stripe to change something, a plan change, a pause, a cancellation, but the request does not make it true. The signed event coming back does. The webhook handler is the only writer of billing state.
That handler processes 16 event types: subscription lifecycle, invoice lifecycle, payment failures, refunds, disputes from opened through funds withdrawn to closed, expiring cards, checkout completion. Each one lands as an idempotent upsert, so an event applied twice converges instead of corrupting.
What does the money path actually contain?
Measured on August 21, 2026: the money path is 5,760 lines across 20 billing API routes and the webhook layer, referenced by 146 files, checked by 609 tests in 40 dedicated test files. All of it written with Claude Code, under instruction, through the same gauntlet as every other line.
The routes are the visible part: subscriptions, plan changes with proration preview, pause, resume, cancel, reactivate, coupons, retention offers, one-time purchases, the billing portal. The webhook layer is where the real engineering lives, in three unglamorous mechanisms.
Dual-signature verification. Live and test events verify against different signing secrets, and whichever secret verifies decides the mode for that request. Mode is resolved per request and threaded explicitly, never stored in module state, because a test event must not flip a live one mid-flight.
Two-tier idempotency. Stripe retries failed deliveries for days, so dedup is durable Postgres with a Redis fast path on top. Cache-only dedup fails exactly when you need it: a Redis outage during a retry storm would replay every side effect, duplicate emails included. And when a handler throws, the dedup is released deliberately, so the retry actually reprocesses instead of being swallowed as a duplicate.
Quarantine. Some events can never succeed, a foreign key pointing at a deleted user, a constraint violation. Retrying a poison event for days risks Stripe disabling the endpoint, which would halt billing sync for every customer at once. So permanent failures are quarantined: recorded, acknowledged, kept out of the retry loop, surfaced to me.
None of this is clever. All of it is the difference between billing and a demo of billing.
Why is the money path protected from the agents that built it?
Because the boundary is drawn by consequence, not by capability.
My agents write product surface all day inside a permissions threat model where none of 12 seats can merge to the branch that deploys. The webhook directory goes further: it is a protected surface, off limits to any agent without an explicit human instruction naming it. An agent can propose; only a person can decide that the money path changes.
The reasoning is the same one behind failing closed: a wrong line in a marketing page is a bad afternoon, and a wrong line in a webhook handler is a wrong charge on a real card. Same fleet, same codebase, different blast radius, different rules. The agents supply volume. The boundary supplies trust.
Why ship the whole thing before taking a dollar?
Because the money path is the one part of a product you cannot iterate on in public.
As I write this, the system sits behind an early-access waitlist: billing verified end to end in Stripe's sandbox, production cutover held behind a single switch. Flipping it is one line. Everything this post describes, the mirror principle, the dedup tiers, the quarantine, the 609 tests, exists on the unpaid side of that switch, built before the first live charge instead of after the first live incident.
That order is the entire point. You earn the right to charge people by finishing the failure handling first. The features took days. The trust took the rest, and the working product is the validation either way.
Every feature can apologize its way through a bad week. A billing system cannot.
What to do Next
If you are building billing with AI agents, three rules transfer directly.
Make the processor the source of truth and mirror it. Your database holds a copy of reality; Stripe holds reality. The webhook is the only writer, and every handler is an idempotent upsert.
Engineer for the retry, not the happy path. Assume every event arrives twice or never. Durable dedup, released on failure, with a quarantine lane for events that can never succeed.
And draw the agent boundary before the first live charge. Decide, in writing, which directories the fleet may never touch without a named human instruction. Mine is the money path. Yours will be too, the first time an agent proposes a confident edit to the code that charges cards.
Let the agents build the vault. Keep the only key.
Related reading:
- 391 Yeses and Not One No. the permissions model this boundary lives inside
- Metering the API for Agent Buyers what billing looks like when the customer is a machine
- Per-Seat Pricing Is Dying the pricing logic upstream of the plumbing
- The Working Product Is the Validation why finished beats launched
- Building Orbyt, Part 3: What Production Grade Actually Means what production grade actually means
Common questions
What is Orbyt One and how does its billing system work?
Orbyt One is the unified account and payment layer across every Orbyt product, letting customers sign in once to manage plans, invoices, payment methods, and data export for both Orbyt Jobs and Orbyt Intelligence in a single dashboard. Underneath, one Stripe integration serves the whole family, with one customer record and shared invoice history.
Why does Orbyt treat Stripe as the single source of truth instead of its own database?
Because two authorities on money will eventually disagree about money, and a billing disagreement becomes a support ticket with a lawyer attached. Orbyt One follows one rule everywhere: mirror, never own. All subscription and invoice state in the database is upserted from Stripe webhook events, and the webhook handler is the only writer of billing state.
Why won't Orbyt let the AI agents that built its billing system touch the webhook code?
Because the boundary is drawn by consequence, not by capability: a wrong line in a marketing page is a bad afternoon, but a wrong line in a webhook handler is a wrong charge on a real card. The webhook directory is a protected surface, off limits to any agent without an explicit human instruction naming it.
Related research
