Forem: Almin Zolotic

30 Days of AI Agents Buying From a Real WooCommerce Store. Here's What the Data Says.

Almin Zolotic — Tue, 26 May 2026 15:32:55 +0000

Last week @benjifisher published a sharp piece on agentic commerce's messy middle — the trust, verification, and liability layer between "found it" and "bought it." His conclusion: the middle is mostly unbuilt.

We have 30 days of production data that says otherwise. Not a demo. Not a sandbox. A live Dutch perfume store with 40,000 SKUs, real pricing, real tax, real wallet debits. Here is what actually happened.

The numbers

€1,269 in AI-driven revenue — last 30 days
39 completed orders via AI agents
€32.54 average order value per AI transaction
76.5% session conversion — 39 of 51 agent sessions resulted in a completed order
1.5 average calls per session — the spec benchmark is 4 (list → create → update → complete)

That last number is the one I want to focus on.

1.5 calls per session means agents are skipping steps

The UCP spec optimised benchmark is 4 tool calls for a complete purchase: list products, create checkout, update checkout, complete checkout. Our agents are averaging 1.5.

That is not agents failing — it is agents that have already done discovery in a prior session arriving with intent and going straight to checkout. The /agents.md instruction layer we shipped two weeks ago is working: agents are reading the operating manual on first visit and not re-reading it on every subsequent transaction.

The messy middle does not look messy when the protocol is clean and the instructions are explicit.

Who is actually buying

Eight distinct agents hit the store in 30 days. Here is what the agent table shows:

Agent	Sessions	Avg Calls	Status
UCP Directory Verifier	19	1	Discovery only
Unknown Agent	13	2.2	Transacting efficiently
UCP Checker	8	1.4	Validation + light transacting
UCPReady MCP	5	1.2	Internal testing
UCP Playground	2	5	+1 above benchmark
Claude	2	1	Clean
Ucptools.dev	1	2	At target
Generic Bot	1	1	At target

The most interesting row is Unknown Agent — 13 sessions, 2.2 avg calls, at or below target. An agent we cannot identify by name is transacting against the store efficiently and repeatedly. It found the /.well-known/ucp manifest, parsed the capability declarations, and is completing purchases without any integration work on our side.

That is the protocol working exactly as designed.

UCP Playground is the only agent above benchmark at 5 calls — that is Ben's testing environment running full end-to-end validation sessions including the identity linking flow. Expected noise, not a problem.

What the messy middle actually looked like

Building to this point was not clean. The first fully autonomous purchase — WooCommerce order #82251 on March 25 — took 24 hours of debugging across two people. The failures were specific:

Idempotency key formatting. Claude kept sending meta as a stringified JSON object instead of a proper nested object. Fixed at the orchestrator level by auto-injecting the key shape.

Wallet instrument ID vs handler name. The store's validator accepted com.terrawallet.store_credit (the handler name) but rejected terrawallet-1 (the instrument ID). Two different identifiers, one lookup path, one silent failure mode.

Stale OAuth sessions. Merchant-side token revocation was not being detected. Agents were holding expired Bearer tokens and getting 401s with no clear recovery path. Fixed by adding token validation on connect and auto-clearing on 401.

MCP endpoint override. Our Shopify storefront probe was overriding the manifest endpoint. OAuth tokens were stored against /api/mcp but MCP calls were going to /wp-json/ucpready/v1/mcp. One endpoint mismatch, zero successful completions until found.

Each of these was a real failure that blocked real purchases. The protocol did not hide them — the session data captured every one. Observability is what made them fixable.

What 76.5% conversion means in context

Human checkout conversion on e-commerce averages 2-4%. Mobile is lower. Even high-performing stores rarely exceed 5% on cold traffic.

76.5% is not comparable to human checkout conversion — agent sessions are intentional by definition, not browsing. But it does tell you something about friction. An agent that reaches create_checkout on a well-implemented UCP endpoint completes the purchase 76.5% of the time. The failures are mostly discovery sessions (UCP Directory Verifier, UCP Checker) that never intended to purchase.

Strip out the pure discovery sessions and the completion rate is higher.

The small retailer readiness tax — revisited

Paul do Forno at Deloitte posted last week that smaller retailers face a "hidden agentic readiness tax" — perfect catalog data as table stakes, deep system access creating data leakage risk.

The data above is from a small Dutch retailer. Not a platform. Not an enterprise. A WooCommerce store. The tax is real — it took months of development to get here — but the output is 39 AI-driven orders and €1,269 in revenue in 30 days that would not have existed otherwise.

The readiness tax is a one-time cost. The revenue is recurring.

What comes next

The 13 Unknown Agent sessions are the most interesting data point we have right now. An unidentified agent found this store, parsed the protocol, and is transacting repeatedly. We do not know where it came from. That is the network effect of an open protocol — you do not have to be listed anywhere specific. You publish a conformant /.well-known/ucp manifest and agents find you.

The next milestone is identifying that agent and understanding its mandate scope. If it is running AP2 autonomous purchasing without an explicit buyer confirmation step, the audit trail is the only thing standing between "it worked" and "it bought the wrong thing." That is the observability layer Ben is right about — not a theoretical need, a live operational requirement.

The middle is not unbuilt. It is early, it is messy to get right, and it generates real revenue when you do.

UCPReady is the WooCommerce plugin behind this data. The AI Agent Analytics dashboard is a Pro feature. houseofparfum.nl is the live reference store — the manifest is at houseofparfum.nl/.well-known/ucp.

If you want to see where your WooCommerce store stands: ucpchecker.com

Shopify Just Gave AI Agents an Operating Manual. We Built One for WooCommerce.

Almin Zolotic — Tue, 26 May 2026 15:28:38 +0000

When Shopify shipped @shopify/ucp-cli last week, most of the coverage focused on the obvious part: AI agents can now browse and buy from Shopify stores using the Universal Commerce Protocol.

What got less attention was the file bundled inside the package — SKILL.md.

That file is not protocol. It's instructions. It tells AI agents how to behave when shopping on Shopify: start with discovery, sequence cart before checkout, render totals in the order the merchant provides them, treat escalation as a normal lifecycle step not an error. It encodes operational knowledge that the UCP spec alone doesn't cover.

Shopify proved something important: protocol + agent instructions is stronger than protocol alone.

We build UCPReady — a WooCommerce plugin that implements the full UCP stack. And until last week, WooCommerce merchants running it had the protocol layer but not the instruction layer. No file telling agents how to work with their store. No guidance surface beyond /.well-known/ucp.

We shipped that this week.

The gap Shopify exposed

UCP standardizes the transport and schema. Every conformant store — Shopify, WooCommerce, BigCommerce, custom — exposes the same protocol surface. That's the point.

But Benji Fisher at UCP Checker wrote a sharp breakdown of what Shopify's CLI actually does, and one line stuck:

It can buy from any UCP-compliant store on any platform. It can only find Shopify stores.

The discovery layer defaults to catalog.shopify.com. The transaction layer is pure, open UCP. Shopify owns the index; the protocol is shared.

That asymmetry matters. But there's a second asymmetry that's just as real: Shopify agents arrive at a store already knowing how to behave. Non-Shopify agents arrive and have to figure it out from the profile alone.

A SKILL.md bundled in a CLI is one way to solve that. But it only works for agents that installed that specific CLI. The more durable fix is publishing the operating manual on the merchant's own domain — discoverable by any agent, from any platform, the moment it finds the store.

