Agentic-Commerce Readiness File: What Must Be Machine-Readable Before Checkout

Public-source evidence review. Sources checked 21 September 2026. Educational and operational review discussion only.

A merchant page says an insulated bottle is available for $32. An agent can parse the SKU, seller, price and delivery estimate. A minute later, the checkout returns a different color, a higher shipping charge and a final-sale policy. The buyer’s earlier authority covered only the first variant.

Nothing in that sequence requires a dramatic failure. Every individual screen can look reasonable. The problem is that “machine-readable” has been allowed to stand in for several different questions.

Can the agent parse the offer? Are the commercial terms still current? Does the actor have authority for this exact purchase? Which version of the cart is being approved? And, after commitment, which systems will be authoritative for order, payment, fulfillment and recovery?

Those questions need one reviewer object before checkout: an Agentic-Commerce Readiness File.

Reader note: “Must” in this article means the proposed minimum for this review method unless a specific requirement is tied to a cited specification or merchant policy. The Readiness File is author synthesis. It is not an industry standard, certification, audit opinion, checkout payload or authorization to transact.

Executive summary

Machine-readable is necessary in agentic commerce. It is not a synonym for current, authoritative, authorized or operationally proven.

For a merchant-finance or payments reviewer, a pre-checkout file should keep at least five layers separate:

1. Offer identity: the exact merchant, product, seller offer, variant, quantity and unit.
2. Current commercial terms: price, currency, discounts, tax, shipping, fees, fulfillment option, return/refund terms and the status of the total.
3. Authority: who the buyer and agent are, what purchase scope is permitted, when that authority expires or can be revoked, and where human confirmation is required.
4. Checkout snapshot: the exact basket and terms the authority applies to, plus the change set that can or cannot proceed without renewed confirmation.
5. Outcome evidence contracts: the systems and correlation references that will later establish order, payment, fulfillment and recovery states.

That last layer is intentionally future-facing. A pre-checkout file should say which receipt or event is expected later. It should not pretend that payment, settlement or fulfillment already happened.

This article uses current OpenAI Commerce documentation, UCP 2026-08-25, AP2 v0.2 and Schema.org as examples of different machine-readable layers. They are mappings, not one interchangeable wire schema.

Parseable is not the same as purchasable

The cleanest evidence for this distinction is surprisingly simple.

OpenAI’s current product-feed documentation uses stable identifiers for an item, its parent group and a seller’s offer. It also supports seller, price, availability, shipping and return fields. But its minimal example says search defaults to enabled while checkout defaults to disabled.

That is exactly the boundary a reviewer needs.

A feed can make a product discoverable without making a merchant capable of, or eligible for, agentic checkout. A Schema.org Product or Offer can make price, seller, availability or priceValidUntil easier to parse without giving an agent purchase authority. A browser can expose the same information visually without proving which backend state is authoritative.

So the first line in the Readiness File is not “agent-ready: yes/no.” It is the integration path and the authority of each source.

For each field, record where it came from, which system owns it, when it was observed, and what makes it stale.

The offer needs identity before it needs intelligence

A product name is not enough.

The reviewer wants merchant identity, seller identity where relevant, product and offer identifiers, variant or SKU, quantity and the sale unit. Two offers can have the same product URL but different sellers. Two variants can share a parent listing but have different price or stock.

OpenAI’s product-feed specification makes this explicit with item_id, group_id and offer_id. UCP 2026-08-25 goes further for checkout by giving the business authority over the sale basis: quantity, unit, scale and any increment.

This is operationally important. “2” might mean two bottles, 2.00 kilograms or two packs. If the machine cannot represent the unit that the merchant actually sells, the apparent precision of the rest of the checkout is misleading.

Availability needs its own boundary too. A catalog can say in_stock, out_of_stock or even unknown. An observed stock field is not the same thing as a reservation. If the workflow depends on stock being held, the reservation evidence needs its own field and source.

Price is a structure, not a number

A catalog price is often the beginning of the commercial answer, not the end.

The review file should make the money representation explicit: currency, amount and exponent or other unit convention. Then it should preserve components rather than only the final display number:

• item base amount;
• item or order discount and qualification;
• shipping;
• tax;
• fees or surcharges;
• fulfillment option;
• total;
• whether that total is final, provisional or unknown.

