UCP can now sell a product on a plan. On 10 November the spec merged PR #890, the Purchase Options extension: a store lists the ways a product can be bought (once, or as a subscription), the agent picks one, and the order keeps what the buyer agreed to. It comes with a new policy type for subscriptions and a disclosure the agent must show before the buyer pays.
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 an agent run, from search to the order. Every request, reply and screenshot below is from that session, and the run is linked.
What are purchase options in UCP?
A purchase option is one way to buy a product: an id, a title, a price for this purchase, and, for a subscription, the schedules of the orders that follow. The extension is dev.ucp.shopping.purchase_options. In the spec's words:
A product can be bought once or as a subscription. The Purchase Options extension lets a Business advertise those ways on a variant, lets a Platform select one by opaque identifier, and preserves the selected option on the resulting Order.
It uses the same shape UCP already uses for delivery options and payment terms: the store lists options[], the agent sends back the id it chose. Daniel Wyckoff (Shopify) wrote it, combining an earlier proposal (#901) after a council deep dive in October.
What the extension adds
| Where | Field | Who writes it |
|---|---|---|
| Catalog variant, cart and checkout line | purchase_options[] |
The store (response only) |
| Cart and checkout line | selected_purchase_option_id |
The agent selects; the store echoes it |
| Order line | purchase_option |
The store: the option as it stood at checkout |
policies[] |
dev.ucp.shopping.policy.subscription |
The store, for each line that recurs |
messages[] |
a disclosure warning coded as that policy |
The store, beside each recurring line |
The rules that protect the buyer
- Nobody is signed up by default. The first option is the default, and where a one-time option is listed, the default must be one without
schedules. In the spec's words, "a buyer is never enrolled in recurring orders because a Platform did not choose." - The disclosure must be shown. Every recurring line carries a warning with
presentation: "disclosure"that says what today costs, what each later order costs and whether tax and delivery are added, how often and from when, until when, and how to cancel. An agent that declares the extension must show it near the line before completing (unless the buyer authorised those terms in advance, for example through a signed AP2 mandate), or send the buyer to the store's own checkout. - A choice is never swapped silently. If an option disappears, the store says so with
purchase_option_changed, and never moves a buyer from one subscription to another they didn't choose. - One card. A checkout with a subscription is paid with one instrument, which the store keeps for the orders that follow.
- The order is the record. The order line keeps the option, its schedule, the policy and the disclosure exactly as agreed; a dispute is settled against them.
- Agents that haven't adopted it buy once. A store must not hand an agent that didn't declare the extension a product it can't buy the ordinary way.
The setup
The store is Northlight Flowers on flowers-subscriptions.ucpsandbox.com, one of our UCP Sandbox test stores, with test cards only. Four products cover the cases the spec walks through:
- Sunflower Bundle: $25 once, or every 2 weeks for $22.50 (subscribe and save).
- Peonies: once, or monthly for 15% less, in each size.
- Letterbox Flowers: once; monthly with the first box half price (an introductory price); or a 3-month gift that ends on its own.
- Office Weekly Flowers: sold only as a weekly subscription.
The store answers this way on its 2026-08-25 responses, ahead of the release, and only for an agent whose profile declares the extension. UCP Playground declares it, and its agent was told to buy a plan only when the buyer asks for one and to show the disclosure before paying. The run used Gemini 3.6 Flash over MCP.
Step 1: the store lists the ways to buy
On the store's own product page, Letterbox Flowers shows three ways to buy it. The one-time option comes first and is selected.

An agent sees the same in the catalog, on each variant. The introductory price is the option's price ($13 today); its schedule says what each later order costs ($26). Before a checkout, the schedule has no dates, because the store can't know them yet:
{
"id": "po_monthly_intro",
"title": "Monthly, first box half price",
"price": { "amount": 1300, "currency": "USD" },
"schedules": [{
"description": { "plain": "$26.00 plus delivery and any tax every month, starting a month after your first order, until you cancel." },
"totals": [
{ "type": "subtotal", "amount": 2600 },
{ "type": "total", "amount": 2600 }
],
"interval": "P1M"
}]
}
The catalog reply also carries a subscription policy for the product, so the terms can be read before anything is in a cart.
Step 2: an agent without the extension buys once
Ask the same store as an agent that hasn't declared purchase options (we sent the request as a 2026-04-08 agent, which takes the same path) and the plans disappear. Sunflowers come back at $25 with no options, and the subscription-only item is left out, with a message the agent can act on:
{
"type": "error",
"code": "item_unavailable",
"severity": "recoverable",
"content": "Office Weekly Flowers is sold only as a subscription. Buying it needs the Purchase Options extension (dev.ucp.shopping.purchase_options) in your platform profile."
}
That's the extension's rule for platforms that haven't negotiated it: they can still buy what can be bought once, and never get something they can't buy.
Step 3: the agent picks the plan the buyer asked for
The task: sunflowers for an office, delivered every two weeks if the store offers that, with delivery details and the test card. The search card shows both ways to buy.

The agent chose the plan the buyer described and sent its id on the line:
"line_items": [{
"item": { "id": "bouquet_sunflowers" },
"quantity": 1,
"selected_purchase_option_id": "po_every_2_weeks"
}]
Step 4: the checkout binds the schedule
Once a plan is selected, its price is the line's price ($22.50), and its schedule binds, now with a start date. The checkout adds the subscription policy and the disclosure, both pointing at the line. In the run, the checkout card shows the disclosure beside the line it's about.

"policies": [{
"type": "dev.ucp.shopping.policy.subscription",
"description": { "plain": "Renews automatically until you cancel. Cancel any time from your order page, linked in your order confirmation; no notice period and no minimum commitment." },
"applies_to": ["$.line_items[0]"]
}],
"messages": [{
"type": "warning",
"code": "dev.ucp.shopping.policy.subscription",
"path": "$.line_items[0]",
"presentation": "disclosure",
"content": "$22.50 today for this item, charged when you place the order. Then $22.50 plus delivery and any tax every 2 weeks from November 24, 2026, until you cancel. Cancel any time from your order page, linked in your order confirmation."
}]
The same works by hand in Playground's Inspect. Changing the quantity keeps the plan, and the disclosure follows the new total.

Step 5: the agent shows the disclosure and waits
The checkout was ready to pay, and the buyer had given the card. The agent still didn't complete. It summarised the order, quoted the store's disclosure word for word, and asked for a yes.

Play the whole run below, or open it with the full trace.
One run with one model doesn't measure how agents handle subscriptions. It shows the pieces arriving where the spec puts them, and one agent using them as intended.
Step 6: the order keeps the plan
After the buyer said yes, the agent paid $27.50, the checkout's own total, and the store placed order NF-BLWHAW. The order line keeps the option exactly as it was agreed, schedule and start date included, and the order carries the policy and the disclosure again, re-targeted to the order line.

"purchase_option": {
"id": "po_every_2_weeks",
"title": "Every 2 weeks, save 10%",
"price": { "amount": 2250, "currency": "USD" },
"schedules": [{
"description": { "plain": "$22.50 plus delivery and any tax every 2 weeks from November 24, 2026, until you cancel." },
"totals": [
{ "type": "subtotal", "amount": 2250 },
{ "type": "total", "amount": 2250 }
],
"interval": "P2W",
"starts_at": "2026-11-24T00:00:00Z"
}]
}
This snapshot doesn't change if the store later renames or withdraws the option. It records what was agreed, not what happens next.
What isn't in it yet
- Managing a subscription. Pausing, skipping and cancelling are a separate capability. PR #1048 sketched one; it was built on #890's branch and closed when #890 merged.
- The recurring orders themselves. When each order is placed, and how the card is charged, stay with the store and its payment handler.
- Split payments. PR #987 covers splitting a payment across a schedule; it was also stacked on #890. Until something lands, a subscription checkout takes one instrument.
- Delivery schedules. How often an order is billed doesn't say when it's delivered; that stays in the schedule's description for now.
What it means for stores
- List the one-time option first wherever you sell one. Your default must never be a subscription.
- Make each schedule's
descriptioncomplete on its own: what each order costs, that tax and delivery are added, how often, from when, until when. - Send the subscription policy and the disclosure on every cart, checkout and order that carries a recurring line, and send them again when the terms change.
- Show plans only to agents that declare the extension; everyone else buys once.
What it means for agent builders
- Declare
dev.ucp.shopping.purchase_optionsin your profile only if you can show disclosures. Declaring it is how you accept the extension's obligations. - Send
selected_purchase_option_idonly for an option the buyer chose, and re-read prices from each reply: the catalog's prices aren't promised to survive selection. - Show every
disclosurebeside its line, in full, before you complete. If you can't, hand the buyer to the store's checkout. - Treat
purchase_option_changedandpurchase_option_unavailableas questions for the buyer, not something to fix silently.
What we'll watch
Purchase options are planned for the 2026-12-08 release. Once it's tagged, we'll watch for stores declaring the extension, whether their one-time option comes first, and whether every recurring line carries a disclosure. 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
Does UCP support subscriptions?
Yes, on the spec's main branch since 10 November 2026, through the Purchase Options extension (dev.ucp.shopping.purchase_options). It's planned for the 2026-12-08 release; neither 2026-08-25 nor 2026-04-08 has it.
How does an AI agent choose a subscription in UCP?
It sends selected_purchase_option_id on the cart or checkout line, set to the id of one of the line's purchase_options. If it sends nothing, the store picks the default, which is never a subscription when a one-time option exists.
What must an agent show the buyer before a subscription checkout?
The store's disclosure for that line: what the purchase costs today, what each later order costs and whether tax and delivery are added, how often and from when, until when, and how to cancel. The agent shows it beside the line before completing, or sends the buyer to the store's own checkout.
Can an agent cancel or pause a subscription over UCP?
Not yet. Managing a subscription is meant to be a separate capability; a first sketch (#1048) was closed when #890 merged. Today the buyer manages it from the store's order page.
What happens with an agent that doesn't support purchase options?
It buys the one-time option at the one-time price. A product sold only as a subscription is left out of its search, and an exact lookup or add-to-cart returns item_unavailable.
Is an introductory price a discount in UCP?
No. The option's price is what today's order costs, and its schedule says what later orders cost. The spec says choosing a cheaper option isn't a discount, so it isn't itemised as one.
Where can I test an agent against UCP subscriptions?
Our test store at flowers-subscriptions.ucpsandbox.com has subscribe-and-save, an introductory price, a plan that ends on its own, and a subscription-only item. 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
- Purchase Options Extension. UCP specification, draft (main branch).
- Purchase options schema. UCP, draft (main branch).
- PR #890: add purchase options extension and subscription policy. Merged 10 November 2026.
- PR #1048: add subscription management capability. Closed 10 November 2026, with #890's branch.
- PR #987: split payments across deferred schedules. Closed 10 November 2026, with #890's branch.
- Shopping Tech Council meeting, 6 November 2026. UCP meeting minutes.
- Milestone 2026-12-08. UCP spec repo, a plan that can move.
- The recorded run in Steps 3 to 6. UCP Playground, Gemini 3.6 Flash, 10 November 2026.
Related coverage: UCP list_price explained, step by step · 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
