DEV Community: Almin Zolotic

From Booking to Beyond: Making Autonomous Travel Servicing Work in Practice

Almin Zolotic — Tue, 09 Jun 2026 22:10:28 +0000

This is part of an ongoing series on building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Built by Almin Zolotic at Zologic.

Last time I wrote about getting an AI agent to autonomously book a flight: search, revalidate, pay, confirm. That was the exciting part.

This week was the less glamorous, but arguably more important, part: what happens after the booking.

Anyone who has built anything in travel knows the booking is only the beginning. The real complexity shows up afterward. The traveler wants to change their flight. The airline changes it for them. The traveler wants to cancel. Dates shift, prices reprice, confirmation windows expire. A real travel platform has to handle all of this without falling apart — and without making the traveler feel like they are operating blind.

That is what we spent the week building.

The three moments that matter after a booking

There are really three post-booking scenarios that define whether a travel platform feels like a product or a prototype.

Voluntary cancellation — the traveler decides to cancel and needs to understand the consequence before committing.

Airline-initiated change — the carrier reschedules or changes the trip, and the platform has to reflect that clearly instead of pretending the booking is still unchanged.

Voluntary change — the traveler wants a different flight, and the system has to guide them through a preview, a confirmation step, and any additional payment required, without ambiguity about what is final and what is not.

All three are multi-step flows. None should happen in a single call. And none should complete without the traveler knowing exactly what they are confirming.

Making irreversible actions feel safe

The principle we kept coming back to was simple: anything irreversible should be preceded by a preview.

The traveler should see what will happen, have a chance to pause, and only then confirm. If the preview expires before they act, the system should catch that and ask them to start again — rather than proceeding with stale information.

That sounds obvious, but implementing it correctly takes real discipline. There are a surprising number of places where a system can skip the preview, auto-confirm, or fail to communicate that a confirmation window has closed. We closed those gaps and added guards at multiple layers, so that if one check is bypassed, the next one still catches it.

The same principle applies to how the system talks about fare conditions. A fare being labelled refundable is a policy statement — not a guarantee that the system can execute a refund right now. We changed the platform to check live booking state before promising that change or cancellation is available. If a booking cannot be serviced through the current interface, the traveler now hears that clearly instead of getting a confusing error after the fact.

Airline-initiated changes were the hardest part

The scenario that took the most care was airline-initiated change.

When an airline changes a trip, the platform receives an event and has to decide what to do. The wrong answer is to handle it silently. Airline changes can involve new flight times, a different aircraft, or sometimes different routing — none of which the traveler has agreed to.

The right answer is to surface the change clearly, show what was originally booked versus what is now being proposed, and ask the traveler to review before anything is accepted or rejected.

We built that escalation path properly, made sure the platform re-fetches fresh booking state before presenting the change, and validated the full flow end to end against real provider behavior.

Settlement honesty matters too

One smaller change that mattered a lot was how cancellation refunds are communicated.

In many travel products, cancellation language implies the traveler will simply get money back to their card. In our model, the commercial reality is different — settlement happens through the platform's billing arrangement with operators.

Those are not the same thing, and conflating them would be misleading.

So the platform now communicates cancellation in terms of service status: the booking is cancelled, and any applicable credit or adjustment is handled through the billing arrangement. It no longer implies a direct traveler refund where that is not actually the right commercial interpretation.

Small wording change. Matters a lot for trust.

How we know it actually works

The thing I am most satisfied with this week is not just the feature list.

It is that we did not stop at "it works locally."

We exercised the full booking lifecycle — booking, changing, cancelling, and handling airline-driven changes — against live provider responses, step by step, until we had confirmed outcomes for every scenario.

That shifted the project from "we think this works" to "we know these core flows work."

There is a meaningful difference between code that looks correct and a system that has been proven to behave correctly under real conditions. This week we crossed that line for the servicing layer.

What is next

The immediate next track is operator tooling: giving the people running travel programs visibility into booking settlement, billing data, and the ability to manage their travelers' bookings with confidence.

The AI agent layer is now in a healthy place.

Now the work is turning that foundation into a full product for the humans operating on top of it.

More soon.

Almin Zolotic is the founder of Zologic and building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Follow the build here on dev.to.

We Just Completed a Live AI-Agent Flight Booking End to End

Almin Zolotic — Mon, 01 Jun 2026 14:25:44 +0000

An AI agent received a natural language instruction, searched for flights, selected an offer, passed authorization checks, and created a confirmed booking — autonomously, without human input after initial setup.

Today that went from architecture spec to production reality.

