pitch.payments.do
Payments as verbs, not a project.
The money-in service of the estate's business layer — charge, subscribe, invoice, refund as callable verbs, behind a front door that serves today and answers in JSON before it answers in prose.
↓ scroll · arrow keys
A builder whose product already sells — customers exist, revenue exists — is offered everything except collection at the unit they need: a payments platform to integrate, a dashboard to operate, subscription states to reconcile, invoices to chase, refunds to process, webhooks to babysit. The charge takes milliseconds; collecting revenue is apparently a department. The prevailing money-in product sells the back-office around the verb and prices the builder into staffing it.
The tax lands hardest exactly where the estate's whole premise lives: on businesses too small to carry a billing function. The platform layer's thesis is that infrastructure must become a metered call rather than a hired department — and money-in is the department every revenue-earning business is forced to hire first. If the charge, the subscription, and the refund are not verbs, the smallest viable business stays larger than it needs to be by exactly one back-office.
Three things in this estate are the substrate itself: the studio, the platform, and the runtime. This is deliberately not a fourth. payments.do is a service of the business layer the platform operates — and the lead of a four-service fin-stack the estate's registry files behind it: accounts, cards, treasury, accounting, every one P0 and pro-tier, every one still planned while payments alone is filed implementing.
The sequencing is the strategy: money-in leads because it is the verb a revenue-ready builder needs on day one, and the rest of the finance function follows through the same gateway as each door's gate flips. The stack is stated here at its filed state — the sibling apexes do not serve yet, and the ambers slide below says exactly that rather than letting "fin-stack" imply four live doors.
Resolve the apex cold — no login, no signup — and this is what answers
(excerpted from the live record; resolve payments.do for the full map):
GET https://payments.do
{
"api": "payments.do",
"version": "0.2.0",
"status": "ready",
"connect": "Pass Stripe-Account header to scope API calls to a connected account",
"endpoints": {
"customers": { "create": "POST /customers", "...": "..." },
"subscriptions": { "create": "POST /subscriptions", "pause": "POST /subscriptions/:id/pause", "...": "..." },
"charges": { "create": "POST /charges", "...": "..." },
"invoices": { "create": "POST /invoices", "finalize": "POST /invoices/:id/finalize", "...": "..." },
"products": { "...": "..." },
"prices": { "...": "..." },
"refunds": { "create": "POST /refunds" },
"webhooks": "POST /webhooks"
}
}
The apex is machine-addressed by construction: it answers a caller — human or agent — with its own versioned endpoint map before any prose. Nine verb families cover the money-in function: customers, subscriptions, charges, invoices, products, prices, refunds, checkout, and webhooks. Calls scope per connected processor account, so the records are the tenant's and the licensed edge stays where the licenses are.
payments.do serves this record today: version 0.2.0, status ready,
the endpoint map above, and the connected-account scoping note — checked
cold on 2026-07-30. Serving the map is a liveness fact about the
surface, not a claim that any external tenant transacts on it.
Metered per call is the intended model, and the rate card IS the pricing surface: it binds when it posts alongside this map — verbs, protocol, rate card, guarantees — not before, and never as prose in a deck. The registry files the domain pro-tier; no figure is published or implied until the card posts.
Concreteness over adjectives: each door below was checked cold on 2026-07-30 and carries its own state and its own evidence URL — never one URL evidencing several domains. Serving is a liveness fact, not a tenancy claim: nothing here asserts external tenants, production money movement for third parties, or a volume roll. Those publish behind their own gates.
payments.do serves — the apex answers its versioned, machine-readable
endpoint map to a caller with no login.
The gateway routes this service by name today: GET https://apis.do/payments returns a machine-readable service record —
no login — naming the service, its domain payments.do, its category
business, and its status available.
platform.do serves — the operator's front door, whose own record files
the business layer this service belongs to under the same claim
discipline.
functions.do serves — the sibling execution primitive, whose record
this one mirrors in structure and discipline.
agents.do serves — the sibling runtime whose agents are the machine
callers this apex is addressed to.
The ambers below are the exact distance between what serves and what this door intends to be — each a checkable gate, none blended into present-tense marketing.
The gateway's own service record lists an alternate machine door,
payments.do/api — and today that path returns an error envelope, not
the map. A machine following the gateway's also link finds a door
that fails to open. The claim flips when the path serves what the apex
serves.
The fin-stack behind this lead does not serve yet: all four sibling
apexes returned HTTP 500 when checked cold on 2026-07-30 — while the
gateway files each as a named service with status available. Two
estate surfaces disagree, and this record reports the disagreement
rather than citing the flattering one. The stack is real in the
registry and the gateway; it is not yet real at its own doors.
The estate's own registry files this domain at status implementing
— while the apex self-reports ready. The estate does not round up its
own registry: the filed state is reported here at face value, and this
claim flips when the registry does.
Money transmission is a licensed function. This layer does not hold those licenses and does not pretend to: the apex's own connect note scopes every call to a connected account at a licensed processor, so the regulated humans in the money path — compliance, licensure, sponsorship — are the processor's, held under the processor's licenses. What this layer owns is the verb surface and the tenant's records.
The estate's doctrine is blunt about borrowed supply: a regulated dependency you do not own is a seam you must name. Here it is named. The mitigation is architectural — the tenant's interface is the verb map, not the processor, and the scoping seam is designed so the processor behind the verbs is an implementation detail of the layer rather than the tenant's integration. The dependency is real today; the record states it instead of wearing it silently.
The dependency is visible in the record itself: the live apex's
connect field instructs callers to scope requests to a connected
processor account. This deck quotes the surface rather than
characterizing it.
Primary motion is B2D: the buyer is a developer who evaluates by resolving the apex — which already answers the full endpoint map with no login — and converts at the first successful charge against a scoped account. No sales motion, no demo call, no procurement. Secondary is B2A, and this door starts closer to it than most: the apex is machine-addressed by construction, and the gateway already returns this service's record to an agent with no login — so the discovery leg of the machine motion serves today. Purchase and settlement for the machine motion gate on the posted rate card, exactly as the sibling records state for theirs.
Business-layer economics: fixed cost is operating the verb surface; each additional tenant and call is served at near-zero marginal cost above the rail, so blended margin improves with occupancy — while the processor's per-transaction cost passes through the layer rather than being staffed inside it.
Honesty about the floor: unlike the pure compute layers, a payments path carries a real per-transaction cost — the licensed rail's processing fees. But that floor is a fee, not a headcount: it prices through the layer instead of being staffed inside it, and nothing in operating the verb surface itself reserves a step for a statutory person on this side of the seam. The layer's own implementation mix migrates toward Code; the statutory humans in the money path remain the processor's, on the processor's side, priced per transaction.
Tenant counts, call volumes, processed totals, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish.
the estate’s own stack is wired to collect through this service — the live endpoint map itself carries an estate checkout route, occupancy visible in the record rather than asserted in a deck; whether and how much moves through it, like the tenant roll, publishes behind the stack#1 §A5 gate or not at all
the estate’s gateway already routes /payments as a named service to a machine with no login — when the buyer is an agent, being discoverable and callable IS the distribution channel
the front door answers a versioned endpoint map before any prose — the evaluation surface and the product surface are the same URL, so the cost of a first integration is one cold request
accounts, cards, treasury, and accounting are filed behind the same gateway seam — a stack held at its honest filed state today, and a compounding one as each gate flips; the builder who starts with charges never re-integrates to grow into the rest
Serving is a liveness fact, not a tenancy claim: each posted URL below evidences that one door resolves — not that anyone transacts on it.
payments.do serves — the apex answers version 0.2.0, status ready,
and the full endpoint map to a cold caller.
apis.do/payments serves machine-readable JSON — the gateway's service
record for this door resolves for a machine with no login, status
available.
platform.do serves — the operator of the business layer is live.
The alternate machine door the gateway advertises returns an error envelope today — the nearest gate, and the cheapest to flip.
The fin-stack behind the lead is filed, gateway-routed, and not yet serving at its own doors — HTTP 500 at all four apexes, checked cold 2026-07-30.
The claim that matters — a real external tenant's charge created, settled, and webhook-confirmed through this surface at the posted card — posts when it has happened, with the record in evidence. Until then, this deck claims a serving surface and nothing more.
The front door is payments.do — it serves today, and it answers in
JSON.
If this was forwarded to you: payments.do is the money-in service of the startups.studio estate's business layer — the lead door of a four-service fin-stack (accounts, cards, treasury, accounting) filed behind it in the estate's own registry. It is deliberately not one of the estate's three substrate properties, and its deck says so; it is the first finance verb the platform's tenants call, sold to the builder who has revenue to collect and refuses to staff a billing department to collect it. What is live is posted with a URL checked cold — the apex that answers in JSON, the gateway record, the operator's door; what is not is pending with the gate that flips it — the alternate machine door, the sibling apexes still dark, the unposted rate card, and the first external settlement. Judge it by what is posted, and by how plainly it labels what is not.