OpenClaw + Stripe: payments with a gate on every write

Install it in OpenClaw

OpenClaw reads the open Agent Skills directory at ~/.agents/skills — the same one Codex and Pi read — so there is nothing to configure inside OpenClaw itself. Three commands, and the next session knows how to charge a customer:

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

That writes four skills into the shared directory: clize for the real-world actions, plus clize-seo, clize-site-build and clize-site-debug. Verified on OpenClaw 2026.8.1: all four report ready, sourced from the personal agents-skills directory, with no plugin to install, no manifest to edit and no restart flag. Confirm it from OpenClaw's side with openclaw skills list.

One trap worth naming before you hit it. Do not also drop a workspace copy of the skill into the project you happen to be working in. Two skills with the same name — one in the workspace, one in the shared personal directory — compete for priority, and which copy wins is not a thing you want silently deciding whether a refund command is gated. Install once, at the user level, and let every agent on the machine read the same file. That is also why upgrading is a single clize update rather than a hunt through three directories.

The skill is the default and is enough on its own: it teaches the agent to call the clize CLI directly, which keeps a tool list out of the context window every session. If you would rather have structured tools, register the MCP server too — and note that OpenClaw's registration syntax is not Claude Code's:

# OpenClaw — no `--` separator; the stdio command goes in --command
$ openclaw mcp add clize --command clize-mcp

# Claude Code / Codex, for comparison
$ claude mcp add clize -- clize-mcp

Measured on the same machine, OpenClaw's probe reports 32 tools across the whole surface. If you only want the shop in context, the server accepts --profile storefront, which narrows it to 15: payments, orders, fulfilment, refunds, shipments, the outbound event stream and the account calls, with nothing about domains or media. The registry side is deliberately simple: one package (@clize/clize) and one entry (ai.clize/clize) — the per-line thin packages and their separate registry entries were withdrawn on 2026-09-04 after a month with no installs, so the subset lives in the flag, not in a second listing.

Now notice what is absent from every command above: a Stripe secret key. The published walkthroughs for this exact search — the integration-platform tutorials, the directory entries — all begin by asking for sk_live_…, and several ask for a second API key for the integration platform on top. Those guides are answering a different question: how to let an agent read and manage an account you already have. Clize never touches your Stripe account, so it never asks for a credential to it. What it hands the agent instead is a payment surface of its own — which is the next two sections. If the agent also needs an identity to send from, the same install gives OpenClaw a mailbox of its own.

Read-only isn't the only safe answer

The most useful page currently ranking for openclaw stripe is a careful, hands-on build log, and it ends by making its Stripe skill read-only — it even has a section titled "Why This Skill Is Read-Only". That is an honest conclusion from a real constraint. The design hands the agent a live secret key, and a live secret key can refund, cancel, and change payout settings. Once the key is in the agent's hands, the only remaining control is the key's scope, so scope is where the author put it. Given the premise, read-only is the right call.

The premise is what is worth challenging. Read-only has a cost that rarely gets counted: everything it forbids still has to happen, so it lands back on you. The agent can notice at 2am that an order needs refunding, draft you a summary, and then wait. You are still the one who opens the dashboard. The work moved, the decision did not — and a merchant with one agent and no staff feels that trade every day.

Clize takes the other route. The write commands exist. The agent can refund, can email a buyer, can move an order to shipped. But the two that scare people do not fire when they are run: they return what they would do, and stop.

Refunds. Run clize shop refund cs_live_a1b2c3 and you get the quote, not the refund. Add --amount for a partial, --reason to record why — the suggested codes are out_of_stock, damaged, not_as_described, buyer_remorse, fraud_suspect and other, plus free text — and only then --confirm. The confirmed call carries an idempotency key derived from the order and the amount already refunded, so a retried command, a flaky connection or an over-eager agent loop cannot refund the same money twice.

Outbound email. clize shop notify hits the same gate the rest of Clize puts on mail: the agent writes, a human approves, then it sends. The default output is the full draft. You read the tracking number in it, you decide the tone is right, you add --confirm. The duplicate guard means a buyer does not get the same "your order shipped" twice because two sessions both thought it was their job.

