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, completed a purchase, and then handled a return with keep-offer logic. Not on a mock store. Not with human agents behind the curtain. Through UCPReady and KeepCard.io on protocol-native rails.
The transcript in one line
Customer asked for a face cleanser. Model searched the live WooCommerce catalog. Customer bought two products. Checkout ran through UCPReady. Order completed. Customer changed their mind. KeepCard.io verified the order, surfaced the line items, collected the reason, and presented a keep offer. Customer accepted. 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 session 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 ✓
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 important part: no AI in the business logic
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 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."
}
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 but the agent runner could report failure because the round trip took too long. This is a latency problem, not a logic problem.
2. Duplicate finalization needed hardening. When the first accept completed but the runtime retried, the system needs to treat the retry as a successful terminal state rather than an error. Repeated accept should return: already processed, discount code, final state.
3. Mixed shopping and returns in one session exposed session contamination. Running search, purchase, and return inside a single session exposed a session-context boundary problem: return tools were receiving stale search arguments from the earlier shopping flow. 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