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

Our view

Commerce protocols standardise selected transitions, not the complete commercial relationship. UCP and ACP give a merchant and an agent documented ways to represent checkout and order state. AP2 binds a represented purchase to signed intent, checkout and payment mandates. A2A's x402 extension can carry payment events alongside an asynchronous task. x402 and MPP carry payment challenges or receipts, but they do not become a catalogue, an order system or an acceptance record by doing so. (UCP Checkout, UCP Order, ACP checkout specification, AP2 v0.2, A2A x402 extension)

No protocol currently “owns” agentic commerce. Each component carries a different state, hands authority to another system and leaves a different reconstruction problem when records disagree. A completed checkout is not necessarily settled payment. Settled payment is not delivered work. Delivered work is not accepted work. A protocol field called success cannot erase those distinctions.

Key Takeaways

• ACP, UCP and AP2 solve overlapping but different problems. They are 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 commercial states in the job record.
• A reliable agent purchase maps every native protocol state to one Commercial Job Record and keeps unknown, disputed and residual-effect states visible.

This chapter uses versioned specifications and official provider documentation checked on 13 September 2026. UCP's live specification pages and repository release information identify different dates, ACP's stable materials sit beside unreleased work on main, and MPP remains an active Internet-Draft rather than a finished IETF standard. Those are current evidence conditions, not editorial inconveniences.

Sources and scope

Agentic Economy compared the official UCP and ACP specifications and repositories, AP2's v0.2 specification, the A2A x402 extension, and adjacent payment and recognition documentation named in the Part III research pack. We did not create an account, fund a wallet, place an order or run a cross-provider conformance test for this chapter. The public UCP playground was inspected as a sandbox path; that establishes an observable simulation, not a funded merchant transaction or customer demand. Capability records below establish documented supply, reported programme activity or an observed public sandbox according to the label shown. They do not establish adoption, reliability, legal effect or interoperability. About Agentic Economy explains the publication. Contact us through the contact page to submit a correction.

Protocols are dividing the commerce state

The market is not converging on one end-to-end agentic commerce protocol. It is producing components around different parts of the transaction. UCP and ACP centre merchant checkout and order interaction. AP2 centres signed intent and mandate evidence. x402 and MPP centre request-time payment. Card networks and payment providers are adapting credentials and transaction signals. Existing ERP, invoicing and bank systems continue to hold longer-lived commercial records.

This division reflects the positions of the companies building the protocols. Merchants retain their order systems. Agent platforms want portable ways to request and update checkout. Payment providers extend existing acceptance and settlement networks. Enterprise systems preserve supplier, invoice and accounting state.

Stripe's case for ACP is blunt: “The AI economy needs standardized infrastructure to flourish” (Stripe, "Developing an open standard for agentic commerce"). The market agrees on the fragmentation problem. It has not agreed that checkout, mandate, payment, fulfilment and post-purchase state belong in one protocol or under one commercial owner.

Our view is that composition will matter more than protocol dominance. The most important interfaces will be the hand-offs between authority, checkout, payment, fulfilment and post-purchase state.

The protocols cover different commerce states

The most useful comparison starts with the state a buyer or merchant must be able to prove. The figure is a compact visual map. Filled cells represent native documented coverage in the source set; outlined cells represent optional, external or mapped coverage; blank cells mean unsupported or not established. A blank is evidence discipline, not a prediction that no implementation could ever add the state.

Commerce protocol is a shared message and state contract for selected buyer, seller or platform interactions. Checkout state is the merchant-owned representation of a purchase as it is formed and completed. Mandate is evidence of bounded intent or authority represented for another system to verify. Order state means the seller's record of what was placed and how it changes; it does not mean payment settled or work was accepted.

Accessible state table

