The B2B Agentic Commerce Readiness Checklist

An AI agent can recommend a product, assemble a cart, and even initiate checkout. That does not mean your business is ready for agentic commerce.

The difficult part begins after the buyer says yes. The agent must identify the right account, retrieve the correct catalog and contract terms, stay within its authority, calculate the financial impact, update the subscription, provision the right entitlements, and leave every connected system with a consistent record.

A checkout protocol helps standardize part of that exchange. It does not replace the commerce infrastructure behind it. This checklist asks the production question: Can an authorized agent turn buyer intent into a correct, traceable, and recoverable transaction?

The checklist at a glance

Requirement	A passing system can…
Make the catalog machine-readable	Return products, prices, compatibility rules, and entitlements as structured data.
Resolve account-specific commercial truth	Apply the buyer's actual contract, price, currency, tax context, and eligibility.
Give agents scoped authority, not blanket access	Limit authority by account, action, product, amount, duration, and approval policy.
Verify policy before committing the transaction	Explain whether a proposed action is allowed before changing anything.
Represent subscription changes as first-class transactions	Model upgrades, downgrades, add-ons, seat changes, renewals, and usage commitments directly.
Separate preview, approval, and execution	Return the exact commercial impact before the buyer or agent commits.
Make every transaction safely retryable	Prevent duplicate orders, charges, amendments, and entitlement grants.
Design for partial failure	Prevent or repair inconsistent updates across every downstream system.
Keep every participant synchronized with authoritative events	Publish signed lifecycle events and expose the current transaction state.
Preserve a complete audit trail—and a clear intervention path	Reconstruct who authorized what, why it was allowed, what changed, and how to reverse it.

1. Make the catalog machine-readable

An agent should not have to scrape a pricing page or infer product rules from marketing copy. Your commerce layer should expose product identifiers, prices, currencies, billing periods, quantities, entitlement bundles, dependencies, incompatibilities, and effective dates as stable, explicit data.

The Agentic Commerce Protocol follows this principle at checkout: sellers return a complete, authoritative checkout state rather than asking the agent to calculate totals itself. ACP also uses capability declarations so agents can discover supported payment handlers and optional extensions programmatically.

ACP seller documentation

Pass test: Given an account and a product request, can an agent retrieve the valid purchasable options without reading a webpage or asking a language model to interpret prose?

2. Resolve account-specific commercial truth

B2B buyers rarely transact against a universal list price. The correct result may depend on a negotiated contract, price book, minimum commitment, region, reseller relationship, tax status, renewal date, existing products, or a prior amendment.

A generic catalog can tell the agent what exists. It cannot necessarily tell the agent what this buyer is entitled to purchase, under which terms, or at what effective price. An agent-ready system must resolve those facts at request time and return one authoritative commercial state.

Pass test: Can the system return the price and terms that would actually appear on the customer's invoice—not merely the public price associated with the SKU?

3. Give agents scoped authority, not blanket access

Authentication establishes who is calling. Authorization determines what the caller is allowed to do. For commerce, that boundary should specify which customer account an agent can act for, which actions it can take, which products it can modify, how much it can spend, how long the authority lasts, and when human approval is required.

Current protocol work is moving in this direction. ACP's delegated-payment model supports constraints such as maximum amount, currency, expiration, and usage scope. Google's Agent Payments Protocol describes typed mandates that bind buyer intent, approval, cart, and payment into an auditable chain. MCP's authorization specification similarly emphasizes least-privilege scopes, audience-bound tokens, and resource-specific access.

Pass test: If an agent is authorized to add ten seats, can the same credential be prevented from changing the plan, purchasing another product, or exceeding an approved budget?

4. Verify policy before committing the transaction

An agent should be able to ask, “Is this allowed?” before it asks, “Did this complete?” Expose product compatibility, contract restrictions, budget limits, approval thresholds, account standing, regional availability, and required human intervention as discrete policy checks.

The response should provide a structured reason when an action is denied or requires approval. A precise policy response lets the agent explain the constraint, request the missing approval, or offer a valid alternative instead of improvising from a vague error.

Pass test: Can an agent verify eligibility and obtain an actionable reason for denial without attempting a real transaction?

5. Represent subscription changes as first-class transactions

A one-time purchase usually creates a new order. B2B subscription commerce often changes an existing commercial relationship. Adding seats, switching plans, scheduling a future change, renewing early, or committing to a usage tier can affect proration, invoices, credits, entitlements, contract dates, and downstream provisioning.

These details cannot safely be flattened into a generic “buy item” call. Stripe's subscription documentation illustrates the complexity: price and quantity changes can create prorations, billing behavior varies by request, and pending updates may be needed to prevent a subscription change from taking effect when payment fails.

