Skip to main content
HomeLanding pagesAgno payment integration
LANDING PAGE

Agno payment integration

8 min read·Last updated June 2, 2026

Integrating payments into Agno means giving an agent a payment toolkit so it can pay for what it calls, and optionally charging for what it serves. Agno is Python and the x402 client is Node, so the toolkit's tools call a small local Node proxy built on createX402Client from @blockchain0x/x402. It settles any HTTP 402 in USDC on Base, with one wallet per agent.

What integration means

Integrating payments into Agno means two related things: giving an agent the ability to pay for what it calls (a paid API, a data source, another agent), and, when you want it, charging other callers for what your agent serves. The first is the common case; the second is the earn side, turning an Agno agent into a paid service.

This page is the integration reference: the pieces, how they fit, and the Agno idiom that makes payment feel native. For the same overview in sibling frameworks, see crewai-payment-integration and autogen-payment-integration. The payment API product page is the broader reference. Here the focus is the shape of an Agno integration, packaged the way Agno packages capabilities.

The Node proxy reality

Start with the fact that shapes everything: Agno is Python, and the payment packages, @blockchain0x/x402 and @blockchain0x/node, ship for Node. There is no Python payment package, so you do not call Blockchain0x from inside the agent directly.

Instead, the payment work runs in a small Node process and the agent talks to it over localhost. On the pay side this is a proxy that holds the wallet; on the earn side it is a gateway that gates an endpoint. Both are small, about thirty lines, and both keep every payment identifier on the verified Node surface. It is the same pattern used across the Python-framework integrations, and for Agno the clean move is to wrap the call to that proxy in a Toolkit.

Package it as a Toolkit

Agno groups related tools into a Toolkit, so the idiomatic integration is a payment toolkit. It holds the pay tool (and optionally a read-the-limit tool), carries shared config like which proxy to call, and drops onto any agent in one line.

PYTHON
import requests
from agno.tools import Toolkit

class PaymentToolkit(Toolkit):
    def __init__(self, proxy_url: str = "http://127.0.0.1:8787"):
        super().__init__(name="payment")
        self.proxy_url = proxy_url
        self.register(self.pay_and_fetch)

    def pay_and_fetch(self, url: str) -> str:
        """Fetch a URL, paying in USDC if it requires payment. Returns the body."""
        res = requests.post(self.proxy_url, json={"url": url}, timeout=30)
        return res.text if res.status_code == 200 else f"Failed: {res.status_code}"

Add it with Agent(tools=[PaymentToolkit()]), start the proxy, and the agent can pay. When Agno's tool-calling decides a task needs a paid resource, it invokes pay_and_fetch, the proxy settles the 402 in USDC on Base, and the result returns. The payment is invisible to the model, and the wallet's spend limit is the backstop. Packaging it as a toolkit means payment is one reusable unit, not loose functions.

Per-agent wallets in a team

Agno supports teams of agents, and in a team each agent should keep its own wallet. Because the toolkit takes its proxy address as config, you give each agent a toolkit pointed at its own proxy and key.

PYTHON
researcher = Agent(name="researcher", tools=[PaymentToolkit(proxy_url="http://127.0.0.1:8787")])
writer = Agent(name="writer", tools=[PaymentToolkit(proxy_url="http://127.0.0.1:8788")])

Run one proxy per agent on its own port with that agent's key, and each agent pays from its own wallet. The dashboard attributes spend per agent, and a compromised agent can only spend its own balance, not the team's. The toolkit class is shared code; the proxy each instance points at is what separates the accounts. This is the same per-agent isolation the other Python-framework integrations use, expressed through Agno's toolkit configuration.

The earn side

To charge for what your Agno agent serves, expose it over HTTP and front it with a small Node gateway running createX402Plugin. The gateway returns the 402, verifies payment, and proxies paid requests to your agent.

TYPESCRIPT
import Fastify from "fastify";
import { createClient } from "@blockchain0x/node";
import { createX402Plugin } from "@blockchain0x/x402/server/fastify";

const sdk = createClient({ apiKey: process.env.B0X_API_KEY! });
const app = Fastify();
await app.register(createX402Plugin, {
  sdk,
  defaultNetwork: "testnet",
  pricing: { "POST /agent/run": { amountUsdc: "0.10", payToAddress: process.env.B0X_PAYTO_ADDRESS!, paymentRequestId: "pr_agent" } },
});
app.post("/agent/run", async (req) => {
  const r = await fetch("http://127.0.0.1:8000/run", { method: "POST", body: JSON.stringify(req.body) });
  return await r.json();
});
await app.listen({ port: 8080 });

