When an AI assistant brokers the purchase, it also inherits the question the shopper asks next: where is it? Two open standards now describe how a merchant reports order state back to an agent. Google's Universal Commerce Protocol defines fields for a tracking number, a tracking URL and a carrier. OpenAI and Stripe's Agentic Commerce Protocol does not. That difference decides who owns the post-purchase conversation.
Why post-purchase status is the real battleground
Checkout is a moment. Delivery is a period, and it is the period in which most customer contact happens. In a conventional storefront the merchant controls that period: the confirmation email, the tracking page, the notification. When an agent brokers the transaction, the shopper's natural next move is to ask the agent, not to return to the store.
That creates a simple fork in the road for any merchant integrating with an agentic surface:
- If the protocol carries fulfilment data, the agent can answer the question directly. The merchant loses the visit but gains a delivery experience that works where the customer already is.
- If the protocol does not carry fulfilment data, the agent can only say the order shipped and hand the shopper a link. The merchant keeps the visit, but the agent's answer is thin and the shopper does the extra work.
Neither outcome is automatically better. What matters is knowing which one your integration produces, because the two protocols make that choice for you.
What UCP's Order Capability actually specifies
The Universal Commerce Protocol is an open standard released under Apache 2.0, announced by Google at NRF on January 11, 2026 and co-developed with Shopify, Etsy, Wayfair, Target and Walmart. More than twenty partners have endorsed it, including Adyen, American Express, Best Buy, Flipkart, Macy's, Mastercard, Stripe, Home Depot, Visa and Zalando. Google's reference implementation powers direct buying in AI Mode in Search and in the Gemini app, with merchants integrating through Merchant Center. The spec version at launch was 2026-01-11; the current published version is 2026-04-08.
The relevant piece is the Order Capability, identified as dev.ucp.shopping.order. Its data model has three parts:
line_items: what was bought.fulfillment: split intoexpectations, the buyer-facing delivery promises, andevents, an append-only log of what actually happened.adjustments: refunds, returns and disputes.
The split between expectations and events is the design decision that matters. A promise and a fact are modelled separately, which means an agent can compare the two and tell a shopper that a parcel is running behind the estimate without the merchant having to compute that comparison itself.
The Fulfillment Event fields
From the published schema at https://ucp.dev/2026-04-08/schemas/shopping/types/fulfillment_event.json:
| Field | Status | Description as published |
|---|---|---|
id |
Required | Event identifier |
occurred at |
Required | Timestamp, RFC 3339 |
type |
Required | Event type, open string |
line items |
Required | Array of {id, quantity} |
tracking number |
Conditional | "Carrier tracking number (required if type != processing)" |
tracking url |
Conditional | "URL to track this shipment (required if type != processing)" |
carrier |
Optional | "Carrier name (e.g., 'FedEx', 'USPS')" |
description |
Optional | Human-readable status |
The description field carries the sort of string a shopper actually reads, such as "Delivered to front door" or "Out for delivery".
type is an open string, so a merchant is not boxed in, but the schema description enumerates the common values: processing, shipped, in transit, delivered, failed attempt, canceled, undeliverable, returned to sender. That list is close to what most carrier-agnostic status models already use, which makes mapping from an existing tracking pipeline straightforward rather than novel.
Worth knowing. Because line items is required on each event, UCP models fulfilment per item rather than per order. Split shipments, partial deliveries and a returned single unit from a multi-item order all have a natural representation. Anyone who has tried to express a split shipment in a one-status-per-order system will recognise why that matters.
The conditional requirement is a promise, not a lock
Here is the nuance a developer needs and a summary will usually miss. tracking number and tracking url are described in their own field descriptions as required if type is not processing. They are not listed in the JSON Schema required array.
The practical consequence: a payload that reports type: "shipped" with no tracking number will validate. The obligation is stated in prose and enforced by nothing. carrier is plainly optional and carries no conditional language at all.
So UCP does not guarantee that agents receive tracking data. It guarantees there is a correct, unambiguous place to put it, and it states that you are supposed to. Whether the data arrives depends entirely on the merchant's integration discipline. That is a meaningful distinction when you are assessing what an agentic surface will actually be able to tell your customers.
What ACP's order webhook specifies, and what it omits
The Agentic Commerce Protocol is maintained by OpenAI and Stripe, also Apache 2.0, and launched on September 29, 2025 alongside Instant Checkout in ChatGPT.
Its order webhook is POST /agentic_checkout/webhooks/order events, HMAC-signed via a Merchant-Signature header. The event type is either order create or order update, and data must contain the full Order object rather than incremental deltas.
The documented EventDataOrder fields are type, id, checkout session id, permalink url, status, refunds, line items (which carry quantity.ordered and quantity.shipped) and totals. status is an enum: created, manual review, confirmed, canceled, shipped, fulfilled.
Read that list again with a post-purchase question in mind. There is no tracking number, no tracking url and no carrier anywhere in the published webhook reference. ACP signals shipment as a state transition and then hands the shopper off to permalink url.
That is a coherent design, not an oversight in the ordinary sense. ACP treats the merchant's own order page as the destination for detail. But it means an ACP-integrated agent cannot, from protocol data alone, tell a shopper which carrier has the parcel or where it currently is. The best it can do is report that the status changed to shipped and offer the link.
Unconfirmed. We have seen a reference suggesting ACP may carry an optional fulfillments array holding tracking data. The published webhook reference does not document such a field, and we have not been able to verify it. Treat it as unconfirmed until it appears in the reference. Do not plan an integration around it.
Where AP2 sits, and why it does not help here
The Agent Payments Protocol is a separate, Google-led effort announced in September 2025 with more than sixty partners, including Mastercard, PayPal, Coinbase, American Express and Salesforce. AP2 handles authorisation: cryptographically signed Intent, Cart and Payment Mandates that create a non-repudiable audit trail of what the user authorised an agent to do.
UCP is explicitly compatible with AP2. But AP2 defines nothing about post-purchase or delivery status. It is worth naming here only because it is frequently discussed in the same breath as UCP and ACP, and it is easy to assume that three protocols means three chances of the tracking problem being solved. It does not. AP2 stops at the payment.
Side by side on post-purchase
| Description | UCP (Order Capability) | ACP (order webhook) | AP2 |
|---|---|---|---|
| Scope | Order lifecycle including fulfilment | Order lifecycle | Payment authorisation |
| Tracking number field | tracking number, conditional |
Not in published reference | None |
| Tracking URL field | tracking url, conditional |
Not in published reference | None |
| Carrier field | carrier, optional |
Not in published reference | None |
| Granularity | Per line item, per event | Order-level status, plus quantity.shipped per line item |
Not applicable |
| Delivery event log | fulfillment.events, append-only |
None | None |
| Promise vs actual | expectations vs events |
Not modelled | Not applicable |
| Handoff to merchant | permalink url, platforms SHOULD delegate |
permalink url |
Not applicable |
| Signing | Detached JWT in Request-Signature |
HMAC in Merchant-Signature |
Signed mandates |
The obligations UCP puts on the merchant
UCP is more demanding of merchants than a status-only model, and the requirements are worth reading before scoping the work. For the Order Capability, businesses:
- MUST send an "order created" event with a fully populated order entity.
- MUST send the COMPLETE order entity on updates, not incremental deltas.
- MUST retry failed webhook deliveries.
- MUST sign all webhook payloads with keys from
signing keyspublished at/.well-known/ucp, as a detached JWT per RFC 7797, in theRequest-Signatureheader. - MUST include a business identifier in the webhook path or in headers.
Platforms, for their part, MUST return 2xx quickly and process asynchronously.
Transport is a POST from the business to a platform-supplied webhook url declared in the order capability config. There is also a pull path, GET /orders/{id}, which returns a current-state snapshot. Notably, the REST binding says platforms SHOULD delegate to permalink url because "the business site is the source of truth for order details and post-purchase operations."
That last line is easy to skip past and it sets the ceiling on the whole exercise. Even under UCP, the merchant remains authoritative. The protocol is a syndication channel for a subset of what you know, not a replacement for your own order and tracking systems. If your internal tracking data is incomplete or arrives late, UCP will faithfully syndicate incomplete, late data.
Send the whole entity. The complete-entity rule is the most common source of integration bugs in systems built around change events. If your internal architecture emits deltas, you need a hydration step that reassembles the full order before it goes out. Plan for it early.
Market state as of August 2026
The protocol picture is clearer than the commercial one.
- OpenAI. Instant Checkout launched on September 29, 2025 with US Etsy sellers, then Shopify. In early March 2026 OpenAI pulled back, citing insufficient flexibility, low conversion and thin merchant uptake, and refocused on product discovery while routing purchases to retailer apps and sites. The ACP spec remains live.
- Google. UCP-powered checkout is live in AI Mode and Gemini. Universal Cart was announced at I/O 2026. Coverage has expanded to Canada and Australia, with the UK planned.
- Microsoft. Copilot Checkout was announced on January 8-9, 2026 and is live in the US on Copilot.com, with launch brands including Urban Outfitters, Anthropologie, Ashley Furniture and Etsy. Shopify merchants were auto-enrolled after an opt-out window.
- Perplexity. "Buy with Pro" runs alongside a merchant programme, powered by PayPal and Venmo, with the merchant remaining merchant of record and a Shopify product-feed integration.
The legal position on third-party buying agents also shifted recently. Amazon sued Perplexity over its Comet agent, and a judge granted a preliminary injunction around March 10, 2026 on Computer Fraud and Abuse Act grounds. In early August 2026 the Ninth Circuit reversed, holding that it is the user, not Perplexity, who accesses Amazon. The injunction was dissolved. The underlying case continues, so this is a direction of travel rather than a settled rule, but it makes agent-mediated shopping harder for retailers to block outright.
The strategic reading: OpenAI's retreat from in-chat checkout does not reduce the importance of agent-readable order data. It arguably increases it, because more agents are routing shoppers back to merchant surfaces and every one of those handoffs is a place where accurate status either exists or does not.
What to do now to make tracking data agent-ready
None of the following requires committing to a specific protocol. All of it is prerequisite work.
1. Audit whether you can emit a tracking number at the moment of shipment
UCP expects tracking number and tracking url on any event that is not processing. Many merchants generate a label well before the record reaches the system that would emit the webhook. Measure the actual lag between label creation and tracking number availability in your order service. If it is measured in hours, that is your first fix.
2. Normalise carrier names and statuses
carrier is a free string with "FedEx" and "USPS" given as examples. type is an open string with an enumerated set of common values. Both invite inconsistency across a multi-carrier estate. Decide now on a canonical carrier name per carrier and a deterministic mapping from your internal statuses to the UCP set, including the awkward ones: failed_attempt, undeliverable, returned_to_sender.
3. Model fulfilment per line item
If your system stores one status per order, split shipments will not map cleanly to fulfillment.events. This is usually the largest piece of work and it pays off independently of agentic commerce, because it is also what an accurate customer-facing tracking page needs.
4. Build the full-entity snapshot
You need a function that, given an order ID, returns the complete current order entity. This serves both the webhook requirement and the GET /orders/{id} pull path. Build it once.
5. Get the security plumbing right
Publish signing_keys at /.well-known/ucp, implement detached JWT signing per RFC 7797 in the Request-Signature header, include a business identifier in the path or headers, and implement retries with backoff. Test the retry path deliberately, because it will be exercised in production whether or not you tested it.
6. Keep permalink_url genuinely good
Under both protocols, permalink url is the fallback and, under ACP, effectively the only route to detail. If that page is slow, requires a login, or shows less than the agent already said, the handoff fails. Aggregating multi-carrier tracking behind a single consistent endpoint is exactly the problem Ship24's tracking API and webhooks exist to solve, and it is worth solving regardless of which protocol you end up supporting.
Conclusion
The headline holds up under inspection. UCP's Order Capability gives an AI agent a defined place to find the carrier, the tracking number and an append-only log of what happened to each line item. ACP's published order webhook gives it a status enum and a link. AP2 gives it nothing on this axis, by design.
The caveat is equally important: UCP's tracking fields are conditionally required in prose and absent from the JSON Schema required array, so the data will only be there if merchants put it there. As of August 2026, with agentic surfaces multiplying and OpenAI redirecting shoppers back to merchant sites, the merchants who benefit will be the ones whose tracking data is complete, normalised, per line item and available the moment a label is created. That work is protocol-independent, and it is the part you can start today.
Sources & methodology
- Universal Commerce Protocol Protocol documentation Primary documentation.
- Universal Commerce Protocol Order capability specification Primary documentation.
- Universal Commerce Protocol Fulfilment event schema Primary documentation.
- Google Developers Blog Under the hood of Universal Commerce Protocol Primary company source.
- Agentic Commerce Protocol Webhook reference Primary documentation.
- Agentic Commerce Protocol Reference repository Primary documentation.
- Agent Payments Protocol (AP2) Protocol documentation Primary documentation.
