Agent Payments Protocol (AP2): What It Proves—and What It Doesn't
AP2 makes an agent’s payment authority verifiable. It does not establish that a purchase is necessary, compliant, or correctly accounted for. Here is how finance teams should evaluate the difference.
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.
| Evidence or event | What it can establish | What finance must still establish |
|---|---|---|
| Verified mandate signature | Integrity and signing identity | Signer’s corporate approval authority |
| Intent constraints | Scope of delegated permission | Budget availability and business need |
| Authorized cart | Approved purchase details | Procurement compliance and tax treatment |
| Payment-facing mandate | Agent and authorization context | Processor acceptance and applicable rules |
| Linked mandate records | Traceable authorization sequence | Delivery, settlement, and ledger matching |
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.
- Establish corporate authority. The budget owner approves a bounded purchase policy. Finance records the legal entity, permitted product, commercial conditions, and expiry.
- Translate permission into supported constraints. The implementation creates the applicable mandate and separately enforces any corporate conditions the protocol cannot express.
- Validate the proposed checkout. The system checks the final product, supplier, total cost, currency, and contract implications against that permission.
- Stop material changes. A different supplier, new recurring commitment, or out-of-policy cart goes back to a human approver.
- 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.
Discussion
32 commentsRelated resources
How AI Agents Get Wallets and Spend Limits: A Finance Leader's Guide
AI agents can now hold funds, initiate payments, and operate within defined spend limits — but what does that actually mean for financial controls? Here's how the plumbing works and what finance leaders need to think through before deploying autonomous money movement.
Mastercard and PayPal Agentic AI Payments: The AP Gap
Mastercard and PayPal are building infrastructure for AI-initiated checkout. For finance leaders, the critical distinction is between permission to transact and approval to spend company money.
QuickBooks AI Invoice Generator: From Draft to Ledger
QuickBooks offers several AI-assisted invoicing routes, but generating a document is not the same as recording a receivable. Here is how to choose a workflow and control what happens next.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The finance control map table is useful but I think it undersells the operational burden. You're not just checking these things once—you're building processes to continuously verify signer authority, reconcile mandate chains against settlements, and enforce policy layers that AP2 can't see. That's a significant lift for teams that are already stretched on AP automation.
Agreed, and the continuous verification piece gets worse if you're managing multiple legal entities or subsidiaries. We're looking at AP2 now and the question isn't just whether someone had authority when they signed, but whether that authority applies to the right cost center, entity, and approval matrix—none of which the protocol tracks for you.
The part about not assuming natural language constraints become enforced protocol fields is critical. We've had vendor demos where the agent 'understands' budget limits but those limits weren't actually in the intent mandate schema—just prompt text. That's not a control, that's a suggestion.
This happened to us during a proof of concept. The agent would verbally acknowledge budget caps and even repeat them back in the UI, but when we inspected the actual intent mandate it was just merchant and validity period. The constraints were living entirely in context window, which means they reset or drift depending on the session.
We caught the same thing in our eval. The sales team kept saying the agent 'respects' spend limits but when we dug into the actual mandate spec they were using, the amount cap was validated client-side in their UI, not in the signed intent. That fails the moment a different client or API call is involved.
The mandate chain logic makes sense in theory but I'm not clear on what happens when the payment method changes between cart and settlement. If the agent switches from a corporate card to ACH after cart approval, does that invalidate the mandate or does the payment mandate just reference a different instrument?
The payment mandate should bind to the actual settlement method, not just what was in the cart. If your implementation doesn't re-verify the mandate when the method changes, you've got a gap between authorization evidence and what actually moved money.
Good question. The payment mandate should reference whatever method is actually used at settlement, so a switch would require a new payment mandate signing. If your implementation allows silent method substitution without re-authorization, that's a gap in your approval chain, not an AP2 design issue.
The key line for me is 'a valid signature is not a complete control conclusion.' We're seeing finance teams treat AP2 support as if it solves the entire agent spending problem when it really just gives you a better audit breadcrumb. You still need to enforce budget checks, duplicate detection, and segregation of duties separately—none of that comes from the protocol.
Exactly right. We had a provider demo where they emphasized AP2 compliance but couldn't answer basic questions about how we'd enforce our three-way match or flag out-of-policy spend categories. The mandate proves delegation happened, not that the spend was appropriate.
Same experience here. We're adding AP2 to our agent purchasing pilot but still keeping hard blocks at the ERP level for budget and duplicate checks. The mandate gives us traceability but doesn't replace the policy engine.
The section on what reaches each participant in the payment flow is critical and often glossed over. We're seeing wildly different mandate field support across processors, and the lack of standardized verification behavior means we can't assume uniform fraud or dispute handling even if the merchant implemented AP2 correctly.
We hit this too. One processor was passing the full intent mandate context through to the card network, another was only sending a transaction ID reference. The issuer sees completely different signals depending on routing, which makes dispute resolution inconsistent even when the mandate itself is identical.
We hit this too. One processor was passing the full intent mandate context through to the issuer, another was only sending a payment-present flag, and a third was stripping agent metadata entirely. The result is your dispute and chargeback rights vary by processor even when the mandate structure is identical.
The bit about cross-border purchasing retaining ordinary tax and sanctions requirements is important—we're seeing vendors pitch AP2 like it somehow simplifies international compliance, which it absolutely does not. Still need local tax advice, entity structure, and proper vendor classification regardless of how clean the authorization chain looks.
Agreed. We flagged this in our evaluation too. AP2 gives you authorization provenance but does nothing for VAT determination, withholding tax obligations, or sanctions screening. Those systems still need to run independently, and someone on the finance team still owns that risk.
Agreed. We flagged this in our evaluation too. AP2 gives you authorization provenance but your withholding tax obligations, VAT registration requirements, and OFAC screening still apply exactly as before. The protocol doesn't touch any of that.
The mandate chain is helpful but I'm stuck on reconciliation. If the cart mandate captures approval and the payment mandate adds settlement context, which one do we actually match against the GL entry? Our ERP expects a single source document and I'm not sure whether to treat the payment mandate as authoritative or just supplementary metadata for the underlying invoice.
We're treating the payment mandate as the source document for GL since it captures settlement reality, but attaching both cart and payment mandates to the voucher for audit. The cart mandate becomes supporting evidence like a purchase order would be. Your ERP probably needs the one that has final amounts and payment method.
We're treating the payment mandate as the source document for GL since it captures settlement context, but linking back to the cart mandate for audit and dispute workflows. The payment mandate has the actual transaction identifier and timestamp that ties to bank feeds, while the cart gives you the original approval details if someone challenges the expense later.
The protocol-versus-policy framing here is important. We evaluated AP2 last quarter and our biggest internal debate was whether to wire mandate constraints into procurement policy or treat them as separate transport metadata. Still not fully settled on that but leaning toward keeping business rules upstream and using AP2 strictly for authorization lineage.
We went the opposite direction—treating intent constraints as first-class policy expressions that feed directly into our procurement workflow. The risk we saw with treating them as transport metadata is that approvers stop checking the actual business justification because a signed mandate feels like it already happened upstream.
We're leaning transport metadata too. The risk is drift—if mandate constraints start being treated as authoritative by downstream systems, you end up with two sources of truth and have to reconcile them anyway. Better to keep procurement rules in one place and use AP2 strictly for evidence that delegation happened within those boundaries.
I'm curious how the cart mandate integrity actually works when a merchant changes pricing between authorization and final charge. The article mentions substituted products shouldn't inherit approval, but in practice most payment rails don't block a transaction just because the amount ticked up by 2%. Does AP2 expect the agent to request a fresh mandate for every delta, or is there a tolerance band that defeats the whole point?
This is where the payment-facing mandate becomes critical. In our implementation we set a tolerance threshold at the intent level—anything beyond 3% requires a new cart authorization. The real problem is when merchants don't expose the final amount until settlement, which happens more than it should with dynamic pricing or forex conversions.
We ran into this exact issue during pilot. Our approach was to treat the intent mandate amount as a hard ceiling at the payment gateway level, not just protocol validation. If the final charge exceeds the authorized amount by any margin, it gets kicked to manual review. Adds friction but prevents the 2% creep from becoming 20% without anyone noticing.
appreciate the control map table—that's the most useful framing I've seen on this. too many vendor pitches act like protocol support = solved compliance when really you still need the same three-way match, same budget checks, same vendor master hygiene. AP2 gives you a better audit trail but doesn't replace your AP workflow.
right, it doesn't replace your AP controls at all. we're treating AP2 as a way to tie agent activity to authorization logs, but ERP approval workflows and GL coding still run exactly the same way they did before agents touched anything.
Exactly. The signature proves the mandate wasn't tampered with, not that the expense should have been approved in the first place. We still flag agent purchases above threshold for retroactive procurement review even when the AP2 chain is clean.
The distinction between 'authorized' and 'compliant' is exactly what keeps me up at night. We can cryptographically prove an agent had permission to buy something, but that doesn't mean it should have been purchased in the first place or that it maps to the right GL code. The mandate signature solves the technical problem but doesn't touch procurement policy, which is still the harder part.
This is why I think AP2 is actually helpful despite the limitations. The mandate gives us a structured hook to attach our own policy engine to. We're testing a flow where the intent mandate has to pass budget and category rules before the signature even gets issued. The authorization evidence doesn't replace compliance, but it at least creates a clean handoff point between agent delegation and our existing approval workflow.
Exactly. We're essentially building two parallel audit trails now—one for cryptographic authorization and one for whether the spend was actually justified under our procurement policy. The real question is how to bridge them without creating more reconciliation work than we had before agents entered the picture.