An unpaid call gets a 402; a paid one runs your agent. The agent's Python code does not change; the gateway is the paywall. Keep a free discovery route so callers can see what the agent does before paying.

Add a budget-aware read

A toolkit is a natural home for more than one related tool, so add a second one that lets the agent read its own spend limit. It is a plain GET to the spend-permissions endpoint, registered alongside pay_and_fetch, and it lets a planner avoid attempting a call it cannot afford.

PYTHON
    def check_spend_limit(self) -> str:
        """Return this agent's spend limit (per-transaction cap and period allowance)."""
        res = requests.get(
            f"https://api.blockchain0x.com/v1/agents/{self.agent_id}/spend-permissions",
            headers={"Authorization": f"Bearer {self.api_key}"}, timeout=30)
        return res.text  # per_tx_wei, allowance_wei, period_seconds

Register it in __init__ next to the pay tool, and the agent has both pay and read-limit in one toolkit. The limit is enforced on chain regardless, so the read is for smarter planning, not safety; the spend limit is the safety. Grouping the two is exactly what Agno's toolkit model is for, and it keeps the agent's whole payment surface in one place.

Compatibility

The integration works across Agno's surfaces because it lives in a toolkit (pay) or a gateway (earn), not in the framework internals.

Agno surface Works? Notes
Toolkit on an Agent Yes Add PaymentToolkit() to the agent's tools
Plain tool function Yes A toolkit is the tidy way to group it
Agno teams Yes One toolkit and proxy per agent
Earning from an agent endpoint Yes Front it with the Node gateway
Payment package language Node Python Agno talks to it over localhost

When this fits

The integration fits when an Agno agent needs to pay for what it calls, when you want to charge for what it serves, or both, and you are comfortable running one or two small Node processes alongside the Python. That covers most agent workloads that touch money: an agent paying for data, an agent selling a result, or a team that does both.

It fits less well when the agent never touches paid resources or when a single human-approved payment is the only money movement. For per-call machine payments at agent scale, the payment toolkit plus proxy, with an optional earn gateway, is the integration that fits Agno's lightweight, toolkit-based shape.

Pricing

Integration is free; you build it from open packages. What you pay is the wallet platform fee per agent on the pricing page: Free is $0 per agent per month at a 5% transaction fee, Pro is $9 at 2%, Business is $29 at 1%. Per-agent pricing means each agent that transacts, paying or earning, is billed on its own wallet, so a team where only some agents pay only incurs fees for those agents.

What to ship today

Write a PaymentToolkit, add it to an Agent, start a proxy with a sk_test_ key, and make one paid call on Base Sepolia. For a team, give each agent a toolkit pointed at its own proxy. To earn, front your agent with the Node gateway and confirm an unpaid call gets a 402. For sibling-framework overviews see crewai-payment-integration and autogen-payment-integration. Pricing is on the pricing page.

FAQ

Frequently asked questions.

Is there an Agno package from Blockchain0x?

No. Agno is Python and the x402 client and server adapter ship for Node, so there is no Python package to install. An Agno toolkit's tools call a small local Node proxy built on createX402Client from @blockchain0x/x402, and the proxy holds the wallet. There is no dedicated Agno adapter package; the toolkit plus proxy is the pattern.

How does an Agno agent pay for something?

You add a payment toolkit to the agent. One of its tools posts a target to a local Node proxy, which settles any HTTP 402 in USDC on Base through createX402Client and returns the result. Agno's tool-calling invokes the tool when a task needs a paid resource, so paying is just another tool the agent can use, bounded by the wallet's spend limit.

Why package payment as a Toolkit?

Because that is Agno's idiom for grouping related tools. A payment Toolkit can hold the pay tool and a read-the-limit tool together, give them shared configuration like which proxy to call, and be added to any agent in one line. It keeps payment as one reusable unit rather than loose functions scattered across agents.

Do agents in an Agno team share one wallet?

They should not. Give each agent its own payment toolkit pointed at its own proxy and key, so each pays from its own wallet with its own spend limit. In a team, that keeps spend attributed per agent and means a compromised agent can only spend its own balance, not the whole team's.

Which network and token does it use?

USDC, 6 decimals, on Base. A sk_test_ key (on the proxy) settles on Base Sepolia (eip155:84532), a sk_live_ key on Base mainnet (eip155:8453). The proxy reads the network from the key prefix, so the same toolkit works on either by swapping the proxy's key.

Create your free agent wallet in 5 minutes.

First payment confirmed in under ten minutes. Free to start.