Claude Code and Stripe: manage your account, or charge your customers

If you want the agent to manage your Stripe account, use Stripe's own MCP

Start at the fork, because the two jobs share a name and share nothing else.

Job one: administration. Your business already runs on Stripe and you would like Claude Code in that account — what did we bill this customer, why was the payout short, cancel this subscription, refund that charge. Stripe publishes tooling for exactly this: an MCP server documented at docs.stripe.com/mcp, plus a connector listed on Stripe's own marketplace. It reads and writes the account you already own, using a key you already have. Install it. Nothing here replaces it, and a page that pretended otherwise would waste your afternoon.

Job two: revenue. Not a report about money — money. A customer paying you tonight, from a session, possibly before you own a merchant account at all. Almost nobody writes about this one, because every guide starts from the assumption that the Stripe account exists and the only question is which key to paste. That assumption is the whole gap, and the rest of this page is what fills it.

So that the fork is unambiguous, here is what Clize deliberately cannot do. It cannot read your Stripe balance, list your charges, look up one of your customers, edit a price, cancel a subscription, or change a payout setting. It never asks for sk_live_… — which is the same sentence said from the other direction, since a tool that holds no key to your account cannot act inside it. If what you need is anywhere in that list, take the first path and stop reading this one.

If you want the agent to take money from your customers

One line, and there is somewhere for the customer to pay:

$ clize pay link --amount 49 --to buyer@example.com --for "invoice 1042"

What comes back is a Stripe Checkout URL: Stripe's hosted form, Stripe's card handling, Stripe's receipt, the checkout your customer has already seen on a dozen other sites. What you skipped is the part every other guide opens with — no signup, no business verification, no key in a config file, no waiting for a payout schedule to clear review. The --to and --for values are labels for your own benefit; a fortnight later clize pay list still shows which link was which.

Now the paragraph that decides whether this product fits you. The charge is collected on Clize's Stripe account, and your Clize balance is credited with the full amount the buyer actually paid — the platform takes no percentage. That balance spends on what Clize sells: registering and renewing domains, hosted deploys, and generated images, video and music. It does not travel to a bank. Paying out into a merchant's own Stripe is real code behind clize pay connect, but the platform switch is off, so the onboarding endpoint answers "not enabled yet" and everything collected today lands in the balance instead.

Read that as a boundary, not as a footnote. If this money has to arrive in a bank account on a schedule, open a real merchant account and wire up Stripe the ordinary way — you will be happier and it will take an afternoon. If you are running an agent that is already spending on domains, hosting and generated assets, then earning into the same pot is the design rather than a consolation: clize balance is where both directions meet, and clize pay status tells you which payout mode you are genuinely in rather than the one you assumed.

The gate the incident story is missing

Search this topic and sooner or later you land on a post that is not a tutorial: someone recounting what happened after their coding agent cancelled a live customer's subscription. Stories like it are why people arrive at this page uneasy, and they deserve a serious reading rather than a joke about letting the model cook.

The mechanism is boring, which is the useful part. An MCP server holding a live secret key hands the model a set of verbs, and a few of those verbs are irreversible against real people. Between the verb and the customer sits exactly one thing — whether the model judged well in that moment, with whatever it had in context. An approval prompt covers you while somebody is watching the terminal and covers nothing at 3am in a scheduled run. Narrowing the key to read-only removes the danger and the usefulness in the same stroke: every refund and every apology comes back to you, so the agent reports and you still do the work.

Clize draws the line somewhere else — not at the key, at the verb. The commands exist and the agent is free to run them. They simply do not take effect on the first call.

• clize shop refund <id> answers with a quote: the charge, how much has already gone back, the payout mode it would use, and the reminder that nothing has happened. Adding --confirm is what reaches Stripe, and that call carries an idempotency key derived from the order and the amount already refunded — a retried command or an over-eager loop cannot send the same money twice.
• clize shop notify <id> answers with the drafted email in full: sender, recipient, subject, body, tracking link. --confirm sends it, stamps emailed_at, and then refuses a second send unless you explicitly pass --allow-duplicate.
• clize domain buy and the clize gen commands quote a price and stop. Same rule, applied to spending rather than to refunding.

What that leaves running unattended is reading, drafting, quoting, and fulfilment bookkeeping with no effect outside your own records. Anything that moves money or reaches a stranger's inbox waits for a person. Because the rule lives in the product rather than in the host's approval dialog, it behaves the same in an interactive session, in a headless run and in a cron job — which is the case that matters, since a cron job has nobody available to click Allow. Both gated calls, and every state change underneath them, are written to the order's history and to a replayable event stream, so clize shop events can tell you afterwards what the agent actually did.

Install in Claude Code

Three commands, and the next session knows how to charge somebody:

$ npm i -g @clize/clize
$ clize login
$ clize install --claude

That writes four skills into ~/.claude/skills/: clize for the real-world actions, plus clize-seo, clize-site-build and clize-site-debug. There is no plugin to add, no manifest to edit and no restart flag — and if you would rather look before anything is written, clize install --claude --dry-run prints the four target paths and exits. Worth knowing on a shared machine: Claude Code is the only one of the four supported agents that keeps skills in its own directory. Codex, Pi and OpenClaw all read ~/.agents/skills, so installing for one of them installs for all three.

The skill by itself is the default and is usually all you need: it teaches the agent to call the clize CLI directly, which keeps a tool list out of the context window in every session you ever start. If you prefer structured tools, register the MCP server as well:

$ clize install --claude --mcp

# or by hand
$ claude mcp add clize -- clize-mcp

The full server is deliberately broad. When a project only sells, narrow it with --profile storefront and the agent sees fifteen tools instead of the whole surface: payments, orders, one-order detail, the to-do list, fulfilment, notification, refunds, shipments, the event stream, the outbound webhook, the form receiver, and the three account calls — with nothing about domains or media in the way. There is one package (@clize/clize) and one registry entry (ai.clize/clize): the per-line thin packages and their separate registry entries were withdrawn on 2026-09-04, so the commerce subset is a flag on the one server rather than a second listing. If you also run the same server under Codex, note that its registration syntax differs.

What happens after they pay

A payment link is a moment. A store is the ten days after it, and that is where most integration write-ups stop.

Clize keeps the order and walks it through states it will not let you skip: created when checkout opens, paid only when Stripe's webhook says so, then sourced, shipped and delivered, with a refund branch available from any paid state. The agent has no way to mark an order paid, so it cannot invent revenue, and an illegal transition raises an error rather than quietly corrupting the record.

The daily question is one command. clize shop todo answers with newly paid orders that still need sourcing, tracked parcels the buyer has not been told about, and shipments that have stopped moving in transit — and it declines to tell you whom to buy from or whether to refund, because those are judgement calls. Recording work is clize shop fulfill: --supplier-order moves an order to sourced, --tracking moves it to shipped. The tracking form also registers the number with 17TRACK, so carrier detection and door-to-door scans arrive without you naming the carrier, and it drafts the shipping mail that then waits at the gate described above.

Your buyer gets something as well, free and already deployed: every site shipped through Clize answers at /orders with a self-service lookup, opened by email address plus order number so nobody can browse a stranger's purchases. Search engines are told to skip it, for the obvious reason. Publish your own /orders/index.html and yours wins instead.

The whole loop, catalogue through delivery, is on the Agent Storefront overview; the shortest possible version of one charge is one agent, one payment link.

$ npm i -g @clize/clize && clize login
$ clize install --claude
$ clize pay link --amount 49 --for "invoice 1042"