Blog Posts

How agents learn to trust, transact, and settle on-chain‍

AI agents today can research, negotiate, and collaborate, but when it comes to handling payments, everything suddenly becomes messy. Custom logic everywhere. Fragile approval flows. No standard way to express or enforce what an agent is allowed to spend. And worst of all, no clear trust model for users.

Nevermined’s integration with x402, A2A, AP2 as well as ERC-8004 for trustless agent communication, introduces a clean, safe, programmable way for agents to make payments with real on-chain settlement. The result is a system where users stay in control, product teams gain a consistent pricing layer, and engineers no longer have to reinvent payments inside every agent workflow.

In our latest demo, a client agent purchases from a merchant agent with explicit user approval and verifiable settlement. The flow is simple, auditable, and fully interoperable.

TL;DR (Product)

AI agents shouldn’t just communicate efficiently, they should also transact safely.

Nevermined's x402 integration introduces programmable, on-chain payment permissions enforced by smart account policies.

A2A provides secure agent-to-agent messaging, AP2 expresses payment context, and x402 guarantees that agents can only spend what the user explicitly authorizes.

In the demo, a consumer agent buys from a merchant agent via on-chain settlement. Every step: request, approval, transfer, receipt is validated and enforced by protocol design.

TL;DR (Engineering)

The client agent mints x402 access tokens using payments SDK.
These tokens encode scoped spend permissions: plan, agent, amount, network, scheme.
The merchant verifies and settles through Nevermined’s x402 facilitator.
A2A transports payment-required and payment-submitted messages.
AP2 standardizes payment metadata.
Smart-account policies enforce the allowed spend on-chain via Nevemined.

All code is reproducible in the following demo:
https://github.com/nevermined-io/a2a-x402/blob/feat/a2a-nvm/python/examples/adk-demo/README.md

Why Agentic Payments Matter

If agents are going to participate in real commerce, they need:

Clear, bounded permissions
Explicit user approval aka Entitlement
Predictable pricing
Transparent receipts
Guardrails that prevent overspending or unauthorized actions

Nevermined's integration of x402 provides exactly that. AP2 standardizes payment intent, A2A transports messages, and x402 enforces permissions using Nevermined’s smart account policies.

Crucially, plans, SKUs, quotas, and pricing models live in the policy layer, not in each agent’s code. Changing pricing mechanics or adding new products becomes a config update, no agent refactoring required.

Because settlement is on-chain, businesses get:

deterministic receipts
auditability
finality
reduction in payment-related integration bugs

The demo shows a subscriber agent purchasing from a merchant agent with real settlement, verification, and user-controlled permissions.

How Nevermined’s Payment Plans Differ from Standard x402

Throughout this post we refer frequently to plans and credits. To avoid confusion, it’s important to distinguish between two related but conceptually different layers:

The x402 protocol’s built-in payment model
Nevermined’s extended payment plans and settlement capabilities

‍What Is a Nevermined Payment Plan?

In the Nevermined ecosystem, a payment plan is an abstraction representing an entitlement to consume resources according to predefined business rules. These plans are defined by smart contracts and enforced via smart account policies. Typical examples include:

Credit plans: a wallet can hold a fixed number of credits that a client can spend to access services.
Subscription plans: periodic access rights for resources available for a defined billing period.
Time-based plans: access rights tied to a duration rather than a count of usage.

These payment plans are a product-level monetization construct. They encapsulate commercial terms such as quotas, renewals, expirations, and usage limits. They are not part of the base x402 protocol spec.

See What is a Payment Plan? for a more detailed explanation.

Why Nevermined Extends x402

The standard x402 flow is well-suited to pay-per-use requests, but Nevermined’s ecosystem requires broader flexibility:

support for plans with pre-loaded credits
periodic or recurring entitlements
separation between purchase and usage
programmable enforcement of consumption policies

To support these use cases, Nevermined introduces a new x402 scheme extension where the payload signed by the client contains:

session keys representing delegated permissions representing a set of authorized on-chain actions
allowance to burn credits or perform plan-specific interactions

This extension stays compatible with the base x402 flow, meaning the client still generates a signed x402 payment payload that the facilitator can process but allows richer settlement semantics beyond a single ERC-20 transfer.

How Nevermined, A2A, AP2, and x402 Fit Together

A2A, AP2, and x402 each solve a different part of the agent-to-agent interaction stack. Although they are often discussed together, their responsibilities are distinct. This distinction becomes even more important when introducing Nevermined’s extended x402 scheme, which supports smart-contract settlement and policy-based permissions instead of only ERC-20/EIP-3009 transfers.

A2A - Communication & Transport Layer

A2A provides the message delivery mechanism between agents. It handles:

structured message formats
routing between client/merchant agents
request/response semantics
reliability and transport guarantees

AP2 - Payment Intent Layer

AP2 defines how agents express that a payment is required and how a client submits a payment authorization. It gives agents a shared vocabulary for:

“payment-required”
“payment-submitted”
metadata linking the request to a purpose or resource

Importantly AP2 does not define the payment method, pricing model, amount, plan, allowances, or settlement mechanism. Those details belong to the payment scheme carried within the AP2 messages…in our case, the x402 payload.

