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.