Component	Discovery	Cart or checkout	Mandate or approval	Order	Fulfilment	Post-purchase
UCP	Native in the cited specification: business profile and capability discovery	Native in the cited specification: create, update and complete states	Payment handler and buyer input are separate; authority is mapped or external	Native in the cited specification: order object with checkout_id, line items and adjustments	The specification describes fulfilment expectations and events	The specification describes adjustment examples, including return/refund/dispute states; implementation, funding, enforceability, acceptance and legal remedy remain unverified
ACP	Discovery and feed work on main is unreleased; not stable chapter scope	Stable merchant-owned create/get/update/complete/cancel checkout	External or composed authority; stable ACP does not define a mandate	Complete creates an order and returns checkout plus order	Signed order webhooks provide asynchronous order updates	No general stable return, tax, fraud or acceptance contract; seller policy and other systems remain required
AP2	Outside AP2's current scope	Checkout representation is supplied by a commerce protocol	Native signed Intent, Checkout Mandate and Payment Mandate	Checkout digest can bind the order representation; AP2 does not define order APIs	Outside AP2's current scope	Receipts provide evidence; delivery, acceptance and dispute retrieval are outside current scope
A2A x402 extension	Outside the payment extension	Outside the extension	Payment metadata can accompany a task; buyer policy is external	Task can remain working while an artefact is generated	taskId and append-only receipt history link payment to the task	Task and payment terminal states remain distinct; return, acceptance and remedy are external
x402 / MPP / card, bank and recognition components	Usually addressed by the seller or a separate directory	May be invoked by a checkout; not an order model	Payment requirement, token, mandate or recognition signal, depending on component	No general order state in the payment handshake	Not established by payment success	Method/provider refund, dispute or invoice processes; no common acceptance state

The table is a documentation taxonomy, not conformance or deployed-coverage evidence. It answers the primary question directly: there is useful overlap, but no current source in the reviewed set establishes one interoperable state model from offer through accepted work. In the versions reviewed, UCP documents the widest order and adjustment surface; that says nothing about seller implementation quality or buyer fit. ACP is a narrower merchant-owned checkout boundary. AP2 adds signed authority and evidence rather than a catalogue or checkout API. The adjacent components attach a credential, mandate, recognition signal or payment receipt to the path. They do not silently fill the blank cells.

The canonical state chain

Business states sit above provider-specific statuses. The following chain is an Agentic Economy editorial model for the job record, not a protocol standard:

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

Each transition needs an issuer, identifier, version or digest, timestamp, source and owner. “Payment boundary” is intentionally a hand-off to Chapter 13: this chapter records where a credential or payment attempt attaches to the order, while the payment record owns initiation, settlement, refund and dispute details.

At minimum, the record answers these questions at each point:

• Offer and authority: what was offered, by whom, at what price and expiry, and who authorised which seller, purpose, amount and time?
• Checkout and order: which cart or checkout version was represented, what changed, and which merchant system created the order?
• Payment boundary: which payment attempt is attached to this job? Settlement, refund and dispute remain in Chapter 13.
• Fulfilment and acceptance: what was delivered, when and in which version, and which person or deterministic test accepted or rejected it?
• Change, cancellation and reconciliation: what was requested, what actually stopped, what residual effect remains, and can finance match every order, attempt, adjustment and invoice?

Unknown is a valid value for any answer. An unresolved state carries its identifier, source, owner and deadline rather than a guessed value.

The distinction matters when systems use the same word differently. UCP's completed checkout state means the business reports that the order was placed; it is not a settlement or acceptance state. UCP's complete_in_progress can contain no order, so a lost response cannot justify a second completion. ACP's Complete creates an order in its stable specification, but its merchant-owned checkout boundary does not supply general acceptance. An AP2 Payment Receipt proves signed payment evidence, not a delivered result. An A2A x402 Task may stay working after payment while an artefact is generated. (UCP Checkout, ACP OpenAPI, AP2 specification, A2A x402 specification)

Compare components before brands

