DEV Community: Almin Zolotic

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

How I Built Autonomous AI Purchasing on WooCommerce: OAuth 2.0, Identity Linking, and Wallet Payments

Almin Zolotic — Sun, 22 Mar 2026 12:57:11 +0000

An AI agent searched a 40,000-SKU store, identified a product, pre-populated the buyer's details from a linked identity, debited a wallet, and created a paid WooCommerce order — with zero human interaction after the initial consent screen.

This is what I built this week. Here's how it works.

The Problem: AI Agents Can't Authenticate as Customers

AI agents can already browse your store, read product listings, and build a cart. That part is solved by protocols like UCP (Universal Commerce Protocol) and MCP (Model Context Protocol).

But the moment an agent tries to actually complete a purchase, it hits a wall:

Whose account is this order going on?
What's the shipping address?
How does the agent pay without a browser redirect?

The standard answer is: surface a continue_url and make the human finish the job in a browser. That's not agentic commerce — that's just a fancy product search with extra steps.

The real problem is identity. The agent doesn't know who it's acting for, and the store doesn't know who the agent represents.

The Solution: OAuth 2.0 Identity Linking

The draft UCP spec (version 2026-03-14) introduces a capability called dev.ucp.common.identity_linking. The mechanism is OAuth 2.0 Authorization Code flow with PKCE, where the AI agent platform is the OAuth client and the WooCommerce store is the authorization server.

The flow in plain English:

Agent platform discovers the store's capabilities via /.well-known/ucp
Sees that the store supports identity linking via OAuth 2.0
Discovers the OAuth server metadata endpoint (RFC 8414)
Initiates an authorization request — the customer sees a consent screen
Customer approves once — agent platform receives a bearer token
Every subsequent API call includes that token
The store resolves the token to a WC customer account and pre-populates all buyer data automatically

After consent, every checkout session created with that bearer token automatically has the customer's name, email, billing address, shipping address, and available store credit surfaced as a payment instrument — without the customer doing anything.

The customer approves once. After that, the agent can complete purchases autonomously until the token expires or the customer revokes access.

What I Built: UCPReady

UCPReady is a WooCommerce plugin that implements the full UCP spec including identity linking. The key components:

A complete OAuth 2.0 authorization server inside WordPress — dynamic client registration, Authorization Code + PKCE S256, refresh token rotation, token revocation with cascade revocation on account events, and RFC 8414 server metadata. All rendered server-side, no external dependencies.

Identity resolution — bearer token resolves to a WC customer automatically. Checkout sessions created with a valid token have buyer data pre-populated without any additional calls.

Connected Agents tab in My Account — customers see every agent platform that has access, when it was granted, when it expires, and can revoke any of them with one click.

Automatic token revocation — tokens are cascade-revoked automatically when a customer changes their password, updates their account, or deletes their account. No stale access.

The Result

Here's what actually happened on houseofparfum.nl — a live WooCommerce store with 40,000+ SKUs:

Agent platform connected to the store via MCP
Customer linked identity via the OAuth consent screen (one click, one time)
Agent searched the catalog, found the product, created a checkout session
Buyer details pre-populated automatically from the linked account
Shipping method selected, wallet balance surfaced as payment option
Agent completed the purchase — wallet debited server-side
WooCommerce order created, status: Processing, customer: linked account, attribution: agent platform

No browser. No redirect. No human interaction after the initial consent.

What the Store Owner Sees

Orders placed by AI agents appear in WooCommerce exactly like any other order — but with full attribution:

Status: Processing (paid)
Customer: the linked WC account, not Guest
Order attribution: the agent platform hostname that placed the order
UCPReady Analytics: revenue breakdown by AI platform, order count, average order value

Every agent that has ever been granted access is visible and revocable by the customer. No black boxes.

The Wallet Payment

When a customer has store credit and their identity is linked, the wallet balance is surfaced automatically in the checkout response as an available payment instrument. The agent sees it, selects it, and calls complete_checkout. The payment is processed entirely server-side — no Stripe, no card network, no browser redirect.

This works with any WooCommerce wallet plugin that exposes a programmatic debit API. We tested with TeraWallet.

UCP Playground Validation

Ben Fisher's UCP Playground — the primary tool for testing UCP compliance — now has a "Link Identity" button. When pointed at houseofparfum.nl, it discovers the identity linking capability, triggers the OAuth flow, and renders our consent screen correctly.

Schema Quality score: A (98).

The Playground currently stops at checkout creation — full autonomous completion from the Playground requires Ben to add payment instrument selection to the runtime. That's the next step on his end.

What's Missing (Honest Assessment)

Playground autonomous completion — identity linking and checkout creation work end to end via the Playground. Full completion requires payment instrument selection in the Playground runtime, which isn't there yet.