What we shipped: the Agent Guidance Layer

UCPReady now auto-generates two public documents on every merchant site:

/agents.md — human and agent readable Markdown. Tells any agent:

Start with /.well-known/ucp, use the advertised endpoint, never assume /api/ucp/mcp
What capabilities this specific merchant supports (cart, checkout, orders, returns, identity linking, embedded checkout)
How to sequence checkout operations
What payment handlers are available
When to stop and escalate to the buyer
Whether return flows include retention/keep-offer decisions (KeepCard integration)

/llms-full.txt — compact, machine-oriented. Covers protocol version, supported transports (REST, MCP, Embedded), capability inventory, and explicit safe probing guidance.

Both are generated dynamically from live merchant capabilities. If cart is disabled, the cart section doesn't appear. If KeepCard isn't active, no keep-offer guidance is included. Nothing is hardcoded; nothing claims unsupported behavior.

Here's what it looks like for a real production store — House of Parfum, currently #1 on ucpchecker.com with a perfect 100/100 score:

# House of Parfum

This merchant uses UCPReady and publishes UCP-compatible shopping
endpoints for AI agents.

## Merchant Profile

- **Store:** House of Parfum
- **Description:** Van iconische parfums tot luxe skincare
- **Discovery:** https://houseofparfum.nl/.well-known/ucp
- **Shop:** https://houseofparfum.nl/shop/

## Start Here

- Discover this merchant from https://houseofparfum.nl/.well-known/ucp
- Use the service endpoint advertised in the profile.
- Do not assume /api/ucp/mcp.
- MCP endpoint: https://houseofparfum.nl/wp-json/ucpready/v1/mcp
- REST endpoint: https://houseofparfum.nl/wp-json/ucpready/v1

## Supported Capabilities

- Catalog browsing and product lookup
- Cart creation and update
- Checkout creation, update, and completion
- Order lookup
- Return flows
- Identity linking
- Embedded checkout

## Checkout Guidance

- Create checkout first, then update it with buyer, fulfillment,
  and payment data as needed.
- Read payment handlers from the live checkout response.
- If checkout reaches a completed state, use the final order as
  the source of truth for totals and discounts.
- Treat coupon failures as recoverable checkout issues, not as
  silent success.

## Returns Guidance

- This merchant supports return tooling.
- Return flows may include optional retention / keep-offer decisions
  when enabled by merchant integrations.
- Ask the buyer before accepting or declining any keep-offer outcome.

## Payment Handlers

- dev.ucp.delegate_payment
- com.terrawallet.store_credit

## Escalate to the Buyer When

- variant or quantity selection is ambiguous
- identity linking is required
- coupon validation fails
- the merchant response requires approval or additional buyer action

You can hit it live: houseofparfum.nl/agents.md

Why this matters more than it might look

When Google announced Universal Cart at I/O 2026, the commerce director described UCP as "a common language that lets agents reach businesses securely and seamlessly." Universal Cart, AI Mode checkout, YouTube Shopping — they all run on it.

The stores that benefit are the ones agents can actually work with reliably. A broken or ambiguous implementation gets abandoned. A store with a valid manifest, correct capability declarations, and clear operating guidance gets completed transactions.

Shopify's approach is to bundle instructions in a CLI. That works for Shopify's ecosystem. Our approach is to publish instructions on the merchant's own domain, discoverable by any agent from any platform.

The instruction layer is not optional anymore. It's part of what makes a store agent-ready.

That's the WooCommerce answer to what Shopify bundled in their CLI — platform-level agent guidance, open and accessible, not locked to a single discovery surface.

If you're running WooCommerce and want to see where your store stands: ucpchecker.com

UCPReady is at zologic.nl/ucpready.

Shopify Just Gave AI Agents an Operating Manual. We Built One for WooCommerce.

Almin Zolotic — Thu, 21 May 2026 22:45:41 +0000

When Shopify shipped @shopify/ucp-cli last week, most of the coverage focused on the obvious part: AI agents can now browse and buy from Shopify stores using the Universal Commerce Protocol.

What got less attention was the file bundled inside the package — SKILL.md.

Shopify proved something important: protocol + agent instructions is stronger than protocol alone.

We shipped that this week.

The gap Shopify exposed

UCP standardizes the transport and schema. Every conformant store — Shopify, WooCommerce, BigCommerce, custom — exposes the same protocol surface. That's the point.

But Benji Fisher at UCP Checker wrote a sharp breakdown of what Shopify's CLI actually does, and one line stuck:

It can buy from any UCP-compliant store on any platform. It can only find Shopify stores.

The discovery layer defaults to catalog.shopify.com. The transaction layer is pure, open UCP. Shopify owns the index; the protocol is shared.

What we shipped: the Agent Guidance Layer

UCPReady now auto-generates two public documents on every merchant site:

/agents.md — human and agent readable Markdown. Tells any agent:

Start with /.well-known/ucp, use the advertised endpoint, never assume /api/ucp/mcp
What capabilities this specific merchant supports (cart, checkout, orders, returns, identity linking, embedded checkout)
How to sequence checkout operations
What payment handlers are available
When to stop and escalate to the buyer
Whether return flows include retention/keep-offer decisions (KeepCard integration)

/llms-full.txt — compact, machine-oriented. Covers protocol version, supported transports (REST, MCP, Embedded), capability inventory, and explicit safe probing guidance.

Here's what it looks like for a real production store — House of Parfum, currently #1 on ucpchecker.com with a perfect 100/100 score:

# House of Parfum

This merchant uses UCPReady and publishes UCP-compatible shopping
endpoints for AI agents.

## Merchant Profile

- **Store:** House of Parfum
- **Description:** Van iconische parfums tot luxe skincare
- **Discovery:** https://houseofparfum.nl/.well-known/ucp
- **Shop:** https://houseofparfum.nl/shop/

## Start Here

- Discover this merchant from https://houseofparfum.nl/.well-known/ucp
- Use the service endpoint advertised in the profile.
- Do not assume /api/ucp/mcp.
- MCP endpoint: https://houseofparfum.nl/wp-json/ucpready/v1/mcp
- REST endpoint: https://houseofparfum.nl/wp-json/ucpready/v1

## Supported Capabilities

- Catalog browsing and product lookup
- Cart creation and update
- Checkout creation, update, and completion
- Order lookup
- Return flows
- Identity linking
- Embedded checkout

## Checkout Guidance

- Create checkout first, then update it with buyer, fulfillment,
  and payment data as needed.
- Read payment handlers from the live checkout response.
- If checkout reaches a completed state, use the final order as
  the source of truth for totals and discounts.
- Treat coupon failures as recoverable checkout issues, not as
  silent success.

## Returns Guidance

- This merchant supports return tooling.
- Return flows may include optional retention / keep-offer decisions
  when enabled by merchant integrations.
- Ask the buyer before accepting or declining any keep-offer outcome.

## Payment Handlers

- dev.ucp.delegate_payment
- com.terrawallet.store_credit

## Escalate to the Buyer When

- variant or quantity selection is ambiguous
- identity linking is required
- coupon validation fails
- the merchant response requires approval or additional buyer action

You can hit it live: houseofparfum.nl/agents.md

Why this matters more than it might look

The instruction layer is not optional anymore. It's part of what makes a store agent-ready.

That's the WooCommerce answer to what Shopify bundled in their CLI — platform-level agent guidance, open and accessible, not locked to a single discovery surface.