Underneath both, the record is not optional. Every state change appends an entry to that order's own history — from state, to state, who did it, a note — visible with clize shop order <id>. Separately, an outbound event stream records order.paid, order.sourced, order.shipped, order.delivered, order.refunded and order.disputed, replayable with clize shop events --since 2026-09-01 whether or not you ever configured a webhook. If your agent did something, there is a row for it afterwards.

So the safety question changes shape. It stops being what can this key do and becomes what runs without a human. The answer: reading, drafting, quoting, and fulfilment bookkeeping that has no effect outside your own records. Money movement and mail to a stranger always need a person. And because those gates live in the product rather than in the host's permission prompt, they behave identically whether the agent is running in OpenClaw, Claude Code, the Codex CLI or a cron job — an important property, since a background run has nobody to answer a permission dialog.

Take the first payment without a Stripe account

Once the skill is installed, charging someone is one line:

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

Out comes a live Stripe Checkout URL. Real card, real receipt, Stripe's own hosted page with its fraud checks and its card handling — the customer sees a normal checkout. What you did not do is open a Stripe account, pass a KYC review, paste a secret key anywhere, or wait for a payout schedule to be approved. --to and --for are recorded for your own display, so a week later clize pay list still tells you which link was which.

Where the money goes — read this part literally.

Take that table as written rather than as you would like it to be. The direct path exists in the code — clize pay connect opens the connection page and clize pay link --mode direct is a real flag — but the platform switch is off, so the onboarding endpoint answers with a plain "not enabled yet" and every payment collected today lands in the balance. When it does open, connecting on the web flips the default by itself and links made afterwards go direct; nothing on your side changes. Until then, treat the balance as exactly what it is: revenue you can spend on the things Clize sells, not a bank account with a slow withdrawal button.

That limit decides who this is for, and it is worth being blunt about it. If you are a shop whose survival depends on cash reaching your bank on Friday, connect your own Stripe the ordinary way and use a normal integration. If you are running an agent that spends money on domains, hosting and generated assets, and you would like it to also bring money in, then the balance is not a consolation prize — it is the same ledger both directions run through. Revenue from a customer and the cost of a domain registration land in one account, and clize balance prints the running total with every entry that moved it.

Two supporting commands worth knowing on day one. clize pay status tells you which mode you are actually in rather than which one you assumed. clize shop status answers the store readiness questions in one shot: Stripe connected or not, payout mode, catalogue size, whether a fulfilment webhook is registered, order counts by status, and whether 17TRACK is wired. Ask for those before you send a link to a real customer, not after.

A payment link is the small end of this. The larger one is a store: deploy a static site with Clize, add a _catalog.json and the cart snippet that clize shop init prints, and the checkout, the orders and the buyer-facing pages come with it. See what Agent Storefront covers end to end, or the short version in one agent, one payment link.

From paid to delivered

Taking the money is the easy half. The half the integration tutorials skip entirely is what happens over the following ten days, when a human has to source the item, ship it, tell the buyer, and answer "where is my order?" three times. That is the part Clize models as state rather than as a folder of screenshots.

An order moves through six states, and only through the transitions that make sense:

created → paid → sourced → shipped → delivered
                  ↘ (any paid state) → refund_pending → refunded

created is set when checkout opens; only Stripe's webhook can promote it to paid, so nothing your agent does can mark an order paid that was not. From there the transitions are enforced: delivered cannot go back to shipped, and an illegal move raises an error instead of quietly corrupting the record. A dispute is orthogonal — order.disputed fires as an event and appends to the history, but it does not rewrite the fulfilment state, because a chargeback and a parcel are two different timelines.

The daily loop is one command:

$ clize shop todo

It returns three buckets, and nothing else: newly paid orders waiting to be sourced, orders with tracking that have not been notified yet, and shipments overdue in transit that need a reassuring email. Notably it does not tell you whom to buy from or whether to refund — those stay judgement calls, and the tool says so in its own output.

Recording work is clize shop fulfill, which infers the target state from what you give it:

$ clize shop fulfill cs_live_a1b2c3 --supplier-order PO-9182     # → sourced
$ clize shop fulfill cs_live_a1b2c3 --tracking 1Z999AA10123456784  # → shipped
$ clize shop fulfill cs_live_a1b2c3 --delivered                    # → delivered, by hand

