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.
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.
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.
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.
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_secondsRegister 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.