Payments

Cofounder connects your company to Stripe. Agents start in a Stripe test sandbox, where they can build and try your checkout without touching your real account or charging anyone. When you're ready to take real money, connect your live Stripe account.

Check where things stand

Run this first. It shows whether the company has a test sandbox, whether you've claimed it, whether a live account is connected, and how far your app's payment setup has got:

Try it in a test sandbox

setup --mode test creates the company's Stripe test account, or returns the existing one. --country is the business's two-letter country code. When the sandbox needs claiming, the response's next steps carry a link for the founder to open in a browser and claim the sandbox under their own Stripe login; payments get returns that link again without starting over.

Connect your live Stripe account

setup --mode live returns a link the founder opens in a browser to approve the Cofounder Stripe App on their existing Stripe account. You don't need a sandbox first. Connecting doesn't turn on payments in your app by itself.

Never paste Stripe keys into chat or command arguments. These commands return a Cofounder link rather than a Stripe one; Stripe's own claim and dashboard links open only in your signed-in browser.

Test or live

Every command below works on the test sandbox unless you pass --mode live (mode: "live" on MCP), which needs live setup (payments setup --mode live) done first. In live mode, writes change your real Stripe account and customers can pay you real money.

On MCP, each Stripe write takes an idempotency_key; the CLI fills one in for you (--idempotency-key). If a write fails partway, retry with the same key so Stripe doesn't make the object twice. Stripe forgets keys after about 24 hours, so after that, check whether the first attempt went through before you retry.

Read your revenue

revenue get reads the company's money-in projection in one call: monthly recurring revenue per currency, gross/refunded/net charge volume over the last 30 days, the Stripe balance available and pending, and the five most recent payouts. Pass --since with the previous response's next_since to poll cheaply; it returns only the charges and refunds created since that cursor, so idle polls cost almost nothing and never skip a gap.

Sell a pricing plan

Declare the plans your generated app shows on its pricing page. The app reads active Stripe prices whose lookup keys match plan_<key>_month and plan_<key>_year (or a single plan_<key>_one_time price for a lifetime deal) and groups them into plans. A plan has either recurring prices or one one-time price, never both:

Amounts are in the currency's smallest unit, so 2900 in usd is $29.00. plans set creates or updates the plan product and its monthly, yearly, or one-time price; pass --dry-run to preview the changes without writing. A one-time plan uses --one-time '{"amount": 9900}' instead of --month/--year. Adopt an existing Stripe price by passing {"price_id": "price_..."} as the --month, --year, or --one-time value instead of an amount. plans remove archives a plan's prices and product; existing subscribers keep billing.

Prove a test payment works

payments verify proves in test mode that the deployed generated app can take a payment end to end: the synced test key matches the sandbox account, a ready deployment serves those keys, the billing block is reachable, plans resolve, the webhook points at the app, and a verification subscription lands in the app's database before being cancelled. It never returns a checkout URL, and it always cancels its verification subscription. Run it after plans set and before you connect a live account.

plans publish is the only way plans reach the live account, and it runs in two steps. The first call (no --diff-id) previews the create, update, and archive changes that would make live match test, and returns a diff_id. The second call passes that diff_id to apply exactly those changes; it refuses to write when the test or live plans changed in between. When the two sides already match, the first call returns no diff_id and a live_matches_test notice.

Customer support

customers get reads a customer by --email or --customer-id and returns their recent subscriptions and charges. Refund and cancel flows read the customer first and pass the returned snapshot back to the write: a refund needs the charge's expected amount, amount refunded, and currency; a cancellation needs the subscription's expected status and customer. Omit --amount to refund the full refundable amount; --at-period-end false cancels immediately instead of at the period end. These are explicit founder requests only, and they use live mode once a live connection exists.

Money events

Once you're live, cofounder payments get also reports the money-out events that cost you money if ignored: disputes needing a response, past-due subscriptions, failed payouts, and paused payouts. Poll it and act on every critical notice; each has a deadline or a matching next step. A dispute step links to the dispute in the Stripe dashboard; your agent may draft evidence but never submits it, so you always respond in Stripe yourself.

Next steps

To reach customers by email, phone, social, and ads, go to Communicate and Sell.