The following is a market map of protocol components and adjoining systems. A component is a bounded capability with a native object, actor responsibility and evidence boundary. It is not a claim that the publisher offers the whole commercial stack.

Component	Native in the cited source	Evidence status and what remains outside
UCP	Business profile, checkout, order, fulfilment events, adjustments and payment-handler negotiation (Checkout, Order)	Specified. Live pages identify 2026-08-25 while repository release information exposes 2026-04-08; pin before use. Settlement, acceptance, legal relationship and implementation coverage remain outside.
ACP	Merchant create/retrieve/update/complete/cancel checkout plus signed order webhooks (OpenAPI, webhooks)	Specified, stable 2026-04-17. Unreleased main work is excluded. PSP settlement, returns, tax, fraud, acceptance and finance reconciliation remain outside.
AP2	Signed intent, checkout and payment mandates and receipts (v0.2)	Specified. It binds represented constraints; catalogue, checkout API, rail settlement, delivery, acceptance and legal effect remain outside.
A2A x402	Payment metadata and append-only receipts within an asynchronous Task (v0.1)	Specified. taskId correlates task and payment; examples use legacy x402 v1 fields. General order, acceptance, recurring terms and current v2 compatibility remain unverified.
x402 v2 / MPP	HTTP payment requirement, credential/payload, receipt and method-specific intent (x402 v2, payment identifier, MPP, HTTP draft)	Specified; MPP remains draft. Exact/upto/batch or charge/subscription semantics do not supply catalogue, order, delivery, acceptance, invoice or universal remedy.
Provider/network components	Link/SPT approval or credential state; Visa/Mastercard recognition and credential signals; PayPal handlers (Stripe Link CLI, seller SPT, Visa, Mastercard, PayPal)	Provider-documented or reported; availability varies. These are not a neutral wallet, order/acceptance model or adoption evidence. Mastercard's Australian activity is a vendor-reported controlled trial.
PayTo / Peppol	Australian debit-agreement controls and structured business documents (PayTo, ATO eInvoicing)	Scheme/government documented. Access depends on participating institutions; neither supplies agent-order authority, job settlement, delivery acceptance or a universal cross-border route.

The table is a source taxonomy. Composition requires an implemented adapter, pinned versions and the failure fixtures below; documentation alone does not establish interoperability.

Interoperability has a ladder

Interoperability claims fall into a five-step ladder:

similar fields
  -> explicitly mapped fields
  -> implemented adapter
  -> conformance-tested path
  -> independently observed end-to-end job

“Supports UCP”, “AP2-compatible” or “accepts x402” can describe a documented capability without proving the next rung. The test must preserve the same buyer intent, seller identity, amount, line items, order ID, payment reference, delivery result and acceptance decision across the hand-offs. It must also show what happens when a field changes or a callback disappears.

Four seams deserve special attention:

1. Discovery to offer. For example, a UCP profile or ACP endpoint can describe a capability. It does not prove the endpoint is reachable, current, eligible for the buyer or bound to the seller the agent thinks it is buying from. A live runtime quote supersedes stale directory metadata.
2. Human-present to human-not-present authority. AP2 distinguishes the two modes and binds constraints, while Link, SPT and PayTo expose their own approval or agreement rules. A payment credential is not automatically permission to choose the supplier, vary the scope or accept the result.
3. Checkout to payment. UCP and ACP can form or complete an order boundary while a separate handler, token, mandate or rail processes payment. A credential being approved or a checkout being completed must not be recorded as settled funds.
4. Order to fulfilment and remedy. For instance, UCP has fulfilment expectations/events and order adjustments; ACP webhooks report order changes. Neither source establishes a general buyer acceptance test. Returns, refunds, disputes, credits and cancellation may be merchant or rail-specific, so the job record must retain the cross-reference.

The merchant's role is important here. UCP and ACP both preserve a seller-side system of record. That protects merchant control over catalogue, pricing, inventory, tax or order operations where the implementation supports them. It also means a platform cannot promise a buyer that a checkout transcript alone is the authoritative order. Retrieve the merchant state by the stable ID, preserve every update and ask the merchant which event is final for the specific operation.

