Google Agent Payments Protocol: A Finance Pilot Plan
Google’s Agent Payments Protocol gives agent-led purchases a framework for verifiable authorization. Finance teams need a controlled pilot to turn that framework into a reliable purchasing and payment workflow.
The Google Agent Payments Protocol (AP2) is an open protocol for carrying verifiable authorization through purchases initiated by AI agents. It helps participants establish what a user authorized and whether a proposed transaction matches that authority. It is not a replacement for payment networks, an accounts payable system, or a company’s approval policy.
For CFOs and controllers, the useful next step is not blanket approval of autonomous purchasing. It is a narrowly scoped pilot that tests whether delegated authority survives the journey from purchase request to payment and reconciliation.
This guide focuses on that pilot: what to select, what to connect, which failures to simulate, and what evidence to require before allowing live transactions.
Understand the protocol before defining the pilot
Google announced AP2 on September 16, 2025 as an open, payment-agnostic framework developed with payments and technology companies. Its central mechanism is the mandate: a cryptographically signed record that helps connect user intent to a specific purchase.
In a human-present flow, the user can review and approve the final cart. In a delegated, human-not-present flow, the user authorizes conditions in advance, and the agent acts within those conditions. An Intent Mandate expresses the authorized task and constraints; a Cart Mandate captures the specific purchase. Exact credential structures and verification requirements should come from the AP2 specification and implementation repository, not from a vendor’s marketing summary.
AP2 complements agent tooling and communication protocols such as MCP and A2A. Those integrations help agents access tools or communicate; AP2 addresses payment authorization in the resulting transaction. The underlying payment method still determines how money moves.
Governance has also evolved. On April 28, 2026, Google announced AP2’s donation to the FIDO Alliance alongside version 0.2 and human-not-present payment updates. For procurement, that makes specification version and implementation support important diligence questions. Ecosystem participation alone does not establish that a provider supports your intended workflow in production.
Choose a purchase workflow—not your entire AP operation
A useful AP2 pilot starts where an agent actually makes a purchase. Invoice coding, purchase-order matching, and vendor follow-up can benefit from AI, but they do not inherently require an agent-payment protocol.
Choose a bounded purchasing task with an approved supplier, a clear deliverable, stable commercial terms, and an observable completion event. Avoid starting with new beneficiaries, disputed invoices, variable contracts, or purchases that can create uncapped recurring obligations.
Hypothetical pilot: an agent replenishes an approved office consumable from an existing supplier when an inventory signal arrives. The delegated authority specifies the permitted item, supplier, quantity, currency, total-cost ceiling, delivery location, and expiration. Substitutions and new subscriptions are excluded.
Begin with human review of the final purchase. Consider unattended execution only after the same workflow passes exception testing. This separates two questions: whether the integration works and whether delegation is acceptable.
Your existing AP automation workflow should remain responsible for invoice capture, approvals, and payment records where applicable. AP2 is an additional authorization mechanism, not a reason to create a separate accounting process.
Write a pilot contract between finance and engineering
Before integration, document the operational rules the pilot must satisfy. The following are recommended enterprise controls, not claims that every AP2 implementation provides them automatically.
Define who can delegate authority
Identify the legal entity purchasing the goods, the employee entitled to authorize the task, and the agent allowed to act. Check that the employee’s authority covers the category and commitment being made. A valid signature should not be treated as proof that the signer has unlimited corporate purchasing authority.
Keep authority administration separate from execution. An agent should not be able to increase its own limit, approve a new supplier, or grant itself broader purchasing permissions.
Translate instructions into enforceable conditions
“Buy more supplies at a reasonable price” is not a sufficient control. Express permitted suppliers, items, currencies, deadlines, and total landed cost in fields that deterministic checks can evaluate.
Include taxes, shipping, and other charges when testing the ceiling. Apply both transaction-level and aggregate budget controls so repeated compliant purchases cannot exhaust a budget unnoticed. Company policy must also define how expired or revoked authority is detected immediately before execution.
Use your approval policies to decide which exceptions return to a human. The model may explain an exception; it should not decide that the policy no longer applies.
Specify the payment and accounting handoffs
Document which system verifies authorization, which releases the payment instruction, and which records the obligation. Define how mandate references, purchase orders, merchant orders, invoices, payment identifiers, and refunds will be linked.
Do not assume the bank or payment network will carry every AP2 reference. If it cannot, maintain a durable mapping in the orchestration or accounting layer. Finance needs to reconstruct the transaction without relying on a chat transcript.
Test broken transactions before successful ones
A successful checkout demonstrates connectivity. The more important acceptance tests demonstrate that the integration stops, escalates, or recovers safely when conditions change.
| Test scenario | Expected pilot behavior | Evidence to retain |
|---|---|---|
| Final total exceeds authority | Block and request fresh approval | Approved ceiling and rejected total |
| Supplier or item changes | Reject unauthorized substitution | Original scope and changed cart |
| Authority expires or is revoked | Stop before payment submission | Validity check and stop event |
| Concurrent purchases exceed budget | Reserve capacity and reject excess | Budget reservations and decisions |
| Request is replayed | Prevent duplicate purchase or payment | Request identity and deduplication result |
| Provider times out after submission | Resolve status before retrying | Provider lookup and retry decision |
| Refund follows a completed purchase | Link credit to original transaction | Refund, payment, and ledger references |
Implement replay protection at the business-operation level as well as the payment-request level. Preventing a duplicate payment call is insufficient if an agent can accidentally create another merchant order for the same replenishment request. The control principles in duplicate invoice detection are relevant here: different identifiers do not necessarily mean different obligations.
Also test hostile content. A supplier page or invoice might contain instructions to ignore limits or change the destination. Treat that content as transaction data, never as authority to modify policy. Verification and payment controls should operate outside the model’s discretionary reasoning.
Make reconciliation part of the authorization design
Record separate states for authorized, ordered, payment submitted, settled, and refunded. Authorization is not evidence that the beneficiary received funds, and an order confirmation is not proof of delivery.
For the pilot, require an evidence record connecting:
- The business request and authorized delegator.
- The agent identity, approved scope, and relevant mandate records.
- The final commercial terms and policy-check results.
- The merchant order and payment-provider references.
- The invoice, accounting entry, and any subsequent adjustment.
Store references and verification evidence without unnecessarily copying payment credentials into application logs. Assign access, retention, and investigation responsibilities before live use.
Legal and contractual review remains separate. Fenwick’s April 2026 legal analysis identifies unresolved U.S. regulatory and liability questions around agentic payments. Do not assume protocol compliance resolves money-transmission obligations, fraud liability, or a provider’s dispute rules. Review the actual activity, jurisdiction, and contracts.
A go-live checklist for the controller
Approve production use only when the responsible teams can demonstrate the following:
- Implementation scope: the supported AP2 version, mandate flows, payment methods, and environments are documented.
- Enforcement: expired, altered, out-of-scope, and duplicate requests fail safely.
- Human escalation: exceptions have named owners, and unattended transactions cannot bypass required approval.
- Recovery: ambiguous payment status is investigated before retries or replacement payments.
- Accounting: finance can trace each purchase through settlement, refund, and ledger treatment.
- Shutdown: operators can disable delegated purchasing without losing records or abandoning in-flight payments.
Evaluate outcomes against agreed acceptance criteria, not a generic automation percentage. A blocked unauthorized purchase is a successful control outcome, even though it reduces straight-through processing.
Adopt AP2 through a bounded operating model
The practical value of Google’s Agent Payments Protocol is a more structured foundation for delegated purchasing. Real operational readiness comes from connecting that foundation to company authority, payment execution, exception handling, and accounting.
Payouts.com brings payouts, treasury, AP/AR automation, and AI digital employees into one financial operating system. Its AI agents have identities, wallets, and spend limits—operating controls relevant to governed automation, not a claim of AP2 compatibility.
Start by mapping one purchasing workflow and its failure cases. Then ask every integration provider to demonstrate the authorization checks, payment-state transitions, and accounting evidence your finance team will need to own the result.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
39 commentsRelated resources
Duplicate Invoice Detection: Evaluate the Control, Not the Alert
A duplicate alert is not the same as a prevented payment. Learn how to evaluate matching accuracy, exception handling, and payment-release controls before choosing AP automation.
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 guidance to include taxes, shipping, and other charges when testing the ceiling is something we learned the hard way with our procurement card program. An agent that only checks item price against a $500 limit but ignores a $200 international shipping fee will blow through budget controls fast.
We encountered the same issue with dynamic freight calculations that only resolved at checkout. The solution was enforcing a buffer—if the item subtotal exceeds 75% of the delegated ceiling, the agent must escalate. Not perfect, but it prevented most overruns while we waited for suppliers to expose shipping estimates via API.
Same issue here. We now enforce total landed cost validation at the orchestration layer before the agent even gets to checkout, using the supplier's shipping calculator API when available. If the total can't be determined in advance, the transaction requires human approval.
The assertion that a valid signature should not be treated as proof of unlimited purchasing authority is basic separation of duties, but I'm curious how AP2 implementations handle federated identity scenarios where the signing key might be managed outside the corporate directory—does the spec require real-time entitlement lookups or is it silent on that?
The spec itself doesn't enforce organizational identity structures—that's deliberate. It's on the relying party to verify that the signing key maps to an authorized principal before accepting the mandate. If your IdP is federated, you need a local resolver that ties external identities to internal purchasing authority before the mandate gets evaluated.
The spec itself doesn't enforce organizational identity structures—that's deliberate. It's on the verifying party to map the signing credential to actual purchasing authority in their system. If your IdP is federated, you need middleware that translates the signature into a permission check against your internal approval matrix before honoring the mandate.
The recommendation to test expired or revoked authority detection immediately before execution is critical but I'm not seeing clarity on how that lookup happens in practice. If the mandate was signed two days ago and the employee's authority was revoked yesterday, what system is the agent querying in real-time to confirm the mandate is still valid? We're evaluating AP2 now and this is the gap our legal team keeps raising.
This is exactly why the pilot contract needs to specify the authority registry. In our design we require the agent to query an internal HR/authorization service on every execution, not just at mandate-signing time. The mandate proves what was authorized when, but a separate real-time lookup confirms the person still holds that authority. If those don't match, the transaction blocks regardless of signature validity.
This is exactly why the pilot contract needs to specify the authority registry. In our design the agent queries an internal authorization service via API immediately before checkout—not at mandate creation time. The service checks current role assignments, spending limits, and revocation lists in real time. The mandate proves what was authorized initially, but the live lookup determines whether that authority is still valid.
The recommendation to start with human review of the final purchase before moving to unattended execution is the right approach, but I'm curious how the article envisions the transition criteria. What specific number of successful cycles or exception scenarios need to pass before finance should feel comfortable removing that human checkpoint?
We used a combined threshold: 30 consecutive successful purchases with no manual intervention, plus documented handling of at least eight exception types from the article's test scenario table. The harder part was getting finance and engineering to agree on what constitutes 'safe failure'—we wanted proof that budget ceiling breaches and supplier substitutions were caught before payment release, not just logged after the fact.
We set our transition bar at 50 clean cycles plus at least one example of each documented exception being correctly rejected or escalated. The number matters less than proving you've seen and handled the failure modes that will definitely happen in production.
The instruction to avoid starting with new beneficiaries or variable contracts is sound advice, but it sidesteps the actual pain point for most finance teams—those workflows are exactly where we need automation most. Existing suppliers with stable terms are already low-friction. I'd be more interested in guidance on how to incrementally extend a working pilot into higher-variance scenarios without losing control.
I get the frustration, but if you can't prove the authorization chain holds for a controlled scenario, adding complexity with variable terms and new vendors just means you'll have authorization failures you can't diagnose. Crawl first.
That's the whole point of starting narrow—prove the authorization layer works in controlled conditions before you apply it to complex edge cases where failure carries higher risk. If you can't make it work reliably for stable suppliers, it definitely won't handle variable contracts safely.
The recommendation to write a pilot contract between finance and engineering before starting integration is something we should have done six months ago. We ended up with engineering treating every AP2 mandate as automatically valid if the signature checked, while finance assumed the ERP approval workflow was still gating everything. Nobody documented which system was actually responsible for budget enforcement.
We hit the same misalignment. Engineering saw it as a technical verification problem and finance saw it as a policy enforcement problem. The article's advice about keeping authority administration separate from execution would have caught that disconnect early.
We hit the same misalignment. Engineering saw it as a technical verification problem and finance saw it as an approval governance problem. The pilot contract forces both sides to agree on what 'authorized' actually means before any code gets written.
The distinction between AP2 as an authorization layer versus a replacement for payment rails is crucial and I'm glad the article hammers this home. We've had vendor pitches conflate the two, and it's caused confusion about where this actually fits in the stack—our payment processor still handles movement of funds, AP2 just gives us a verifiable chain from intent to execution.
Same experience here. The key is understanding that AP2 sits between intent and instruction—it doesn't touch settlement or liquidity at all. Once we mapped it correctly in our architecture diagram, the integration scope became much clearer and we stopped getting questions about whether this replaced our existing banking connections.
We had the same confusion internally until we mapped it out: AP2 verifies the authorization token, the payment processor executes the instruction, and our ERP still records the liability. Three separate layers. The article's recommendation to document those handoffs explicitly in the pilot contract is the only way to prevent everyone from assuming someone else is handling reconciliation.
The handoff section is where most pilots will actually fail. We spent two weeks getting AP2 mandates generated correctly, then discovered our ERP couldn't ingest the reference structure without custom middleware. Finance wanted a clean GL tie, engineering wanted to avoid schema changes, and we ended up building a reconciliation layer that nobody asked for but everyone now depends on.
We solved this by treating the mandate reference as metadata only and using a separate correlation ID that both the payment rail and ERP could handle natively. The AP2 reference gets logged in a sidecar table that audit can query, but the GL posting doesn't touch it. Not elegant, but it kept us moving without a schema migration.
We ran into the exact same problem. The solution that worked for us was treating the mandate reference as an optional annotation field in the ERP and maintaining the full linkage in a separate reconciliation table that finance owns. It's not elegant, but it preserved the GL structure and gave us a complete audit trail without waiting for a schema migration that would've taken months.
The article says AP2 complements MCP and A2A but doesn't replace payment networks or AP systems—I think this is the most underappreciated point for people evaluating vendor pitches right now. We've had three demos in the past month where the provider implied AP2 was a full procurement stack replacement, when really it's just the authorization envelope.
We had the same confusion during vendor selection. One provider kept showing AP2 in architecture slides right next to their ERP connector, implying it handled both authorization and settlement. It doesn't—it's purely the authorization piece, and you still need everything else to actually move money and record the transaction.
Same here. The key distinction that helped us was realizing AP2 is purely an authorization envelope—it doesn't touch invoice matching, three-way reconciliation, or payment execution. Once we mapped it as a thin layer between intent capture and our existing AP workflow, the vendor confusion cleared up fast.
The point about choosing a bounded purchasing task with stable commercial terms is spot-on, but I'm curious how finance teams are supposed to handle the situation where an agent makes a valid purchase under its authority but the underlying supplier changes their pricing or terms between when the mandate was issued and when the purchase executes. Do you revoke and reissue, or build tolerance bands into the original authority?
That's why the article recommends including expiration dates in the authority structure. If supplier terms change materially, the merchant should reject the old cart total against the approved ceiling, which forces it back to human review. The real question is whether your procurement system has a live feed of supplier price changes or if you're relying on the agent to detect the mismatch at checkout.
That's why the article recommends including expiration dates in the authority structure. If the supplier changes terms mid-flight, the agent should either reject because the new total exceeds the ceiling or the mandate should have expired and require fresh approval. The real question is whether your procurement system gets notified of the term change before the agent tries to execute.
I appreciate the specificity around "total landed cost" controls—we got burned once on an automated reorder that looked compliant on item price but blew the budget when freight and duties hit the invoice. One question: how realistic is it to expect stable mandate references to survive the full loop through a payment network and back to the ERP? Most of our bank feeds still lose half the remittance detail.
We had the same tracking problem. Our workaround was maintaining a reference table in the ERP that maps the internal mandate ID to the payment processor's transaction ID and the supplier's order number. It's not elegant, but audit can reconstruct the chain without depending on any single system to carry the full context.
We had the same issue tracking mandate references through our payment processor. The solution that worked was maintaining a separate ledger table that maps the original intent hash to the bank transaction ID and invoice number. Not elegant, but it survived audit without needing the payment rail to preserve AP2 metadata.
The section on separating connectivity from delegation is critical. We've seen too many vendor demos where a successful checkout becomes the argument for full unattended deployment. Running exception tests with human review first gives you the evidence you actually need for a risk assessment.
Exactly. We're building the exception catalog first—expired authority, item substitution, budget exceeded, supplier mismatch—and requiring the agent to surface every case cleanly before anyone even considers removing the approval gate. The mandate structure helps, but only if you actually test rejection paths.
Agreed. The article's suggestion to run the same workflow through exception testing before unattended execution is the right sequence. If your integration can't cleanly reject an out-of-bounds purchase with a human watching, you definitely don't want to discover that behavior in production.
honestly the part about not letting an agent increase its own limit should be obvious but I bet we're going to see that exact vulnerability in production somewhere in the next 12 months
We already saw a version of this with RPA bots that had write access to their own config files. Someone thought it was efficient. It was not.
We already saw a version of this with RPA bots that had write access to their own config files. Same pattern, different surface area. The question is whether the protocol itself enforces this separation or whether it's just implementation guidance that half the vendors will ignore.