In this essay
A customer asks an assistant to find two replacement filters for a household appliance. The assistant identifies a compatible product, presents an offer and helps complete a purchase. One filter arrives damaged. The customer wants to return that item while keeping the other.
The useful question is what evidence connects those events. Which offer did the customer accept? Which checkout produced the order? Was one item returned or the whole order cancelled? Has a refund been issued, and what does that say about money reaching the customer?
This is an illustrative purchase, not a claim that any named agent or merchant implements every step. Current protocol documentation provides examples of contracts at particular boundaries. The operating model below keeps those boundaries visible.
Keep a reference chain through the purchase
Begin with the customer's request and the offer shown for acceptance. Preserve the product identity, quantity, total, delivery terms and any permitted substitutions. The assistant's ability to describe a product does not itself establish permission to buy it.
Once checkout begins, retain the merchant's checkout-session reference and the resulting order reference. Link the payment reference through the supported merchant or provider interface. Do not put raw payment credentials into a general conversation log to make the chain easier to trace.
OpenAI's Agentic Commerce Protocol checkout specification describes merchant endpoints for creating, updating, completing, retrieving and cancelling checkout sessions, with the merchant returning authoritative checkout information. Its request contract also distinguishes an idempotency key from a request identifier. Those identifiers serve different purposes; a trace identifier alone should not be assumed to prevent duplicate execution. ACP checkout specification
For this article, the proposed record is a chain of references rather than one giant status field:
| Stage | Record to retain | Question it answers |
|---|---|---|
| Request and accepted offer | Saved intent and accepted terms | What did the customer want and agree to? |
| Checkout | Merchant checkout-session identifier | Which commercial session was completed? |
| Payment | Provider reference and documented state | What happened to the payment operation? |
| Order | Merchant order and line-item identifiers | What did the merchant accept to supply? |
| Fulfillment | Shipment or service-event references | Which items were delivered, and when? |
| Return and adjustment | Return, affected line items and adjustment references | What was accepted for return and how was it resolved? |
The systems need a way to join these records. They need not share a database, identifier format or lifecycle.
Check the commercial offer again before completion
The filter price may change, a delivery option may disappear or a substitute may be proposed. The assistant should compare the current merchant offer with the customer's actual permission. A material difference needs the appropriate customer decision before completion; it should not be silently absorbed because the assistant is already in checkout.
There is a separate compatibility question. UCP's overview describes capability and version negotiation between participants. A supported function on one side is insufficient if the other side cannot use the same contract. For an unsupported step, use an explicit supported continuation, such as handing the customer to the merchant, rather than inventing interoperability between protocols. UCP specification overview
That paragraph is deliberately limited. Protocol support does not establish deployment by a particular merchant, purchase authority or a guarantee that a refund will succeed.
Resolve a timeout against the existing purchase
Suppose checkout completion times out after the merchant has accepted the order. A helpful-sounding “I'll try again” can become a second purchase if the system loses the original identity.
The recovery should look up the original checkout and order through the supported contract. Any retry must follow the operation's documented idempotency rules and use the same valid purchase intent. Keep an unresolved result visible until the merchant or payment provider establishes what happened.
The same care applies after payment confirmation. The merchant may have a payment but a missing order record, or an order whose fulfillment instruction has not been acknowledged. The payment-successful, order-missing guide describes that narrower recovery problem. An assistant's summary should report the established state rather than turning every intermediate success into “your order is complete.”
Follow items through fulfillment and return
In the example, both filters belong to one order, but only one is returned. Preserve the line-item identity and quantity through the return request. If fulfillment was split, retain the relevant shipment as well. This allows the merchant to distinguish an undelivered item, a delivered damaged item and a request to return an item already refunded.
UCP's order specification models line items, fulfillment expectations and events, and adjustments. Its adjustment states include pending, completed and failed. These are order-contract states. A completed commercial adjustment does not, by itself, establish that a customer's bank has credited cash. UCP shopping order specification
The customer may also need to approve the type of resolution. Replacement, store credit and a refund to the original payment method are different outcomes. Do not let a generic “refund” label conceal the actual method or the quantity affected.
Follow the decision points through to a resolved exception
Check item, quantity, total and delivery terms before completing checkout.
Obtain the needed decision or hand off to the merchant. Return to the offer check before purchase.
Join the checkout, payment and merchant order references.
Use the documented lookup and duplicate controls. Return here when the result is established.
Retain shipment or service evidence. Keep undelivered and delivered items distinguishable.
Match the affected item, quantity, return and authorised adjustment.
Name its owner and next evidence. A request is not a completed refund.
Separate replacement, store credit, refund issuance and confirmed bank credit. Close only the stage supported by the evidence.
Proposed cross-system operating model, not a universal protocol state machine. Each participant's supported contract and authority remain controlling.
Give support the evidence behind the assistant's answer
ACP's checkout specification describes merchant-reported issued refunds with a type such as store credit or original payment. It does not define the requested and pending refund states used in this article's general operating example. UCP's adjustment states are a separate contract example; the two should not be merged into an invented universal schema. ACP checkout and order information
For the damaged filter, a support record should identify the accepted return, affected quantity, approved amount and resolution method. If a refund was issued to the original payment method, report that fact and the supported tracking information. Claim customer bank credit only when suitable evidence confirms it. Store credit may never involve a bank credit at all.
The agent roles guide explains who owns the different responsibilities. The merchant launch checklist includes full and partial refund tests. In this purchase, success means the customer and operator can follow one consistent record from accepted offer through the remaining item and the resolved return, without relying on an assistant's unsupported completion statement.
Closing thought and further reading
An agent can find a product and start checkout, but each later step needs its own authority and evidence. Follow one purchase through delivery and a partial return.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.