What agentic commerce protocols cover from offer to checkout

On this page

Chapter 12 of The Hitchhiker's Guide to the Agentic Economy

Report hub · Previous: discovery, marketplaces and offers · In this chapter: state comparison · components · AE-JOB-001 · Commerce State Contract · Next: payment credentials and settlement

The fragmentation of commercial state

E-commerce protocols are standardizing the mechanics of digital transactions, but they are dividing commercial authority among the platforms that author them.

Protocols like the Universal Commerce Protocol (UCP) and the Agentic Commerce Protocol (ACP) define how an autonomous agent interacts with merchant checkout flows and ingests order status updates (UCP Checkout; UCP Order; ACP OpenAPI). The Agent Payment Protocol (AP2) establishes cryptographic data structures that bind user purchase intent to signed checkout and payment mandates (AP2 specification). The A2A x402 extension links payment metadata to asynchronous task execution (A2A x402 extension), while HTTP payment protocols like x402 and the Machine Payments Protocol (MPP) negotiate challenge-response settlement over digital rails (x402 v2; MPP specifications).

Each specification reflects the operational priorities of the organization that designed it:

• UCP and ACP preserve the merchant's internal database as the authoritative system of record for inventory, pricing, and order lifecycle management.
• AP2 keeps authority with the identity and wallet layer that signs the buyer's purchase mandate.
• Machine payment protocols manage the credential challenge and asset transfer over a designated rail.

None of these protocols define who verifies deliverable quality or who accepts completed work on behalf of the buyer.

The architectural decision is not selecting a single protocol to govern end-to-end commerce. It is determining which protocol component carries the required transaction state, which system retains authoritative truth at each boundary, and how an enterprise reconstructs a complete audit trail when independent systems report conflicting statuses. An authorized checkout is not settled payment. Settled payment is not fulfilled delivery. Fulfilled delivery is not accepted work. Protocol status flags like completed do not bridge those operational boundaries.

Key Takeaways

• ACP, UCP and AP2 solve overlapping but different problems. Treat them as composable components with explicit seams, not interchangeable end-to-end stacks.
• Similar field names do not prove interoperable semantics. Version, actor, signature, identifier, update rule and authoritative owner all matter.
• Repricing, escalation, lost completion responses, partial fulfilment and cancellation expose the boundary faster than a clean checkout demo.
• Protocol completion, payment settlement, delivery and buyer acceptance are separate evidence states. Keep them separate in the job record.
• Before enabling an agent purchase, map every native protocol state to one Commercial Job Record and make unknown, disputed and residual-effect states visible.

Commercial modes and protocol selection

Before selecting protocol components, an organization must define its operational purchasing mode:

Commercial transaction mode	Primary protocol composition	What the composition standardizes	Requirements external to protocol	Market implementation status
Attended consumer purchase	UCP or ACP checkout, AP2 signed mandates, tokenized card/wallet credentials	Itemized shopping cart, user checkout approval, merchant order lifecycle	Sponsoring buyer identity, post-purchase dispute arbitration, deliverable acceptance	Specified developer documentation; broad merchant and consumer adoption unmeasured
Unattended bounded purchase	AP2 human-not-present mandate or account debit agreement (PayTo) with merchant checkout	Explicit spending ceilings, merchant whitelisting, time limits, and material change rules	Deterministic policy enforcement, revocation propagation, deliverable inspection, and refund paths	AP2 and PayTo specifications published; enforcement must be verified directly at the merchant resource
First machine-to-machine call	x402 exact or MPP charge over digital payment rails	Real-time resource quotation, HTTP 402 challenge, cryptographic receipt	Enterprise budget tracking, service quality inspection, deliverable acceptance, and recurring accounts	Protocol specifications and developer implementations published; production enterprise volume unmeasured
Variable metered service	x402 upto or batch schemes, MPP authorize, or account-level billing	Pre-authorized financial caps for variable or high-frequency machine calls	Meter verification, duplicate action suppression, statutory tax invoicing, and dispute channels	Scheme documentation published; actual enterprise billing integration remains route-specific
Recurring enterprise trade	Existing vendor accounts, master service agreements, purchase orders, Peppol eInvoicing	Standardized order intake and durable supplier identifiers	Corporate counterparty verification, tax compliance, delivery acceptance, three-way ERP matching	Traditional B2B procurement rails established; autonomous agent integration requires custom engineering
Australian domestic B2B	PayTo real-time debit agreements paired with Peppol structured eInvoicing	Enforceable domestic banking mandates and standardized, machine-readable tax invoices	Agent ordering authority, statutory GST compliance, delivery acceptance, and dispute recourse	Scheme documentation published; end-to-end autonomous agent execution remains experimental