AE-JOB-001: a briefing that is repriced and cancelled

This is an Agentic Economy proposal, not an observed transaction. It instantiates one Commercial Job Record across the chapter boundary. An Australian business buyer asks an agent to buy a bounded competitor briefing from a candidate supplier with identity evidence for the proposed fixture; no live supplier was verified. The supplier may be global. The output has a versioned schema, a delivery window and an acceptance test. The amount, currency or asset are quoted at runtime and are not invented here.

The initial offer

The agent begins with a discovery record from Chapter 11, then fetches the supplier's live quote. It records the supplier, capability version, output, line items, price basis, currency or asset, expiry, delivery, acceptance and cancellation/refund terms under offer_id, quote time and source. A listing is neither an order nor permission to spend.

The buyer policy might permit one briefing for one named company within a maximum amount and short time window, while requiring approval for material change. AP2 can represent signed constraints and a checkout digest; it does not decide whether the organisation permits the purchase. The policy and mandate sit beside the merchant checkout.

A UCP route

For a structured path, the agent discovers the seller profile, creates a checkout, records line items and waits for a completion-permitting status. It compares the current total and material terms with the approved quote and mandate, then completes once under checkout_id.

If the seller reports complete_in_progress, an absent order is not failure: retrieve the existing checkout and order and wait for the merchant result. A timeout after acceptance follows the same rule. Resolve the original attempt before creating another checkout or payment. (UCP Checkout)

An ACP route

Where the supplier wants its own cart, tax, payment and order systems authoritative, the agent uses the stable ACP create/get/update/complete/cancel session. Complete with payment data creates and returns an order; signed order_create and order_update webhooks carry later changes. Retain IDs, exact version and events, but do not call the response settlement or acceptance.

The stable ACP contract leaves PSP authorisation/capture, returns/exchanges, tax and fraud to the merchant or adjoining systems. A supplier may provide them around ACP; they are not supplied by the checkout contract. (ACP OpenAPI, ACP webhook OpenAPI)

The reprice edge

Suppose the supplier changes scope, line item, tax, delivery promise, currency, asset or total after the initial quote. The agent compares the new representation with the approved quote and mandate. A material change invalidates prior approval unless the authority permits it. The branches are:

• obtain a new approval or mandate over the new checkout digest, then continue;
• reduce the order back to the approved representation, if the merchant supports that update; or
• stop and request cancellation, recording that the purchase was not authorised at the new amount or scope.

UCP line-item/total history and an AP2 checkout representation provide comparison evidence; the application must enforce rejection. ACP Update carries the new state, but buyer policy decides approval. Retain a field diff even when the total is unchanged: supplier, data scope, delivery and acceptance terms can be material.

The cancellation edge

Cancellation has a ladder, not one Boolean:

requested -> acknowledged -> execution_stopped
  -> no_effect_confirmed
  |-> residual_effect_present -> reconciled_or_compensated

Before an order exists, checkout cancellation may close it. During complete_in_progress, cancellation can race with order creation, so retrieve the original state. After an order exists, the seller's cancellation, return, refund or adjustment policy controls the result. ACP cancel is not a universal return contract; UCP adjustments do not remove merchant responsibility.

If cancellation arrives after work starts, record work performed, delivery, acceptance, credit/refund or rework route and residual-obligation owner. “Cancelled” does not mean no data, payment attempt or supplier work existed.

Fulfilment, acceptance and payment hand-off

On delivery, store delivery_id, output schema/version, content hash, timestamp and fulfilment event. A deterministic check can test required sections and sources; the buyer or acceptance system decides whether the briefing is fit. Protocol completion does not substitute for acceptance.