AP2 is intentionally payment-method-agnostic. Whether agents use ERC-20 transfers, ERC-4337 operations, credit plans, or something else is left to the payment scheme.

x402 - Permission + Enforcement Layer

The x402 protocol defines how a payment authorization is represented and transported. In the standard “exact” scheme:

the client signs an EIP-3009 authorization for an ERC-20 transfer
the facilitator verifies and submits that transfer on-chain

In Nevermined’s integration, we extend x402 with a new scheme “smart-account”, because the standard “exact” scheme is not expressive enough for:

credit plans
subscription or time-based plans
ERC-4337 delegated permissions encoded as session keys
programmable settlement in smart contracts

‍Nevermined’s x402 Extension Smart-Account Scheme

The Nevermined implementation introduces an x402 scheme where the client signs:

an EIP-712 payload
containing one or more session keys
each authorizing specific ERC-4337 `UserOperation`s
representing actions like:
- redeem credits
- burn credits
- subscribe to a payment plan
- perform a pay as you go settlement

This gives x402 the ability to authorize flexible settlement behaviors rather than just ERC-20 moves.

The facilitator validates these delegated capabilities and executes them on-chain according to smart-account policies.

How They Work Together in the Demo

A2A carries the messages (“payment-required”, “payment-submitted”)
AP2 defines the shape of those messages, but remains agnostic to the payment model
x402 (Nevermined extension) carries the actual payment authorization, including:
- payment plan identifier
- merchant/agent binding
- credit burn / PAYG actions
- network
- scheme (`smart-account`)
- delegated permissions
- validity window
Facilitator verifies the authorization and executes settlement on-chain

In short:

A2A moves the messages,

AP2 defines payment intent semantics,

x402 carries the payment authorization,

and Nevermined extends x402 to support advanced on-chain settlement.

Flow Overview

The demo implements the following transaction sequence:

The user instructs the client agent to purchase something.
Merchant sends an AP2 `payment-required` message describing plan, amount, scheme, network.
The client asks the user for approval.
The user approves.
Client generates an x402 token with allowed permissions through the Nevermined API.
Client sends `payment-submitted` with x402 token + metadata.
The merchant calls the Nevermined provided facilitator to verify token/policies.
The Nevermined facilitator simulates spend and returns validation.
Merchant settles on-chain (burns credits or deducts PAYG).
Merchant returns receipt + transaction hash.
Client updates the user’s balance and displays success.

You can inspect real demo transactions:

- Pay-as-you-go: https://sepolia.basescan.org/tx/0xf88cb8217505c25d8225c803332b4da6b4c18f93a51b384d4fdc0a9205512b7c
- Credits plan: https://sepolia.basescan.org/tx/0xe476f4612bd2293954f64f493f04239a7867efcbc522e00daec6732a1ce6e5f3

Sequence Diagram

The Facilitator’s Role

The facilitator is the enforcement and settlement engine for x402. It:

validates x402 tokens
checks smart-account policies
simulates spend on-chain
executes settlement (burn or deduct)
returns canonical receipts

This enables product teams to:

change pricing models without altering agent logic
mix credit plans, PAYG, subscriptions, or hybrid models
guarantee safe and predictable spending patterns

For engineering teams, the facilitator becomes the single integration point for all settlement behavior.

Smart Account Policies and x402 Permissions

Smart account policies define:

which plans exist
what merchants are allowed
how many credits a token can burn
on which chain or scheme the payment may occur
how long permissions remain valid

For users, this means strong protection:

no paying unauthorized agents
no accidental overspending
no ambiguous or hidden charges

For businesses, this means enforceable monetization with predictable guardrails.

x402 ensures these policies are not optional, they are cryptographically enforced.

Why This Pattern Scales

The architecture decouples business logic from payment logic:

A2A: communication
AP2: intent semantics
x402: permissions
Nevermined Facilitator: verification and settlement

This modularity ensures:

monetization evolves independently from agent capabilities
agents can interoperate across ecosystems
safety and consent become core features, not add-ons
enterprise guardrails become programmable

This is the foundation for AI Commerce: agents that transact deliberately, safely, and verifiably.

Try the Demo

Explore the full implementation here:

👉 https://github.com/nevermined-io/a2a-x402/blob/feat/a2a-nvm/python/examples/adk-demo/README.md

The repo includes:

agent setup
environment configuration
x402 token generation
facilitator verification
AP2 messaging
real Base Sepolia settlement
logs, diagrams, and examples

Nevermined x402 Pay as you go demo

‍

Nevermined x402 Credits demo

Scaling Beyond the Demo

With this pattern, agents can:

Subscribe to services
Charge for compute, data, expertise, etc.
Orchestrate multi-agent workflows requiring payments
Enforce enterprise-level budget controls
Operate in marketplaces with trusted settlement

It unlocks a new category: agentic commerce.

Key Takeaways

Agents need safe, programmable ways to transact.
x402 + Nevermined provides enforceable permissions and user-controlled spending.
A2A / AP2 standardize communication and payment intent.
Smart account policies act as a product-level control plane.
The facilitator ensures verification and settlement are secure and final.
The pattern is modular, interoperable, and ready for real-world agent commerce.

References

‍

Building Agentic Payments with Nevermined, x402, A2A, and AP2