Attribute-based disambiguation — the flow assumes the agent can identify exactly which product to buy. "The blue one, size M" requires variant resolution before checkout. That's an agent-side problem, not a protocol problem.

AP2 for non-wallet payments — for stores without store credit, completing payment without a browser redirect requires an AP2-compatible payment processor. Store credit / wallet is the cleanest path today. Card payments without browser redirect are the next frontier.

Try It

The live UCP discovery endpoint: https://houseofparfum.nl/.well-known/ucp

The OAuth server metadata: https://houseofparfum.nl/.well-known/oauth-authorization-server

If you're building an agent platform and want to test identity linking against a live WooCommerce endpoint, both are open. Point your runtime at the discovery endpoint and the rest is spec-compliant.

UCPReady runs on any WooCommerce store. Available at zologic.nl.

The Bigger Picture

Identity linking is the piece that turns AI agents from "helpful product finders" into actual autonomous purchasing agents. Without it, every agentic commerce flow ends with "here's the checkout URL, go finish it yourself."

With it, the agent can complete the entire transaction — discovery, identity, payment, order creation — without the customer ever opening a browser after the first consent.

The UCP spec is still in draft on this capability (2026-03-14). But the implementation is live and working today on a real store.

UCPReady is built by Almin Zolotic at Zologic. The live test store is houseofparfum.nl.

Want this on your store?

UCPReady is available at zologic.nl/ucpready — €149/year, instant download, works on any WooCommerce store.

Tags: #woocommerce #ai #webdev #opensource

Y Combinator validates ideas. Nobody validates adoption. Here's what I built instead.

Almin Zolotic — Sun, 15 Mar 2026 15:30:50 +0000

By Almin Zolotic — Founder of Zologic, City Shower, and Market Physics Engine

The validation that didn't save me

In 2020 I was living in a vacant school in Rotterdam after a divorce wiped out everything I had built. During that period I noticed something obvious that nobody was solving: tens of thousands of homeless people in the Netherlands couldn't access a shower. Not because showers didn't exist — because access was fragmented, gatekept, and invisible.

I built City Shower. A network of accessible hygiene facilities for people living on the streets.

I validated it the way every startup course tells you to. I talked to people. Social workers, shelter managers, municipal health officers, community leaders, entrepreneurs. Every single one said it was needed. Many said it was overdue.

I had positive signals everywhere.

And then I ran into a wall that no interview had prepared me for.

Regulatory friction. Switching costs embedded in institutional processes. Trust infrastructure that didn't exist yet between gyms, municipalities, and social services. The idea was sound. The adoption pathway was blocked.

Nobody's survey had told me that. Because surveys don't measure adoption. They measure intent. And Kahneman proved decades ago that intent and behavior are not the same thing.

That gap — between "people say yes" and "people actually adopt" — is where most startups die. And almost nobody is measuring it.

What traditional validation actually measures

The lean startup canon — customer interviews, problem validation, demand testing — is built on a flawed assumption: that what people tell you they will do predicts what they will actually do.

It doesn't.

Daniel Kahneman and Amos Tversky's Prospect Theory (1979) showed that human decision-making is not rational utility calculation. Losses loom approximately twice as large as equivalent gains. The friction of changing behavior is systematically underweighted by the people experiencing it — and almost completely invisible in an interview context, where social pressure to be supportive overwhelms honest friction assessment.

Y Combinator's application asks: "What do you understand about your business that other companies in it just don't see?"

It doesn't ask: "What structural friction stands between your idea and the people who will need to change their behavior to adopt it?"

Lean startup asks: "Have you talked to customers?"

It doesn't ask: "Have you modeled the regulatory environment your regulator is operating in, the switching cost your operator faces, or the trust infrastructure your early adopter needs before they convert?"

These are different questions. The first set measures whether your idea sounds good in a room. The second set measures whether it will actually spread in a market.

There's another problem nobody talks about: the people who will kill your idea don't show up to customer discovery sessions.

Regulators don't attend your user interviews. Risk officers don't fill in your survey. Institutional gatekeepers don't book a 30-minute call on Calendly. They show up after you've scaled — and by then you've already built the wrong thing in the wrong way.

So I built a simulator

After City Shower, after founding Zologic, after shipping UCPReady (an AI agent commerce plugin for WooCommerce, currently in WooCommerce Marketplace business review) — I kept running into the same pattern. Good ideas. Real problems. Structural friction that surveys didn't surface until after significant time and money had been spent.

So I built Market Physics Engine.

Not another survey tool. Not another AI that asks you questions and gives you generic feedback. A behavioral simulation engine that treats adoption as a physics problem — where perceived value competes against structural friction across a heterogeneous population of decision-makers.

Here's the conceptual architecture:

