In brief. ACP covers product feeds and merchant-hosted checkout, while AP2 centers on signed records of buyer intent and cart approval. Visa and Mastercard focus on agent trust and payment credentials, and MCP standardizes callable access to tools and data. Merchants still need accurate identifiers, variants, prices, availability, policies and a working checkout path.
- ACP, AP2, Visa, Mastercard and MCP cover different layers of an agent-mediated purchase.
- Accurate product identity, variants, prices and availability must be established before authorization or payment can help.
- Merchants should require account-level provider confirmation for supported protocols, markets, failures and disputes.
- A field-by-SKU evidence matrix reveals readiness gaps that a successful checkout test can miss.
- Checkout should remain on the brand’s rails with merchant-of-record responsibilities explicitly documented.
A size 10 shoe can reach an agentic checkout and still lose the order because its price, stock status or color was unreadable upstream. For brands and e-commerceSelling products online through your own store or marketplaces. For AI visibility the deciding factor is whether the shop's catalog is readable by machines.Read more operators, an agentic commerce protocol covers one or more parts of a purchase, while ChatGPT, Gemini and other buying surfaces may depend on several overlapping systems before a valid order reaches checkout.
Payment and checkout standards leave product readiness in the merchant’s hands. This guide maps five initiatives to the layers they document, then gives a non-technical worksheet for checking the gaps that can stop a product before payment begins.
What jobs do agentic commerce protocols separate?
- Discovery: the step where a shopping system finds a product page, feed entry or catalog record that could answer a buyer’s request.
- Product data: the facts describing an item, including its identifier, title, variant, price, currency, availability, images and policies.
- Cart: the authoritative list of products, quantities, taxes, shipping choices and totals prepared for purchase.
- Mandate: a signed record of what a buyer intended or approved an agent to purchase.
- Payment credential: a protected reference that lets an approved payment instrument be used within defined limits.
- Settlement: the movement and reconciliation of funds among the buyer’s provider, network, processor and merchant.
- Merchant of record: the legal seller responsible for the charge, taxes, fulfillment and commercial transaction.
- Dispute path: the documented route for refunds, chargebacks, fraud claims and customer support.
Protocol readiness and seller-side readiness require separate owners. Signed payment authorization depends on accurate product identity, while settlement depends on a functioning payment flow.
The protocol map has deliberate blanks
The matrix treats each publisher’s documented scope as the boundary. Partial means the initiative supports part of a layer without defining the full operating model. A blank means the reviewed first-party material did not support a reliable claim.
| Initiative | Publisher | Discovery | Product data | Cart | Authorization | Payment credential | Settlement | Merchant of record | Disputes | Maturity |
|---|---|---|---|---|---|---|---|---|---|---|
| Agentic Commerce Protocol (ACP) | OpenAI and Stripe | Partial | Covered | Covered | Partial | Covered | Outside stated scope | Covered | Partial | Published open specification; changing |
| Agent Payments Protocol (AP2) | Google-led open project | Outside stated scope | Outside stated scope | Partial | Covered | Partial | Outside stated scope | Published open specification; evolving | ||
| Visa agent-commerce initiatives | Visa | Outside stated scope | Outside stated scope | Partial | Covered | Implementation-dependent | Public network and developer initiatives | |||
| Mastercard Agent Pay | Mastercard | Outside stated scope | Outside stated scope | Outside stated scope | Partial | Covered | Implementation-dependent | Public network initiative | ||
| Model Context Protocol (MCP) | Created by Anthropic; open-source project | Partial | Partial | Outside stated scope | Outside stated scope | Outside stated scope | Outside stated scope | Outside stated scope | Outside stated scope | Published general-purpose protocol |
Methodology. Veliu Editorial Team reviewed the linked first-party materials on July 29, 2026: OpenAI commerce documentation, the OpenAI product-feed specification, the ACP repository, Stripe’s ACP publication, Google’s AP2 repository, Visa Developer, Mastercard Newsroom and the MCP documentation. We recorded publisher, stated scope, merchant obligations and maturity. Silence was left blank. The main limitation is timing: specifications, governance and provider support can change after the review date.
The unevenness is the finding.
Five names describe a collection of interfaces and trust mechanisms. The merchant still has to operate the complete sale.
How do ACP and AP2 divide purchase layers?
ACP and AP2 are often grouped together because both concern purchases made through agents. Their documented strengths sit at different points: ACP describes product and checkout interactions, while AP2 centers on signed evidence of intent and cart approval.