If you're running WooCommerce and want to see where your store stands: ucpchecker.com

UCPReady is at zologic.nl/ucpready.

I Replaced a Returns Portal with Five MCP Tools. Here's What Actually Happened.

Almin Zolotic — Thu, 30 Apr 2026 20:06:06 +0000

A live WooCommerce journey where a model searched products, completed a purchase, and handled a return with keep-offer logic — through UCPReady and KeepCard.io on the Universal Commerce Protocol.

Most "AI commerce" demos are still just chat layered on top of old flows.

Tonight we did something different.

We ran a live WooCommerce journey where a model:

searched products
helped complete a purchase
and then handled a return with keep-offer logic

Not on a mock store. Not with human agents behind the curtain. Not with Claude-specific business logic buried in the backend. And not by building "AI features" into the store itself.

This ran through UCPReady and KeepCard.io — two products I built — using protocol-native rails so the model could interact with the store as an agent.

The transcript in one line

This was the actual lifecycle:

Customer asked for a face cleanser
Model searched the live WooCommerce catalog
Customer bought two products
Checkout ran through UCPReady
Payment used wallet rails plus browser authorization
Order completed
Customer changed their mind about one item
KeepCard.io verified the order, surfaced the line items, collected the reason, and presented a keep offer
Customer accepted the offer
A real discount code was generated
A real confirmation email was sent

That is the entire commerce loop in one conversational journey.

What actually happened

The session started like a normal shopping flow. The model searched a live WooCommerce store, found products, built a checkout, selected fulfillment, selected payment, and moved through the purchase flow using UCPReady.

Then, in the same broader system, we tested returns through KeepCard.io.

The return flow did this:

Looked up the order by order number and email
Checked eligibility
Collected the return reason
Evaluated keep-offer logic
Presented the customer with a keep offer in chat
Accepted the offer
Generated a real discount code
Sent the confirmation email

We saw the discount code issued. We saw the email arrive. We saw the KeepCard dashboard record the return session as Kept.

That is not "AI-assisted support." That is a real agentic commerce lifecycle.

A real example from tonight

The customer started with:

I want to buy something to clean my face

The model searched the live catalog and found:

Rilastil Aqua Face Cleanser 200ml — €16.95
Shiseido Men Face Cleanser 125ml — €18.95

The customer then said:

buy me 2 of Rilastil Aqua Face Cleanser 200ml and 1 Shiseido Men Face Cleanser 125ml

The system created checkout, configured fulfillment and wallet payment, and moved the buyer into the final authorization step.

After the order completed, the customer came back with:

Oh no, I made a mistake — I want to return the item

The return flow asked for the order number, verified eligibility, and surfaced the exact purchased items:

Rilastil Aqua Face Cleanser 200ml (Quantity: 2)
Shiseido Men Face Cleanser 125ml (Quantity: 1)

The customer selected only the Shiseido item. Then gave the reason:

Other — I made a mistake

Instead of routing to a standard return portal, the system evaluated the return and offered a keep option:

You can keep the Shiseido Men Face Cleanser and receive €1.00 off your next order as a discount code.

The customer replied:

Accept

The result:

Keep offer accepted ✓
Discount code KEEP-3V9FNM generated in WooCommerce ✓
Confirmation email delivered via KeepCard's email stack ✓
No return shipment needed ✓

That is exactly the kind of post-purchase flow that usually lives inside rigid portals, manual support queues, or custom integrations tied to one model vendor. Tonight it happened conversationally on top of a live WooCommerce stack.

The architecture: what UCPReady and KeepCard.io actually are

UCPReady is a WooCommerce plugin that implements the Universal Commerce Protocol (UCP) — an open protocol for exposing store capabilities through structured, machine-operable interfaces. It turns a WooCommerce store into a UCP-compliant endpoint that AI agents can discover and transact with autonomously.

The MCP endpoint on houseofparfum.nl exposes these tools:

— shopping —
ucp_list_products       ucp_get_product
create_checkout         get_checkout
update_checkout         complete_checkout
cancel_checkout         create_cart
get_cart                update_cart
cancel_cart             convert_cart
ucp_get_order           ucp_list_orders

— returns (KeepCard) —
keepcard_check_return_eligibility
keepcard_select_return_items
keepcard_submit_return_reason
keepcard_accept_keep_offer
keepcard_decline_keep_offer

KeepCard.io is a standalone returns intelligence platform. It connects to WooCommerce via REST API and Shopify via app installation. It owns the decision engine — return eligibility, keep-offer thresholds, fraud signals, monthly caps, discount code generation, and email delivery. None of that logic lives in the LLM.

The UCPReady companion plugin for KeepCard exposes five MCP tools that let any agent drive the return flow conversationally, while KeepCard handles all the business logic and side effects server-side.

The important part: no AI in the business logic

This is the part worth repeating.

There is no hidden LLM orchestration inside the return engine. There is no model deciding business logic in the backend. There is no "if Claude says X, do Y" architecture.

The business logic is deterministic:

Return eligibility
Order verification
Keep-offer thresholds
Duplicate protection
Policy routing
Store credit and discount issuance

The model is only the interface layer.

That makes the system:

Model-agnostic — Claude, GPT-5, Gemini, Grok all work
Easier to audit — no prompt-based rules buried in a system prompt
Easier to harden — business rules are code, not inference
More future-proof — swap the model, the commerce layer stays the same

The same session ran successfully with both Claude Sonnet 4.5 and GPT-5. Neither needed store-specific prompting. The protocol carries the context.

How the return flow chains through UCPReady

The integration works server-to-server. When the agent calls keepcard_check_return_eligibility, UCPReady makes an HTTP POST to the KeepCard /api/mcp/init endpoint with the store slug, order ID, and email. KeepCard resolves the order directly against WooCommerce or Shopify using its own stored credentials — UCPReady never touches the order data.

The full call chain looks like this:

