Agentic Payments Governance: Evaluating AP2 and the Agentic Commerce Protocol

Why agentic payments need a governance framework

As AI agents move from recommending purchases to executing them, enterprises face a specific governance problem: how to authorize, scope, and later verify a transaction that an agent initiated on a human’s behalf. Agentic payments governance refers to the mechanisms that establish who authorized a transaction, what limits applied to it, and what record exists for post-transaction review.

In September 2025, two open protocols were published to address this gap. Google introduced the Agent Payments Protocol (AP2), built on its existing Agent2Agent and Model Context Protocol frameworks and developed with more than 60 partner organizations. OpenAI and Stripe jointly published the Agentic Commerce Protocol (ACP), scoped to checkout flows initiated from conversational agent platforms such as ChatGPT. Both protocols address authorization and identity, but they take structurally different approaches, and neither was designed as a complete governance solution on its own.

AP2: mandate-based authorization

AP2’s core mechanism is the Mandate, a cryptographically signed, tamper-evident object that records a user’s authorization for a transaction. AP2 distinguishes between an Intent Mandate, used when a human is not present at the moment of purchase and the agent operates within user-defined constraints, and a Cart Mandate, used to confirm a specific transaction at the point of purchase.

Mandates are structured using the W3C Verifiable Credentials format, which supports a non-repudiable audit trail that can be independently checked after the fact. Because AP2 is built on A2A and MCP, agent identity is inherited from those underlying frameworks rather than defined natively at the payment layer. This design separates what a user authorized from what an agent actually executed, creating a discrete artifact that a compliance reviewer can inspect independently of the transaction record itself.

Google describes AP2 as payment-method agnostic, intended to extend across card networks, bank transfers, and additional rails, including a crypto-oriented extension referenced in partner communications but not fully detailed in public specifications.

Agentic Commerce Protocol: token-based delegation

ACP takes a different approach, centering governance on the payment credential rather than a separate signed consent record. Stripe’s implementation uses a Shared Payment Token that tokenizes a buyer’s payment credential and delegates it to a merchant or platform for a single transaction, so the agent never handles raw card data directly.

ACP’s specification covers product feed formatting, checkout session initiation, and order and payment delegation between merchants and agentic platforms. It launched alongside ChatGPT’s Instant Checkout feature with a limited set of merchant integrations. Unlike AP2, which is designed for broader agent-to-agent negotiation, ACP is scoped primarily to merchant-checkout flows initiated from a single conversational platform. Authorization in ACP is tied to the payment-session token itself rather than to an independently verifiable consent artifact, which shapes how traceability and reconciliation work after the transaction completes.

AP2 and ACP compared on governance mechanics

The table below summarizes how the two protocols differ on the dimensions that matter most for enterprise control and auditability.

Audit trails and compliance reconciliation

Post-transaction traceability differs in kind between the two protocols, not just in degree. AP2 produces a cryptographically verifiable consent artifact that can be checked against the Mandate independently of any single processor’s records. ACP ties traceability to the payment processor’s transaction records, since authorization is embedded in the token rather than expressed as a separate signed document.

In practice, an ACP-based deployment may require separate reconciliation between the agent platform, the merchant, and the payment processor to reconstruct a full audit picture. Neither protocol’s public documentation specifies a standardized enterprise-grade audit reporting format. Enterprises evaluating either standard should treat the mandate or token record as raw evidence, not a finished compliance report, and validate it against internal requirements such as SOX or PCI DSS rather than assuming compliance readiness by default.

Governance gaps enterprises must close

Both protocols address authorization and identity at the transaction-artifact level, but neither specifies a real-time monitoring or anomaly-detection layer. Least-privilege enforcement, such as per-transaction spend caps or merchant allowlists, is conceptually supported by AP2’s Intent Mandate constraints and ACP’s token scoping, but it is not automatically enforced without additional policy configuration from the implementing organization.

Revocation and expiration handling for mandates or tokens is also not guaranteed to terminate stale authorizations automatically. This is where runtime governance becomes necessary regardless of which protocol an enterprise adopts. Capabilities such as agent identity verification, permission scoping, tool approval workflows, and audit logging need to operate independently of the payment protocol itself, so that spend limits, revocation, and anomaly monitoring are enforced at runtime rather than assumed from the authorization artifact alone.

Evaluation criteria before adopting either protocol

Use the following questions when assessing readiness for production agent-initiated payments:

• How does the protocol cryptographically bind a specific authorization to a specific agent, user, and transaction scope?
• What mechanisms exist to revoke or expire an agent’s payment authorization mid-session, and how quickly does revocation propagate?
• What audit artifacts does the protocol generate natively, and do they satisfy existing compliance requirements without additional tooling?
• Which payment processors or platforms have production-grade support for this protocol today, and what integration effort is required?
• What runtime controls, such as spend limits, anomaly detection, or human review, must be built separately since the protocol does not enforce them?