UCP list_price Explained: Reference Prices in Cart, Checkout and Order, Step by Step

UCP now has one meaning for list_price. On 9 November the spec merged PR #1016. It defines a list price as a reference price, the crossed-out price beside the one you pay, and adds it to the line items of carts, checkouts and orders. Until now it lived only in the catalog, described as a price "before discounts".

The change is on the spec's main branch and planned for the 2026-12-08 release, a plan that can move. We built it into a test store and followed it through Inspect and an agent run, from search to the order, then gave six models the same task. Every request, reply and screenshot below is from those sessions, and each run is linked.

#What is list_price in UCP?

list_price is a reference price a business offers so a buyer can judge the price they pay, usually shown struck through. It is never charged and never part of the totals. The spec now defines it once, in the overview, for catalog, cart, checkout and order:

list_price is a reference price: a benchmark a Business offers so Buyers can judge the value of price, typically shown as a strikethrough.

Three rules come with it:

• It is not a discount. A business "MUST NOT also report it as a discount (for example, in totals or discounts.applied)", and a platform "MUST NOT derive an amount owed from list_price". The totals stay authoritative.
• No saving unless it's higher. A platform "SHOULD NOT present a saving (a strikethrough, percentage, or "save" amount) unless list_price is greater than price". A list price at or below the price is still valid, for example a manufacturer's suggested price on goods sold at a premium.
• The basis is the business's call. UCP doesn't say what the reference is measured against: a typical recent price, the lowest price in the last 30 days, a recommended retail price. That is the business's choice within the law where the buyer is, and a business leaves list_price out where an unlabelled strikethrough can't lawfully be shown.

#What changed

The proposal started as issue #751 in August: return list_price in cart, checkout and order item responses. Greg Smith opened #1016, and PR #1031 from Ilya Grigorik (Shopify) folded the definition into one overview section before the merge. Ilya Grigorik and Amit Handa approved it.

#The setup

The store is Northlight Flowers on flowers-list-price.ucpsandbox.com, one of our UCP Sandbox test stores, with test cards only. Four products carry a list price, chosen to cover each case the spec describes:

• Sunflower Bundle: $20, list price $25 (a sale).
• Peonies: 15% off in every size.
• White Orchid: $45, list price $52 (a higher recommended price).
• Ceramic Pot: $15, list price $14 (below the price: valid, and no saving).

The store sends item.list_price on its 2026-08-25 responses ahead of the release, so agents can be tested now, and leaves it out of 2026-04-08 responses. A store on the 2026-08-25 release isn't expected to send it yet.

We used UCP Playground two ways: Inspect, where each button sends one call and the trace keeps the reply, and an agent run with Gemini 3.6 Flash over MCP.

#Step 1: the catalog sends price and list price

A search for "sunflower" returns the variant with both prices, each as an amount and currency. Inspect shows the list price struck through beside the price.

"price": { "amount": 2000, "currency": "USD" },
"list_price": { "amount": 2500, "currency": "USD" }

#Step 2: a list price below the price is not a saving

The Ceramic Pot's list price is $14 and its price is $15. The store sends it; the spec allows that. Inspect shows no strikethrough, because a lower list price isn't a saving.

#Step 3: the cart line carries item.list_price

This is the new part. After adding the sunflowers, the cart's line item has list_price next to price, as a plain amount in minor units. The line's totals are the price alone: 2000.

"item": {
  "id": "bouquet_sunflowers",
  "title": "Sunflower Bundle",
  "price": 2000,
  "list_price": 2500
},
"totals": [
  { "type": "subtotal", "amount": 2000 },
  { "type": "total", "amount": 2000 }
]

#Step 4: the checkout has no discount line

At checkout the sunflowers still show $25 struck through. The totals are subtotal $35, shipping $5 and total $40. There's no discount entry for the $5 gap, because a list price is a comparison, not a deduction.

#Step 5: an agent reads it

Then we gave the same store to an agent. The task: buy the Sunflower Bundle and a Ceramic Pot, and say first whether either one is a saving.

The agent got both right. It called the sunflowers a saving of $5 and the pot "No savings". Its reasoning shows it noticed the pot: "It appears the listed price is lower than the current selling price, which is an interesting anomaly." It then paid $40 with the test card, the checkout's own total.

Play the whole run below, or open it with the full trace.

One run with one model is not a measure of how agents handle list prices, so Step 7 repeats it across six models.

#Step 6: the order keeps the checkout's list price

Looking up the order afterwards, the sunflowers' line still carries list_price: 2500. The spec says an order's list price is "the value captured at Checkout, not recomputed from live Catalog", so a later price change doesn't rewrite what the buyer was shown.

#Step 7: six models, the same task

One run with one model shows the field reaches the model. To see whether the reading holds, we gave six models the same task, three runs each, on 9 November: same store, same Playground version, over MCP. This time the task added a discount code, so a model has to keep the list-price gap and the discount apart:

