Agentic payments: what enterprises need to get right (Sept.2026)

An enterprise agent could find a useful dataset, purchase access within an approved budget and return the result to its team. For that purchase to be dependable, the business needs to connect what it authorized to what the agent actually paid for, then account for the outcome. That connection is the research question behind Rialto.

EEA is exploring how verified agent-payment authorization could be bound to Ethereum settlement. A working integration could help businesses let agents buy services under defined spending controls, with records that connect approval, payment and delivery. Rialto is a proposed research profile to test that connection; its compatibility and operating limits still need to be demonstrated.

The motivation comes from questions explored at the Agentic Finance Summit, co-hosted by EEA and Microsoft in June 2026 during New York Tech Week. Speakers from Stripe, Coinbase, Crossmint and Merit Systems discussed machine payments, open standards and the infrastructure needed for agentic commerce. This research takes those questions into an enterprise comparison: what the protocols do, where Ethereum could fit and what an implementation must prove. The September research brief develops that comparison; this article introduces the decisions behind it.

What changed by September

The AP2 v0.2 specification published in April defines Checkout Mandates and Payment Mandates with linked receipts. FIDO announced standards work drawing on contributions from Google AP2 and Mastercard Verifiable Intent. Separately, the x402 Foundation became operational under Linux Foundation governance in July. These developments give implementers public specifications and standards venues to engage with. They do not establish a single winning protocol. AP2 v0.2; FIDO initiative; x402 Foundation launch.

September also brought a wallet-focused update. Ant International reported a global rollout of its Agentic Mobile Protocol and collaboration with Mastercard and Visa on Know-Your-Agent interoperability. The announcement says each network will retain its own verification and decision processes, a useful distinction for teams evaluating shared agent identity. Ant International's September update.

Start with the purchase you want to support

For a retailer, the immediate issue may be accepting an agent-assisted checkout while preserving its customer relationship. ACP organizes interactions between agents and businesses; UCP covers a broader commerce journey, including checkout and order handling. AP2 supplies authorization evidence within that journey. Visa TAP helps merchants verify agent requests, while payment-network services have separate credential and acceptance rules. ACP; UCP; Visa TAP.

For a company selling data or API access, payment may happen within the service request. x402 and MPP support HTTP payment interactions; L402 combines Lightning payments with credentials for paid access, commonly using macaroons. Payment authorization, verification and settlement are separate steps; the selected scheme determines when funds move. The buyer still needs to know what a successful payment buys and whether retrying a failed request can charge it again. x402 payment flow; MPP announcement; L402 development.

Where Ethereum fits

Ethereum can support agent registries, programmable spending controls and settlement. ERC-8004 proposes identity, reputation and validation registries. Those records can help a business discover agents and evaluate evidence, but the business must decide who it trusts. Registration does not certify an agent's legal identity or authorize a purchase. ERC-8004.

ERC-8183 addresses a different arrangement: a funded job with a provider and an evaluator. The evaluator's decision affects release of escrowed funds. That may suit a marketplace commissioning work, provided it can define acceptable delivery and who may judge it. Both ERC-8004 and ERC-8183 remain draft proposals in the canonical specifications reviewed for this edition; deployment is a separate question. ERC-8183.

A purchasing agent can use some of these components without using all of them. The integration has to connect the approval to the actual payment. For a purchase approved with a fixed recipient and amount, the system must reject a transaction that changes either, uses the wrong chain or relies on expired authorization. A delegated budget may allow multiple purchases, but each must stay within its approved constraints.

What an enterprise pilot should demonstrate

Choose a narrow workflow, such as paying a known supplier for an API request under a fixed budget. Document who controls the account and how the operator can revoke spending authority. Then test failures as carefully as successful purchases.

• Alter the amount or recipient and confirm the request is rejected.
• Repeat a request and check for duplicate charges or replayed authorization.
• Expire or revoke permission while a purchase is pending.
• Fail delivery after payment and demonstrate the refund or escalation path.

Keep records that procurement and operations teams can reconcile. A signed approval, a settlement receipt and proof of delivery are different pieces of evidence. The pilot should show how they refer to the same purchase and who handles an exception.

What Rialto needs to demonstrate

For Rialto, the next step is to choose one purchase workflow and demonstrate the connection from authorization to settlement. The profile needs a defined AP2 version, transaction-binding rules and reproducible tests. Registry lookups, smart-account permissions and escrow should be evaluated against that workflow.

An Ethereum signature does not replace an AP2 mandate. The profile must verify the AP2 evidence and bind it to an authorized Ethereum operation. Typed signing makes that operation inspectable, but expiry and replay controls still need to be enforced by the application. EIP-712 security considerations.

The next useful output is a discussion draft with test vectors that implementers can run and challenge. Institutions can contribute their spending, custody and exception requirements before the architecture expands.

This article was written with AI assistance.