UCP Cart or Checkout: which capability should you use?

Published 19 August 2026 . Part of the UCP implementation guide.

In UCP, Cart builds a basket before purchase intent exists. Checkout finalizes a transaction. They share several entities, but they represent different levels of commitment and have different payment requirements.

Key takeaways

• Cart provides 4 lightweight operations and needs no payment handler.
• Checkout provides 5 operations and a status lifecycle that ends with an order.
• Conversion through cart_id must be idempotent.

Cart and Checkout serve different moments

The Cart specification reserves Cart for exploration: adding, removing or saving items, requesting localized estimates, and sharing a session through continue_url. The buyer has not confirmed a purchase yet, so totals may remain partial.

Checkout begins once purchase intent exists. It configures payment methods, collects required information, handles errors, and moves the session toward an order. The specification describes the normal sequence clearly: cart session, checkout session, then order.

Criterion	Cart	Checkout
Purpose	pre-purchase exploration	purchase finalization
Payment	none	handlers and instruments required
Price	may be estimated	authoritative transaction price
Status	resource exists or not found	full status lifecycle
Operations	create, get, update, cancel	create, get, update, complete, cancel

How does a cart become a checkout?

When the merchant profile advertises dev.ucp.shopping.cart, Create Checkout can receive a cart_id. The merchant must initialize the checkout from that cart. If the request body repeats fields already present in the cart, the cart content takes precedence.

{
  "cart_id": "cart_abc123",
  "line_items": []
}

The conversion has one critical rule. If an incomplete checkout already exists for the same cart_id, the merchant must return it instead of creating another session. This prevents two competing payments for one basket.

During checkout, the specification recommends keeping both resources linked. Quantity changes can then flow back to the cart. After completion, the merchant may clear the cart according to its expiry policy or business rules.

Which entities do both capabilities share?

Cart reuses Checkout entities for line items, items, buyer, context, signals, attribution, totals, messages, and links. This reduces transformations during conversion. A variant identifier found through Catalog should remain the identifier expected in line_items[].item.id.

Totals do not have the same authority. Cart may omit shipping or tax when the address is unknown. Checkout must produce the amounts needed to make and complete the purchase.

When is Cart worth implementing?

Use Cart when an agent needs to compare products, resume a selection, share a basket, or temporarily hand control to the merchant interface. It also supports early market-aware estimates before asking for a full delivery address.

Checkout alone may be enough for a short path where the item is known and purchase intent is established. UCP does not require merchants to deploy Cart before Checkout. Each capability is advertised and negotiated separately in the UCP manifest.

Implementation checklist

1. Advertise Cart only when all 4 operations work.
2. Keep estimates visibly distinct from checkout prices.
3. Provide a usable continue_url for human recovery.
4. Maintain one incomplete checkout per cart_id.
5. Synchronize relevant changes during the transition.
6. Return not_found for an expired cart instead of silently reusing its ID.

For the broader architecture, see the UCP implementation guide.

Sources

• UCP, Cart Capability
• UCP, Checkout Capability
• UCP, Catalog Capability

---

Back to the UCP implementation guide · All notes · Lire en français