Payment belongs in the linked Payment and Settlement Record. Reference payment_id, attempt and method without rewriting it. A pending or ambiguous payment leaves the job outcome_unknown; settled-but-late or rejected work can remain settled and rejected until remedy closes. job_id joins records without collapsing states.

The Commerce State Contract

The Commerce State Contract is an Agentic Economy editorial proposal, not a standard, certification or substitute for a merchant's legal, accounting or operational records. It is a linked view of one Commercial Job Record. The merchant or service system remains authoritative for its native order state; the buyer's policy system remains authoritative for approval; the payment system owns payment and settlement; the acceptance owner decides whether the delivered result meets the job's promise.

The contract carries the following minimum fields:

Contract section	Required fields	Authoritative owner and evidence
Job identity	job_id, buyer and supplier, purpose, owners, consequence, jurisdiction	Commercial Job Record and accountable owner
Offer snapshot	offer_id, endpoint, capability/schema version, lines, quote, currency/asset, expiry, delivery, acceptance, remedy terms and source	Discovery and Offer Record; provider response and checked time
Authority	Principal, agent, policy, approval/mandate ID, seller/resource, purpose, cap, time, permitted changes, digest, expiry and revocation	Buyer policy system; approval or signed mandate and evaluation
Checkout	checkout_id/cart_id, protocol/version, merchant, status history, request IDs, line/total diff, escalation events	UCP, ACP or merchant checkout and exported events
Order	order_id, checkout link, merchant system, lines, fulfilment expectations and webhook/event IDs	Merchant order retrieval and signed updates
Payment boundary	payment_id, method/mandate, presented amount/asset and attempt link to Chapter 13	Provider, bank, facilitator or wallet; do not copy settlement into checkout
Fulfilment and acceptance	delivery_id, output/shipment hash/version, time, partial state; criteria, acceptance_id, decision and rework/rejection	Supplier delivery evidence plus buyer or deterministic acceptance owner
Change and cancellation	Diff/materiality decision, request/acknowledgement, stop result, residual effect, return/refund/credit/dispute IDs and case owner	Merchant, buyer policy and remedy owner; append-only transitions
Reconciliation and lifecycle	Invoice/PO/contract, payment/ledger/tax/FX match, attempts, fees, adjustments, exceptions, source/version, retention, repeat or exit	Finance owner and each linked source record; declared matching rule

The contract also states what it does not know. If a seller webhook is late, payment is settlement_pending, an order ID is missing after a completion timeout, or a cancellation may have raced with fulfilment, the state remains outcome_unknown with a reconciliation owner and deadline. Missing evidence does not become failed, cancelled or accepted by default.

Minimum conformance fixture before unattended use

This is an unexecuted test contract for one exact implementation, not evidence that UCP, ACP, AP2 or a payment handler interoperates in production. The contract pins the seller endpoint, protocol release or commit, payment-handler version, schema hash and terms version. For AE-JOB-001, the fixture covers:

Case	Expected authoritative evidence	Fail closed when
Normal completion	Buyer authority digest, merchant checkout and order IDs, one payment reference, delivery and separate acceptance	Any ID or owner changes without a linked event
Material reprice	Exact before/after diff and a new approval or mandate before completion	Old authority is silently reused
Lost completion response	Retrieve the original checkout/order by stable ID before any retry	Order existence remains unknown or a second effect cannot be excluded
Cancellation race	Merchant records whether cancellation won, order formed or fulfilment began; residual payment/work is reconciled	cancelled is written from intent alone
Partial or rejected delivery	Delivery remains distinct from buyer acceptance; correction/refund owner and deadline open	Payment or fulfilment auto-writes accepted
Duplicate or out-of-order event	One logical effect, append-only attempts and deterministic event folding	A late webhook can recreate or regress the business state

The merchant system owns order existence and fulfilment. The buyer policy system owns authority. The payment provider owns its authorisation and settlement evidence. The named reviewer owns acceptance. The Commercial Job Record stores their identifiers and precedence; it does not overwrite their native records. These cases define the boundary between a documented route and one demonstrated for unattended use in a safe test environment.