The commercial transaction lifecycle progresses across seven distinct phases:

offer and commercial terms
  -> buyer authority and policy
  -> checkout and order state
  -> payment hand-off (Chapter 13)
  -> fulfilment and acceptance
  -> invoice, ledger and reconciliation
  -> cancellation, remedy and repeat or exit

When an individual protocol component addresses only a subset of these transitions, the preceding and subsequent hand-offs must be explicitly managed by enterprise systems of record.

Mapping commercial state across protocols

Protocol evaluation begins by analyzing which operational states each standard natively supports:

Commerce protocol state comparison:
  - UCP: Native catalog discovery, cart creation, merchant order objects, fulfillment tracking, and post-purchase adjustments. Mandate authority is mapped externally.
  - ACP: Merchant-owned checkout sessions, order completion, and signed order webhook updates. Discovery and post-purchase dispute handling sit externally.
  - AP2: Cryptographic Intent, Checkout, and Payment mandates. Cart state, order management, and fulfillment tracking sit externally.
  - A2A x402: Links payment metadata and receipts to asynchronous task execution. Order state and deliverable acceptance sit externally.
  - x402 / MPP: HTTP challenge-response settlement over digital rails. Catalog, order, fulfillment, and acceptance sit externally.

State comparison matrix

Protocol component	Discovery & catalog	Cart & checkout	Mandate & authority	Order management	Fulfillment tracking	Post-purchase & disputes
UCP	Native business profiles and capability discovery	Native checkout creation, itemized updates, and completion	Delegated to external payment handlers or identity vaults	Native order objects with checkout_id and line-item history	Native fulfillment tracking expectations and webhook events	Native return, refund, and adjustment schemas; legal enforceability and acceptance sit externally
ACP	Experimental discovery in development branches	Native merchant checkout sessions (create, get, update, complete, cancel)	External; stable ACP specifications do not define buyer mandates	Checkout completion returns order; signed webhooks deliver async updates	Asynchronous order status webhooks report fulfillment updates	No native return, tax, or fraud dispute handling; seller policy controls remediation
AP2 (v0.2)	Outside protocol scope	Standardized checkout representation binds to mandate digests	Native signed Intent, Checkout Mandate, and Payment Mandate payloads	Digest can bind to external order ID; AP2 does not manage orders	Outside protocol scope	Signed Payment Receipts provide audit evidence; delivery and dispute resolution sit externally
A2A x402	Outside extension scope	Outside extension scope	Payment metadata attaches to task parameters	Task maintains state while downstream services execute	Tasks link payment receipts to task execution via taskId	Task and payment statuses remain decoupled; deliverable acceptance sits externally
x402 / MPP	External directory	Invocable during checkout	Payment challenges and signed authorization payloads	No native order state management	No native fulfillment verification	Method-specific refunds; lacks standardized deliverable acceptance

No single protocol covers the full commercial lifecycle from initial offer to accepted business outcome. UCP defines a broad order and adjustment schema; ACP establishes a clean merchant-owned checkout boundary; AP2 provides cryptographic proof of buyer authority; machine payment protocols settle asset transfers over HTTP. Robust commerce architectures compose these components across explicit system boundaries.

The canonical commercial state chain

Enterprise systems manage commerce across ten primary business states and eight exception paths:

offer_available -> quoted -> authority_pending -> authorised
  -> checkout_formed -> order_formed -> payment_boundary
  -> fulfilled -> accepted

side paths: repriced | escalated | cancellation_requested
  -> cancellation_acknowledged -> cancelled_or_residual_effect
  -> adjusted | returned | refunded | disputed | outcome_unknown
  -> reconciled -> repeated_or_exited

Every state transition requires an explicit record: initiating actor, correlation ID, schema version, timestamp, and authoritative system of record:

• Offer and authority: What deliverable was promised, at what price, with what expiration deadline, and which human principal authorized the expenditure?
• Checkout and order: Which cart digest was authorized, what items changed, and which merchant system created the binding order?
• Payment boundary: Which payment attempt links to this specific task? Settlement finality and dispute resolution are governed downstream in Chapter 13.
• Fulfillment and acceptance: What artifact or physical shipment was delivered, when, and which human reviewer or automated rule verified that it met contractual acceptance criteria?
• Change and cancellation: What modification was requested, what processes were halted, what financial or operational side-effects occurred, and how are ledger accounts reconciled?