The distinction between zero and unknown matters. OpenAI’s current product documentation explicitly says an omitted shipping price means unknown, not free shipping. The same documentation separates a return-policy URL from the Boolean question of whether returns are accepted.

UCP 2026-08-25 provides another useful control. It treats the business’s checkout totals as authoritative for display. A platform may verify the arithmetic, but if its calculation does not match the business’s total it should not substitute its own number and should not autonomously complete the checkout. The mismatch becomes a reject, escalation or buyer-review problem.

That is a good merchant-finance principle even outside UCP: do not make an unknown or disputed commercial component disappear just because a machine can compute a plausible total.

A retrieval timestamp is also not an offer-expiry timestamp. If the merchant publishes a validity field such as Schema.org priceValidUntil, preserve it. If no validity condition is available, record that as unknown and define a refresh condition.

And a delivery window such as “5–7 business days” should stay an estimate unless the merchant’s applicable contract says otherwise.

Identity, consent and authority are different records

The most dangerous shortcut is “the user is authenticated, therefore the agent can buy.”

Authentication can establish an identity in a defined system. Data consent can permit processing. Tool permission can allow an agent to call a service. Purchase intent can describe what the buyer wants. Payment authority can allow a particular instrument or amount. None of those should silently replace the others.

AP2 v0.2 is useful precisely because it makes some of these roles and boundaries explicit. It distinguishes the Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor and Trusted Surface. It also separates Checkout Mandates from Payment Mandates.

In its direct mode, the user approves a closed checkout and payment mandate. In autonomous mode, a user-authorized open mandate contains constraints, and the agent later signs a closed mandate that must conform to them. AP2 recommends keeping expiry short enough for the assigned task.

But AP2 also says the underlying commerce protocol — catalog APIs, checkout updates and other commerce details — is outside AP2’s scope. Authorization cannot freeze a merchant’s catalog by itself.

The Readiness File should therefore carry a purpose-limited, non-secret authority reference, its scope, expiry, revocation check and human-confirmation boundary. It should never publish or copy payment credentials, cookies, bearer tokens or unnecessary buyer identity.

And “technical mandate verified” should remain a technical statement. Whether a particular interaction creates legally valid consent or an enforceable commitment is a jurisdictional and contractual question for qualified review.

Bind authority to the exact checkout, then define what may change

A budget cap is not a permission to change the purchase.

Suppose the buyer approves a navy bottle up to $80. The merchant later offers a charcoal bottle for $74. The new total is still under the budget. That does not answer whether the buyer permitted a substitute variant, a final-sale policy or a different delivery option.

The Readiness File needs an exact checkout snapshot: item/offer/variant, quantity and unit, merchant, totals, policy references, fulfillment choice, observation time and expiry. It also needs an allowed change set.

For many flows the safest allowed set may be empty: any material change returns to refresh and confirmation. Other workflows may explicitly permit defined changes. The point is to write that rule before the change happens.

A digest can help identify the serialized snapshot that was reviewed. It should not be described as a magic lock. A hash does not, by itself, authenticate the source, make comparison and commit atomic, or prove consent.

Protocols can provide stronger binding. AP2 binds its Payment Mandate to a particular merchant-signed checkout. UCP’s AP2 extension, when negotiated, requires merchant authorization in checkout responses and requires an AP2 checkout mandate for completion.

Those are specific mechanisms with specific scope. The Readiness File records which mechanism actually applies instead of inventing a universal one.

Three integration paths, three evidence problems

A structured catalog plus checkout API gives the machine the best chance of working with explicit fields. It still needs versioning, freshness, authority and current checkout state.

A merchant-hosted handoff can keep the automation bounded. The machine prepares a proposal; the merchant’s own checkout becomes the place where current terms are presented and the human confirms. UCP’s base checkout model is a useful example: checkout is finalized manually through a trusted UI unless the AP2 extension is supported, and requires_escalation can hand control to a buyer through a continuation URL.

Browser-mediated extraction is the most fragile of the three. A page can be readable without exposing durable identifiers, explicit units, versioned terms or authoritative state. The right reviewer response is not “browser bad.” It is to record the uncertainty: what was displayed, when it was observed, which fields lack semantic identity, and where the flow must hand off for authoritative terms and confirmation.

None of these paths is a permission to bypass access controls, CAPTCHA or merchant bot rules.

Define post-checkout evidence before checkout

Merchant finance needs to know what happens after “Buy,” but the pre-checkout file should not fabricate those outcomes.

