Agent Payments Protocol (AP2): What It Proves—and What It Doesn't

The Agent Payments Protocol (AP2) is an open protocol for securely authorizing payments initiated by AI agents. It uses cryptographically signed records, called mandates, to connect a user’s instructions with a purchase and its payment authorization. For finance leaders, its value is evidence: what an agent was permitted to buy, what transaction followed, and how those records connect.

AP2 is not a bank account, a settlement rail, or a replacement for accounts payable controls. A transaction can have valid authorization evidence and still be an unnecessary purchase, a duplicate expense, or a policy violation. The practical question is therefore not simply whether a provider supports AP2, but which facts that support lets your finance team verify.

What AP2 changes about agent-led payments

Traditional checkout generally assumes a person is selecting goods and authorizing payment. An agent separates those actions: a person may delegate a task, while software later chooses the item, interacts with the merchant, and initiates payment.

In its September 2025 announcement, Google framed AP2 around authorization, authenticity, and accountability. The protocol is intended to make delegated purchase authority verifiable across participating systems rather than leaving it inside a chat transcript.

That distinction matters. “The user asked me to buy this” is a model-generated assertion. A signed mandate provides evidence that a particular authorization was issued and has not been altered, subject to trustworthy identity binding, key management, and verification.

On April 28, 2026, Google announced AP2’s contribution to the FIDO Alliance and the release of version 0.2, including updates for human-not-present payments. FIDO separately described standards work drawing on AP2 and Mastercard’s Verifiable Intent. These developments indicate continuing standardization—not universal production support or a completed allocation of commercial liability.

How AP2 mandates connect intent to payment

The AP2 specification describes mandate-based flows for agent-mediated transactions. Finance teams should understand the distinct purposes of intent, cart, and payment records, while checking the exact schema and supported flow in their provider’s implementation.

Intent: what the agent may do

An Intent Mandate captures purchase instructions and constraints, especially when the user will not be present at checkout. It establishes the boundaries of delegated authority rather than giving an agent unrestricted permission to spend.

For an enterprise implementation, ask which constraints are machine-enforceable: permitted merchant, product, amount, currency, validity period, or payment instrument. Do not assume a condition expressed in natural language becomes an enforced protocol field.

Cart: what is actually being purchased

A Cart Mandate records the concrete purchase. In a human-present flow, it captures the user’s explicit authorization of a specific cart, including its items and price.

The operational question is whether approval remains bound to the final checkout. A changed price, substituted product, or added subscription must not inherit approval merely because the original cart was acceptable.

Payment: what the payment ecosystem receives

A Payment Mandate provides payment-facing authorization context, including agent involvement and whether the user is present. This helps distinguish an agent-mediated payment from an ordinary checkout.

It does not mean every processor, network, or issuer receives or evaluates identical information. Ask what reaches each participant, what is verified, and what happens when required evidence is missing.

What the protocol proves—and what remains outside it

Evaluate AP2 as an authorization evidence layer. The following is a finance control map, not a claim that every implementation exposes all these checks.

A valid signature is not a complete control conclusion. The signer may lack authority for that legal entity. A permitted merchant may sell an unapproved product. An authorized purchase may duplicate an existing order.

Your spend and payment approval policies must therefore remain authoritative. AP2 evidence should connect to those policies, not silently replace them.

Where AP2 fits in the finance stack

AP2 concerns payment authorization and trust. MCP connects agents to tools and context; A2A supports interaction between agents. Neither makes a payment properly authorized by itself, and AP2 does not move funds merely because a mandate exists.

Likewise, protocol-level ambitions for cards, bank transfers, wallets, or digital currencies do not establish operational availability. Verify the supported payment method, merchant integration, jurisdiction, currency, and transaction flow with the actual provider.

Do not assume merchant-purchase support extends to invoice bill pay, recurring obligations, supplier payouts, or transfers between financial accounts. Each requires explicit confirmation. Cross-border purchasing also retains its ordinary tax, sanctions, authentication, and payment-method requirements.

Agent identities, wallets, and spending controls are another layer. Our guide to how AI agents get wallets and spend limits explains that infrastructure. AP2 addresses the related but different question of how delegated purchase authority travels between participants.

Hypothetical example: purchasing approved software capacity

Consider a company allowing an agent to purchase additional software capacity from an existing approved supplier when an operational trigger occurs. This is an illustrative design, not a claim about a deployed integration.

1. Establish corporate authority. The budget owner approves a bounded purchase policy. Finance records the legal entity, permitted product, commercial conditions, and expiry.
2. Translate permission into supported constraints. The implementation creates the applicable mandate and separately enforces any corporate conditions the protocol cannot express.
3. Validate the proposed checkout. The system checks the final product, supplier, total cost, currency, and contract implications against that permission.
4. Stop material changes. A different supplier, new recurring commitment, or out-of-policy cart goes back to a human approver.
5. Connect payment to accounting. Retain the authorization records alongside the order, processor reference, invoice, service confirmation, and ledger entry.

The subtle failure case is a purchase that stays inside the spending cap but changes the commitment. A small initial payment might start an unwanted subscription. An amount limit alone does not authorize contract terms.

Where human approval still belongs

AP2 does not decide how much autonomy is appropriate. As a starting policy, agents can propose coding, match routine records, and chase missing vendor documents without permission to release money. Automatic posting or purchasing should require explicit, testable conditions.

Keep human approval for exceptions that change authority or exposure: new suppliers, beneficiary changes, ambiguous instructions, altered contractual obligations, and attempts to override failed verification. Materiality thresholds should come from the company’s policy, not the protocol.

AP2 also does not eliminate prompt injection. Manipulated website or document content could steer an agent toward an unwanted but technically permitted purchase. Keep policy enforcement outside the model’s discretionary reasoning, and treat merchant content as transaction data—not permission to expand authority.

An AP2 pilot acceptance checklist

Before allowing live spending, require demonstrations of these controls rather than accepting a general compatibility statement:

• Implementation scope: Document the protocol version, supported mandates, payment methods, merchant connections, and human-present or human-not-present flows.
• Corporate authority: Show how the signing identity maps to an authorized employee or delegated corporate role.
• Constraint enforcement: Distinguish signed constraints, externally enforced rules, and instructions the model merely interprets.
• Negative tests: Reject altered carts, expired permissions, invalid signatures, and mismatched payment details.
• Duplicate and retry handling: Demonstrate that a timeout or replay cannot produce another unintended purchase.
• Revocation: Explain how stopping an agent affects pending authorizations and transactions already submitted.
• Evidence export: Retrieve linked mandate, order, payment, and accounting records without relying on the agent’s narrative.
• Exceptions and disputes: Name the owner for refunds, failed payments, delivery disputes, and evidence submission. Confirm contractual responsibilities separately.

Measure evidence completeness, blocked policy breaches, duplicate prevention, unresolved reconciliation items, and escalation quality. A high autonomous completion rate is not success if finance cannot explain the resulting expenses.

Start with a verifiable purchase, not broad autonomy

AP2’s useful contribution is portable evidence of delegated payment authority. Its limits are equally important: authorization is not business justification, settlement confirmation, compliance clearance, or accounting accuracy.

Select a narrow purchasing workflow and map its approval-to-ledger evidence before integrating a protocol. Payouts.com combines agent identities, wallets, and spend limits with financial operations; its AP automation supports invoice capture, approvals, and payment. Evaluate those operating controls separately from any AP2 integration claim. The goal is not simply to let an agent pay—it is to make every purchase explainable and accountable.

Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.