Agent Payment Standards Are Moving to Governance

Executive summary

Agent payments need more than a message saying “pay.” The system must prove which user authorized which agent, for what purpose, under what limits and with what accountability. In April 2026, FIDO announced an Agentic Authentication Technical Working Group and payment work drawing on Google’s AP2 and Mastercard’s Verifiable Intent.

Shared governance can reduce fragmentation across wallets, merchants, payment providers and AI platforms. It will matter only if it produces conformance tests, version discipline and liability clarity. Operators should build a portable internal authority model rather than betting on a protocol name.

The market in context

The Universal Commerce Protocol covers discovery, checkout, identity linking, orders and payment-token exchange. AP2 focuses on secured agent-performed payments. Authentication standards establish who or what is acting. A production flow may use all three layers.

A vendor logo does not establish interoperability. Operators need the exact version, optional capabilities, human-present or unattended support, wallet compatibility, post-purchase behavior and exported evidence.

The standards landscape is layered because commerce itself is layered. A merchant needs a way to expose products and terms; an agent needs a way to communicate an order; a payment provider needs a defensible authorization; and every participant needs evidence when the outcome is challenged. Treating one specification as a complete answer usually means overlooking one of those boundaries.

The practical question is not which acronym wins. It is whether independently built systems interpret the same mandate in the same way. Optional fields, default values and error behavior matter as much as the headline schema. Two implementations can both claim compliance while disagreeing about expiry, substitutions or a partially fulfilled order. Governance becomes valuable when it narrows those ambiguities and makes divergence observable.

Delegated authority is the central primitive

Delegated authority is the central primitive. Human login proves account access; it does not prove that an agent may buy tomorrow below a price ceiling. A machine-verifiable mandate must express item or category, maximum amount, timing, recurrence, delivery terms and further delegation.

Human-not-present execution removes the confirmation screen that normally resolves ambiguity. Expiry and exception rules must be encoded before the event. A standard can carry fields, but each participant still needs policy for interpreting them.

A mandate should be specific enough to constrain action without being so brittle that every harmless change requires a new ceremony. For a replenishment purchase, that may mean a category, maximum unit price, total spend cap, approved sellers, delivery window and recurrence limit. For travel, it may include refundability, connection count and an escalation rule when the fare changes. The correct fields depend on the commercial risk, which is why a transport standard cannot substitute for business policy.

Delegation depth also matters. A user may authorize a personal agent, which then calls a merchant agent and a payment agent. The evidence chain should show which system transformed the instruction and whether it was allowed to do so. Otherwise a valid signature at the final step can conceal an unauthorized expansion of scope earlier in the chain.

Governance can be a competitive asset

Governance can be a competitive asset. FIDO’s multi-stakeholder model may earn trust from participants unwilling to depend on a rival platform. Governance must include security review, change control, test vectors and backward compatibility. Otherwise implementations share vocabulary and diverge on the edge cases where disputes occur.

The strongest evidence will be independently tested products completing the same mandated transaction and producing comparable audit records, not a long member list.

Good governance is visible in unglamorous work: published version histories, security review, deprecation windows, reproducible test vectors and a process for resolving contradictory implementations. Those mechanisms determine whether a merchant can upgrade without breaking valid customers and whether an issuer can reject a risky extension without blocking an entire channel.

Conformance also has to cover failure. A test suite that proves only a successful purchase is incomplete. It should include an expired mandate, replayed authorization, altered basket, unavailable item, partial shipment, refund, duplicate message and agent handoff. Participants need the same answer about whether to retry, ask the user, reverse the payment or preserve the order for manual review.

Fragmentation will persist

Fragmentation will persist. Commerce, identity and network-led specifications have different incentives. Some will specialize; others will overlap. Payment orchestrators can absorb variation, but merchants need the original authority evidence and a record of any translation.

Business policy should be separated from transport. Rules for prohibited products, returns or human review belong in a normalized internal engine that can receive several formats consistently.