Buy the Sunflower Bundle and a Ceramic Pot with code 10OFF. Before paying, tell me what each costs, whether either is a saving, and what the code takes off. Then pay with the store's test card, shipped to Alex Test, [email protected], 123 Market St, San Francisco, CA 94105, US, cheapest shipping.

The right answer, checked against the store first: the sunflowers are $5 under their list price, the pot is no saving, 10OFF takes off $3.50 (10% of $35), shipping is $5, and the total is $36.50. Adding the $5 list-price gap to the discount would give a wrong total of $31.50. We wrote five checks down before the first run and scored every run against them:

Every model read the list price correctly in every run. None counted the list-price gap as a discount, none called the pot a saving, and every one quoted the store's total. The one miss isn't about list_price: in one DeepSeek V4 Flash run the agent stopped at a ready checkout and asked "shall I go ahead and complete it with the test card?" instead of paying (the run).

Where the models differed was in how they described the pot's lower list price:

• Claude Opus 5 cast doubt on it in two runs: once to "treat the 'list price' here as unreliable" (run), once to treat any "was/now" framing "with suspicion" (run). The spec treats a list price below the price as valid, for example a recommended price on goods sold at a premium.
• DeepSeek V4 Flash wrote it once as "$15.00 (was $14.00 — no saving)" (run), presenting the list price as a former price. What a list price is measured against is the business's call, and the field doesn't say.
• Gemini 3.1 Pro called the sunflowers' list price their "regular list price" (run).

Each model name in the table links to one of its runs. Three runs per model on one test store is illustrative, not a benchmark. A store whose catalog and checkout disagree, or a list price far above the price, may get different answers.

#What it means for stores

• Send list_price only where you can stand behind the comparison, and leave it out where a strikethrough can't lawfully be shown to that buyer.
• Keep it out of totals and discounts. A sale shown as a list price and a discount code are different things in UCP.
• Keep catalog, cart and checkout consistent. An agent compares what each step says.

#What it means for agent builders

• Show a saving only when list_price is greater than price, in the same currency.
• Never charge, total or quote from list_price. The checkout's totals are the amount owed.
• On orders, treat it as what the buyer saw at checkout, not today's catalog.

#What we'll watch

The 2026-12-08 release is planned to carry this change, alongside other merged work such as return policies as data. Once it's tagged, we'll watch whether stores send list_price on line items, and whether it agrees with the catalog for the same item. You can follow what's merged, and what's planned for which release, on our Changes to UCP tracker, synced from the spec repo every day.

#FAQ

#What is list_price in UCP?

A reference price a business shows beside the price you pay, usually struck through, so you can judge the price. It is never charged and never part of the totals.

#Is list_price the price before discounts?

Not any more. Until #1016 the catalog described it as "List price before discounts". The spec now calls it a reference price, and the gap between list_price and price is not a discount.

#Which UCP release has item.list_price?

None yet. It's on the spec's main branch and planned for the 2026-12-08 release. The 2026-08-25 and 2026-04-08 releases have list_price in the catalog only.

#Do AI agents read list_price correctly?

In our test, yes. Six models, three runs each, all named the real saving, didn't call a lower list price a saving, and quoted the store's total rather than working one out from the list price. It's a small test on one store, not a benchmark.

#Can list_price be lower than price?

Yes. It's valid, for example a manufacturer's suggested price on goods sold at a premium. A platform shouldn't show a saving in that case.

#Should a checkout show the list price gap as a discount?

No. A business must not report it as a discount in totals or discounts.applied, and a platform must not work out an amount owed from it.

#Does an order keep the list price?

A business may show the list price from the checkout on the order's lines. It's a snapshot from checkout, not re-read from the catalog.

#Where do I test an agent against list prices?

Our test store at flowers-list-price.ucpsandbox.com has a sale, a higher recommended price and a lower one. You can run any agent against it in UCP Playground.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• List price. UCP specification, draft (main branch).
• Item schema. UCP, draft (main branch).
• PR #1016: add optional response-only list_price to item schema. Merged 9 November 2026.
• PR #1031: one list_price definition as a reference price. Merged into #1016, 6 November 2026.
• Issue #751: return list_price in cart, checkout and order item responses. Proposal, August 2026.
• Milestone 2026-12-08. UCP spec repo, a plan that can move.
• The recorded run in Steps 5 and 6. UCP Playground, Gemini 3.6 Flash, 9 November 2026.
• Six-model comparison runs. UCP Playground, 18 runs, 9 November 2026 (one per model linked in the Step 7 table).

Related coverage: How UCP's Ask works, step by step · UCP for B2B: an agent buys on net 30 terms · How UCP works: a real agent buys flowers · Product video and 3D in UCP, step by step