ACP connects product records to merchant checkout
ACP combines a product-feed specification with merchant-hosted cart and checkout operations. It also documents delegated payment so a protected credential can reach the merchant’s payment flow while the merchant remains the seller.
According to OpenAI’s product-feed specification, a merchant supplies structured records with facts such as item identifier, title, description, URL, price, availability and image. In shop-floor terms, the feed is the stock card handed to the buying system. If a navy size 10 shoe carries the price of a black size 8 shoe, the protocol can transmit an accurate record of the wrong offer.
ACP then moves from shelf to till. The public repository and OpenAI commerce documentation describe interactions in which the merchant hosts the authoritative checkout session and returns current cart details, fulfillment options and totals.
Stripe calls ACP “an open standard for agentic commerce” in its September 2025 publication. That description establishes the interface’s purpose. It does not establish support by every commerce platform or processor.
Specifications move. Ask which ACP functions a platform supports, which version its documentation references, how failed sessions are logged and how feed errors reach the catalog owner.
AP2 records buyer intent and approval
The Google AP2 repository documents signed records including an Intent Mandate, which captures what the buyer wants, and a Cart Mandate, which binds the approved items and totals. “Buy running shoes under $160” expresses intent. A cart containing one SKU, size, tax, shipping and total records the concrete purchase presented for approval.
AP2 materials may also describe payment authorization artifacts as the specification evolves. Operators should verify the current artifact name, role and required sequence against the repository version their provider implements before writing it into procurement or compliance requirements.
A mandate records the buyer’s permission before payment execution.
For an operator, the obligation is practical. The commerce system must produce an accurate cart, preserve evidence of what was approved and define what happens if the SKU, stock or total changes before completion. Provider documentation should identify any re-authorization path.
Visa and Mastercard controls enter through providers
Visa and Mastercard approach agentic payments through network, trust and credential infrastructure. Settlement behavior can vary by payment method, network, processor, acquirer and implementation, so a public announcement cannot establish how one merchant account will behave.
Visa capabilities require account-level confirmation
Visa Developer and Visa’s first-party publications describe mechanisms intended to recognize trusted commerce agents and control protected payment credentials or tokens. These mechanisms can help participating providers assess the source of a request and the permitted use of a credential.
Ask whether the acquirer, processor or payment service provider supports the named Visa capability for the merchant account, market and checkout flow. Require a direct capability document, supported-market list and written account confirmation before planning implementation.
Mastercard Agent Pay belongs in the payment workstream
Mastercard’s first-party newsroom describes Agent Pay and agent-linked payment credentials with consent controls on Mastercard rails. The public scope does not establish identical interfaces, markets or obligations across Mastercard, Visa, ACP and AP2.
For merchants, Agent Pay belongs in a payment-provider conversation. It enters the product-data backlog only when a provider identifies a specific catalog or checkout dependency.
MCP opens controlled access to tools
Model Context Protocol, created by Anthropic and maintained through its current open-source project, is a general standard for exposing tools and resources that an agent can call. In commerce, those tools might search a catalog, retrieve one product or check inventory at the time of a request.
It can expose a controlled door into the stockroom. Commerce schemas, authorization rules and payment systems still define the inventory, approvals and movement of funds.
The appeal is obvious: connect one MCP server and assume the store is ready for agent-mediated purchases. The evidence does not support that conclusion. MCP documentation describes a general tool-and-resource protocol, leaving commerce meaning and operating controls to the merchant’s application and other systems.
A commerce platform could expose three callable tools. A product search finds candidates for “waterproof carry-on backpack.” A product lookup returns the selected bag’s dimensions, material and canonical URL. An inventory check confirms whether the olive variant is available.
Checkout can remain on separate rails.
MCP is useful here because it makes product functions callable. Each discovery surface sets its own access requirements, and order completion still depends on commerce and payment systems.
AI-findability verdict: product data shapes selection
ChatGPT, Gemini, Perplexity, Copilot and AI Overviews can read or retrieve varying combinations of live pages, structured dataMachine-readable schema.org markup (Product, Offer, AggregateRating) embedded in a page as JSON-LD. It is the canonical way to hand engines unambiguous product facts.Read more, feeds and catalog programs, depending on the surface and merchant integration. Making supported product facts consistent gives these systems clearer material to interpret, while each engine controls retrieval and selection.
Consider a shopper asking for “a 50 ml fragrance under $120 that arrives by Friday.” The engine needs the exact size, current price, currency, availability, delivery information and a product identity it can reconcile. A mandate becomes relevant after a particular offer enters the cart.
That timing matters.
The blanks in the matrix expose the shared gap. Standards can carry data, create a cart or authorize payment after a product enters play. Product truth, relevance, evidence and availability shape whether the correct offer reaches that point.
The buy side depends on seller-side preparation
Agentic Selling is the seller side of agentic commerce: preparing a brand’s offer so shopping agentsSoftware agents that search, compare and complete purchases on a buyer's behalf. They read structured catalog data and transact through protocols like ACP and MCP.Read more can understand it and complete a valid path to purchase. The buy side interprets a shopper’s request. The sell side supplies a credible offer, an authoritative cart and an operating checkout.
Machine-readable information is one mechanism within that work. Our guide to generative engine optimization for e-commerce explains how feeds, schema.org markup and catalog facts can be extracted by answer and shopping engines.
This closes the size 10 problem from the opening. A checkout protocol can carry the order only after the exact size, color, stock state and price have been understood.
Product readiness starts before payment
- Externally readable product information. A product page and feed expose a real item with a current offer.
- Valid identifiers and variants. A GTIN, the numeric trade-item identifier that can be encoded in a barcode, or a brand plus manufacturer part number distinguishes the item; size and color relationships identify the exact variant.
- Consistent price and availability. The page, feed and callable endpoint agree that the red size M jacket costs $149 and is in stock.
- Precise category. The jacket sits in a category specific enough for comparison with similar jackets.
- Actionable cart and checkout. The chosen variant enters a cart with current shipping, tax and payment terms.
A disagreement at step 3 can block later steps. Google’s Merchant Center guidance says price or availability mismatches between submitted product data and landing pages can cause item disapproval. The documented consequence applies to affected items and Merchant Center processing; it does not establish a universal site-wide effect.
Operator work starts with evidence
Use this as a Monday-morning worksheet. Retain a timestamp, SKU and provider response for every test so the next failed transaction can be traced.
| Work item | Owner | Do now | Safe to monitor | Evidence to retain |
|---|---|---|---|---|
| Externally testable product pages | E-commerce lead | Test representative URLs without an account | New rendering formats | URL, timestamp, rendered facts |
| Product and Offer schema.org validation | SEO or platform owner | Compare visible facts with markup | New recommended properties | Validator output and sample pages |
| Valid GTIN or brand plus MPN | Merchandising | Verify assigned identifiers; never invent them | Policy changes | Source record and check result |
| Variant-family checks | Catalog owner | Test size, color and material relationships | Platform automation | Parent and child SKU sample |
| Price and availability consistency | Commerce operations | Compare changed and high-volume SKUs | Engine refresh timing | Values and timestamps |
| Crawler access choices | Security and SEO | Set access rules by use case | New user-agent tokens | Versioned rules and edge settings |
| Feed eligibility | Channel owner | Check required fields and item status | Additional programs | Diagnostics by SKU |
| Checkout-session tests | Engineering and payments | Test create, update, complete, cancel and retry paths | New versions | Request IDs, totals and result |
| Merchant-of-record confirmation | Finance and legal | Confirm the legal seller for each lane | New contracts | Signed agreement and tax ownership |
| Dispute ownership | Support and payments | Map refunds, chargebacks and customer contact | Network tooling | Written escalation matrix |
Catalog work and payment implementation need separate workstreams with one shared end-to-end test. A single “AI commerce” project can hide ownership because each team may assume another has corrected the missing field.
Providers may absorb defined payment work
A payment service provider may absorb credential tokenization, network controls, mandate transport and parts of settlement integration when it confirms support for the merchant’s account and target channel. Product names in a network announcement are insufficient evidence.
Request written scope covering supported markets, transaction types, failure handling, refund ownership, chargeback handling and customer support. Then ask one blunt question: “When an authorized agent transaction fails after cart approval, who contacts the customer and who reverses the funds?”
If the answer crosses three providers, document all three handoffs.
Product truth remains the merchant’s responsibility
The merchant must maintain canonical identifiers, variant relationships, current offers, shipping and return policies, clean images and a checkout path on the brand’s rails. Those facts determine whether an agent compares the intended item before payment infrastructure becomes relevant.

