Take payment — and keep the record of what was paid for

Payments feel like the scary part, so the instinct is to reach for Stripe, wire the checkout, watch a test charge succeed, and file billing under done. The card handling really is done — that part you should rent and never think about again. But "we can take money" and "we have a billing product" are two different claims, and the line between them is exactly where this gets decided.

What the capability gives you

A payment provider — Stripe, or any of its peers — does a genuinely hard job and does it so you don't have to. It takes the card, carries the compliance burden of touching card numbers, runs the hosted checkout, manages the subscription lifecycle, retries a failed renewal, and sends the card-declined email. Rebuilding any of that yourself would be a mistake. This is the clearest kind of capability to rent: high stakes, well-solved, and not your product.

So the model is right. The question is what you keep on your side of it.

What stays yours, and what doesn't

The provider owns the money movement and the card data. You own the meaning of a payment — what a paid plan actually entitles a person to do. That entitlement is a product decision, and it lives in your code, never in a setting on a billing dashboard. "A Pro subscriber can run the screener" is a sentence about your product; the fact that money changed hands is a sentence about Stripe. Keep them in different places, owned by the side that understands them.

And you keep a local record of the facts you will be asked about: who is on which plan, when they started, what they were charged, when a charge failed. Stripe holds all of this too — but reachable only through an API call, on their schedule, shaped their way. The copy your product reads from, and answers questions from, should be yours.

What breaks when it's hacked in

The failure mode has one shape: the provider becomes the only record. Everything below is a consequence of that.

A support email arrives — "I paid, why am I locked out?" — and answering it becomes an API spelunking session instead of reading a row in your own database. Entitlement that's decided by calling the provider on every request couples your product's core behaviour to a third party's uptime and rate limits; when they're slow, your app is slow at the worst possible moment. And reconciliation — confirming the money you think arrived actually arrived — has nowhere to happen, because there are no two records to compare. None of this shows up in the demo, where one person pays once and it works. It shows up the first month real people are paying real money.

Where it already runs

This isn't theoretical for the foundation. CompanyGraph takes subscription payments through Stripe today, wired exactly this way: the provider runs the card, and a local mirror of subscriptions and transactions lives in CompanyGraph's own database. The webhook updates that mirror; the product reads the mirror, not the webhook. Entitlement — what a subscriber is allowed to do — is enforced locally, which is why the admin can answer "what is this customer paying for" without leaving the building or waiting on an external call.

The Stripe integration was a few days of work. The part that makes it a billing product — the entitlement model and the local record — is the part that lasts, and it's the part a foundation should already carry.

Where it shows up in a build idea

Almost anything that charges money rides on this: a B2B billing dashboard, event ticketing, a market-data alerter. In each one the payment call is small and nearly identical; the product is the entitlement model and the local mirror underneath it. The capability note that pairs with this one — what has to stay yours when the model is someone else's — makes the same argument about a different rented capability, because it's the same argument every time: rent the hard external job, own the record that says what it means.

---

Billing wired this way is part of the foundation — the same Stripe integration runs CompanyGraph's subscriptions today. It's also the spine of build ideas like a market-data alerting service, where the alert is the feature but the subscription is the business.