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: