Learn

Agentic Commerce RFP Questions: What To Ask Platforms, Processors, And AI Vendors

Andrew McPherson · Updated August 1, 2026

Depth · Core

Good for: Leaders

An agentic commerce RFP should turn vendor claims into evidence. Ask what is live, which standards are supported, how product data stays current, how checkout and payment authorization work, who carries liability, what data is shared, and what reporting exports you receive. If a vendor cannot answer those concretely, the capability is not ready for procurement.

Short answer

Use the questions below to separate three things vendors often blend together: product discovery, agent-assisted checkout, and agent-authorized payment. A vendor may support one without supporting the others. Your RFP should force that distinction, then test interoperability, data quality, liability, reporting, and lock-in.

RFP question map

AreaWhat the answer should prove
ScopeWhich use cases are live, in pilot, or only roadmap
StandardsWhere ACP, AP2, UCP, MCP, A2A, x402, MPP, or proprietary APIs are used, and at which version
Product dataHow catalog freshness, completeness, and live-store parity are maintained
CheckoutWhether the vendor can create, update, complete, cancel, and report orders
PaymentsHow authorization, tokens, mandates, disputes, and liability work
PrivacyWhat customer, product, and transaction data is collected or shared
ReportingWhether exports separate agent surface, product, order state, and outcome
PortabilityWhat you can take with you if you leave

1. Scope and live status

Start by asking what is actually shipping. Agentic commerce is full of announcements, pilots, and future-roadmap language, so the first RFP job is to classify claims.

  • Which use cases do you support today: discovery, comparison, cart creation, checkout, payment authorization, post-purchase support, or all of these?
  • Which capabilities are generally available, in private beta, in pilot, or still roadmap?
  • Which customers, verticals, or categories are live now?
  • Which capabilities have you announced publicly that are not yet available to a customer like us, and in which countries?
  • Can you show an end-to-end demo using our category and a realistic product set?
  • What fails or falls back to a human when the agent cannot complete the task?

That second question is doing more work than it looks. A large share of agentic commerce news is an announcement of intent rather than a shipped capability, including retailer and payment-provider commitments made at launch events, so an RFP that does not force the distinction will buy a roadmap.

2. Standards and interoperability

Do not accept “standards-based” without details. A useful answer names the standard, the version if relevant, and the boundary where proprietary APIs begin.

  • Which open standards do you support: ACP, AP2, UCP, MCP, A2A, x402, MPP, or others?
  • Which revision of each? These specifications are date-versioned and moving. Ask for the exact version, then check it against the standard’s own release page rather than the vendor’s marketing page.
  • Where do you use open standards, and where do you use proprietary APIs?
  • Can we export integration mappings, product mappings, order logs, and transaction records?
  • How do you handle version changes and backward compatibility, and what notice do we get before a breaking change?
  • Can we support more than one agent surface or protocol without rebuilding?

Two version questions are worth asking by name in 2026.

MCP. The 2026-07-28 revision shipped as final on 28 July 2026 and is a deliberate clean break. The protocol is now stateless: the initialize handshake and the session header are gone, protocol version and capabilities travel on every request, and header-based routing is required on the Streamable HTTP transport. Authorization was hardened, with dynamic client registration deprecated in favor of client ID metadata documents, and the legacy HTTP with server-sent events transport is deprecated on a twelve-month clock. So ask which revision the vendor implements, whether anything in their design still depends on MCP sessions, and what their migration plan and timeline are. Treat a vendor who describes MCP session handling as a current feature as behind the spec.

ACP and UCP. Both are date-versioned too. Ask which ACP spec release the integration targets, and which UCP revision, and which optional UCP capabilities such as cart, catalog, and identity linking are actually implemented rather than merely available in the specification.

3. Product data and catalog quality

Agents buy from data. If a vendor cannot explain feed requirements and data freshness, the integration is fragile.

  • What fields are required, recommended, and optional?
  • Which identifiers are used for product matching: SKU, GTIN, brand, category, merchant ID, or platform IDs?
  • How quickly do price, availability, promotion, and variant changes reach agent surfaces?
  • How are feed errors, mismatches, missing attributes, and stale inventory reported?
  • Can we see how agents describe and compare our products before launch?

For the underlying readiness work, see product catalog for agentic commerce.

4. Checkout and transaction control

The buyer may interact with an agent, but the merchant still needs control over pricing, tax, fulfillment, eligibility, policies, and order state.

  • Does the agent complete checkout through your platform, our checkout, or a third-party checkout surface?
  • Which checkout standard or API is used?
  • What cart, shipping, tax, promotion, inventory, and policy data is exchanged?
  • Can we enforce restricted products, shipping limits, minimum order values, fraud rules, and promotion exclusions?
  • How are failed, partial, canceled, refunded, or changed orders handled?

5. Payments, authorization, and disputes