When systems use identical words to represent different operational milestones, enterprise ledgers must preserve native distinctions. In UCP, completed checkout status confirms that the merchant accepted the order for processing; it does not confirm payment settlement or customer acceptance. In ACP, completing checkout creates a merchant order, but post-purchase support and tax calculations are managed outside the protocol. In AP2, a signed Payment Receipt confirms that payment was authorized against a specific digest; it does not prove that the purchased service was delivered or fit for purpose.

Component evaluation across the commerce stack

Evaluating commerce infrastructure requires distinguishing between component capabilities:

Component standard	Documented native capability	Operational boundary and external dependencies
Universal Commerce Protocol (UCP)	Merchant business profiles, checkout creation, line-item adjustments, and order objects (UCP Checkout; UCP Order)	Specification documents protocol semantics; repository release tags and live site documentation show differing dates; payment settlement, deliverable acceptance, and legal dispute recourse remain external
Agentic Commerce Protocol (ACP)	Merchant checkout session management and signed asynchronous order update webhooks (OpenAPI; webhooks)	Stable specification (2026-04-17) defines merchant checkout; payment processing, tax calculation, inventory allocation, and customer acceptance remain managed by the merchant's ERP
Agent Payment Protocol (AP2)	Cryptographic Intent, Checkout, and Payment mandates binding user authority to specific transactions (v0.2 specification)	Binds intent and authority parameters; product catalogs, checkout APIs, physical settlement rails, fulfillment tracking, and dispute arbitration sit externally
x402 v2 & MPP	Machine-readable HTTP 402 payment requirements, cryptographic payloads, and settlement receipts (x402 v2; payment identifier; MPP; HTTP draft)	Standardizes request-time payment exchange; MPP remains an active IETF draft; product catalogs, commercial invoicing, and customer acceptance sit externally
Payment Networks & Card Schemes	Scoped virtual card tokens, network agent credentials, and fraud risk signals (Stripe Link CLI; seller SPT; Visa Trusted Agent; Mastercard Agent Pay; Mastercard Australian activity; PayPal Agent Ready)	Extends existing card acquiring and settlement rails; provides established chargeback protections; does not manage non-payment business task logic or deliverable verification
PayTo & Peppol Frameworks	Enforceable Australian bank debit agreements and structured eInvoicing document exchange (PayTo; ATO eInvoicing; Stripe Invoicing; Stripe bank transfer reconciliation)	Standardizes domestic banking mandates and tax compliance; does not automate agent task selection, delivery acceptance, or cross-border trade

The interoperability ladder

Evaluating integration claims across vendors requires climbing an empirical verification ladder:

similar field names in documentation
  -> explicitly mapped data schemas
  -> implemented software adapter
  -> passing automated conformance test suite
  -> independently verified end-to-end production transaction

Asserting that a system "supports UCP" or is "AP2-compatible" indicates developer documentation. Verifying interoperability requires proving that the same customer intent, merchant identity, line-item pricing, order ID, payment reference, and deliverable acceptance persist across system boundaries without state corruption.

Four operational seams require explicit engineering controls:

1. Discovery to offer: A directory listing or A2A Agent Card advertises capability. It does not prove that the endpoint is currently available, eligible for the buyer, or bound to the legal seller the agent intends to purchase from. Real-time runtime quotes must always supersede cached directory metadata.
2. Attended to unattended authority: AP2 distinguishes between human-present and human-not-present execution modes, while systems like Stripe Link and PayTo maintain distinct approval agreements. Granting an agent a payment credential does not confer authority to select suppliers, alter purchase quantities, or sign off on deliverable acceptance.
3. Checkout to payment: UCP and ACP form and track commercial orders while independent payment gateways, token vaults, or crypto rails execute settlement. An authorized checkout session must never be recorded as settled balance-sheet funds until payment clearing is confirmed.
4. Fulfillment to acceptance: UCP order webhooks and merchant fulfillment notices confirm that an order was dispatched or an API response was returned. They do not confirm that the customer accepted the work. Returns, refunds, credits, and dispute arbitrations operate across merchant terms and financial rail rules, requiring explicit cross-referencing in the central job ledger.

Applied walkthrough: procuring AE-JOB-001 with repricing and cancellation

The reference competitor briefing (AE-JOB-001) illustrates the operational failure modes encountered when an autonomous purchasing run deviates from the happy path.

Task context: An Australian advisory firm authorizes an autonomous agent to procure a competitor briefing from an external specialist service, enforcing a maximum budget of A$25 for external research inputs and establishing explicit quality criteria for acceptance.

