The best, and perhaps only, operable protocol that can solve agent payment issues today.

Stripe’s Agentic Commerce Protocol (ACP), co-developed with OpenAI, is a functional leap forward in enabling agentic commerce. While its open-source nature invites broad adoption, Stripe is uniquely able to “make it work” by leveraging its existing fraud-fighting assets. Another less reported benefit of ACP is payment rail agnostic operation. ACP will work for paybybank, PIX, EFTPOS, Swish, Bizum or anything else. Anywhere that Stipe’s device graph and Radar (Risk/Fraud) are effective. Stripe’s secure payment token plus risk signals allow merchants to operate the way they do today (no operational change).

ACP may only have a limited 2-3 yr runway as more advanced authentication methods become mainstream, and network rule sets/services advance to serve all agent providers (leveling the playing field).

OpenAI, Shopify, Stripe – A Symbiotic Solution

It is impossible to assess Stripe’s ACP in a vacuum. Its brilliance lies in solving the final, crucial step in a longer value chain. Shopify’s pioneering integration with OpenAI’s ChatGPT brought merchant products into the conversational AI space, solving the “discovery” and “selection” problems. However, the “purchase” step remained a point of friction and security risk. Stripe’s ACP directly addresses this payment challenge, effectively completing the loop and making seamless agentic commerce a reality. This symbiotic relationship, where each platform leverages its strengths, has been crucial in solving the overarching problem.

ACP – Open Protocol – Leveraging Stripe’s Strengths

While ACP is an open standard, its true efficacy is unlocked by Stripe’s tightly integrated ecosystem. The protocol’s success is a synergistic combination of four key elements:

• The Shared Payment Token (SPT): Rather than adopt new network agentic tokens, Stripe has expanded their own tokenization services to provide finer grained tokens (limited by time, amount, merchant). These Stripe tokens are mapped to network token services (Visa’s VTS, Mastercard’s MDES). Stripe took this approach because they wanted to leverage their own device graph and risk signals integrated uniquely into SPT. Thus Issuers see a network token with enhanced transaction data (flowing either within the transaction, or within the Stripe Issuer network) to support enhanced authorization and support 3DS like decisioning by Issuer ACS server. My belief is that Stripe wants to continue to expand support of the Issuer network data flow. 
• The Device Graph: Stripe’s vast device graph fingerprints and tracks devices across its global network, providing a critical layer of passive authentication to verify the transaction’s origin.
• The Risk Management Engine (Radar): Stripe’s machine learning engine ingests signals from the SPT and device graph, alongside billions of other data points, to assess risk in real-time (across all Stripe clients globally). Note that both the device graph and risk management engine will provide information needed by Stripe enterprise customers to process agentic transactions (with SPT), replacing device data. I see this as expanding the stripe issuer network to also support merhchants (who own the risk in eCommerce transactions – US)
• NO CHANGE to merchant fraud systems or existing operations. Where Agents obscure consumer device data, Stripe replaces it. This stands in contrast to other options like Google AP2.

A Pragmatic Approach: Comparing ACP to Google’s A2P

When compared to alternatives like Google’s Agent-to-Processor (A2P) protocol, ACP’s strategic advantages become even clearer, particularly in operations and authentication.

1. Authentication and Trust: Google’s A2P protocol provides a sound approach for  authentication of the cart and payment, but as I discussed in Google AP2 blog, authentication must exist in a governance framework where legal liability (and economics) can be assessed. The heart of A2P is adoption of W3C’s Verifiable Credentials. I strongly support VC, but it will take 5+ years for the industry to adopt, and 10+ years to integrate into existing governance structures. Functionally, AP2 assertions will be unusable as card networks must have control over how authentication and credentials operate. Thus, Google AP2 will operate primarily within the Google domain. This domain includes merchants where it is the trusted party (data exchange and cart assertions) but not in payments with defined governance. Stripe’s ACP, by contrast, cleverly leverages existing, bank-recognized payment credentials via network tokens and layers its proprietary risk signals on top. This approach works with the existing financial infrastructure, rather than trying to create a new, unproven layer of trust.
2. Operational Impact on Merchants: Stripe’s ACP is designed for minimal disruption. Its fraud signals provide the necessary data for merchants to assess the transaction as if it came directly from the consumer’s device. This allows them to integrate agentic commerce into their current operational and risk-management flows with little friction. Google’s A2P, will be operable for all agentic flows except for card payments, as its authentication model requires card network integration. I see A2P as something created by the Google Cloud team (internal use within Google’s ecosystem) which will manage intent and baskets among various agents that operate on different data sets. Because of card dependencies, initial pilots will process payments either through Paypal (see recent PYPL/Goog Agentic Partnership) or Stablecoin. While Braintree provides the “Stripe Side” equivalent in payment, the Shopify side is missing. Thru I predict Google will partner with Woo Commerce, Big Commerce or similar Shopify competitor. 

ACP will work best in the US

ACP’s design is optimally suited for the United States market, where merchants typically bear the financial risk for fraudulent card-not-present transactions. This incentivizes the adoption of sophisticated, data-driven fraud tools (like Stripe’s), which manage risk without the conversion-killing friction of active customer challenges like 3D Secure (3DS), a common requirement for liability shift in other regions.

In my view Stripe’s ACP is the most pragmatic and broadly operable protocol for agentic commerce today. It is a brilliant piece of transitional technology. However, the very foundation of its advanced risk assessment (the device graph) may have a limited lifespan of 2-3 years.

The future of online authentication is moving swiftly towards stronger, user-centric models like FIDO-based payment passkeys. As passkeys become ubiquitous, they will provide direct, cryptographic proof of the user’s identity within existing governance structures (ie V/MA/Amex), rendering the need to infer trust from a device’s history obsolete. This will create a more seamless customer experience and drive higher authorization rates.  It will be authentication plus governance (ex DAF/TAF rulesets) that will radically transform payments for both consumer in the loop and agent-agent/API interactions. My top company in this space is LoginID.

Side note: Yes PayPal could recognize Google’s authentication, and PayPal can own the risk on the transaction as the merchant of record (ie branded), or allow the merchant to own the risk (ie Braintree enterprise). Also Google could work to expand the use of DPANs as in their SPA effort. 

Because it works today, I see ACP gaining adoption quickly. All wallets will be moving quickly to integrate to it. My top recommendation for Stripe (to drive further adoption) is to build economics for participants aligned to your objectives.