What actually happened

At 15:33 CET, on UCPPlayground, we ran the following prompt against our live stack:

"Use search_flights for ZAG to AMS tomorrow. Then immediately call complete_checkout on the first direct offer. Do not explain first."

Two tool calls. Eight seconds.

The agent searched. The agent booked. A confirmed booking reference came back. We opened the travel provider dashboard and the order was sitting there — confirmed, with a PNR, an e-ticket, passenger details, everything.

No human touched the booking flow after the initial traveler setup.

Why this is harder than it sounds

Anyone can wrap a travel search API in an MCP tool and call it "AI travel booking." That part is easy.

The hard part is everything that happens between search and confirmed booking:

Offers expire. Flight fares are perishable inventory. An offer returned from search may be gone in 15–30 minutes. No LLM checks this unprompted — it will try to book an expired offer and get a rejection it doesn't know how to recover from.

Prices change silently. A fare can reprice between the moment the agent sees it and the moment it tries to book. Without a revalidation gate, the agent books at the new price without telling anyone.

Bookings can partially confirm. A travel provider can return an async response — booking accepted, outcome pending. An agent that doesn't understand this state will retry, and retrying a booking call risks a double charge.

Identity and authorization matter. Who is this booking for? What are they allowed to spend? What cabin class? Are they direct-only? Without a mandate layer, an agent has no constraints. It will spend whatever inventory is available.

Document requirements gate certain routes. Some routes require passport details to be validated before an order is created. An agent that doesn't check this wastes a booking attempt and confuses the traveler.

These aren't edge cases. Every one of them will happen in production. None of them are solved by the travel API or the LLM — they have to be solved by the layer in between.

That's what we built.

The stack

We built UCP Travel — a travel transaction layer that sits between AI agents and travel inventory.

It implements:

UCP (Universal Commerce Protocol) — the open standard for agentic commerce, including the full checkout lifecycle
MCP (Model Context Protocol) — so any MCP-compatible agent can discover and call our tools
AP2 (Agent Payments Protocol) — cryptographically signed traveler mandates that enforce spending limits, cabin class ceilings, and booking constraints before any transaction The traveler sets up once: connects their AI assistant via OAuth, signs a mandate defining their booking constraints, stores their travel preferences. After that, every booking is autonomous within those constraints.

Our capability declarations are public at ucp.travel/.well-known/ucp and verified by UCPChecker — currently the only verified implementation of travel.ucp.mandate in the world.

UCPPlayground now recognizes ucp.travel as the reference pattern for travel-as-shopping — the travel.ucp.* namespace layered over dev.ucp.shopping is the model the ecosystem is converging on.

The UCPPlayground integration

The booking today happened through UCPPlayground — a live testing environment for the UCP ecosystem built by Ben Fisher. It connects real AI models to real UCP endpoints and runs end-to-end agent sessions.

Gemini 2.5 Flash connected to our MCP endpoint, discovered three tools (search_flights, complete_checkout, get_booking), and completed the booking in 3 turns:

Turn 1: search_flights(origin: ZAG, destination: AMS, departure_date: 2026-06-02, max_connections: 0)
Turn 2: complete_checkout(offer_id: off_..., checkout_id: chk_live_1)
Turn 3: [confirmed — PNR returned]

Outcome: purchase_completed. PNR confirmed in the provider dashboard.

What "traveler setup once" actually means

The autonomous booking only works because we solved the identity problem first.

During onboarding, a traveler:

Creates a profile with travel documents and preferences
Signs an AP2 Intent Mandate — their authorized booking constraints, cryptographically signed
Links their AI assistant via OAuth 2.0 Authorization Code flow From that point, every MCP tool call the agent makes carries a bearer token that resolves server-side to the traveler's identity, mandate, and payment profile. The agent never sees raw credentials, card numbers, or passport data. It just calls tools and gets results.

This is the architecture that makes autonomous booking trustworthy — not just technically possible.

What's live now

The multi-tenant operator platform is running. Operators onboard, configure traveler mandates, and connect AI assistants today. Flight booking is live.

Expanding next:

Stay (hotel) booking alongside flights
Post-booking servicing — changes, cancellations, ancillaries
Complete audit trail UI for operators and compliance teams If you're building an AI travel assistant, a travel management platform, or anything that needs to turn travel intent into confirmed bookings — we'd like to talk.

ucp.travel · contact@zologic.nl

Built by Zologic — zologic.nl

UCP spec: ucp.dev · MCP spec: modelcontextprotocol.io · AP2: ap2-protocol.org

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

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

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