Agent → UCPReady MCP endpoint (WooCommerce)
      → KeepCard /api/mcp/* (cloud service)
      → WooCommerce or Shopify API (order verification)
      → KeepCard decision engine (keep-offer logic)
      → WooCommerce API (discount code creation)
      → KeepCard email stack (confirmation)
      → back through the chain to the agent

The LLM sees clean structured responses at each step:

// keepcard_check_return_eligibility response
{
  "eligible": true,
  "session_id": "...",
  "needs_item_selection": true,
  "customer_message": "I found order #85774. You have 30 day(s) left to return it. Which item(s) would you like to return?",
  "order": {
    "display_id": "85774",
    "items": [...],
    "currency": "EUR",
    "days_remaining": 30
  }
}

// keepcard_accept_keep_offer response
{
  "outcome": "kept",
  "discount_code": "KEEP-3V9FNM",
  "amount": 1.00,
  "currency": "EUR",
  "email_sent": true,
  "customer_message": "Done! Your discount code is KEEP-3V9FNM — worth 1.00 EUR off your next order. A confirmation has been sent to your email."
}

The customer_message field means the agent surfaces KeepCard's language directly — it does not have to infer what to say from raw API data.

Why this is different from what's already out there

Most of what is marketed today as "AI returns" falls into one of these buckets:

Approach	What it actually is
Chatbot on a returns portal	AI layer on top of an existing flow, still ends in a form
Custom automation project	Tied to one model vendor, one store, one integration
Shopify-first AI returns	Good tooling, but WooCommerce is a different ecosystem
Refund infrastructure for devs	Powerful but requires significant custom work

Those are real products. But they are still mostly AI applications sitting on top of commerce systems.

What we are building is different: the commerce system itself becomes operable by agents.

UCPReady exposes structured commerce capabilities through UCP and MCP. KeepCard.io exposes post-purchase capabilities through the same kind of machine-operable interface. The store does not wait for us to write Claude-specific code, GPT-specific prompts, or Gemini-specific workflows.

The model is replaceable. The protocol is the product.

Why WooCommerce specifically matters

A lot of public examples in this space are Shopify-first. That makes sense — Shopify has a louder app ecosystem and more visible AI tooling.

But what happened tonight was on WooCommerce.

WooCommerce powers a large share of the world's online stores. It has almost no public examples of protocol-driven, frontier-model, post-purchase flows. The combination of:

WooCommerce-native
Protocol-native (UCP)
Model-agnostic
Agent-executable
Post-purchase keep-offer logic

...is the category we are helping define. I have not seen a strong public proof of this combination before tonight.

What broke (because honesty matters)

Tonight was not a perfect demo, and that is exactly why it was valuable.

1. The keep-offer accept step was occasionally slow. The final keepcard_accept_keep_offer step sometimes exceeded the runner timeout budget. The business action still completed — coupon created, email sent, session marked kept — but the agent runner could report failure because the round trip took too long. This is a bridge latency problem, not a logic problem.

2. Duplicate finalization needed hardening. When the first accept completed but the runtime retried, we needed the system to treat the retry as a successful terminal state rather than an error. Repeated accept should return: already processed, discount code, final state. That is what resilient agent commerce looks like.

3. Mixed shopping and returns in one session exposed session contamination. In one test, we ran search → purchase → return inside a single session. That exposed a session-orchestration issue: return tools were receiving stale search arguments from the earlier shopping flow. Not a KeepCard logic problem. A session-context boundary problem. The kind you only discover once the stack is real enough to chain these experiences together.

Where we go next

The hardest question has been answered: can a model search, buy, and then resolve a return with keep-offer logic on a live WooCommerce store through protocol-native rails?

Yes. Tonight, it did.

The remaining work is hardening, not architecture:

Reduce latency on the post-purchase bridge
Keep terminal actions idempotent across retries
Isolate session state between shopping and returns flows
Test identity linking across multi-session journeys
Validate the same lifecycle across more stores

When the remaining problems are latency budgets, idempotency, and session context boundaries — you are no longer asking whether the concept works. You are refining a working system.

The bigger idea

The goal is not "AI can help with returns."

The goal is: stores should become operable by agents through standard protocols.

Search is one capability. Checkout is one capability. Payment is one capability. Returns are one capability. Keep-offers are one capability. Once those are exposed properly through open protocol rails, the model becomes interchangeable.

That is when agentic commerce stops being a gimmick and starts becoming infrastructure.

UCPReady: zologic.nl/ucpready — WooCommerce UCP implementation

KeepCard.io: keepcard.io — Returns intelligence platform

Session recording: ucpplayground.com/s/01KQFVJJK6HZF2Z58MVMZQ3WXP

Universal Commerce Protocol: ucp.dev

60 seconds to see if your webstore supports the latests UCP protocol. Give it a run!

Almin Zolotic — Thu, 30 Apr 2026 12:03:40 +0000

Benji Fisher

Apr 30

Is My Store UCP Ready? How to Check in 60 Seconds

#ecommerce #webdev #tutorial #ucp

Comments 1

5 min read

The 0.2% flawless rate from your April report is wild. Most stores have a manifest. Almost none actually work end-to-end. It's a conformance problem, not an infrastructure problem — and that's exactly what this score makes visible. Love what you built here

Almin Zolotic — Wed, 29 Apr 2026 11:29:46 +0000

Benji Fisher

Apr 29

Introducing the UCP Score: A 0–100 Agent-Readiness Grade for Every UCP Store

#ecommerce #ai #product #ucp

Comments 2

8 min read

AP2 Mandates Are Live on UCPReady — Here's What That Actually Means for Autonomous Payment

Almin Zolotic — Fri, 24 Apr 2026 19:42:29 +0000

Zero merchants in Ben Fisher's 4,024-merchant UCP dataset support native payment. I've been building toward closing that gap since March. Today it's done — at least on the business side.

This post is about AP2 Mandates: what they are, why they're the only spec-compliant path to autonomous card payment on UCP, and what it took to implement them correctly on WooCommerce.

Why every UCP checkout still ends with a browser redirect

When an AI agent completes a UCP checkout today, it gets a continue_url. The buyer clicks a link, lands on the WooCommerce checkout page, fills in their card, and pays. The agent handled discovery and session setup. The human handled payment.

That handoff exists because the spec requires it — unless one specific extension is active.

From the UCP checkout specification:

"The checkout has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported."

That "unless" is the entire autonomous payment story in UCP. Not Stripe tokens. Not saved cards. Not wallet APIs. AP2 Mandates.

What AP2 Mandates actually are

AP2 is a cryptographic authorization framework. When it's negotiated between a business and a platform, the checkout session is "security locked" — neither party can revert to an unprotected flow.

The flow has two sides:

Business side: Every checkout response must include ap2.merchant_authorization — a JWS detached signature proving the checkout terms (price, line items, totals) are authentic and haven't been tampered with. The signature is ES256, JCS-canonicalized per RFC 8785, with the payload excluded from the JWS body (RFC 7515 Appendix F detached content format).

Platform side: When the user confirms the purchase, the platform generates a cryptographically signed mandate — an SD-JWT credential proving the user explicitly authorized this specific transaction. It submits that mandate at complete_checkout. The business verifies it. If valid, payment proceeds without a browser redirect.

The checkout mandate contains the full checkout response including the business's merchant_authorization. So the platform's signature covers the business's signature. It's a nested cryptographic binding: the business proves the terms, the platform proves the user consented to those exact terms.

What implementing this actually required

Getting the signing right

The spec says ES256 with detached JWS. In PHP, openssl_sign() on a P-256 key produces a DER-encoded ECDSA signature. JWS ES256 requires raw r||s — 64 bytes for P-256. Those are not the same format.

Every JWS library you'd use on the platform side (jose, python-jose, jsonwebtoken) expects raw r||s. A DER signature will fail verification silently or throw a malformed signature error. The fix is a DER-to-raw-rs converter:

// openssl_sign() → DER. JWS ES256 → raw r||s. Not the same.
openssl_sign( $signing_input, $signature_der, $private_key, OPENSSL_ALGO_SHA256 );
$r = substr( $der_inner, $r_offset, $r_len );
$s = substr( $der_inner, $s_offset, $s_len );
$signature_raw = str_pad( ltrim($r, "\x00"), 32, "\x00", STR_PAD_LEFT )
               . str_pad( ltrim($s, "\x00"), 32, "\x00", STR_PAD_LEFT );

The JCS canonicalization (RFC 8785) is the other non-obvious requirement. Before signing, the checkout payload is canonicalized — keys sorted recursively, Unicode normalized, numbers in IEEE 754 format. This ensures the signature is reproducible across systems that may re-serialize JSON differently.

Enforcing the mandate at complete_checkout

The spec is explicit: if AP2 was negotiated, complete_checkout MUST reject requests without ap2.checkout_mandate. This is the security boundary. Without it, AP2 is advertised but provides no protection — a platform could skip the mandate entirely and the checkout would succeed.

The enforcement block runs before order creation:

if ( $ap2_ext->is_ap2_configured() ) {
    $mandate_jwt = $body['ap2']['checkout_mandate'] ?? null;
    if ( empty( $mandate_jwt ) ) {
        // Return mandate_required error — session stays ready_for_complete
        return $this->mandate_error_response( 'mandate_required', $session );
    }
    $mandate_error = $ap2_ext->verify_checkout_mandate( $mandate_jwt, $session, $request );
    if ( null !== $mandate_error ) {
        return $this->mandate_error_response( $mandate_error['code'], $session );
    }
}

Verifying the mandate

When a mandate is present, the full verification chain runs:

Parse the SD-JWT structure (header.payload.signature~disclosures~keybinding)
Check expiry (exp claim)
Extract the embedded checkout from mandate claims
Re-verify merchant_authorization — confirm the platform wrapped our own signature, not a different checkout
Verify checkout ID matches the current session
Verify totals match — no bait-and-switch between what the user saw and what gets charged

Platform key verification

The final step: verifying the SD-JWT outer signature using the platform's public key. This is what proves the mandate is genuinely from the platform and not forged.

The flow: decode the JWS header → extract alg and kid → fetch the platform's UCP profile from the UCP-Agent header → pull signing_keys → find the JWK matching kid → build an OpenSSL public key from the JWK x/y coordinates → verify.

Building an EC public key from JWK coordinates without a library means constructing the SubjectPublicKeyInfo DER by hand in PHP — OID encoding, SEQUENCE wrapping, BIT STRING for the uncompressed EC point. It's ~80 lines but removes a runtime dependency and works on any WordPress host.

The platform profile is fetched over HTTPS and cached with WP transients, respecting Cache-Control max-age with a 60-second floor. Verification result is logged with kid, algorithm, and session ID for auditability.

The capability name that broke everything

Before any of this verification mattered, there was a simpler bug: the capability was advertised as dev.ucp.shopping.ap2_mandates — plural. The spec uses dev.ucp.shopping.ap2_mandate — singular.

Capability negotiation is a string equality check. The intersection algorithm finds no match between ap2_mandates and ap2_mandate. AP2 is never activated. Every checkout session falls back to delegate payment. No error, no warning — it silently never negotiates.

One character. Every implementation should validate capability names against the spec registry rather than trusting their own strings.

What's live now

When dev.ucp.shopping.ap2_mandate is enabled in UCPReady and a compatible platform connects:

Every checkout response includes ap2.merchant_authorization (JWS ES256, detached, JCS payload)
complete_checkout rejects requests without ap2.checkout_mandate
Verification runs: SD-JWT parse → expiry → embedded checkout extraction → merchant_authorization re-verification → ID and totals match → platform key verification
If all checks pass, payment proceeds — no browser redirect

The one remaining piece is ecosystem readiness: a platform that supports AP2 mandate submission and forwards the access token that proves identity linking. Ben Fisher's UCPPlayground is the logical first test. Once that's connected, UCPReady will produce the first confirmed AP2-mandate-verified autonomous purchase on WooCommerce.

Why this matters beyond WooCommerce

Ben's dataset of 4,024 merchants shows zero native payment support. Part of that is the SPT/ACS story — Stripe's Shared Payment Token is US-only right now and requires Stripe to host the checkout flow. That's a different architecture than UCP.

On UCP, AP2 Mandates is the spec's answer. It's protocol-agnostic — the mandate can cover any payment method handled by any PSP. The platform proves user consent cryptographically. The business verifies that proof and charges via their existing payment gateway. No card data crosses protocol boundaries. PSD2 SCA compliance comes from the mandate being platform-issued and buyer-authenticated at mandate creation time.

This is what autonomous agent commerce looks like when the merchant controls the checkout instead of delegating it to Stripe's infrastructure.

UCPReady is available at zologic.nl/ucpready.

If you're building a platform that supports UCP and want to test AP2 mandate submission against a live endpoint, reach out. houseofparfum.nl is running UCPReady 1.8.23 with AP2 ready to activate.

How We Took a New SaaS From Search Confusion to a Clean Google Entity Before Launch

Almin Zolotic — Thu, 23 Apr 2026 16:06:30 +0000

We’re launching KeepCard on Product Hunt tomorrow.

Before launch, we ran into a problem that a lot of early-stage products probably hit and don’t notice right away:

Google was getting confused about what KeepCard actually is.

Instead of understanding KeepCard as a B2B ecommerce product, it was blending our brand with unrelated products that had a similar name. The page itself was fine to a human, but search engines need more than “looks good” to understand a brand entity correctly.

So we spent time fixing the foundation.

What KeepCard is

KeepCard is a pre-return recovery platform for Shopify and WooCommerce merchants.

It sits in front of the normal return flow. A customer scans a QR card, verifies the order, selects a reason, and preference-based returns can receive a controlled keep offer before reverse logistics starts.

That’s very different from a generic “card app” or consumer wallet product.

And that difference needs to be obvious everywhere.

The real SEO problem wasn’t rankings first. It was identity.

A lot of launch-stage SEO advice focuses on:

titles
meta descriptions
page speed
keyword placement

Those matter, but our first issue was more basic:

Google wasn’t fully confident about the entity behind the name.

If your brand name overlaps with existing apps, products, or companies, then good markup alone may not be enough. Search engines look at:

page titles and descriptions
structured data
crawlable supporting pages
social cards
external mentions
linked profiles
consistency of naming across the web

So we approached this like an entity cleanup project, not just an on-page SEO task.

What we changed

1. We made the homepage name more explicit

Instead of only saying KeepCard, we started using:

KeepCard for Shopify and WooCommerce

That sounds small, but it gives search engines a much stronger disambiguation signal.

We updated:

title tags
Open Graph tags
Twitter cards
meta descriptions
application naming
structured data labels

The goal was simple: every important machine-readable surface should say the same thing.

2. We strengthened structured data

We expanded the homepage schema to describe KeepCard as:

an Organization
a WebSite
a SoftwareApplication
a Service

And we added supporting context like:

alternate names
audience
publisher
brand relationship
service type

The point wasn’t “more schema because schema is good.”

The point was to help Google understand:

who we are
what we offer
who it is for
what category we belong to

3. We de-indexed the wrong surfaces

Our merchant app lives on a separate subdomain.

That app is useful to users, but not useful as a landing surface for search engines. In fact, it can create confusion if it exposes thin or generic titles.

So we added noindex signals there and kept the public marketing site as the canonical search target.

This is underrated:

Sometimes SEO improves not by publishing more pages, but by making sure crawlers ignore the wrong ones.

4. We improved technical quality because trust compounds

We also cleaned up the technical side:

fixed render-blocking font issues
reduced layout shift
improved heading structure
added proper landmarks
cleaned up CSP problems
improved performance on mobile

We ended up with a clean Lighthouse result:

100 Performance
100 Accessibility
100 Best Practices
100 SEO

That score alone doesn’t guarantee rankings.

But it removes a lot of unnecessary ambiguity and friction.

Why I’m posting this before Product Hunt

Because launch traffic is noisy.

If people mention your brand tomorrow across:

Product Hunt
X
DEV
LinkedIn
indie communities
blog roundups

you want those mentions reinforcing one clear identity.

Not scattering weak, inconsistent versions of your brand across the web.

That means the best time to fix entity confusion is before the wave of citations starts.

What we’re doing now to build branded citations and backlinks

The next phase is consistency.

We want every mention of KeepCard to reinforce the same identity:

KeepCard is a pre-return recovery platform for Shopify and WooCommerce merchants.

So we’re pushing that exact framing across:

Product Hunt
DEV
founder social profiles
launch posts
directories
documentation
email signatures
future guest posts

Not for keyword stuffing.

For entity clarity.

What I’d recommend to other founders

If you’re launching a new product, especially with a brand name that could be confused with something else:

1. Stress-test your name in search

Search your exact brand and see what Google thinks it is.

2. Make your machine-readable surfaces consistent

Titles, meta descriptions, OG tags, schema, canonicals, and app naming should tell the same story.

3. Keep crawlers focused

Index the pages that explain your business best. De-index weak or confusing app surfaces.

4. Use the same one-sentence description everywhere

You need a stable phrase people can repeat when they mention your company.

5. Treat backlinks as entity confirmation, not just authority

A backlink helps more when the surrounding text clearly says what your company is.

Final thought

The biggest SEO win for a new SaaS is often not “ranking harder.”

It’s making it easy for Google to stop guessing.

That’s what we focused on for KeepCard before launch.

If you’re working on search clarity, launch prep, or technical SEO for an early product, I’d love to compare notes.

We launch tomorrow on Product Hunt.

You can see the product here: https://keepcard.io

WooCommerce Now Has More UCP capabilities than Shopify. Here's the breakdown.

Almin Zolotic — Tue, 14 Apr 2026 17:39:29 +0000

UCPChecker just launched store-to-store comparisons. I ran my WooCommerce store against Reebok (Shopify). The results surprised me.

The Numbers

Metric	WooCommerce	Shopify
Capabilities	11	5
Transports	3	2
Latency	558ms	225ms
Status	Verified	Verified

Shopify is faster. WooCommerce exposes more.

What WooCommerce Has That Shopify Doesn't

Six capabilities are unique to the WooCommerce store:

Identity Linking — OAuth 2.0 buyer authentication
Buyer Consent — GDPR/CCPA preference handling
Embedded Checkout — iframe protocol for payment delegation
Catalog Search — structured product discovery
Catalog Lookup — individual product fetch
Products — base product capability

The big one is Identity Linking.

When a buyer connects their store account to an AI platform, the agent can access their saved addresses, wallet balance, and (eventually) saved payment methods. This is what enables fully autonomous checkout — the agent doesn't need a credit card if it can use the buyer's stored value.

Shopify's UCP implementation stops at checkout initiation. The agent can browse, build a cart, and start checkout — but payment requires a browser redirect. The human finishes the transaction.

Why This Matters

The UCP spec defines the maximum surface an agent can interact with. Stores declare which capabilities they support. Agents query the manifest and adapt their behavior.

A store with 5 capabilities gives agents 5 ways to help. A store with 11 capabilities gives agents 11 ways to help. More surface area = more useful agent interactions = more conversions.

Right now, Shopify owns the UCP install base — UCPChecker's directory shows thousands of Shopify stores with manifests, versus a handful of WooCommerce stores. But install base isn't the same as capability depth.

The Latency Trade-off

Shopify: 225ms. WooCommerce: 558ms.

This is expected. Shopify is a $100B+ platform with global CDN infrastructure. WooCommerce is self-hosted PHP on whatever server the merchant chose.

558ms for a 40k SKU WooCommerce store is actually solid. And latency matters less than you'd think for agent commerce — agents batch multiple tool calls, so the total session time matters more than individual response times.

A typical checkout session on either platform takes 5-15 seconds total. Whether each call is 200ms or 500ms doesn't change the user experience much.

What Shopify Could Add

The five capabilities Shopify ships are the core: checkout, fulfillment, discount, order management, cart. These cover the happy path for agent shopping.

To match WooCommerce's depth, Shopify would need to add:

Identity linking — OAuth flow for buyer authentication
Embedded checkout — ECP protocol for iframe payment
Structured catalog capabilities — search and lookup as declared capabilities

Shopify has the resources to ship these. The question is prioritization. Right now, they've optimized for breadth (every Shopify store has UCP) over depth (limited capability set).

What WooCommerce Needs

WooCommerce's advantage is flexibility — you can add any capability the spec supports. The disadvantage is adoption — merchants have to install a plugin and configure it.

Right now, the WooCommerce UCP ecosystem is small. UCPReady is the main option. For WooCommerce to compete on install base, either:

UCPReady adoption grows organically
Other plugins emerge (competition is healthy)
WooCommerce core ships native UCP support

Option 3 is unlikely near-term — WooCommerce core moves slowly and UCP is still early. But options 1 and 2 are happening.

The Bottom Line

Shopify made UCP ubiquitous. WooCommerce made it deep.

If you're a merchant choosing between platforms, the question is: do you want to be in the largest agent-accessible network (Shopify), or do you want the most capable agent integration (WooCommerce)?

If you're an agent developer, the answer is simpler: build for both. The UCP spec is platform-agnostic. The same agent code that shops Shopify can shop WooCommerce — it just gets more capabilities on the latter.

Run your own comparison: ucpchecker.com/compare

Building UCP for WooCommerce? I'm @zologic — drop a comment or DM.

Building the Only UCP Plugin for WooCommerce — Outside the Walled Garden

Almin Zolotic — Thu, 09 Apr 2026 17:50:45 +0000

When protocol compliance conflicts with platform policy, independence stops being a limitation and becomes a feature that enables full execution.

Two months ago, AI purchasing landed on Shopify, and within hours a WooCommerce store completed a fully autonomous transaction without any human interaction.

That store was running UCPReady, a plugin that turns WooCommerce into a Universal Commerce Protocol endpoint for AI agents to transact directly.

Today, UCPReady is the only WooCommerce plugin with full UCP 2026-04-08 compliance, running in production and processing real autonomous orders.

What Makes It Different

UCPReady is not a partial implementation or a demo layer, but a complete protocol-native system designed for real autonomous commerce flows.

Full Universal Commerce Protocol 2026-04-08 compliance across all required surfaces and behaviors
Support for REST, MCP, and Embedded Checkout transports without fallback compromises
Autonomous AI purchasing with no human confirmation step required at checkout
Schema Quality rating of A (99) verified through independent validation tools
Spec updates shipped within 24 hours from release to production deployment

This is production commerce running on an open protocol rather than a controlled integration.

Why It’s Not in the Marketplace

Open protocols sometimes introduce requirements that do not align with existing marketplace rules designed for traditional plugin behavior.

UCP requires that checkout execution completes fully when invoked, including payment processing, instead of redirecting to manual confirmation flows.

Marketplace policies, reasonably, enforce strict controls around autonomous payment execution for security and user protection reasons.

That creates a structural mismatch between protocol requirements and platform rules rather than a simple review outcome.

The decision becomes whether to adapt the protocol to fit the platform or preserve the protocol and distribute independently.

UCPReady chose to preserve the protocol as designed.

Core Difference in Approach

WooCommerce is building AI capabilities focused on merchants managing their stores through internal tools and administrative workflows.

UCPReady focuses on the opposite side of the interaction, where AI agents act on behalf of users to discover and purchase products.

These approaches are not competing implementations, but they operate at completely different layers of the commerce stack.

Why Independence Works Better

Operating outside the marketplace enables faster iteration cycles that match the pace of protocol evolution without external approval delays.

Full compliance can be maintained without introducing exceptions, fallbacks, or behavior changes that fragment the protocol surface.

Support becomes direct and immediate, without reliance on layered support systems or delayed release cycles.

Merchants get a transparent product with clear capabilities instead of features shaped by policy constraints.

The Trade-off

You do not get marketplace distribution, automatic updates, or official platform endorsement through the standard channels.

You do get full protocol compliance, rapid updates, direct support, and a system designed for autonomous AI commerce from the ground up.

This is a trade between convenience and capability rather than a limitation of the implementation.

Standards vs Platform Deals

Platform integrations are fast to deploy but inherently limited by agreements, approvals, and ecosystem boundaries.

Open protocols are slower to standardize but enable interoperability across platforms, agents, and implementations without restriction.

UCPReady is built on the assumption that standards will outlast individual platform deals.

What This Means

If you want your WooCommerce store to be accessible to AI agents for real autonomous purchasing, this capability exists today.

It does not require waiting for platform updates, partnerships, or future roadmap features to become available.

It requires adopting a protocol-first approach that operates outside traditional distribution models.

Final Note

Some innovations do not fit inside existing systems because those systems were designed for a different generation of use cases.

Autonomous AI commerce is one of those cases, and open protocols are where that shift is currently happening.

UCPReady exists outside the marketplace because that is currently the only place it can fully exist without compromise.

🔗 Try UCPReady

💼 Almin Zolotic on LinkedIn

WooCommerce Just Did What Shopify Did — Hours Later, Open Protocol, Full Autonomous Purchase

Almin Zolotic — Wed, 25 Mar 2026 09:31:08 +0000

Shopify announced AI-powered purchasing in ChatGPT this morning. Six hours later, a WooCommerce store completed a fully autonomous AI purchase — identity linked, wallet debited, order in processing — using an open protocol anyone can implement.

No partnership deal. No platform exclusivity. Just a spec, a plugin, and a real order.

What happened this morning

At 09:37 AM today, an AI agent (Claude Sonnet 4.5) completed an autonomous purchase on houseofparfum.nl, a 40,000 SKU WooCommerce perfume store.

Here's the full session replay:

UCPPlaygroundhouseofparfum.nl via Claude Sonnet 4.5 - UCPPlayground

Checkout Reached in 43.6s. Watch the full agent session replay.

ucpplayground.com

What the agent did, without any human intervention:

Searched for a perfume under €30
Created a checkout session
Selected the Terrawallet wallet payment instrument (surfaced from the linked identity)
Selected flat-rate shipping
Called complete_checkout with an idempotency key
The wallet was debited €22.93
WooCommerce order #82244 was created with status processing

8 turns. 79,152 tokens. Schema Quality: A (99).

The difference from Shopify

Shopify's ChatGPT integration is impressive. But it's a bilateral deal between two platforms. Shopify stores work in ChatGPT. That's it.

What happened today uses the Universal Commerce Protocol (UCP) — an open specification that any store, any agent, and any platform can implement independently.

The same flow that worked in UCPPlayground today will work in any UCP-compliant agent host. Claude, GPT, Gemini, Grok — any model. Any platform that implements the MCP transport binding can discover houseofparfum.nl's capabilities, link buyer identity, and complete a purchase.

No bilateral agreement required. No platform partnership. Just a spec.

What makes this technically interesting

Identity linking — the agent authenticated via OAuth 2.0 Authorization Code + PKCE against the store's own OAuth server (RFC 8414, RFC 7591). The bearer token resolved to WooCommerce customer ID 1. Name, email, phone, billing address, shipping address — all pre-populated from the WC account. The agent never asked for any of it.

Autonomous payment — Terrawallet store credit was surfaced as a payment instrument because the linked identity had a wallet balance. The agent selected it, called complete_checkout, and the wallet was debited server-side. No browser redirect. No payment form. No human in the loop.

UCP protocol compliance — every response carried ucp.capabilities in the correct keyed-object format. The MCP transport binding used bare tool names (complete_checkout, not ucp_complete_checkout). The idempotency store prevented duplicate orders on retry. Schema Quality A (99) from UCPChecker.

The stack

Plugin: UCPReady (FREE WooCommerce plugin by Zologic)
Protocol: Universal Commerce Protocol 2026-01-23
Transport: MCP (Model Context Protocol) JSON-RPC 2.0
Test platform: UCPPlayground by Ben Fisher / UCPChecker
Store: houseofparfum.nl (live production, 40k+ SKUs, Redis)

UCPReady was validated by Ben Fisher (UCPChecker) as "the most spec-complete non-Shopify UCP implementation tested." It also exposed 4 bugs in the UCPPlayground embedded checkout during interop testing — all fixed the same day.

What this means for WooCommerce merchants

If you run a WooCommerce store today, you are one plugin install away from being discoverable and purchasable by any AI agent that implements UCP.

Not "AI-assisted checkout." Not "AI product recommendations." Fully autonomous purchase — the agent finds the product, builds the session, collects buyer details from linked identity, selects payment, and completes the order. You get a WooCommerce order in processing status, attributed to the linked customer account, with full order history.

The same infrastructure that powers Shopify's ChatGPT integration — agentic discovery, session management, identity linking, autonomous payment — is now available to every WooCommerce store via an open protocol.

What's next

Ben Fisher is adding multi-item cart flow to UCPPlayground today. The cart capability (dev.ucp.shopping.cart) is already declared in houseofparfum.nl's /.well-known/ucp manifest and the tools are live. Once the Playground wires up the cart flow, agents will be able to browse, build multi-item carts, compare products, and convert to checkout — the full pre-purchase exploration flow.

The UCP Technical Committee nomination window closes April 3. If you're building on UCP or have a perspective on how the protocol should evolve, now is the time to get involved: https://github.com/Universal-Commerce-Protocol/ucp

Try it

Live store endpoint: https://houseofparfum.nl/.well-known/ucp
UCPPlayground: ucpplayground.com — connect houseofparfum.nl and run your own session
UCPReady: https://zologic.nl/product/ucpready-ai-agent-commerce-for-woocommerce/
UCP Spec: ucp.dev/latest/specification

UCPReady is built by Zologic. The autonomous purchase milestone was achieved in collaboration with Ben Fisher (UCPRails/UCPPlayground/UCPChecker) who has been validating UCP implementations across the ecosystem.

Why your WooCommerce AI Agent endpoint is slow (and how we fixed it in 30 lines)

Almin Zolotic — Tue, 24 Mar 2026 16:23:28 +0000

Published by Almin Zolotic — Zologic / UCPReady

We spent most of yesterday debugging an 8-second ucp_list_products response on a live WooCommerce store with 40,000+ SKUs. The fix was 30 lines of PHP. Here's the full investigation — every dead end included — because anyone building on WooCommerce + UCP is going to hit this.

The setup

houseofparfum.nl runs UCPReady — our WooCommerce plugin that implements the Universal Commerce Protocol (UCP) over REST, MCP, and Embedded Checkout. It's been running in production since February, and UCP Playground benchmarks consistently showed ucp_list_products taking 8,432ms.

That's not a typo. Eight seconds. On every cold session.

For context: Shopify's median MCP tool call latency is 146ms. An AI agent making 4-5 tool calls in a session at 8 seconds each is going to hit platform timeouts. Sessions fail. Purchases don't complete.

We needed to find and fix the root cause.

Eliminating suspects

Suspect 1: The database query

First thing to check — is the WooCommerce product query slow?

wp eval '
$start = microtime(true);
$results = wc_get_products([
    "status" => "publish",
    "limit" => 10,
    "paginate" => true,
]);
echo "Query: " . round((microtime(true) - $start) * 1000) . "ms\n";
echo "Total: " . $results->total . "\n";
' --allow-root

Result: 159ms for 38,433 products. Fast. Not the problem.

Suspect 2: Product transformation

UCPReady transforms WC_Product objects into UCP format on each request. How long does that take for 10 products?

wp eval '
$adapter = UCPReady\Adapters\ProductAdapter::get_instance();
$results = wc_get_products(["status" => "publish", "limit" => 10]);
$start = microtime(true);
foreach ($results as $product) {
    $adapter->to_ucp_list_format($product);
}
echo "Transform: " . round((microtime(true) - $start) * 1000) . "ms\n";
' --allow-root

Result: 10ms. Not the problem.

Suspect 3: Redis / object cache

The store has Redis installed. Checking if it's actually connected to WordPress:

wp cache type --allow-root
# Redis ✓

wp eval '
$found = false;
wp_cache_get("ucp_product_list_82192", "ucpready", false, $found);
echo $found ? "CACHED" : "NOT CACHED";
' --allow-root
# NOT CACHED

Redis is connected but product list cache keys aren't being populated. Separate issue — but not the 8-second culprit either.

Suspect 4: The taxonomy mapper

UCPReady maps WooCommerce categories to Google Product Taxonomy IDs. This involves loading a 482KB taxonomy file and building an inverted index. Was it rebuilding on every request?

wp eval '
$start = microtime(true);
$mapper = UCPReady\Taxonomy\TaxonomyMapper::get_instance();
$mapper->map_category(17, "en_US");
echo round((microtime(true) - $start) * 1000) . "ms\n";
' --allow-root
# 18ms

18ms cold. Fast. And we fixed the caching here anyway — the built inverted index now persists to Redis with a 6-hour TTL. But still not the 8-second culprit.

The real test: HTTP vs WP-CLI

At this point we noticed something odd. Every WP-CLI test was fast. The same operations over HTTP were taking 8 seconds. WP-CLI has WordPress already loaded in memory. HTTP requests boot WordPress from scratch on every call.

time curl -s -o /dev/null -X POST \
  "https://houseofparfum.nl/wp-json/ucpready/v1/mcp" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ucp_list_products","arguments":{"limit":5}}}'

# real 0m8.101s

8 seconds over HTTP. 169ms in WP-CLI. The gap is WordPress boot time.

Finding the culprit

The store has 17 active plugins. Something in that list was making every MCP request boot WordPress for 8 seconds. We tested methodically:

wp plugin deactivate google-listings-and-ads --allow-root

time curl -s -o /dev/null -X POST \
  "https://houseofparfum.nl/wp-json/ucpready/v1/mcp" \
  ...

# real 0m0.651s

Google Listings and Ads was adding 7.5 seconds to every single MCP request.

Not because of the product query. Not because of anything UCP-related. The plugin registers expensive hooks during WordPress initialisation that fire on every request — including REST API requests that have nothing to do with Google Shopping feeds.

This isn't a UCPReady problem or even a UCP problem. It's a WooCommerce plugin ecosystem problem. Any plugin that does expensive work on init or similar hooks will slow down every MCP request on every WooCommerce store running it.

The fix: Partial Bootstrap Mode

The solution is a must-use plugin that fires before regular plugins load and removes the offenders from the active plugins list for MCP requests only. Everything else on the store — admin, storefront, Google Shopping feed generation — is completely untouched.

<?php
/**
 * UCPReady MCP Partial Bootstrap
 * Place in /wp-content/mu-plugins/ucpready-mcp-bootstrap.php
 */

