Most AI returns stories still describe chat layered on top of a portal. What we tested was different. We ran a real commerce flow where a model searched a live WooCommerce catalog, helped complete a purchase, and later handled a return with keep-offer logic through KeepCard.io.
The full lifecycle we ran
The customer journey looked like this:
- The buyer asked for a face cleanser.
- The model searched the WooCommerce catalog through
UCPReady. - The buyer purchased two Rilastil cleansers and one Shiseido cleanser.
- Payment used store wallet rails and browser authorization.
- After purchase, the buyer changed their mind about one item.
- KeepCard verified the order, surfaced the line items, captured the reason, and ran keep-offer logic.
- The buyer accepted the offer in chat.
- A real discount code was issued and a confirmation email was delivered.
Why this mattered
The most important part of the test is that there is no AI in the business logic. Order verification, eligibility, keep-offer thresholds, duplicate protection, and code issuance are deterministic. The model is the interface layer. The return system itself is protocol-native.
What KeepCard did in the flow
KeepCard acted as the post-purchase bridge. Once the order context was available, it handled the structured return flow:
- Eligibility: verify the order and return window.
- Item selection: show the purchased line items and let the customer choose exactly what to return.
- Reason capture: collect a structured reason instead of forcing a generic portal flow.
- Decision logic: either route to the normal return flow or present a keep offer.
- Resolution: if the customer accepts, issue the code and close the session without a return shipment.
What actually happened in the live session
The buyer wanted to return only the Shiseido cleanser after the order completed. KeepCard surfaced the product line items, captured the reason, and returned a keep option instead of immediately routing to reverse logistics.
The buyer accepted. A real code was issued. A real confirmation email was delivered. The item did not ship back.
UCPRails changed the architecture story
The early mixed-session tests exposed runtime issues when shopping and returns were forced through one long conversation. The cleaner proof came later with UCPRails identity linking and multi-session continuity:
- Session 1 created and paid for the WooCommerce order.
- Session 2 resolved the return.
- The same linked identity was recognized across both sessions.
- KeepCard could verify the order without forcing the buyer to repeat their email.
That is exactly what protocol-native commerce should feel like. The chat session can be disposable. The identity and commerce continuity persist through the rail.
Why MCP and API access now matter on the product side
This test changed how we describe KeepCard. It is not only a QR-card or portal-adjacent workflow anymore. It is also a post-purchase resolution layer that can be accessed through APIs and MCP-connected agents. The same deterministic return logic can now power customer flows, operator tools, and frontier-model interactions.
The bigger takeaway
If you are building for agentic commerce, the real leverage is not adding AI to business logic. The leverage is exposing the business logic through rails that any capable model can operate. That is what makes the system portable across Claude, GPT, Gemini, or whatever comes next.
For us, this is what KeepCard.io now represents: a protocol-native post-purchase layer for Shopify and WooCommerce, where returns can be verified, reasoned about, and resolved in chat without replacing the merchant's underlying return policy or workflow.