This is the highest-risk section. Ask for precise flows and contract terms, not conceptual diagrams.

  • Which payment methods and delegated-payment models are supported?
  • How is customer authorization captured, scoped, stored, and auditable?
  • Do you support Shared Payment Tokens, network tokens, AP2 mandates, stablecoins, or other payment artifacts?
  • If AP2 mandates are used, do you retain the receipts as well as the mandates? AP2’s dispute procedure requires the checkout mandate with its receipt and the payment mandate with its receipt, and independently recomputes the hashes that bind them. A vendor that stores authorizations but not receipts cannot produce verifiable evidence.
  • Who is liable for fraud, agent error, customer dispute, chargeback, unauthorized purchase, or “not as described” claims, and which clause of the contract says so?
  • What evidence is available to defend a dispute, in what format, how is it exported, and how long is it retained?
  • Which consumer-protection programs do you rely on, and do any of them shift liability away from us? A cardholder protection pledge, such as the one American Express announced in April 2026 for registered-agent purchases, protects the cardholder and does not by itself change what a merchant absorbs.

One framing to hold on to through this section: no agentic commerce protocol allocates liability. AP2 states that its objective is to provide supporting evidence that helps payment networks establish accountability and liability principles, and its specification puts dispute resolution, retention, and retrieval out of scope. If a vendor answers a liability question by naming a protocol, the question is still open. Push until the answer is a contract term, a network rule, or a written indemnity.

For a non-technical payment overview, see how AI agents pay. For the authorization layer, see AI shopping agent authorization. For the wider risk picture, see agentic commerce risks and readiness.

6. Privacy, security, and data use

Agentic commerce creates new data flows among merchants, agents, platforms, processors, networks, and model providers. Your RFP should make those flows explicit.

  • What customer, product, transaction, and behavioral data do you collect?
  • Which data is shared with agent platforms, model providers, payment networks, processors, or partners?
  • Do you use our data to train models, rank competitors, improve unrelated services, or sell insights?
  • What retention, deletion, access-log, and security controls are available?
  • Can we restrict sensitive products, geographies, customer groups, or data fields?

7. Measurement and reporting

If agentic commerce is a channel, it needs channel reporting.

  • What reporting is available for impressions, recommendations, comparisons, clicks, carts, completed purchases, exceptions, returns, and disputes?
  • Can reporting separate agent surface, protocol, product category, campaign, and order state?
  • How do you attribute a purchase when discovery happens in one agent and checkout happens elsewhere?
  • Can data be exported to our analytics, warehouse, or BI tools?
  • Do logs distinguish human traffic, agent traffic, and platform-to-platform calls?

8. Commercial terms and lock-in

Finally, ask what it costs and what you give up.

  • What fees apply: setup, monthly platform, per-order, payment, referral, ad, data, or support fees?
  • Are fees different by agent surface, protocol, payment method, geography, or category?
  • What contract terms limit portability, direct customer relationships, data reuse, or future integrations?
  • What happens to our data, listings, integration, and transaction history if we leave?

Red flags

  • “We support agentic commerce” without naming live use cases.
  • “Standards-based” without naming where standards end and proprietary APIs begin.
  • Naming a standard without naming the version, especially for MCP, ACP, and UCP, which are all date-versioned.
  • “Real-time catalog sync” without a measurable freshness commitment.
  • “Agents can buy for users” without a clear authorization and dispute record, including receipts.
  • Answering a liability question with a protocol name instead of a contract clause.
  • “Full reporting” without exports by agent surface and transaction state.
  • “Low lift” without naming the work required from ecommerce, product data, legal, payments, analytics, and support.

The downloadable RFP question bank contains a longer buyer-ready version of these questions. It does not yet carry the version and receipts questions added above, so use this page alongside it. Pair both with the agent-readiness checklist before opening procurement.

FAQ

What should an agentic commerce RFP test first? What is actually live. Ask which use cases are generally available, which are in pilot, which customers are live, and whether the vendor can demo your category end to end.

Which standards should vendors name? ACP, AP2, UCP, MCP, A2A, x402, MPP, network tokens, and any proprietary APIs they use, with the version for each. Several are date-versioned and moving, so ask for the revision. The point is precision, not claiming support for everything.

What is the most important payments question? How authorization is captured, scoped, stored, and defended in a dispute, including whether receipts are kept alongside mandates, plus who carries liability and which contract clause says so. No protocol allocates liability, so a protocol name is not an answer.

What is a red-flag answer? Any broad claim that lacks live use cases, supported standards, data freshness commitments, authorization records, reporting exports, and liability terms.

Primary sources

  1. Agentic Commerce Protocol specification (GitHub) · GitHub
  2. Agentic Commerce Protocol documentation · Stripe
  3. Announcing the Agent Payments Protocol (AP2) · Google Cloud, 2025-09-16
  4. Agent Payments Protocol specification (v0.2) · Agent Payments Protocol
  5. AP2 Executive Summary · Agent Payments Protocol
  6. Model Context Protocol · Model Context Protocol
  7. The 2026-07-28 Specification · Model Context Protocol, 2026-07-28
  8. Find and Buy with AI: Visa Unveils New Era of Commerce (Visa Intelligent Commerce) · Visa, 2025-04-30