The tracking form does two extra things. It registers the number with 17TRACK, so carrier detection and door-to-door scans arrive without you naming the carrier (pass --carrier if you want to force it). And it drafts the shipping email — which then sits behind the gate from the previous section until you run clize shop notify … --confirm. You can replace the wording once with clize shop template, using the {{tracking}}, {{trackUrl}}, {{orderId}}, {{shop}} and {{trackPage}} placeholders, and every later draft uses yours.

Parcels stall, so there is a command for that too. clize shop shipments --stale 5 --refresh pulls the latest scans from 17TRACK and lists only the shipments whose tracking has not moved in five days or more. That is the list worth an email before the buyer writes one.

The buyer's side is free and already deployed. Every site you ship with Clize serves a self-service order lookup at /orders without you building it: two factors, the buyer's email plus the order number, so the page cannot be used to enumerate other people's orders. It shows the current status as a badge, the tracking number and carrier, and a door-to-door tracking link. It carries noindex, because a customer's order status has no business in a search index. If you would rather design your own, publish /orders/index.html in your site and yours wins.

For anything you want to automate further, clize shop webhook https://your-endpoint POSTs the same six order events to you, and clize shop events --since <ISO> replays them from the stream if your endpoint was down. Between the two, an agent can rebuild its own picture of the shop after a restart without asking you a single question — which, for an agent that runs on a schedule rather than in a chat window, is the difference between useful and ornamental.

Can your agent spend money?

This is the question most of the OpenClaw payment writing is actually about — agents with wallets, buying things on the open web — and it deserves a straight answer rather than a future tense. Clize is a collection layer, not a spending wallet. Your agent cannot be handed a card and sent shopping.

What it can spend is your Clize balance, and only on what Clize itself sells: registering and renewing a domain, generating an image, a video clip or a music bed. Every one of those is on the money line, which means the same discipline as a refund — the bare command returns a quote, and --confirm is the action:

$ clize domain buy shopname.com          # quote only: price, term, auto-renew
$ clize domain buy shopname.com --confirm # registers it, charges the balance

clize balance is the ledger for both directions: a customer payment credits it, a domain registration debits it, and each row names the action that moved it. That is why "spendable inside Clize" is a description of a loop rather than a euphemism for a lock-in. A storefront that sells $600 of product this month has $600 of runway for the domains and the generated product imagery of the next one, at no platform fee — and if you need more than the store brought in, clize recharge tops the same balance up.

What the agent cannot do is spend outside that boundary. There is no card in its hands, no marketplace account, no way to convert the balance to cash. If your project genuinely needs an agent that pays third parties, this is not that product, and you should stop reading here rather than discover it in week three. If your project needs an agent that gets paid and then covers its own running costs, the loop above is the whole design.

What clize does not do

A page about letting an AI agent handle money should be at least as clear about the edges as about the capabilities. These are the real ones, as of September 2026.

• No withdrawal. Balance funds stay in Clize. Direct payout into your own Stripe is built but not switched on; until it is, do not plan around cash leaving the system. This is the single most important sentence on the page.
• No subscriptions in balance mode. Recurring billing needs the direct mode, so today it is one-off charges only. A subscription request returns an explicit error rather than half-working.
• It does not pick your products or set your prices. The catalogue is a file you write. Margin, positioning and what is worth selling are not decisions a fulfilment tool should be making, and it does not pretend otherwise.
• It does not track inventory. There is no stock count. If you oversell, the tool will happily record both orders and let you refund one — with a preview first.
• It does not do tax. No VAT calculation, no sales-tax nexus, no invoicing compliance in your jurisdiction. That remains yours and, above a certain volume, your accountant's.
• It does not read your existing Stripe account. If the thing you actually want is an agent that queries your live balance, manages your existing subscriptions or reconciles your payouts, then the integration-platform guides you found alongside this page are the right tool and this one is not. Different question, different product.
• It does not fight your chargebacks. A dispute surfaces immediately as order.disputed, on the order history and on the event stream, because response windows are short. Assembling the evidence and answering is still a human job in your Stripe-facing paperwork.

What is left after all of that is a narrow, honest claim: an agent running in OpenClaw can create a real payment link in one command, watch an order through six states, keep a buyer informed, and never move money or send mail without you saying so. If that is the shape of the problem, the install takes about a minute and every command on this page is in the reference.

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