The committability ladder

Evidence update · 22 September 2026

The committability ladder: where merchant truth becomes a commitment

Structured deposit terms, protocol contracts, endpoint validation, and merchant-authored rules are different evidence layers. This August 2026 update shows what became machine-readable - and what still does not prove a live local-service commitment.

Update - July-August 2026

A protocol can describe a commitment. A merchant system still has to make it true.

Four developments sharpen the middle of the ladder.

1. Shopify published one bounded deposit primitive. In API version 2026-07, an authorized app can set DraftOrderInput.deposit when creating or updating a draft order. A scoped Customer Account integration can read the deposit, amountDueNow, and amountDueLater. Shopify limits this to Shopify Plus draft orders. It is useful evidence that a merchant system can structure what is due now and later; it is not a universal deposit, reservation, or local-service commitment protocol.

1. Shopify also moved the enforcement pattern away from the buyer-facing interface. For merchant business rules, Shopify directs developers from the deprecated useBuyerJourneyIntercept hook toward server-side cart and checkout validation Functions that apply across checkout surfaces, including express wallets and agentic checkout. Existing extensions still work on current and prior versions; removal is future. The lesson is architectural: customer-visible terms and server-side enforcement belong together. It is not evidence that any particular merchant has implemented the pattern.

1. UCP `v2026-08-25` expanded the vocabulary. The release adds payment terms and schedules, including deposits and installments; policy snapshots; location and fulfillment context; capability versioning; identity and consent changes; actions and vendor-agnostic 3DS2. It also contains breaking schema changes. These fields can describe more of a transaction, but a protocol declaration does not independently verify freshness, inventory, availability, policy accuracy, merchant authority, fulfillment, or production use. It does not create a local-service reservation hold or cancellation guarantee by itself.

1. Google and an external census show why validation must stay separate from declaration. Google's Merchant Center UCP integration is a limited US pilot for participating merchants and US products. It offers self-configuration, sandbox and production-environment testing, endpoint validation, and readiness monitoring; Google approval and technical implementation remain gates. Separately, UCP Checker published a point-in-time census of public storefront declarations. That census is a live counter its publisher re-crawls every 24 hours, so this page no longer restates the August figures as if they were current; the September reading below carries its own timestamp and supersedes them. What the August census showed, and the September reading confirms, is the shape rather than the size: catalogue-side declarations numbering in five figures, payment-side declarations in single digits. These are publisher-reported observations of public manifests, not audited market share, merchant adoption, or transaction proof.

The operator test: author, expose, enforce, validate, retain

Treat committability as five linked checks:

1. Author the terms in the merchant system. Record the amount due now, amount due later, payment schedule, applicable policy, location and fulfillment context, and any real hold or cancellation boundary. Do not infer a hold from a deposit field.
2. Expose the exact terms to the customer and authorized integration. Scope access correctly. A public capability declaration and an authenticated order record are different surfaces.
3. Enforce the surrounding rules server-side. Apply eligibility and checkout policy beyond one buyer interface so wallets, human checkout, and agentic checkout do not receive different rules.
4. Validate declaration and behavior separately. Check the profile, versions, endpoints, and observed responses. A valid /.well-known/ucp file is not a completed checkout.
5. Retain what was accepted. Preserve the terms, consent or acknowledgement, order evidence, and cancellation or refund policy needed to resolve the transaction later. Visa's public rules are one network-specific example of this evidence discipline; they are not a shared Shopify-UCP implementation.

Update - September 2026: the two rungs that have not moved

What a census of declarations can and cannot tell a retailer

A protocol declaration is a merchant stating in public, in a form a machine can read, that an agent may transact with it a particular way. The manifest is the file that carries the statement: for the Universal Commerce Protocol it sits at /.well-known/ucp, at a fixed address on the merchant's own domain, the way robots.txt has always sat at a fixed address every crawler knows to ask for. A retailer publishes one the same way it publishes an opening-hours page - by putting a file where anyone can fetch it.

UCP Checker fetches those files on a schedule and counts what they say. Counting a file is not counting a sale. Its published methodology states that its optional functional probes, which run only when someone triggers a check by hand, are "deliberately read-only and rate-limited — they do not exercise checkout or write any state", and it describes full end-to-end agent shopping simulation as a separate product. So the census is a supply-side inventory of what merchants have declared about themselves. It is not adoption, not market share, and not evidence that a single order was ever placed against any of it.

The reading

[UCP Checker · 2026-09-22 20:58 UTC] 17,765 verified storefronts across 21,900 tracked domains. 99.6% of verified storefronts declare checkout, 90% declare cart management and 60.3% declare order management. Two further declaration categories the same census counts stand apart: Payment Token Exchange, at 8, and Embedded Checkout, at 1.

Read the last two figures against the rest. Thousands of storefronts have declared the parts of the journey that get an agent to the edge of a purchase. Single digits have declared the parts that would let the purchase itself happen inside that journey. That gap is not a rounding artefact, and it is not closing. Since the August census, cart-management declarations have grown by thousands while payment-token declarations are still in single digits; across the September readings taken for this update, the Payment Token Exchange and Embedded Checkout counts did not move at all.

Why the flat rungs are the ones worth printing

Every growing number on the publisher's page is stale the next morning, which is exactly why this section stamps the moment it was read. The two that have not moved are the ones the committability ladder was built to point at.