Instead, define an outcome contract for each state family:

Provider-native states matter. Stripe’s PaymentIntent documentation, for example, distinguishes processing, requires_capture and succeeded. That is a provider-specific lifecycle, not a universal commerce taxonomy.

Unknown has to remain a valid state. A network timeout does not tell finance that the economic operation failed. Even an idempotency key has a defined provider, operation and retention scope. Before another economic attempt is made, the exact recovery contract and current authoritative state need to support it.

That topic deserves its own runtime treatment. Here it appears only as a pre-commit requirement: know the evidence path and exception owner before you create the event.

Two synthetic examples

Example A in the companion Readiness File is deliberately boring. A fictional merchant offers two identical navy bottles at $32 each. The file records a $64 item amount, a $4 discount, $6 shipping, $5.25 tax and a $71.25 final total. The mandate reference permits that exact merchant and offer up to $80, remains unexpired, and requires human confirmation on the exact snapshot.

The file still says transaction_execution_status: not_executed. It also records live merchant integration not observed.

That is the point. A coherent review file is evidence of a coherent review file — not evidence that a merchant integration works.

Example B uses the same schema and changes the offer before confirmation. The variant changes from navy to charcoal, the unit price rises from $32 to $34, shipping rises from $6 to $9, the return policy becomes final-sale, tax becomes unknown and the old mandate has expired. The total is therefore unknown.

The outcome is not “still under budget.” It is blocked.

The path is: STOP → refresh the authoritative offer and terms → obtain authority that covers the new offer → obtain the final amount → reconfirm.

The compact Agentic-Commerce Readiness File

For one merchant and one channel, the minimum review object is small enough to inspect:

The machine-readable JSON companion in this package is a Treasury Desk review schema, not a protocol payload. The CSV is an evidence matrix, not a certification checklist. No overall readiness score is calculated.

Questions for the merchant-finance and payments owner

Before calling a flow ready for a scoped human review, ask:

• Can we identify the exact seller offer and sale unit, not only the product name?
• Which source owns the price and which source owns the final total?
• What does unknown mean for tax, shipping, stock or delivery?
• Which terms can change without renewed confirmation?
• What evidence proves authority for this merchant, item and amount right now?
• What causes authority to expire or be revoked?
• Which exact checkout snapshot is the confirmation attached to?
• What happens if the merchant revises SKU, return policy, address, shipping or total?
• Which system will be authoritative for order acceptance?
• Which provider state would establish payment outcome for this route?
• What evidence closes an unknown payment state before another attempt?
• Which fulfillment and recovery events will finance reconcile later?
• Which fields can be public, which require an authorized machine, and which belong only in a controlled reviewer record?

If those answers are scattered across product feeds, browser text, policy pages, checkout objects and payment systems, the Readiness File is the place to bind the references without pretending they are one protocol.

The useful output is not a green badge. It is a reviewer who can say, with precision: this is the offer we saw, these are the terms we know, this is the authority we have, this is the snapshot it applies to, these are the changes that would stop the flow, and these are the systems that must prove what happens next.

That is a stronger pre-checkout statement than “the catalog is machine-readable,” and a deliberately narrower one than “the merchant is agent-ready.”

Method and sources

This article reviewed:

• OpenAI Products: https://developers.openai.com/commerce/specs/file-upload/products
• OpenAI Agentic Checkout: https://developers.openai.com/commerce/specs/checkout/
• UCP Checkout 2026-08-25: https://ucp.dev/2026-08-25/specification/shopping/checkout/
• UCP AP2 Mandates extension 2026-08-25: https://ucp.dev/2026-08-25/specification/payment/extensions/ap2-mandates/
• AP2 v0.2 specification: https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md
• AP2 Checkout Mandate: https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/checkout_mandate.md
• Schema.org Product / Offer: https://schema.org/Product and https://schema.org/Offer
• Stripe PaymentIntent lifecycle (https://docs.stripe.com/payments/paymentintents/lifecycle) and idempotency documentation (https://docs.stripe.com/api/idempotent_requests) as provider-specific examples.

The Readiness File, its status vocabulary, its change-control rules and its JSON/CSV representations are Treasury Desk author synthesis. They are not an industry standard or Treasury Desk production feature.

Treasury Desk methodology: https://treasurydesk.io/methodology/
Treasury Desk product boundary: https://treasurydesk.io/legal-scope/