Put a purchase gate in front of OpenClaw
26 Jul 2026 · 8 min read
OpenClaw is useful because it can act close to the user: chat where the user chats, browse, fill forms, run scripts, and load skills. That is also why a purchase needs a separate stop before checkout. If the same agent can find a product and press the payment button, the safety check has to run at the last point where the agent still has a choice.
The practical setup is small. Install the Watchpost skill, give OpenClaw one connection token, and make the agent send the final merchant, title, amount, currency, and recurring status before it pays. Then hold the line: approve means pay, review means wait, block means stop.
What OpenClaw gives the skill
OpenClaw describes itself as a personal AI assistant that can run on the user's machine, connect to chat channels, browse the web, use files and scripts, and extend itself with skills and plugins. Its skills documentation says skills are Markdown instruction files. Each skill lives in a directory with a SKILL.md file, and OpenClaw loads eligible skills into the agent run.
That shape matters for purchase safety. A buying rule should not live only in the user's prompt. Prompts get long, product listings contain their own instructions, and checkout pages change. A skill gives the agent a repeatable procedure: when a purchase is about to happen, run the check first.
OpenClaw also documents environment injection for skills. The relevant part is simple: OpenClaw can apply per-skill environment values during an agent run. The Watchpost skill uses that path for WATCHPOST_TOKEN, the connection token created in the user's Watchpost account.
The skill is a folder, not a black box
The Agent Skills specification defines a skill as a directory that contains, at minimum, a SKILL.md file. It may also contain scripts, references, and assets. The Watchpost skill follows that pattern: the instructions tell the agent when to check a purchase, and the helper script sends one verification request to Watchpost.
For a purchase gate, this transparency is useful. You can inspect the instruction file and the helper script before the agent uses them. The script reads the purchase JSON, reads the Watchpost token, calls the official Watchpost verify endpoint, prints the verdict, and exits with a code the agent can act on.
The important behavior is fail-closed. A missing token, malformed purchase, network failure, block verdict, or plan-limit error does not become permission to pay. The agent must treat those outcomes as "do not complete checkout."
Install the skill from ClawHub
OpenClaw's ClawHub documentation describes ClawHub as the public registry for OpenClaw skills and plugins. It shows native OpenClaw commands for searching, installing, and updating skills, and says ClawHub hosts versioned text bundles that contain SKILL.md plus supporting files.
For Watchpost, the intended install command is:
openclaw skills install @lelis92/watchpostAfter installation, start a fresh OpenClaw session so the skill list refreshes. OpenClaw's skills docs say a session snapshots eligible skills when it starts, and changes normally take effect on the next new session.
Give the skill one token
The skill needs a Watchpost connection token. Create it from Watchpost, then set it as WATCHPOST_TOKEN for the Watchpost skill in OpenClaw's skill configuration. If you have not connected anything yet, the Watchpost install page points to the current connection paths, including the skill route for OpenClaw and other Agent Skills runtimes.
Keep the token scoped to this agent. A shared token makes later review harder because the verdict log cannot cleanly show which agent made which attempt. If you run several OpenClaw agents, give each one its own Watchpost connection.
Do not paste the token into prompts. It belongs in configuration so the helper script can read it when needed and the model does not repeat it back into chat.
Send the final purchase, not the search result
The check should run right before payment. Earlier checks are useful during search, but they do not settle the final purchase. Shipping, tax, currency conversion, subscription language, and merchant redirects can all appear late in checkout.
The minimum payload is the merchant domain, product title, amount in minor units, and currency. Send isRecurring when the charge repeats. Send the product URL and description when the agent has them, because listing text can expose prompt injection, hidden instructions, drip pricing, or subscription clues.
A clean check looks like this:
node scripts/check-purchase.mjs '{"merchant":"example.com","title":"USB-C cable","amountMinor":1599,"currency":"USD","isRecurring":false}'The agent should read the printed verdict and follow the exit code. Exit 0 means approve. Exit 2 means review, so the agent waits for the user. Exit 1 means block or error, so the agent stops. Setup and plan-limit exits also stop payment because the purchase was not protected.
Test the line before a real purchase
Once the skill is installed and the token is set, run one dry check above your purchase cap. The exact product does not matter. What matters is the agent's behavior: it should call the helper, receive a review or block reason, explain that reason, and refuse to continue to checkout until the rule is satisfied.
Also test the missing-token path. Temporarily remove the token in a disposable session, ask the agent to prepare a harmless purchase, and confirm that it stops instead of treating setup as optional. Restore the token after the test.
Your action today is to install the skill, set one token, and run one blocked dry check. If OpenClaw can spend money for you, the first proof you need is boring: a purchase that did not happen because the rule said no.