The enforcement test must reach the receiving resource. A policy record or signed mandate is insufficient if the seller/resource never validates its scope, expiry, nonce and revocation state. The fixture therefore includes revoked/expired authority, payee substitution, replay, out-of-order events, abnormal velocity, prohibited data and a complaint/refund hand-off where relevant. Passing the happy path does not establish fraud control, legal authority, consumer understanding or interoperability.

Proposed invariants

These are AE operating controls, not claims about any named protocol:

1. Every checkout/order transition references one job_id, accepted offer representation and current authority decision.
2. Every retry declares whether it retrieves, resumes or creates an attempt; a new attempt passes an idempotency and duplicate-order check.
3. A material change to supplier, resource, amount, asset, delivery or acceptance invalidates old approval unless policy permits it.
4. Checkout, order, payment, delivery and acceptance statuses remain distinct; native states are preserved and mapped into the AE vocabulary.
5. Cancellation, refund, return, dispute and rework append evidence. The job reaches reconciled only when authority, order, payment, delivery, acceptance and finance match under a declared rule.

The hardest cases are state disagreement

The clean path is easy to diagram. Operating risk appears when two systems report different truths.

“Completed” checkout, no order

UCP explicitly distinguishes complete_in_progress from a completed checkout and may return no order while the merchant processes completion. A client or webhook can disappear at exactly that boundary. Resolution depends on the existing checkout, merchant order and matching payment attempts; an empty first response does not establish that a second order is safe.

Payment success, no accepted work

The payment path can report success while the order is still processing, the A2A task remains working, or the artefact fails its acceptance test. The Commerce State Contract records the payment reference and holds acceptance open. For a stablecoin or other method without a card-style dispute path, the remedy must be declared before enabling the route. This is a Chapter 13 decision, not a reason to mislabel payment as delivery.

Delivered output, unpaid or unmatched invoice

A supplier may deliver before an asynchronous payment or invoice match is visible. Delivery and finance therefore remain independent states. Peppol can carry an order, despatch advice, invoice and invoice response; Stripe can retain invoice and balance-transaction records. Those document or payment states still need the job, supplier and acceptance cross-reference. (ATO eInvoicing, Stripe invoice lifecycle, Stripe bank-transfer reconciliation)

Reprice and cancel at the same time

If the buyer rejects a new price while the merchant is completing the old checkout, the application needs a deterministic precedence rule. The merchant state and authority digest establish whether the old order formed. If it did, cancellation or remedy follows the merchant's order policy; if it did not, the checkout closes with the repriced version recorded as lacking authority. A late cancellation request is a state transition to investigate, not evidence that the supplier did nothing.

Version disagreement

UCP's live page date and repository release date differ in the source set. ACP's stable 2026-04-17 materials sit beside unreleased main work. The A2A x402 extension's examples use x402 v1 fields while core x402 is v2. Pin the source page, repository commit, schema hash and advertised implementation version. Do not label a path interoperable until the exact versions have passed a shared fixture and failure test.

What the market has not resolved

The emerging protocols overlap without sharing one authoritative order, payment or fulfilment record. Similar objects do not yet amount to interchangeable implementations. Version drift, merchant ownership and provider-specific extensions remain part of the market.

We expect protocols to converge first on common representations of offers, carts, mandates and orders. Post-purchase service, delivery acceptance, disputes and enterprise reconciliation will remain harder because those states cross organisational and institutional boundaries.

What the sources establish

