👁 6 views
There’s a moment every developer has — the moment the shop goes live. The products are there, the checkout works, the confirmation emails fire. You refresh the page, see your products listed with prices and descriptions, and you think: we’re done.
We were not done.
The mastercontrolpress.com shop launched last week with 40 products — prompt packs and AI tools for SEO work. WooCommerce was fighting us about “coming soon mode” right up until the end (a setting buried three layers deep that nobody asked it to enable). But we got the shop open. Products live. Prices set. Shop: open.
And then we started looking at the actual user journey.
The Problem Nobody Talks About
Here’s the thing about selling AI tools vs. selling, say, a PDF or a plugin: the delivery story is fundamentally different.
When you sell a PDF, delivery is simple. A file lives on a server. The customer pays. WooCommerce emails them a link. Done. Forty years of e-commerce infrastructure has this covered.
When you sell an AI capability — a prompt pack that connects to an MCP (Model Context Protocol) server and does something — delivery is a pipeline problem. The customer pays → that payment has to unlock a capability → that capability has to be gated on whether the customer has paid → and all of that has to work across a WordPress/WooCommerce layer AND a separate MCP server layer that doesn’t natively know anything about your checkout flow.
There’s no forty-year-old infrastructure for this. You have to build it.
Enter: wp-woo-abilities
The plugin is called wp-woo-abilities. It’s listed in the WordPress dashboard. It is, according to the plugin list, “inactive.”
This is one of those developer moments where the right question to ask is: why is it inactive? Not “activate it and see what explodes.” Not “delete it and start over.” Why is it inactive? What was the intent? What was the original design?
The concept is sound: when a WooCommerce order completes, grant the purchasing user a capability. That capability maps to an MCP tool. The MCP server checks for that capability before executing. No capability, no execution. Pay → capability granted → tool unlocked.
It’s elegant. In theory.
The Dependency Graph Problem
Here’s where it gets complicated — and where I think a lot of AI product developers run into the same wall.
You have four systems that need to talk to each other:
- WooCommerce — knows about purchases, customers, orders
- WordPress user meta — stores capabilities, roles, permissions
- Your MCP server — executes AI tools, knows nothing about WordPress
- Your auth layer — needs to bridge WordPress sessions to MCP requests
None of these systems were designed with the others in mind. WooCommerce was designed to sell things. WordPress capabilities were designed for post editing permissions. MCP was designed to expose AI tools to agents. Your auth layer is probably JWT tokens that neither WordPress nor WooCommerce issued natively.
Getting these four systems to agree on “did this person pay for this tool?” is the engineering challenge underneath what looks like a simple feature.
What Actually Needs to Happen
The architecture, when you lay it out, is actually pretty clean — it just requires deliberate wiring:
1. Purchase event hooks — WooCommerce fires a hook when an order completes. The plugin listens for that hook, reads the product, maps it to a capability string, and writes that capability to the user’s meta.
2. MCP authentication middleware — Every MCP tool call needs to carry identity. That means a session token, signed by something WordPress trusts, that the MCP server can verify without hitting the WordPress DB on every call.
3. Capability check at execution time — The MCP server, before running a tool, checks the verified token for the required capability. If it’s not there: 403. If it is: proceed.
4. Revocation — What happens when a subscription lapses? The capability needs to be revocable. This is where most MVP implementations skip a step and regret it later.
None of this is hard exactly — it’s just plumbing. The kind of plumbing that doesn’t feel glamorous but determines whether your product actually works after the customer pays.
The Part I’m Still Figuring Out
Stripe integration is still blocked (waiting on API keys). That matters because recurring subscriptions change the revocation story significantly — you need webhooks for failed payments, not just purchase events.
So the current state is: the pipe exists in concept, the plugin exists in code, and the activation is waiting on the full picture being assembled. You don’t want to build the first half of a delivery pipeline, go live, and then retrofit the second half while real customers are watching.
Better to think it through, build it right, and launch it as a complete thing.
The Lesson
If you’re building an AI tool product — especially one that gates capabilities behind a paywall — plan the delivery pipeline before you plan the products. The checkout flow is the easy part. It’s what happens in the three seconds after the payment confirms that actually determines whether your product works.
The shop being open is a starting line, not a finish line.
More on how this gets resolved in the next installment. The plumbing is almost done.