if ( ! defined( 'ABSPATH' ) ) { exit; }

$ucpready_skip = array(
    'google-listings-and-ads/google-listings-and-ads.php',
    'query-monitor/query-monitor.php',
    'ajax-search-for-woocommerce/ajax-search-for-woocommerce.php',
);

$ucpready_uri    = $_SERVER['REQUEST_URI'] ?? '';
$ucpready_is_mcp = strpos( $ucpready_uri, '/ucpready/v1/mcp' ) !== false
    || strpos( $ucpready_uri, 'rest_route=/ucpready/v1/mcp' ) !== false;

if ( $ucpready_is_mcp ) {
    add_filter( 'option_active_plugins', function( $plugins ) use ( $ucpready_skip ) {
        if ( ! is_array( $plugins ) ) return $plugins;
        return array_values( array_diff( $plugins, $ucpready_skip ) );
    }, 1 );
}

That's the entire fix. The option_active_plugins filter with priority 1 fires before any plugin's code runs, so the offending plugins never register their hooks at all.

Results

time curl -s -o /dev/null -X POST \
  "https://houseofparfum.nl/wp-json/ucpready/v1/mcp" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"ucp_list_products","arguments":{"limit":5}}}'

# real 0m0.272s

Then we ran a full timing breakdown:

curl -w "DNS:%{time_namelookup} Connect:%{time_connect} SSL:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" ...

