Checkout is a boundary, not the finish line
Product discovery can be anonymous and read-only. Post-purchase support cannot. Once an order exists, the system handles customer identity, addresses, payment state, fulfilment and legal rights. An agent that found a product has not automatically earned permission to inspect or change the resulting order.
Google describes the Universal Commerce Protocol as covering discovery, buying and post-purchase support. Its 2026 updates also added a multi-item Cart option and real-time product details. That direction is important, but support remains dependent on the capabilities each merchant and platform actually expose.
Four words that must not collapse into one
| Term | What it describes | Typical result |
|---|---|---|
| Cancellation | A request to stop an order before completion | Order state changes if still permitted |
| Withdrawal | A consumer exercises a legal right under applicable rules | A legally governed process begins |
| Return | Goods move back to the merchant | Inspection, logistics and status updates |
| Refund | Money is sent back through a payment route | A financial transaction, full or partial |
These events may be related, but they are not synonyms. Our separate guide to the EU withdrawal function for WooCommerce covers the legal-facing distinction. An agent protocol can transport a request; it cannot decide that a customer has a legal entitlement without the merchant’s rules and the applicable law.
The minimum authorization chain
- Identify the customer. Prove control of the account, email link or another merchant-approved channel.
- Bind the order. Confirm that the grant applies to this order and exposes only necessary fields.
- Discover the capability. Status lookup, cancellation request and refund are separate operations.
- Confirm consequence. Irreversible or costly actions may require explicit human confirmation.
- Execute once. An idempotency key prevents retries from creating duplicate actions.
- Record the result. The merchant and customer need an auditable state transition.
State must be factual, not conversational
An agent should report “cancellation requested” when that is the actual state, not “cancelled.” It should distinguish payment authorized, captured, refunded and failed. It should never infer delivery from fulfilment or promise a refund before the payment provider confirms it.
Each transition needs a timestamp, actor, source and stable identifier. Natural-language reassurance is not a substitute for order state.
WooCommerce 10.9 abilities are not shopper authorization
WooCommerce 10.9 includes canonical abilities to query orders, update order status and add order notes. They are schema-defined and permission-checked administrative domain capabilities. Their existence does not make them a public post-purchase API or authorize an external shopping agent to operate for a customer.
A buyer-facing layer would still need scoped customer consent, field-level privacy, merchant policy, replay protection and a safe handoff when automation cannot decide.
What merchants should design before exposing tools
- a canonical order-state model shared by the storefront, support team and agent surface;
- short-lived, revocable grants scoped to one customer and the minimum operation;
- idempotency for every mutation and safe retry semantics;
- PII-minimised responses and redaction by default;
- policy checks for fulfilment stage, product type, geography and payment route;
- a human escalation path with the same audit context;
- clear language separating a request, an approval and a completed outcome.
KaliCart’s current scope
KaliCart Bridge currently focuses on public catalog discovery, live product verification and handoff to the merchant’s own checkout. It can record local attribution around that handoff. It does not expose customer order controls, automated cancellations, returns or refunds to agents.
That is an intentional trust boundary, not an omission disguised as a feature. Post-purchase agent support is a sector development to watch and implement only when identity, authorization and merchant policy can travel together.
The takeaway
Before an agent can manage an order, it must prove whose order it is, what it may do and whether the store actually completed the requested transition.