Pass test: Can the commerce API express the business action directly—such as add seats or upgrade subscription—and return its billing and entitlement consequences?

6. Separate preview, approval, and execution

Before a consequential change is committed, the buyer or agent should be able to inspect the effective date, immediate charge, credit, tax, next-invoice impact, new recurring amount, contract implications, and entitlement changes.

The execution request should reference that preview or use the same effective inputs so the committed result does not silently diverge. Stripe recommends previewing prorations before modifying a subscription and supports reusing the same proration date to keep the calculated result consistent. The broader principle applies across billing systems: calculation and commitment should be separate operations.

Stripe proration previews

Pass test: Can the agent show an authoritative before-and-after view without modifying the subscription, then execute the approved result without recalculating it differently?

7. Make every transaction safely retryable

Agents operate over networks. Requests time out, responses get lost, and the caller may not know whether an operation completed. That makes idempotency mandatory for any endpoint that creates an order, charges a payment method, or changes a subscription.

Both OpenAI's Agentic Checkout specification and ACP include idempotency as a core reliability control. Repeating the same request with the same idempotency key should return the original result rather than perform the transaction again.

Pass test: If the agent receives no response and retries the identical request, is there zero risk of a duplicate charge, order, amendment, or entitlement grant?

8. Design for partial failure

A completed B2B transaction can touch payment, billing, product entitlements, CRM, ERP, tax, and customer communications. Those updates do not always succeed together. Payment might complete while provisioning fails, or the billing amendment might succeed while an ERP sync times out.

An agent-ready commerce layer needs an explicit orchestration model. Depending on the underlying systems, that may mean atomic operations, pending states, compensating actions, reconciliation jobs, or a human intervention queue. Returning an error and hoping the caller retries is not a recovery strategy.

Pass test: For every downstream failure point, can the system identify the last durable state, avoid duplicate work, and either complete or reverse the remaining actions?

9. Keep every participant synchronized with authoritative events

A transaction is not finished when the initial API call returns. Payments fail, approvals arrive later, subscription updates expire, orders are canceled, and entitlements change. The agent, buyer interface, support team, and internal systems need a reliable way to learn what happened next.

OpenAI's checkout specification requires order lifecycle webhooks so ChatGPT can stay synchronized with the merchant's authoritative state. ACP specifies signed webhook requests and full order objects. Subscription platforms also rely on events; Stripe emits events when subscriptions change and when pending updates are applied or expire.

Use signed, versioned events with stable identifiers, timestamps, and replay protection. Also provide a retrieval endpoint so consumers can fetch the current state rather than relying solely on event delivery.

Pass test: Can any authorized system retrieve the current state and reconcile it with signed lifecycle events after a delay, retry, or outage?

10. Preserve a complete audit trail—and a clear intervention path

When an AI agent changes a customer's commercial relationship, “the model decided” is not an acceptable record. The audit trail should connect the initiating identity, delegated authority, policy checks, preview, approval, idempotency key, executed changes, downstream results, timestamps, and final state.

The system also needs a defined human-intervention path. Some transactions will exceed authority, conflict with policy, encounter ambiguous account data, or fail downstream. The agent should stop cleanly, preserve context, and hand the case to a person without leaving the transaction half-complete.

Pass test: Can an operator reconstruct the transaction, explain why it was permitted, identify every system changed, and initiate a controlled reversal or correction?

How to score your readiness

Give your stack one point for each requirement it passes in production—not in a prototype.

0–3: Discoverable, not transactable. Agents may find products or answer questions, but execution still depends on a human or a UI.
4–6: Ready for constrained experiments. A narrow, low-risk transaction may be viable with close supervision.
7–8: Ready for limited production use. The core path exists, but important recovery, governance, or lifecycle gaps remain.
9–10: Production candidate. The core controls exist, but security review, protocol conformance, and operational testing are still required.

Protocol-ready is not the same as commerce-ready

Protocols such as ACP, MCP, and AP2 matter because they standardize how agents discover capabilities, obtain authority, initiate actions, and exchange state. They reduce the need for every agent and merchant to invent a proprietary integration.

But a protocol cannot calculate your customer's proration, resolve a negotiated contract, update the correct billing system, provision entitlements, or reconcile the result across your stack. Those responsibilities remain with the merchant's commerce infrastructure.

PeakCommerce is built around that execution layer. It exposes machine-readable commerce APIs for catalog discovery, policy verification, and transaction execution, with built-in ordering and adapters for Zuora, Stripe, Maxio, Orb, and Metronome. Agents and humans can act through the same governed commerce contract instead of maintaining a separate transaction path for every new interface or protocol.

When the agent says yes, the transaction should be real, authorized, and reconcilable—not another ticket in a queue.