A restaurant group can already be found by an agent, have its menu read, and have a cart assembled against it. Stage one and stage two are filling up in public, and the census is one public measure of that filling. None of it answers the stage-three question - can this deposit be taken, this table held, this booking cancelled inside this window - and the census now shows that the stage-four rung underneath it, where money would actually move inside the agent's journey, is declared by almost nobody. In this framework, committable is the word for the state where both are true: the merchant has authored a commitment it can keep, and there is a route by which someone can pay against it. On this evidence, declared supply is running well ahead of both.

The honest reading is narrow and it is enough. A declaration is a merchant saying what it will accept. It is not a merchant having accepted anything. The distance between those two sentences is the whole of stage three, and it is still the merchant's own work.

Targeted updates to existing stage-three copy

Bounded commitment object

An explicit, versioned record of what is being committed: the amount due now and later, any genuine hold and its expiry, the cancellation window, the applicable policy, the location and fulfillment context, the guarantee, and its limits. A deposit or payment schedule is one field in that object; it does not prove a hold, availability, or fulfillment.

Acceptance and policy terms

Terms should be customer-visible, available to the authorized integration, and enforced in the merchant's system rather than only in a buyer-facing interface. Keep the exact policy version and what the customer accepted so refunds, cancellations, and disputes can be resolved against merchant-authored evidence.

Updated operator rail

Do now

• Separate declared capability, configured endpoint, observed response, and completed production transaction in your evidence.
• Author deposits, payment schedules, cancellation terms, location and fulfillment context, and any true reservation hold as distinct fields. Never use one as shorthand for another.
• Enforce eligibility and checkout rules server-side, expose exact amounts and terms, and retain the customer's acknowledgement.

Monitor

• Whether UCP v2026-08-25 is implemented by production merchant systems, not merely declared in templates.
• Whether deposits and payment schedules become portable across platforms and safely accessible to authorized agents.
• Whether local-service systems add real availability, reservation-hold, cancellation-execution, and fulfillment-guarantee semantics with production payment evidence.

Do not assume

• Do not assume Shopify Plus draft-order deposits are a universal booking or local-service commitment layer.
• Do not assume Google's limited US pilot is generally available or that endpoint validation proves a production transaction.
• Do not assume a UCP manifest, readiness score, identity declaration, or payment-token declaration proves configured, authorized, end-to-end checkout.

Evidence discipline

Observed

Shopify's 2026-07 APIs expose a writable deposit for Plus draft orders and scoped customer-readable amounts due now and later. Shopify directs merchant checkout-rule enforcement toward server-side validation. UCP v2026-08-25 adds terms, policies, locations, fulfillment context, identity, consent, step-up actions, and versioning with explicit breaking changes. Google documents a limited US Merchant Center pilot with endpoint-validation tools. UCP Checker publishes a point-in-time declaration census, re-crawled every 24 hours, whose catalogue-side counts have risen across successive readings while its Payment Token Exchange and Embedded Checkout counts have stayed in single digits. Its probes are read-only by its own published methodology and do not exercise checkout.

Inferred

Our reading is that machine-readable terms become operationally meaningful only when the merchant authors them, the customer can see them, the rules are enforced server-side, the declared endpoints behave as stated, and the accepted terms are retained. This cross-source pattern is an architectural inference. Shopify, UCP, Google, Visa, and UCP Checker do not claim one shared implementation.

Watching

Whether production merchant systems implement the August UCP contracts; whether platform-local deposit terms become portable; whether authorized agents can use them safely; and whether local-service systems add real availability, hold, cancellation, and guarantee semantics with independently verifiable production-payment evidence; and whether the Payment Token Exchange and Embedded Checkout declaration counts ever leave single digits.

What this update does not claim

1. It does not claim UCP v2026-08-25, Shopify's APIs, or Google's pilot is generally available across merchants, countries, platforms, or service categories.
2. It does not claim a deposit creates a reservation hold, service availability, a cancellation guarantee, or fulfillment.
3. It does not claim a public UCP profile or validated endpoint completed a production payment.
4. It does not claim UCP's breaking changes are backward-compatible without implementation-specific migration and testing.
5. It does not claim Shopify's deprecated buyer-journey interception API has already been removed.
6. It does not claim the UCP Checker census is audited market share, merchant adoption, revenue, order volume, or end-to-end purchase evidence.
7. It does not treat the Payment Token Exchange or Embedded Checkout declaration counts in the stamped reading above as production payment capability, as configured merchant systems, or as evidence that any payment was ever taken.
8. It does not claim Shopify, UCP, Google, Visa, or UCP Checker share one architecture or implement one another's fields.
9. It does not claim Obenan has a partnership, endorsement, certification, pilot, special access, or commercial relationship with any named party.
10. It does not claim this work is an Obenan product implementation or current customer capability.
11. It does not claim ranking, recommendation, platform inclusion, transaction completion, revenue, or merchant outcomes.
12. It does not present the UCP Checker census as market share, adoption, penetration, or a count of completed purchases; the census counts public manifest declarations, and its probes are read-only and do not exercise checkout.
13. It does not claim any figure in the stamped reading is current at the moment you are reading this page. The figures are what the public census showed at the stamped moment and at no other.

Sources for the bounded update

1. UCP release `v2026-08-25`
2. Shopify draft-order deposit changelog
3. Shopify Admin GraphQL `DraftOrderInput`
4. Shopify Customer Account `draftOrder`
5. Shopify server-side validation migration
6. Google Merchant Center UCP pilot
7. UCP Checker August census and methodology and methodology
8. Visa public rules
9. UCP Checker live declaration statistics, read at the stamped moment above.