Step 1 — Generate the full stakeholder ecosystem

You submit your pitch. The engine generates 12 stakeholder personas covering every role that influences adoption: consumer, buyer, operator, supplier, regulator, investor, ecosystem partner, technical evaluator, early adopter, skeptic analyst, risk officer, and public stakeholder.

Each persona is scored across two competing forces:

Value drivers — functional utility, emotional motivation, social signaling, market timing, ecosystem readiness

Friction drivers — cognitive cost (switching effort, learning curve), perceived risk (financial, regulatory, technical), and regulatory burden

The scoring is role-specific and grounded in documented behavioral patterns for each archetype. A regulator looks nothing like an early adopter. A risk officer's friction profile is structurally different from a consumer's. The engine enforces this — it doesn't let every persona converge on the same generic scores.

Step 2 — Simulate a heterogeneous population

Each persona seeds a population of synthetic agents with behavioral variation drawn from the persona's scores. The population is designed to be heterogeneous — capturing the full distribution of real market behavior, including the resistant tail that single-point estimates miss entirely.

This is grounded in Monte Carlo simulation methodology. No single persona represents a market. The variance matters as much as the mean.

Step 3 — Run network diffusion across 12 market periods

Agents don't respond to a global market signal. They respond to their immediate network — consistent with Watts-Strogatz small-world topology research and how platform adoption actually propagates in the real world.

Adoption cascades locally before reaching the broader population. This produces tipping points rather than smooth growth curves — which is exactly what you see in every major platform market that has ever succeeded or failed.

The simulation runs across 12 sequential periods, separating innovator adoption from imitator adoption — consistent with Bass Diffusion Model dynamics documented across decades of empirical platform research.

Friction variables are weighted asymmetrically throughout — consistent with Prospect Theory. A blocker's resistance costs more adoption probability than an equivalent level of enthusiasm generates. This is not an assumption. It is empirically documented.

Step 4 — Output you can actually act on

Idea Fitness Index (IFI) — a composite behavioral fitness score
Adoption curve — 12-period S-curve with period-by-period growth rate overlay
Friction profile — Cognitive, Risk, and Regulatory breakdown per persona
Benchmark comparison — your curve overlaid against empirical anchors for Airbnb, Uber, Stripe, and Slack
Stakeholder sentiment — 12 personas classified as supporters, skeptics, or blockers with behavioral reasoning

What this looks like on a real pitch

I ran the Airbnb pitch through the engine:

"A two-sided marketplace where homeowners rent out spare rooms or entire properties to travelers seeking affordable, local accommodation alternatives to hotels."

Output:

IFI: 0.53 — Scalable opportunity
Adoption Probability: 78.5%
Majority adoption at: Period 6
Closest benchmark match: Airbnb
Dominant friction: Risk and Regulatory

The friction profile surfaces exactly what actually happened to Airbnb in their early years — not consumer demand failure (demand was high from day one), but regulatory and trust infrastructure friction that consumed enormous operational energy before the product could scale.

The personas that dragged the score were the regulator and the risk officer — both high on regulatory burden and perceived risk, both structurally resistant to a trust-dependent two-sided marketplace entering an unregulated category.

What traditional validation told founders about Airbnb in 2008:

Travelers want cheaper accommodation ✓
Homeowners would consider renting their space ✓
Waitlist filled up quickly ✓

What it missed:

The regulatory cascade that would define Airbnb's next decade. The trust infrastructure they'd have to build from scratch. The institutional friction that doesn't appear in any customer interview because the people carrying that friction don't attend customer interviews.

Market Physics surfaces that friction in 60 seconds, before you spend a cent building toward it.

The same friction model applied to my own work

I ran the UCPReady pitch through Market Physics before submitting to the WooCommerce Marketplace.

UCPReady makes WooCommerce stores transactable by AI agents via the Universal Commerce Protocol — REST, MCP, and embedded checkout in one plugin. It's the infrastructure layer that lets AI agents shop your store the way a human would, without scraping or hallucinating product data.

The simulation told me exactly where the friction would concentrate: the institutional regulator persona (WooCommerce's own review process), the technical evaluator (merchant-developers who need spec compliance proof before adoption), and the skeptic analyst (merchants who've heard "AI will change everything" too many times).

It concentrated there. The WooCommerce Marketplace business review has been ongoing since February. The technical evaluator friction resolved through independent third-party testing (UCPReady was cited as the most spec-complete non-Shopify UCP implementation tested across 180 real agent shopping sessions). The skeptic analyst friction is resolving through publishing — this article being part of that.

That's not a coincidence. That's the model working.

The honest comparison

	YC Application	Lean Startup	Market Physics