Evidence in the reviewed source set	It establishes	It does not establish
Versioned UCP, ACP, AP2 or A2A specification	The stated message shapes, roles and native states for that version	That implementations are compatible, deployed or commercially adopted
UCP public playground	An observable public simulation of documented steps	A live merchant, funded payment, production conformance or demand
ACP stable OpenAPI and signed webhook materials	A documented merchant-owned checkout/order boundary and event types	PSP settlement, tax/fraud, returns, acceptance or finance reconciliation
AP2 v0.2	Signed intent, checkout/payment mandate and receipt semantics	Legal authority, payment finality, delivery, acceptance or an automated dispute institution
x402/MPP documentation	Payment challenge, payload, receipt or method-specific intent patterns	Buyer policy, product quality, order, acceptance, invoice or universal remedy
Link/SPT, Visa, Mastercard or PayPal documentation	Provider/scheme routes that attach credentials, recognition or handlers to some commerce paths	Australian eligibility for every buyer, universal merchant coverage or independent adoption
PayTo and Peppol documentation	Australian debit-agreement controls and structured business-document exchange	Agent ordering authority, settlement for a particular job, delivery acceptance or cross-border portability
This chapter's Commerce State Contract	A proposed joined record and operating controls	A standard, certification, legal opinion or proof that a provider implements it

The research also has practical limits. We did not execute a paid job, test a live seller, compare two implementations, measure failure rates or collect a denominator for active buyers, repeat orders or accepted work. Vendor announcements and partner lists are reported supply evidence. They do not establish adoption. Product pages, repositories and drafts can change after the checked date. Australian applicability depends on buyer, seller, bank, sponsor, access point, currency, tax and contractual circumstances; the presence of PayTo or Peppol documentation does not fill those gaps.

Unresolved market questions

Six developments would materially change our view of the protocol market:

1. End-to-end conformance: independent tests show multiple ACP/UCP/AP2 implementations preserving an immutable representation from offer through authority, order, fulfilment, acceptance and remedy, including material change, partial failure and cancellation.
2. Neutral reconciliation: a widely implemented identifier and event model lets an ERP join authority, order, payment attempts, settlement, invoice, delivery, acceptance and adjustments across card, bank and stablecoin routes without custom reconstruction.
3. Portable delegated authority: a standard supports cross-agent delegation, revocation, policy change and automated retrieval of dispute evidence with clear liability and retention semantics.
4. Method equivalence: MPP or x402 methods provide comparable merchant acceptance, refund/dispute recourse, tax/FX and finance integration across cards, bank rails and stablecoins at repeat-job scale.
5. Observed repeat use: an independent dataset reports buyer type, geography, active accounts, repeat jobs, accepted outputs, failures, refunds and net settlement by protocol and route. SDK downloads and partner counts alone would not be enough.
6. Australian production path: a documented and independently tested route joins agent authority, PayTo or another rail, Peppol order/invoice records, GST data, delivery acceptance and remedy for Australian businesses.

Until then, open questions remain:

• Which source is authoritative when a live protocol page, tagged repository release and implementation schema disagree?
• Who is liable for a repriced or substituted order when the merchant, agent and mandate each preserve a different representation?
• How should a buyer prove acceptance or reject an artefact when a protocol reports fulfilment but has no general acceptance state?
• Can a cancellation signal reliably stop work already queued across a merchant, payment provider and delegated service, and how is residual work reconciled?
• Which conformance tests should be required before a platform describes two components as interoperable?
• What is the smallest evidence bundle a finance or support team needs to resolve a duplicate order, pending settlement or refund/dispute race?

Conclusion and author record

Commerce protocols create value when they preserve a fact that another system can rely on: a checkout representation, an order identifier, a signed mandate, an asynchronous fulfilment event or a payment-to-task correlation. Their value is proportional to the continuity of that fact across the next boundary. Protocol labels matter less than the state path and the system that owns each transition.

The near-term market will form around bounded jobs that preserve offer, authority, checkout, order and payment state through repricing and cancellation. Routes that cannot reconstruct what changed, what was ordered, what was delivered and who owns remedy will remain unsuitable for unattended commerce.

Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking or proof that every listed component has been independently tested.

Previous: discovery, marketplaces and offers · Next: payment credentials and settlement