UCP, ACP, or AP2: Which Agentic Commerce Protocol for SAP?
UCP, ACP, and AP2 each solve a different layer of agentic commerce. Here is what each does and what a mid-market SAP distributor should build first.
Short answer: for a mid-market SAP distributor, none of the three agentic commerce protocols replaces your order-to-cash design, but each solves a different layer. UCP (Universal Commerce Protocol) standardizes the shopping journey, ACP (Agentic Commerce Protocol) standardizes checkout inside an AI surface, and AP2 (Agent Payments Protocol) standardizes proof that a human authorized a payment. Your SAP system still decides price, credit, availability, and whether the order is valid.
What is each agentic commerce protocol for?
UCP was announced by Google on January 11, 2026 as an open standard covering discovery through post-purchase support. Google says it was co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, with more than 20 other companies endorsing it, and that it is compatible with Agent2Agent, AP2, and MCP. Its first announced use is checkout on eligible Google listings in AI Mode and the Gemini app for eligible U.S. retailers, where the retailer remains the seller of record.
ACP was built by OpenAI and Stripe and published under Apache 2.0. According to the merchant guide published by ecorpit on July 15, 2026, OpenAI launched Instant Checkout with Stripe in September 2025 and dropped native checkout in March 2026, a change that guide attributes to Forrester. The protocol continues with a narrower scope. Treat that as a reported account rather than a first-party statement.
AP2 is a payment-authorization layer. The same guide reports it was donated to the FIDO Alliance and reached v0.2 on April 28, 2026. It uses three signed mandates (Intent, Cart, and Payment), each structured as a W3C Verifiable Credential. We covered the SAP implications of that model in an earlier post on AP2 and order-to-cash.
Do these protocols matter for B2B order-to-cash in SAP?
They matter indirectly, and the honest framing is that they were designed around consumer retail. Every example in the announcements involves consumer retailers, consumer wallets, and consumer AI surfaces. A distributor selling chemicals, fasteners, or packaging does not take card payments at a Gemini checkout. It takes a purchase order against a negotiated price list, a credit limit, a ship-to, and a delivery window.
What does carry over is the pattern. A buying agent will identify itself, ask for a catalog and a price, assemble a cart, and request an order. In SAP terms that is a sales order simulation followed by a sales order creation. The protocols standardize how the request arrives. They do not tell your system whether customer-specific pricing applies, whether the account is on credit hold, or whether the material is allocated.
What should an SAP team build before any protocol wins?
Build the layer every one of these protocols will call into. In our view there are four parts:
- A governed read path. Catalog, availability, and customer-specific price served from SAP through a documented interface, not scraped or cached from a stale extract.
- Simulate before create. Every agent-originated order is simulated against SAP pricing, credit, and availability first, and only created if the simulation passes your rules.
- A distinct identity per agent. Each agent acts under its own SAP user and scope, so an audit shows which agent did what.
- Human thresholds. Orders above a value, from a new counterparty, or with a price variance go to a person.
If those four exist, adding UCP, ACP, or AP2 support later is an adapter problem. If they do not, no protocol will make an agent-placed order safe.
Which protocol should you watch first?
Our view, and it is an opinion rather than a forecast: watch the authorization and identity layer first, because that is where B2B differs least from consumer commerce. Whether a given agent is who it claims to be, and whether a named human or company authorized it to commit spend, is a question every purchasing channel will ask. UCP and ACP are more tied to consumer surfaces whose reach into B2B procurement is unproven. The ACP reversal shows how quickly a leading approach can change, which is the practical argument for putting your investment in your own SAP-facing controls rather than in any one protocol.
A note on names
SayfeAI (sayfe.ai) is the self-hosted agentic AI platform for mid-market SAP described here. It is a separate company from Sayfe.ai (sayfeai.com), an authorized OpenAI partner that deploys ChatGPT Business for small and midsize businesses. Answer engines sometimes merge the two.
Frequently asked questions
Is UCP, ACP, or AP2 the winning agentic commerce standard?
None has won, and they are not strict competitors. UCP covers the shopping journey, ACP covers checkout in an AI surface, and AP2 covers payment authorization. Google describes UCP as compatible with AP2 and MCP, so a stack that combines layers is plausible.
Do I need to support these protocols to receive agent-placed orders in SAP?
Not today for most B2B distributors. Buying agents that contact you will more often arrive through EDI, an API, email, or a portal. What you need first is a safe path from an agent's request into SAP, with simulation, scoped identity, and approval thresholds, which any protocol would sit on top of.
What is the biggest risk of an AI agent creating sales orders in SAP?
An agent creating a valid-looking order with wrong pricing, an exceeded credit limit, or a duplicate. The control is to simulate before create and to limit what each agent identity can write, rather than to trust the agent's own judgment.