A normalization layer can reduce integration cost, but translation introduces responsibility. If a gateway converts one mandate format into another, it must preserve the signed original, identify every transformation and avoid inventing authority that was not present. Merchants should be able to retrieve both the normalized policy decision and the source artifact during a dispute.

This is also a competitive issue. Platforms may add proprietary fields for loyalty, financing or preferred placement. Some extensions will be useful; others will create dependence. Operators should distinguish enhancements that can be ignored safely from extensions that become mandatory for distribution or favorable economics.

Implications for operators

Create an authority schema covering principal, agent, action, amount, expiry, recurrence, merchant scope, fulfillment constraints and delegation depth. Require versioned conformance evidence and test expired, altered, replayed and partially fulfilled mandates.

Use a protocol gateway to normalize external messages while preserving signed originals. Assign ownership across identity, payments, security, legal and customer care. Distinguish unauthorized action, wrong execution, fulfillment failure and customer regret in dispute operations.

Procurement should ask vendors to demonstrate interoperability, not merely list affiliations. Give two implementations the same mandate and compare the resulting authorization evidence, order state and exception behavior. Require the exact protocol version, supported options and deprecation policy in the contract. “Standards based” is too broad to operate or audit.

Internally, firms need one authority model that survives changes in external protocols. Product teams can map outside messages into that model; risk teams can set thresholds; customer operations can classify disputes against it. The original signed evidence should remain attached. This architecture keeps commercial policy under the operator’s control while standards and counterparties evolve.

What would change the view

Standards bodies can move slowly while platforms ship proprietary extensions. Premature standardization can also freeze assumptions too early. Cryptographic proof confirms an artifact, not that a model understood the user correctly. Liability may differ across payment rules, consumer law and contracts.

The thesis would weaken if one vertically integrated platform captures most commerce and counterparties accept its private rules. Large merchants and issuers would still benefit from portable audit evidence.

The chief risk is premature confidence. Cryptographic integrity can prove that a message was signed and unchanged, but it cannot prove that the user understood the delegation or that the agent interpreted an ambiguous request well. User experience, disclosure and escalation remain part of authorization.

Governance can also become a venue for strategic delay. Incumbents may favor requirements that smaller entrants struggle to implement, while fast-moving platforms may ship private extensions before consensus forms. Operators should monitor participation, published test artifacts and real cross-provider transactions rather than equating committee activity with market readiness.

Liability may remain fragmented even after technical convergence. The agent platform, merchant, issuer and payment provider can each satisfy its own rule while disagreeing about who should absorb a loss caused by misunderstood intent. Contracts and customer-service procedures must close that gap before unattended volume becomes material.

Methodology

This report treats announced standards work as direction, not completed interoperability. “Human not present” is a protocol capability, not universal legal permission.

A conformance matrix should record version, mandate fields, authentication, replay protection, unattended support, refunds, partial fulfillment, order change, signed-evidence retention and dispute export. Run one negative-case test suite against every implementation.

A useful conformance record should identify protocol and version, required and optional fields, authentication method, replay protection, unattended-execution support, substitution policy, partial fulfillment, cancellation, refund, evidence retention and dispute export. Each test should preserve the input mandate, messages exchanged, policy decision, payment result and final order state. Passing results should be repeatable against a second implementation, not accepted on vendor attestation alone.

The operating test should also separate semantic agreement from transport success. A message can be delivered, authenticated and parsed while two parties reach different conclusions about whether a substitution is permitted. Record the policy decision made by each participant and the rule that produced it. Where specifications leave behavior optional, document the negotiated profile rather than assuming the default will be shared.

For dispute analysis, retain enough evidence to reconstruct the chain without storing unnecessary customer data. The minimum set is the user-facing instruction, signed mandate, protocol version, agent and merchant identities, transformations, payment authorization, order changes and final resolution. Retention periods should reflect payment and consumer-law obligations in each market.

Interoperability claims should be dated. A product that passed tests against version 0.2 may not behave the same way after one participant adopts a newer profile. Release management should identify the last known compatible pair, the deadline for upgrades and the rollback route when a new interpretation fails in production.