Key takeaway
These protocols do not cover identical responsibilities. Capability matrices, evidence boundaries, version governance, and pilot acceptance help merchants decide what to integrate first, who implements it, and what remains their responsibility.
From responsibilities to integration decisions
A protocol name is not a procurement answer
Imagine a home-goods merchant with a catalog, order system, and payment provider that wants shoppers to purchase through external agents. A meeting may quickly become a debate over ACP versus UCP, while the real questions are how products are discovered, who calculates quotes, who confirms the purchase, how payment is authorized, and who handles returns. Protocol names do not answer those questions. This is an original selection method using a hypothetical example, not a guarantee of access to any vendor.
Map the current transaction path before adding agent entry points. Keep trusted merchant systems responsible for prices, stock, orders, and payment states. An agent can coordinate calls, but adopting a protocol should not grant it arbitrary authority to change facts. If the team cannot identify the service that owns final order state, resolve internal responsibilities before adapting protocols. A more standardized interface otherwise spreads existing confusion faster.
Establish shared terminology with a short factual baseline
At verification, OpenAI documentation presents ACP as a connection between merchants and agentic commerce experiences. Google’s UCP introduction covers commercial capability discovery, checkout, and orders and describes compatibility with AP2. Google’s AP2 introduction focuses on verifiable user authorization and payment evidence. Their concerns overlap but differ, so they are not three identical checkout buttons. Actual capabilities depend on the adopted version and implementation.
The editorial verification date is September 27, 2026. Google announced on April 28, 2026 that AP2 would move to the FIDO Alliance alongside a version update, so initial governance and capability descriptions should not be treated as permanent. This guide does not predict a winning protocol. Merchants benefit more from establishing what channels and providers support today, what they explicitly commit to, and what testing demonstrates than from treating announcement volume as certainty about the future.
Build the capability matrix around business actions
Make each row an action the merchant needs: discovering variants, checking current stock, quoting delivery, applying discounts, confirming orders, submitting payment, tracking fulfillment, cancellation, or partial refunds. Columns should represent specific entry points and actual integration arrangements rather than abstract protocol names. Distinguish expressible in the specification, implemented by the provider, enabled for the merchant, and passed in testing. A single Supported checkbox cannot represent all four.
Record the responsible service, evidence link, version, region, and exceptions beside each entry. If a specification permits an extension but the target entry point does not enable it, it cannot be part of the launch promise. Conversely, an existing capability might work through a controlled redirect without an immediate rewrite merely to keep every step inside chat. The matrix exposes capabilities and gaps; it should not manufacture an all-green score for a preferred vendor.
Separate an open specification from production admission
A public specification can be read and implemented; it does not mean a consumer platform accepts every merchant, product, or country. Track admission separately, verifying merchant eligibility, product requirements, payment methods, regions, and application steps for the target surface. Record development completion, test passage, and business approval independently. If admission remains unresolved, a homepage or sales presentation should not claim that shoppers can already buy through that surface.
Likewise, a provider’s compatibility statement may cover only part of a protocol. Ask for a mapping to concrete business actions, current documentation or a test environment, and explicit identification of planned features. Phased delivery can be acceptable, but future goals must remain separate from present capabilities. Resolve vague claims by walking through one complete order instead of asking only whether the provider supports agentic commerce.
Assign separate roles to consent evidence, identity, and execution
Evaluate who makes the request, what the shopper permits, and who actually moves funds. Authenticating an agent helps identify the caller but does not by itself establish the shopper’s consent to the present product and amount. A payment token can constrain credential use without proving product delivery. Treating these as one generic trusted-agent certification creates control gaps.
The matrix should show where user intent, cart confirmation, payment restrictions, and order results are stored and who validates them. Define an action for failed validation: stop, obtain confirmation again, or escalate. A language model should not decide whether a signature is sufficiently trustworthy, and missing evidence must not be interpreted as implied permission. Compare evidence completeness, enforced restrictions, and recoverability rather than counting security terminology in a specification.
Choose between direct integration and a provider adapter
Maintaining protocol endpoints directly offers detailed control over state and extensions, but also requires ongoing version management, signature verification, reliability, monitoring, and recovery. A provider adapter may reduce integration work while raising questions about responsibility, synchronization freshness, error visibility, and migration. Decide according to the operations the team can sustain rather than only the code needed for an initial demonstration.
A small team with stable catalog and order systems and narrow initial needs might first evaluate an adapter with clear mappings and observability. A merchant with complex pricing, distributed fulfillment, and stringent internal controls needs deeper verification that the adapter preserves those constraints. Fewer interfaces do not necessarily mean a simpler implementation. In either path, business facts and review records should remain exportable and independently understandable.
Start with a small, recoverable transaction loop
Pilot a product set with clear stock, straightforward delivery, stable pricing, and understandable support rules. Even the smallest loop must include payment failure, cancellation, order lookup, and a workable refund path. Demonstrating a successful purchase alone does not establish production readiness. Limit regions, methods, and products where necessary and explain those limits accurately. Explicit boundaries make capability gaps easier to distinguish from transient failures.
The loop should let a shopper find the order after leaving the agent, support identify its origin, finance associate collection, and the warehouse avoid duplicate fulfillment from repeated notifications. Make these cross-team acceptance criteria. An adapter’s success response proves only that one step returned as expected, not that the entire commercial transaction completed correctly. Pilot evidence should span discovery through support rather than consist only of a smooth demonstration video.
Include version governance in the launch plan
Specifications and platform implementations can evolve. Record the adopted specification and extension versions, processor capabilities, and test date, and keep reproducible contract tests. Before upgrading, identify whether changes concern fields, semantics, states, authentication, or errors. Unchanged field names can still carry changed behavior, so type checks alone cannot establish compatibility.
For an adapter, agreements should identify who tracks upstream changes, notification timing, staged rollout, and rollback. The merchant must still monitor order and funds outcomes because a successful provider upgrade does not prove compatibility with local custom workflows. Apply changes to a restricted test set, compare important actions with the old version, and expand gradually. Emergency rollback must preserve recovery for in-flight transactions instead of simply disabling endpoints and abandoning pending orders.
Test failures inside the protocol adapter
Test recovery after timeout, duplicate order creation, changing stock, expired quotes, withdrawn consent, additional payment verification, partial refunds, and reordered notifications. For each scenario, identify the layer making decisions, the layer preserving facts, and what the agent tells the shopper. If the adapter cannot express an important failure reason, establish a safe fallback rather than converting every error into Try again later.
Verify that agent replanning still references the original purchase intent. Shopping agents are good at trying another route, but a payment system must distinguish recovery of the same operation from a newly authorized transaction. Protocol selection does not replace business idempotency or funds-state management. Report normal and fault-path results together instead of treating a few successful examples as proof of the entire integration.
Include ongoing work in implementation cost
Include catalog preparation, field mapping, payments integration, testing, monitoring, support training, reconciliation, and version maintenance. A low setup price may leave exception handling with the merchant; a long implementation may reflect incomplete existing data. Separate provider fees from internal work and compare within the actual scope rather than using unsourced industry returns instead of a business-specific estimate.
Assess benefits through observable facts such as identifiable new orders, completed transactions, repeat support contacts, and maintenance time. Agent-origin orders are not necessarily incremental; existing customers may merely switch entry points. Use suitable comparisons and phased observation, identifying limited evidence as pilot data. Standardization’s potential benefits deserve evaluation but should not automatically become claims of achieved revenue growth.
Preserve replaceable integration boundaries
Keep internal order, quote, payment, and support models independent of a particular protocol, with explicit boundary mappings. This does not mean erasing every difference. Special capabilities should remain explicit and identify supported entry points. Excessive abstraction reduces useful distinctions to a lowest common denominator, while excessive coupling makes a new entry point disturb the entire backend. An explainable boundary is more useful than a supposedly universal object.
An exit plan should cover exporting order associations, preserving consent evidence, completing pending refunds, and preventing duplicate intake during transition. Do not wait for a vendor change to discover that historical orders are searchable only in its interface. A maintainable solution admits new entry points while allowing old ones to stop new transactions and finish existing obligations. Verify this during procurement and acceptance rather than relegating it to future operations work.
Give decision-makers a reviewable one-page recommendation
Summarize the priority entry point, initial product scope, required protocol capabilities, implementation owners, verified conditions, and unresolved gaps. Link every recommendation to matrix evidence instead of relying only on a claim about future potential. A second-phase plan can coexist, but its future capabilities should not enter the launch promise. Decision-makers should see exactly what scope they approve and what would pause or reopen the decision.
A sound recommendation includes uncertainty: unresolved admission, an unconfirmed payment method, or support requiring human handling. Explicit gaps help the team schedule concrete work. Protocol selection should produce an executable, verifiable, recoverable path rather than merely an acronym. Evidence and versions will need updates as the market changes, while responsibility-based decomposition and full-transaction acceptance remain a reusable merchant method.
Evaluate evidence quality and commercial interests
Vendor white papers, official specifications, and merchant tests answer different questions. A white paper explains design goals, a specification defines interface agreements, and testing establishes behavior in a particular environment. Record publisher, date, version, and whether a source is a self-reported case. A partner named in an announcement does not necessarily provide complete capability in the merchant’s target region, and marketing figures for network reach are not actual agent-transaction coverage.
Preserve the self-reported status of performance, conversion, or fraud figures that cannot be independently verified, recording whether sample definitions and methods are available. They can motivate pilot questions but should not become promised returns. Editorial updates should retain the time boundaries of earlier judgments and explain changes supported by new evidence, preventing historical pilot conditions from being mistaken for universal current availability.
FAQ
- Does adopting UCP remove the need to consider AP2 or a payment provider?
- Evaluate the actual responsibilities. Commerce interfaces, consent evidence, and funds execution are different concerns. Check how the implementation connects them rather than assuming one protocol name completes the chain.
- Does an open protocol let a merchant sell immediately on every AI platform?
- No. Specification support, platform implementation, merchant admission, product eligibility, and regional availability are separate conditions. Verify each surface and test the experience before claiming support.
- Must a small team build every protocol endpoint itself?
- Not necessarily. Evaluate provider adapters while establishing data, exception, version, and exit responsibilities. Less initial code does not eliminate ongoing work; choose a scope the team can maintain.
Sources & further reading
- Key concepts – Agentic Commerce · OpenAI
- Under the Hood: Universal Commerce Protocol (UCP) · Google
- Powering AI commerce with the new Agent Payments Protocol (AP2) · Google Cloud
- Google donates Agent Payments Protocol to FIDO Alliance · Google
AI-assisted original research. Scenarios are hypothetical; rely on the primary sources listed for facts. Not investment or legal advice.