A product page says an item is available for a stated price. Its JSON-LD says something else, perhaps because a template retained yesterday's offer. A client reading the structured fields now has a different description of the sale from the customer looking at the page.
Commerce metadata deserves maintenance for that reason alone. It publishes product and offer information in forms that software can inspect. MachineRead checks selected fields and discovery documents, but it does not add items to a cart or attempt a purchase.
Product and Offer markup state facts about an offer
Schema.org defines Product as "any offered product or service." Its offers property can point to an offer for that item (Schema.org, "Product").
Schema.org Offer is also narrower than a transaction. The vocabulary page defines it as an offer to transfer rights to an item or provide a service, and it includes properties such as availability and business function (Schema.org, "Offer"). Those fields can help a machine read the public claim on the page. They do not reserve stock, validate a shopper, calculate taxes, authorize a card, create an order, or prove that a merchant will fulfill anything.
MachineRead treats that boundary explicitly. Its JSON-LD check requires Product records to include name, description, and offers; it requires Offer records to include price, priceCurrency, and availability; and it parses those records from public JSON-LD in the fetched HTML. A passing finding is structured-field evidence from the page. It is not a purchase test.
A catalog endpoint is still just a public document
A catalog-shaped JSON endpoint can be helpful for the same reason. It may expose product records in a format that a crawler, assistant, marketplace tool, or internal system can parse without scraping page chrome. But a JSON response at /products.json, /catalog.json, or a similar candidate path does not become a checkout system by being parseable.
MachineRead's machine-surface check treats catalog JSON as a commerce-scoped surface. It checks candidate paths including /products.json, /catalog.json, and /collections/all/products.json, and it accepts the result only as sufficiently long parseable JSON under the audit conditions. That is a shallow document observation.
The check does not follow every product or compare the catalog with current stock. If it finds a candidate document, inspect the records before relying on them. If it finds none, check whether the publisher uses a different location before concluding that no catalog exists.
Match the protocol to the intended exchange
Different commerce protocols describe different exchanges. x402's version 2 specification includes payment requirements, payloads, and settlement responses. Its discovery material names /discovery/resources and /discovery/search; these should not be confused with MachineRead's candidate .well-known paths (x402 Foundation).
MPP's maintainer documentation describes a 402 challenge and a subsequent credential-bearing retry. It links its core work as an IETF Draft, not a final RFC (Tempo/Stripe). UCP describes capabilities and checkout-related operations, while the ACP repository labels its work beta (Universal Commerce Protocol project; Agentic Commerce Protocol project).
Choose the documentation for the protocol and version actually in use. A file bearing one of these names is insufficient to establish conformance, and none of those labels makes the protocols interchangeable. MachineRead's shallow discovery tests do not validate a full payment exchange.
What MachineRead observes
MachineRead has two relevant commerce surfaces. The strict readiness probe names x402, MPP, UCP, and ACP separately. For x402 it checks candidate paths /.well-known/x402 and /.well-known/x402.json for shallow top-level keys such as accepts or resource. For MPP, UCP, and ACP it checks one .well-known JSON candidate each for shallow keys such as version or manifest.
The broader machine-surface audit groups x402, MPP, UCP, ACP, /.well-known/payments.json, and catalog JSON as commerce-scoped machine-readable surfaces. It validates those candidates as public parseable JSON after basic length screening.
Those implementation choices are deliberately modest. They let MachineRead report that a target exposed a candidate document with a label and shape worth inspecting. They do not call the candidate path canonical. They do not validate a full protocol schema. They fetch documents; they do not exercise checkout or payment operations.
How to read a commerce finding
Compare the product record with the visible offer. Check the item name, price, currency, and availability, then determine which system owns those values. If a template and catalog export obtain their prices from different sources, fix that inconsistency rather than editing only the copy an audit sees.
A protocol finding needs a different follow-up. Identify the named protocol and version, inspect the advertised capabilities, and compare them with the maintainer's documentation. MachineRead's candidate paths are search locations used by the audit, not proof that each protocol requires those paths.
Test checkout behavior separately, with authorized test accounts and payment facilities. A catalog can help a client understand an offer before purchase; confirming an order, payment, or delivery requires the corresponding operational evidence.
Works Cited
Agentic Commerce Protocol project. "Agentic Commerce Protocol." GitHub, https://raw.githubusercontent.com/agentic-commerce-protocol/agentic-commerce-protocol/main/README.md. Accessed 9 Sept. 2026.
Schema.org. "Offer." Schema.org, https://schema.org/Offer. Accessed 9 Sept. 2026.
Schema.org. "Product." Schema.org, https://schema.org/Product. Accessed 9 Sept. 2026.
Tempo/Stripe. "Machine Payments Protocol Specifications." GitHub, https://raw.githubusercontent.com/tempoxyz/mpp-specs/main/README.md. Accessed 9 Sept. 2026.
Universal Commerce Protocol project. "Universal Commerce Protocol." GitHub, https://raw.githubusercontent.com/universal-commerce-protocol/ucp/main/README.md. Accessed 9 Sept. 2026.
x402 Foundation. "x402 Protocol Specification v2." GitHub, https://raw.githubusercontent.com/x402-foundation/x402/main/specs/x402-specification-v2.md. Accessed 9 Sept. 2026.
See also
- Methodology reference - separates observed documents from runtime guarantees
- A standard route to an API's public description - another case where a catalog is an index, not an integration