Skip to main content
This guide explains how to integrate the Nevermined Payments Python SDK with A2A (Agent-to-Agent) protocol servers.

Overview

A2A (Agent-to-Agent) is a protocol that enables AI agents to communicate with each other using JSON-RPC. The Nevermined SDK provides A2A integration to:
  • Build A2A servers with payment validation
  • Automatically verify x402 tokens on incoming requests
  • Handle credit redemption for agent tasks

Building Agent Cards

With a Single Plan

With Multiple Plans

When your agent supports multiple plans (e.g. a basic and a premium tier), use planIds instead of planId:
Note: Provide either planId or planIds, not both. planIds must be a non-empty list.

Agent Card Structure

The agent card declares two extensions: the Nevermined payment extension (pricing metadata) and the official a2a-x402 extension (https://github.com/google-agentic-commerce/a2a-x402/blob/main/spec/v0.2), which signals support for the standards-compliant in-band x402 v2 flow (see In-Band x402 v2 Payments). Both ship for one release; urn:nevermined:payment is dropped once clients use v0.2 only.

Using the @a2a_requires_payment Decorator

The simplest way to create a payment-protected A2A agent:
The decorator handles:
  • Payment middleware (verify/settle) automatically
  • Publishing task status events with creditsUsed metadata
  • Credit burning on task completion

AgentResponse

Starting an A2A Server (Advanced)

For more control, use PaymentsA2AServer.start() directly:

Server Configuration Options

Request Validation

The A2A server automatically validates payments on every POST request:
  1. Extracts Bearer token from Authorization header
  2. Reads planId or planIds from the agent card’s payment extension
  3. Verifies permissions via build_payment_required_for_plans()
  4. Rejects requests with 402 if validation fails, including a base64-encoded payment-required header
When multiple plans are configured, the 402 response includes all plans in accepts[], allowing the client to choose which plan to purchase.

In-Band x402 v2 Payments (Standards Flow)

Payment is signalled in band following the Coinbase x402 v2 A2A transport spec and the official a2a-x402 extension. The X402A2AUtils helpers (see x402 README) now power this live server flow — PaymentsA2AServer stamps and reads the metadata automatically, so the executor is unchanged. The handshake rides on A2A task/message metadata, correlated by taskId — no HTTP 402 is exchanged. Lifecycle:
  1. Payment required — a payment-gated message/send arrives with no payment. The server returns a Task with status.state = "input-required" and status.message.metadata:
  2. Payment submitted — the client replies with a follow-up message/send whose message.metadata carries the payload, correlated via message.taskId:
  3. Completed / failed — on success the final Task carries x402.payment.status: "payment-completed" plus x402.payment.receipts. On failure it is failed / payment-failed with the error under x402.payment.error, and paid content is suppressed.
Metadata keys: x402.payment.status, x402.payment.required, x402.payment.payload, x402.payment.receipts, x402.payment.error.
Note: The legacy payment-signature HTTP header flow still works but is now a deprecated fallback, kept for one release. New integrations should use the in-band metadata flow above.

Client Usage

Discovering Plans from the Agent Card

Consumers can fetch the agent card to discover available plans:

Ordering a Plan and Sending Messages

Hooks

Add custom logic at request lifecycle points:

Error Handling

Next Steps

x402 Protocol

Deep dive into x402 payment protocol

Request Validation

Manual validation patterns