Dynamic quotation and authority binding

The agent begins with a verified discovery record, querying the vendor's endpoint for a binding, real-time quote. It records the vendor identity, output schema version, line-item pricing, delivery turnaround (one business day), and cancellation terms under a unique offer_id.

The enterprise policy engine evaluates the quote against the buyer's mandate. AP2 represents this authority as a cryptographically signed checkout digest binding the approved price, supplier account, and task ID. The mandate establishes the legal and financial boundary within which the agent is authorized to transact.

Managing checkout across UCP and ACP routes

• UCP route: The agent discovers the merchant's business profile, creates a checkout session, verifies line-item prices, and monitors checkout status. If the merchant returns complete_in_progress, the agent pauses execution and polls the existing checkout ID; it does not issue a second completion request, which could trigger duplicate orders (UCP Checkout).
• ACP route: The agent establishes a checkout session with the merchant, submitting payment tokens upon completion. ACP returns a confirmed order object, while signed order_update webhooks provide asynchronous fulfillment updates (ACP OpenAPI). The agent logs the order ID, treating the merchant database as the authoritative record for fulfillment.

The repricing boundary

Suppose the supplier alters its pricing, introduces additional data licensing fees, or adjusts delivery deadlines between the initial quote and final checkout completion.

The agent recalculates the checkout digest and compares it against the signed AP2 mandate. Because the new price exceeds the authorized ceiling, the existing mandate is automatically invalidated. The system enforces three deterministic options:

1. Halt execution, generate a revised checkout digest, and request manual human approval before proceeding.
2. Request an automated cart update to strip optional items and bring total expenditure back within the authorized ceiling.
3. Terminate checkout and log that the transaction was aborted due to unauthorized price modification.

Re-submitting an altered order using an outdated authority digest represents a critical failure of enterprise governance.

The cancellation state machine

Cancellation in automated commerce is a multi-stage operational progression, not a binary switch:

cancellation_requested
  -> cancellation_acknowledged
  -> execution_halted
  -> no_effect_confirmed OR residual_effect_reconciled

• If cancellation is requested before the merchant confirms the order, the checkout session is terminated cleanly.
• If cancellation races with order creation during complete_in_progress, the client must query the merchant order API to determine which state committed first.
• If cancellation is transmitted after the merchant begins fulfillment or calls external paid APIs, the seller's commercial terms govern cancellation fees, partial refunds, or rework credits.

A status of cancelled does not mean zero compute was burned or zero financial liabilities were incurred. The enterprise ledger must capture the exact operational state, reconcile expended funds, and assign a human owner to manage residual liabilities.

Fulfillment and acceptance verification

Upon delivery, the agent logs delivery_id, output schema hashes, and delivery timestamps. Automated validation checks confirm that all five named competitors are analyzed and primary source citations are present.

However, formal business acceptance remains open until an internal human analyst reviews the research deliverable. Protocol completion confirms that the seller transmitted data; business acceptance confirms that the deliverable satisfied contractual specifications.

The Commerce State Contract

Production commerce requires an explicit operational contract governing transactions from quote to reconciliation:

Contract section	Operational parameters captured	Authoritative system of record
Job identification	job_id, purchasing principal, vendor legal entity, business objective, and regulatory jurisdiction	Central Commercial Job Record (Sponsoring Business Unit)
Offer snapshot	offer_id, canonical endpoint, schema version, line items, quoted price, currency, spend ceiling, and expiration	Discovery and Offer Record (Supplier Quoting API)
Authority mandate	Principal ID, agent ID, spending limits, permitted price variance, parameter digest, and expiration	Enterprise Policy Engine (AP2 Mandate / IAM Policy)
Checkout state	checkout_id, protocol version, merchant ID, line-item changes, and status history	Merchant Checkout System (UCP / ACP Gateway)
Order record	order_id, linked checkout ID, merchant order status, fulfillment webhooks, and tracking IDs	Merchant Order Management System (Merchant ERP)
Payment boundary	payment_id, payment method, authorization hold ID, settlement rail reference, and transaction hash	Payment Gateway / Clearing House (Chapter 13 Ledger)
Fulfillment & acceptance	delivery_id, artifact SHA-256 hash, delivery timestamp, inspection sign-off, and acceptance_id	Supplier Delivery System & Buyer Acceptance Authority
Change & cancellation	Parameter diffs, cancellation requests, stop acknowledgments, and residual liability records	Merchant Order System & Corporate Dispute Queue
Reconciliation & ledger	Purchase order ID, invoice ID, tax matching (GST/VAT), currency conversion, and GL account codes	Enterprise General Ledger (ERP Accounts Payable)