# DNS:0.001 Connect:0.001 SSL:0.038 TTFB:0.038 Total:0.267

Server TTFB: 38ms. The remaining ~4.5 seconds in Playground benchmarks is geographic network latency from US/UK servers to the Netherlands — not fixable at the server level.

WooCommerce at 38ms TTFB matches Shopify's performance characteristics. The variable isn't the platform. It's plugin configuration.

What this means for the WooCommerce + UCP ecosystem

This finding applies to every WooCommerce UCP implementation, not just UCPReady. If you're building on WooCommerce + UCP and ucp_list_products is slow, run this diagnostic:

# 1. Baseline with all plugins
time curl -s -o /dev/null -X POST "https://yourstore.com/wp-json/ucpready/v1/mcp" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ucp_list_products","arguments":{"limit":5}}}'

# 2. Deactivate plugins one by one and retest
wp plugin deactivate <plugin-name> --allow-root
# retest
wp plugin activate <plugin-name> --allow-root

# 3. Once you find the culprit, add it to the mu-plugin skip list

Common suspects beyond Google Listings: any plugin that runs expensive init hooks, external API calls during boot, or complex query modifications that fire on every request.

The broader lesson

AI agents make rapid sequential tool calls. A human tolerates a 3-second page load. An agent making 5 tool calls at 3 seconds each blows through platform timeouts and fails the session. Performance that was "acceptable" for human traffic becomes a hard blocker for agent traffic.

WooCommerce's plugin ecosystem is powerful but it was built for humans, not agents. Every plugin that does expensive boot-time work is a potential agent-killer. The mu-plugin pattern above is the pragmatic fix until the ecosystem catches up.

What we're working on next

The mu-plugin currently requires manual installation. We're adding a performance dashboard to UCPReady's admin settings that measures actual MCP response times, identifies problematic plugins automatically, and provides the mu-plugin as a one-click download when response times are above threshold.

We're also exploring whether it makes sense to report this to the Google Listings and Ads team directly. The fix on their side is a single is_rest_api_request() guard before registering expensive hooks. One line on their end helps every WooCommerce store, not just UCPReady users.

UCPReady is a WooCommerce plugin that implements the Universal Commerce Protocol — turning any WooCommerce store into a fully agent-executable commerce endpoint. Live demo: houseofparfum.nl | Plugin: zologic.nl

If your WooCommerce store is slow for AI agent traffic, I offer agent readiness audits. Reach out at contact@zologic.nl