Agentic Payments: The Standards Landscape and Ethereum’s Role (Sept.2026)

Executive summary

An AI agent can select a product or call an API, but paying introduces a different set of questions. Who controls the agent? What did the user authorize? Which system moves the funds? What happens if the purchase or delivery goes wrong? The initiatives reviewed here address different parts of that process.

Two useful starting points are purchases delegated by a person and payments between software systems. They overlap: a delegated purchase can use stablecoins, and an automated API payment can remain subject to a human-approved budget. Checkout protocols, payment-network services and blockchain proposals should therefore be compared by function, rather than treated as equivalent competing standards.

This September 2026 research brief covers selected commerce protocols, payment-network services and Ethereum components. Enterprise implementation questions follow the comparison. An optional AP2-Ethereum profile appears in the research outlook and is linked to Rialto.

Three things to take away

1. Compare capabilities before choosing a protocol. Checkout, authentication, authorization, settlement and delivery evaluation are separate decisions, even when a product bundles several of them.

2. Governance and deployment status matter. FIDO announced agentic standards work drawing on AP2 and Mastercard Verifiable Intent; the x402 Foundation became operational under the Linux Foundation. Neither announcement proves compatibility across implementations.

3. Ethereum offers components worth testing. ERC-8004 proposes agent discovery and trust signals; ERC-8183 proposes escrowed jobs with an evaluator. Both remain draft ERCs in the canonical specification pages reviewed for this edition. Registration, payment and evaluation do not by themselves establish institutional trust or legal accountability.

For enterprise teams, the practical task is to define spending authority, custody, settlement and exception handling for a specific use case. EEA can help convene that work and publish evidence from implementation tests.

I. The payment landscape

1.1 Delegated purchases and software payments

When software initiates a purchase, a merchant needs evidence beyond a human clicking a checkout button. The required controls depend on the buyer, the payment method and what is being purchased.

Human-delegated commerce: an agent shops or checks out on behalf of a person. The system must preserve the person's consent, spending limits and ability to intervene.

Machine-to-machine commerce: software pays for an API, data or another service. The operator still needs to manage keys, budgets, counterparties and failed requests.

Enterprises may need both workflows. A procurement agent might buy a subscription through a merchant checkout and purchase individual data requests through an HTTP payment protocol. A shared budget does not make those payment and dispute processes interchangeable.

1.2 Checkout, consent and network services

UCP also belongs in the checkout comparison. Its commerce capabilities cover discovery, checkout and order handling, with AP2 support for authorization evidence. This is a broader commerce interface, distinct from payment settlement. See the UCP documentation. Universal Commerce Protocol documentation.

1.3 Payment requirements and paid API access

1.4 Convergence dynamics

Several initiatives can coexist because they address different functions. Adoption should be assessed through working integrations and operational evidence.

Cooperation across networks. In September, Ant International reported collaboration with Mastercard and Visa on Know-Your-Agent interoperability. Each network retains its own verification and decision processes. That distinction matters when evaluating claims of shared agent identity. Ant International AMP September update.

Functional separation. An agent registry, a signed purchase instruction and a payment verification service can be separate components. Combining them requires explicit rules for identifiers, amounts, expiry and failure handling.

Operational evidence. Successful transactions, failed-request behavior, merchant acceptance, recurring costs and support processes are more useful for an implementation decision than a partner count alone.

II. Ethereum components

Ethereum can support agent registries, programmable accounts and settlement. These components may be used alongside commerce protocols, but an application must define how their records and permissions fit together.

ERC-8004: Trustless Agents

ERC-8004 proposes registries for identity, reputation and validation. Its authors include contributors associated with MetaMask, the Ethereum Foundation, Google and Coinbase. The specification supports discovery and shared trust signals across organizations; it does not certify an agent's legal identity, competence or authorization to spend. A deployed implementation and a finalized ERC are different milestones. ERC-8004 specification.

A useful analogy is a public directory with feedback and validation records. The relying organization must decide which records and issuers it trusts.

ERC-8183: Agentic Commerce

ERC-8183 proposes jobs funded through escrow, with client, provider and evaluator roles. Completion or rejection by the evaluator affects fund release; expiry provides another path through the job lifecycle. The evaluator remains a trust dependency. This design is not a general replacement for card disputes or legal remedies. ERC-8183 specification.

