Commerce interoperability is the property that lets a merchant's catalog, offers and policies be understood and acted upon by any compliant agent, platform or partner — without custom integration for each one. It is the systems property that makes a Universal Commerce Protocol possible.
Interoperability is not a feature you ship. It is an emergent result of adopting shared identifiers, typed attributes, standard policy semantics and stable endpoints. This page explains the five layers that together produce interoperability in the agentic commerce stack.
The five layers of commerce interoperability
| Layer | What is shared | Example standards |
|---|---|---|
| Identity | Product, brand, merchant identifiers | GTIN, MPN, GLN, schema.org Brand |
| Semantics | Attribute meaning and units | schema.org Product, GS1 attributes, Google Product Category |
| Transport | Feed and API formats | Merchant Center XML/CSV, REST/GraphQL APIs, MCP tools |
| Transaction | Payment, order lifecycle | Stripe ACP, Visa IC, Mastercard Agent Pay, PCI |
| Policy | Returns, warranty, shipping, restrictions | schema.org MerchantReturnPolicy, ShippingRateSettings |
Why interoperability is the economic wedge
In markets with heterogeneous participants, the party that adopts shared standards trades short-term effort for long-term option value. The merchant with GTINs can list on any marketplace. The merchant with structured returns can serve any agent asking about eligibility. The platform with open APIs attracts more integrations than the platform with a proprietary SDK.
Agents accelerate this dynamic. Because agents switch sources cheaply, the cost of being hard to read is immediate, not latent.
What non-interoperable commerce looks like
Symptoms you probably recognize:
- The same SKU described differently on your site, Amazon, Google Shopping and a wholesale catalog.
- Returns policy that is clear in legal prose but invisible to a parser.
- Stock quantities that require a platform-specific API to read.
- Shipping rules encoded in a checkout engine, not expressible externally.
- A new marketplace integration is a 6-week project because your catalog has no canonical form.
Each symptom is a friction an agent will route around — either by preferring a competitor or by degrading your listing's confidence score.
The Identity layer
Identity is the precondition for everything else. Without a canonical identifier, two records describing the same product are treated as two products. Agents that compare across merchants cannot deduplicate. Dashboards that aggregate cannot reconcile.
- GTIN (Global Trade Item Number) — EAN-13, UPC-A, ISBN. GS1-managed. De facto identity for most consumer goods.
- MPN + Brand — manufacturer part number plus brand. Required when no GTIN exists.
- Canonical URL — the stable address of the PDP, used by crawlers and agents for attribution.
- Variant identity — distinct SKUs per size/color, distinct GTINs per variant when applicable.
The Semantics layer
Semantics is where the real work of machine-readability happens. Typed attributes mean an agent does not need to parse prose to answer "is this waterproof?".
- Use standard attribute names where available (schema.org Product properties, GS1 attribute definitions).
- Use enumerations for values when the field is bounded (size, color, material).
- Carry units explicitly ("500g", not "half a kilo").
- Localize values, not just labels (shoe sizes, currencies, date formats).
See product catalogs for AI for a concrete semantic model.
The Transport layer
Transport covers how data moves. Interoperability here is well-established in principle (HTTP, JSON, XML, REST, GraphQL) and still weak in practice (incomplete endpoints, missing fields, proprietary pagination, fragile auth).
- Prefer open, documented feed formats (Merchant Center XML, JSON-LD) over proprietary exports.
- Expose read APIs for partners, not just write APIs.
- Version endpoints; announce deprecations.
- Consider MCP tools to expose catalog operations to agents inside orchestrators.
The Transaction layer
Interoperability at the transaction layer is currently fragmented. Card networks (Visa IC, Mastercard Agent Pay) and payment processors (Stripe ACP, PayPal) are publishing agent-pay schemes that overlap partially. Merchants should insist their PSP supports the schemes relevant to their agent traffic.
- Accept agent-scoped tokens from major PSPs.
- Emit standard order lifecycle events (created, confirmed, shipped, returned).
- Support webhooks agents can subscribe to for status updates.
The Policy layer
Policy interoperability is young and underrated. Most merchant policies are human-readable text. Structured expressions are the leverage:
- MerchantReturnPolicy (schema.org) — eligibility, window, method, cost.
- ShippingRateSettings — rate, region, handling time, delivery time.
- Warranty — scope, duration, claim process.
- AgeRestriction / GeoRestriction — explicit, machine-checkable.
Expressed as structured data, these policies let agents pre-filter offers and pre-answer shopper questions — which raises conversion and reduces support volume.
Interoperability trade-offs
Interoperability costs something. The honest trade-offs:
- Effort. Attribute coverage and policy modelling take time. Mitigation: start with your top SKUs.
- Competitive transparency. A typed attribute is comparable. Mitigation: compete on merit, not on data opacity.
- Platform fees. Marketplaces with better feed compliance take a cut. Mitigation: interoperability also enables direct channels.
Net: the merchants that accept these trade-offs gain disproportionate reach in agent-mediated surfaces.
Where to go next
- Map the actual specs in play in standards, schemas and protocols.
- See the operational translation in product catalogs for AI.
- Run it against your stack with the readiness checklist.