Google's Agent Payments Protocol, AP2, now has more than sixty launch partners including Mastercard, PayPal, Coinbase, American Express and Salesforce, and in May the FIDO Alliance folded it in alongside Mastercard's own approach. But AP2 is not the only standard agents will need to speak. Stripe and OpenAI have built their own competing protocol, ACP, the Agentic Commerce Protocol, and Stripe has separately said it will support AP2 itself on the payment rail side. The pitch behind all of them is similar: let an AI agent transact on a person's or organisation's behalf, with a verifiable record proving the transaction was actually authorised. The part getting far less attention is what it actually takes to wire any of this into an enterprise that already has a functioning procurement system, an ERP platform and a payment card compliance programme it cannot simply switch off.
AP2 is open source and, as of the most recent reporting, still only deployed in production by Google itself, even with the launch partner list attached. ACP sits in a similar position, live but early, backed by two of the most consequential companies in payments and AI respectively. That gap between announced partnership and mature, live deployment is where the real work sits, and it is not a protocol problem. It is an integration problem, the same category of problem that has quietly determined which AI initiatives actually ship and which stall in the demo stage.
What AP2 Actually Solves
AP2 gives an AI agent a standard way to prove it was authorised to spend, using a cryptographic mandate that ties a transaction back to explicit user or organisational consent. That solves a real problem. Without something like it, letting an agent make a purchase, a payment or a booking on an organisation's behalf is either manually gated at every step, which defeats the purpose of automation, or ungoverned, which is a compliance and fraud exposure most finance teams will not accept. AP2 is one of the first serious, multi-vendor attempts at closing that gap.
AP2 Is Not the Only Standard in the Race
Stripe closed a deal in August to acquire OpenRouter, the AI model routing platform, for more than seven billion dollars, a move that has little directly to do with agent payments but says a great deal about how seriously Stripe is treating AI infrastructure as core to its future rather than an adjacent bet. More directly relevant to this specific problem, Stripe and OpenAI have built ACP, a separate standard for agent led commerce, while Stripe has also said it will support AP2 on the rail side. A third variant, an x402 extension for crypto payments backed by Google, Coinbase and MetaMask, is live as well. None of this is settled. Enterprises evaluating agent payments today are not choosing between one live standard and a wait and see approach. They are choosing between at least two live, well backed standards that solve a similar problem in different ways, with a reasonable chance a merchant will eventually need to support more than one.
Where the Integration Work Actually Sits
None of that changes what has to happen inside an enterprise's existing technology estate, regardless of which specific protocol, or protocols, an organisation ends up supporting. Payment workflows are already deeply embedded in procurement systems, ERP platforms and supply chain tooling, built up over years and rarely documented as cleanly as anyone would like. Wiring an agent payment mandate into that environment means middleware to translate between the protocol and whatever the ERP actually expects, an orchestration layer to decide when an agent is even allowed to initiate a payment flow, and a governance layer to log and review what agents are actually doing with that authority. None of that ships with any protocol. All of it has to be built.
The Compliance Layer No Protocol Replaces
Neither AP2 nor ACP make PCI-DSS obligations disappear, and neither resolves data residency requirements or financial crime monitoring on its own. An agent transacting under either protocol's mandate is still moving cardholder or payment data through systems that carry the same compliance obligations they always did. Treating either as a payments integration project without also treating it as a compliance project is the mistake most likely to turn a promising pilot into an incident.
Why Enterprises Should Not Wait for a Perfect Standard
There is a temptation to wait until AP2, ACP or whichever standard eventually wins out becomes the clear default before doing any integration work. That is a reasonable instinct for the protocol layer itself, though with two well backed standards live simultaneously, waiting for a single winner may mean waiting for quite a while. It is a poor instinct for the underlying integration architecture regardless, because the actual hard part, the middleware, the orchestration logic, the governance and audit layer, has to exist regardless of which specific payment protocol, or combination of protocols, an organisation eventually supports. Building that foundation now, in a way that treats the protocol as a pluggable layer rather than a hard dependency, means an organisation is not starting from zero whichever standard, or standards, win.
What This Means for Your Organisation
What we see across implementation engagements is that organisations chasing the protocol conversation, which standard, which vendor, which launch partner, are usually the ones furthest behind on the integration conversation that actually determines whether agentic commerce ever reaches production. With two credible standards now live at once, that protocol conversation has become even less useful to spend time on. The orchestration, governance and legacy system integration work underneath either of them is where the actual project lives, and it is where most timelines quietly blow out.
Key Takeaways
- Google's AP2 has more than sixty launch partners, but it now sits alongside a competing standard, ACP, built by Stripe and OpenAI, with Stripe also separately supporting AP2 as a payment rail, meaning enterprises face at least two live protocols rather than one.
- Both protocols solve the authorisation problem, proving an agent had consent to transact, but neither removes the need for middleware, orchestration and governance layers to connect that authority into existing ERP and procurement systems.
- PCI-DSS, data residency and financial crime monitoring obligations still apply in full to any transaction under either protocol's mandate, meaning this is a compliance project as much as an integration one.
- Building the orchestration and governance layer as protocol agnostic infrastructure now avoids rebuilding it later regardless of which standard, or standards, become the eventual default.
Frequently Asked Questions
What is the Agent Payments Protocol (AP2)?
AP2 is an open standard, created by Google, that lets an AI agent make a payment or transaction on a user's or organisation's behalf, backed by a cryptographic mandate that proves the transaction was authorised.
Is AP2 the only agent payments protocol enterprises need to know about?
No. Stripe and OpenAI have built a separate standard called ACP, and Stripe has also said it will support AP2 as a payment rail. A crypto focused extension, x402, backed by Google, Coinbase and MetaMask, is live as well. Enterprises should expect to potentially support more than one protocol rather than assume a single standard will win outright.
Do AP2 or ACP replace the need for PCI-DSS compliance?
No. Both address transaction authorisation, not payment card data handling. Existing PCI-DSS, data residency and financial crime monitoring obligations apply in full to any transaction an agent initiates under either protocol's mandate.
How Trusenta Can Help
AI Integration Services builds the middleware and orchestration layer that connects emerging agent protocols, including AP2 and ACP, into existing ERP, procurement and payment systems without a future rebuild.
Custom AI Development designs the governance and audit layer that logs and reviews agent initiated transactions, keeping the compliance obligations neither protocol resolves firmly in view.
AI Agents and Automation builds the agents themselves with payment initiation treated as a governed capability from the first deployment, not a later addon.
Conclusion
AP2 and ACP are both genuine steps toward agents that can transact with real accountability behind them, and the fact that two well resourced camps are building competing versions of the same idea makes clear the payments industry is taking this seriously from more than one direction. What neither has done, and was never going to do, is remove the integration work that determines whether any of this reaches an enterprise's actual production systems. Organisations that start that integration and governance work now, treating the specific protocol, or protocols, as replaceable, will be ready regardless of which standard, or standards, win the argument.