Think of a funded work order with an agreed evaluator. The contract enforces its state transitions; the evaluation policy determines whether the work is acceptable.

x402: HTTP payment interaction

x402 lets a service communicate payment requirements and process a client's payment payload. It can be used with blockchain settlement, but it is not exclusively an Ethereum protocol. ERC-8004, ERC-8183 and x402 are not a mandatory three-part stack, and their composition must be demonstrated for the chosen implementation.

EEA's contribution can be practical: collect enterprise requirements, compare implementations and publish interoperability tests. This brief does not announce certification, a finalized extension or an institutional endorsement of an implementation.

III. Identity, authorization and payment

These functions often appear in the same transaction, but they answer different questions. A design can implement them with different technologies and trust models.

ERC-8004 answers: "Who is this agent?"

A relying party can inspect registration, feedback and validation signals. It must still establish who controls the registered account, whether the evidence is current and whether that agent is acceptable for this transaction. Registration is not proof of business legitimacy.

AP2 answers: "Did the human actually authorize this?"

AP2 organizes evidence of the user's intent and the purchase being authorized. A verifier must validate that evidence against the relevant trust policy. A signed instruction does not automatically authorize an unrelated blockchain transaction. AP2 supports both direct purchase approval and autonomous purchases within user-approved constraints.

x402: payment requirements and verification

An HTTP payment interaction communicates the service's requirements and the client's payment payload. Verification, settlement timing, fees and refunds depend on the selected scheme and payment method.

A familiar comparison is supplier onboarding, a purchase order and payment processing. An approved supplier is not permission to make any purchase; an approved purchase order is not proof of payment. Delivery acceptance and refunds add further decisions.

IV. A procurement analogy

Procurement provides a useful way to explain the functions to business teams. The comparison is illustrative: it should not be used to infer technical compatibility or identical legal treatment.

Identity and trust: who can participate?

An agent registry resembles a supplier directory. Signed agent requests help a merchant recognize a caller. Payment-network credentials have their own issuance and acceptance rules. None is a universal certificate of trust.

Consent and purchase: what is approved?

A purchase mandate resembles an approval record. A checkout protocol organizes the interaction with the merchant. The implementation must bind approval to the actual order, amount and payment method.

Payment and delivery: what triggers release?

HTTP payment protocols can gate resource access on payment. An escrowed job can gate fund release on evaluation. These serve different commercial arrangements and need different exception policies.

Integration: how do systems communicate?

A merchant integration service can connect agents, commerce platforms and payment schemes. Support for one interface does not prove support for every version or settlement method. Wallet-focused initiatives also need to be evaluated against their own documented scope.

V. AP2 and enterprise implementation

5.1 Why AP2 deserves attention

Google introduced AP2 with more than 60 collaborating organizations and described it as payment-agnostic, with use alongside A2A and MCP. FIDO subsequently announced agentic authentication and commerce standards work drawing on contributions from Google AP2 and Mastercard Verifiable Intent. This makes AP2 relevant to enterprise review; it does not establish a market winner or a finalized FIDO standard. Google AP2 announcement; FIDO agentic standards initiative.

5.2 Mandates and receipts

AP2 v0.2 defines Checkout Mandates and Payment Mandates, with linked receipts. A closed mandate is bound to the merchant-signed checkout through a cryptographic hash. The release specifies SD-JWT credentials and verification responsibilities for merchants and payment participants. It also supports direct and autonomous authorization modes. These rules should be the starting point for any settlement integration. An Ethereum signature cannot substitute for this AP2 evidence; the integration must validate both the mandate and the Ethereum operation. EIP-712 does not itself provide expiry or replay protection. AP2 v0.2 specification.

5.3 Questions for an Ethereum integration

AP2 v0.2 documents extension points for mandate constraints, checkout objects, payment instruments and credential formats. The five questions below are EEA implementation questions, not a list of those extension points. Each candidate Ethereum approach needs an explicit mapping to the selected AP2 version and its verification rules. AP2 v0.2 specification.

A verifier needs an accepted source of authority. Publishing a key or attestation on-chain makes a record inspectable; it does not decide which institution may issue it, whether its evidence is sufficient or which remedies apply. Those are policy and governance choices.

Appendix. Quick reference