The Google Shopping feed optimization guide shows how page and feed price gaps become item-level operating problems. An agentic checkout can expose the same failure when the authoritative cart disagrees with the earlier offer.
A missing barcode is still missing.
The same discipline applies to ratings. AggregateRating, the schema.org summary of a product’s visible review score and count, should reflect evidence for that specific product. Reusing a company-level score for every SKU creates an unsupported product claim.
Speculative builds can wait
Wait when a commerce platform or payment provider has not published support. Similar words such as “cart,” “token” or “agent” do not establish interoperability between two specifications.
Direct implementation can also wait when a provider is expected to absorb a changing specification, provided the merchant keeps internal concepts such as SKU, variant, price, inventory, fulfillment option, tax and refund status stable and modular.
Monitor first-party documentation, provider release notes and contracts. Prototype when a test answers a current operating decision, such as whether the platform returns an authoritative cart after a stock change.
The readiness worksheet measures the upstream gap
Build a field-by-SKU matrix. Sample hero products and the long tail separately, since a polished bestseller can hide missing information across hundreds of less-promoted variants.

Use four cell states: Present, Invalid, Missing or Conflicting. Conflicting means two surfaces show different current facts, such as $129 on the page and $139 in the feed.
| Field | Hero SKUs | Long tail | Product page | Merchant feed | Protocol endpoint |
|---|---|---|---|---|---|
| Required identifiers | Status | Status | Status | Status | Status |
| Variant attributes | Status | Status | Status | Status | Status |
| Price | Status | Status | Status | Status | Status |
| Currency | Status | Status | Status | Status | Status |
| Availability | Status | Status | Status | Status | Status |
| Canonical URL | Status | Status | Status | Status | Status |
| Image | Status | Status | Status | Status | Status |
| Shipping | Status | Status | Status | Status | Status |
| Returns | Status | Status | Status | Status | Status |
| Rating evidence | Status | Status | Status | Status | Status |
Add one category-confidence label per sampled SKU: precise enough for a fair comparison, plausible with an important distinction missing, or too broad for dependable comparison. A trail-running shoe filed under “footwear” belongs in the third state.
The worksheet can be rerun after every catalog release. Retain the sampled SKU list, source URLs, feed export, endpoint response and test date so later changes remain traceable.
What this means for your store
- Choose standards by transaction layer. Identify whether the current gap concerns product access, cart orchestration, authorization or credentials.
- Ask providers for documented responsibility. Require named support, market scope, version, failure ownership and dispute handling in writing.
- Measure product readiness independently. Track identifiers, variants, price, availability and policy consistency even when checkout tests pass.
- Keep checkout on the brand’s rails. Confirm the merchant of record, customer obligation, refunds, support and fulfillment for every lane.
Final verdict: protocols require seller-side readiness
- ACP matters in OpenAI’s commerce lane when a merchant needs the documented product-feed and merchant-hosted checkout model.
- AP2 matters when a flow needs signed evidence of buyer intent and cart approval.
- Visa and Mastercard capabilities matter through providers that document support for the relevant network initiative.
- MCP matters when an agent needs callable access to tools such as catalog search or inventory checks.
- Seller-side readiness remains essential: accurate products, valid variants, current offers and an actionable checkout.
Veliu’s brand agent studies the market, readies the store, and sells to people and to the AI shopping agents that arrive. It uses clean catalog facts and connected selling surfaces to answer with a current price and valid variant, sell on the brand’s own site, and answer shopping agents machine to machine. Checkout stays on the brand’s rails, with the brand as merchant of record.
Protocol decisions should follow published evidence. Product corrections should start with the next conflicting SKU.
The next paper, when it is written.
One email per paper, and nothing else.
Subscribe





