Google Agent Payments Protocol: A Finance Pilot Plan

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.

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:

1. Implementation scope: the supported AP2 version, mandate flows, payment methods, and environments are documented.
2. Enforcement: expired, altered, out-of-scope, and duplicate requests fail safely.
3. Human escalation: exceptions have named owners, and unattended transactions cannot bypass required approval.
4. Recovery: ambiguous payment status is investigated before retries or replacement payments.
5. Accounting: finance can trace each purchase through settlement, refund, and ledger treatment.
6. 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.