Measures stated intent	✓	✓	—
Measures behavioral adoption probability	—	—	✓
Surfaces regulatory friction pre-build	—	Rarely	✓
Models network diffusion dynamics	—	—	✓
Captures the resistant tail	—	—	✓
Requires access to real humans	✓	✓	—
Takes weeks	✓	✓	—
Takes 60 seconds	—	—	✓
Grounded in behavioral economics	Partially	Partially	✓
Benchmarks against empirical historical data	—	—	✓

Market Physics doesn't replace customer discovery. Talking to real humans is irreplaceable — you learn things about context, language, and emotion that no simulation captures.

What it replaces is the false confidence that intent data gives you. The "everyone I talked to loved it" that precedes so many failed launches.

Run the simulation first. Then go talk to the persona the simulation identified as your biggest blocker.

That conversation will be completely different from a generic customer interview — because you'll know exactly what friction to probe for before you walk in the room.

Try it

marketphysics.eu — free tier, 3 simulations. No credit card.

Run your own pitch. See where the friction concentrates before you build.

If the IFI comes back low, that's not a failure signal. It's a navigation signal. The simulation tells you which variables are dragging the score and which personas are the blockers. Fix those structural barriers, re-run, and watch the curve change.

That's the loop lean startup was always supposed to create. Market Physics just runs it in behavioral space instead of interview space — and it runs it before you've committed to building anything.

One last thing

I built Market Physics because I needed it. City Shower taught me what late-stage friction discovery costs. Every venture since has been shaped by the question I now run through the engine first:

Not "can I build this." Not "do people want this." But "will people actually change their behavior to adopt this — and what stands in the way?"

That's a different question. It deserves a different tool.

Almin Zolotic is the founder of Zologic (AI commerce infrastructure, Den Haag NL), City Shower (hygiene access for the homeless in the Netherlands), and Market Physics Engine (behavioral adoption simulation). UCPReady — the WooCommerce AI agent commerce plugin — is currently in WooCommerce Marketplace business review.

Launching on Product Hunt tomorrow — would mean a lot if you checked it out 👇

🚀 Launching on Product Hunt tomorrow — upvotes mean the world

Tags: startup entrepreneurship ai productivity

The "Efficiency Tax": Why Your AI Agents Are Failing at Checkout

Almin Zolotic — Thu, 05 Mar 2026 23:06:23 +0000

As we move from building simple RAG chatbots to deploying autonomous commerce agents, we are hitting a new kind of bottleneck.

It’s not a model reasoning problem.

It’s not a UI problem.

It’s a Protocol Stability problem.

In our latest research at Zologic, we benchmarked how AI agents (using 4–8 concurrent models) interact with a large-scale WooCommerce store (~42,000 SKUs). The results revealed a massive "Efficiency Tax" that most developers aren't accounting for.

The Problem: Protocol Exposure

When you give an LLM direct access to your commerce APIs ("Protocol Exposure"), you aren't just dealing with occasional hallucinations. You're dealing with high-frequency execution friction.

The Search Loop

Agents in exposed environments averaged 3–5 search retries per session just to find the correct SKU.

Parameter Mismatches

Models frequently generate arguments that don't perfectly align with strict database schemas, leading to immediate execution failure.

The "Handshake" Failure

The transition from a valid cart to a successful checkout is often non-deterministic, causing agents to lose session context and abandon the flow.

The Data: Measuring the Friction

We compared a baseline "exposed" environment against one utilizing an Execution Stabilization Layer (UCPReady + Pro).

Infrastructure impact at 100,000 monthly sessions:

Redundant Work

Exposed environments generated ~160,000 unnecessary tool calls per day.

Latency & Load

Every session averaged ~2 extra searches, significantly increasing server load and token costs.

The Bottom Line

This technical friction resulted in a 20% decay in conversion rates (from a 2% baseline down to 1.6%).

From "Base" to "Pro" Execution

To solve this, we moved away from raw protocol exposure toward Argument Normalization. By implementing a stabilization layer, we forced deterministic outcomes for the AI.

Argument Normalization

Ensuring model-generated arguments match protocol requirements before execution.

Deterministic Checkout

Creating a stabilized path that prevents session loss during the final transaction.

Efficiency Gains

Reducing search attempts to 2–3 per session and significantly lowering the Efficiency Tax on tokens.

The Economic Impact

For a store with an €80 Average Order Value (AOV), fixing this technical friction isn't just a dev task — it's a massive revenue lever.

Monthly GMV Delta: €32,000

Annual Revenue Impact: €384,000

Conclusion for Developers

If you are building for the agentic web, stop optimizing your prompts and start optimizing your execution environment.

As session volumes scale, the economic impact of protocol stability scales with it.

Full Technical Briefing:

https://zologic.nl/research/

Tags

webdev #ecommerce #ai #woocommerce #llm #infrastructure