When data conflicts occur, systems must log outcome_unknown, assign an accountable human owner, and enforce explicit resolution deadlines rather than defaulting to assumptions of failure or success.

Conformance test fixtures for unattended execution

Before certifying an agent system for unattended commercial purchasing, organizations execute six mandatory test fixtures:

Conformance test scenario	Required authoritative evidence	Mandatory failure condition
Standard completion	Buyer authority digest, merchant checkout ID, order ID, payment reference, and separate acceptance sign-off	Transaction IDs or authorization parameters change without linking events
Dynamic price modification	Explicit before/after parameter diff; execution halts until a new authority mandate is signed	Stale authority mandate is reused after line-item prices increase
Dropped connection timeout	System queries existing checkout/order IDs by stable key before attempting retries	System blindly issues duplicate order or duplicate payment charge
Cancellation race condition	Merchant records verify whether cancellation succeeded before order creation committed	System assumes cancellation was successful without verifying merchant state
Defective deliverable delivery	Fulfillment record logs delivery; business acceptance remains open pending inspection	Payment authorization automatically triggers business deliverable acceptance
Out-of-order webhook events	Monotonic event sequencing and idempotency keys ensure late callbacks do not regress state	Delayed order update webhook overwrites subsequent cancellation or refund record

Operational failure modes in commercial protocols

Production implementations must defend against five recurring failure modes:

1. Checkout completion without order creation: Systems like UCP decouple checkout completion from asynchronous order processing. When network timeouts occur during complete_in_progress, the client must poll the existing checkout ID; issuing a new checkout creates duplicate orders.
2. Settlement success without deliverable fulfillment: Payment gateways report successful clearing while sub-agent execution fails or outputs fail validation. Financial settlement must never be equated with deliverable fulfillment.
3. Delivered work with unmatched invoices: Software can deliver analytical outputs before asynchronous B2B invoicing completes. Systems must maintain independent states for deliverable acceptance and accounts-payable invoice matching.
4. Simultaneous reprice and cancellation: If a buyer cancels an order at the precise moment a merchant updates pricing, systems require deterministic precedence logic to verify whether the order was legally formed before processing cancellation fees.
5. Specification version drift: Protocols evolve rapidly across active working groups. Documented features in draft specifications (e.g., experimental UCP branches or unreleased ACP endpoints) must not be deployed in production without pinning exact schema hashes and verifying multi-vendor compatibility.

The trajectory of commerce protocols

Commerce protocols will standardize shopping cart data structures, merchant order state machines, and payment authorization challenges. They will not eliminate the need for enterprise systems of record.

Market architecture is establishing a clear division of responsibility:

• Merchant platforms (Shopify, enterprise ERPs) will maintain authoritative order, inventory, and fulfillment records.
• Identity and wallet platforms will maintain cryptographic authority mandates and spending policies.
• Payment rails will execute real-time clearing and settlement.
• Enterprise procurement systems will manage vendor qualification, deliverable acceptance, and tax reconciliation.

Every commercial transaction formed at the checkout boundary ultimately requires financial settlement. Chapter 13 examines the payment layer: comparing virtual cards, bank debit agreements, stablecoin rails, and machine payment protocols, and evaluating the legal recourse that survives each payment route.

Sources and method

• Primary sources: Technical specifications, OpenAPI schemas, and developer documentation from Universal Commerce Protocol (UCP), Agentic Commerce Protocol (ACP), Google Agent Payment Protocol (AP2 v0.2), A2A x402 extension, Model Context Protocol, Coinbase Developer Platform, Stripe, Visa, Mastercard, PayPal, Australian Payments Plus (PayTo), and the Australian Taxation Office (eInvoicing) checked as of 13 September 2026.
• Analytical frameworks: The Canonical Commercial State Chain, the Interoperability Ladder, the Commerce State Contract, and the six-part Conformance Test Matrix are original analytical structures developed to evaluate commercial protocol governance.
• Evidence boundaries: Specifications establish message schemas, state machines, and declared interfaces. Multi-vendor interoperability, checkout completion reliability, and deliverable quality require empirical validation on customer workloads.
• Institutional references: Australian eInvoicing standards and PayTo banking rules provide domestic regulatory context for structured B2B trade.
• Editorial record: Published by Agentic Economy, Perth, Western Australia. Updates and corrections are logged via the editorial record.

Back to the report hub · Previous: discovery, marketplaces and offers · Next: payment credentials and settlement.