What integration means
Integrating payments into AutoGen means two related things: giving its agents a wallet so they can pay for what they call, and, when you want it, charging other callers for what your agents produce. The first is the common case (an AutoGen agent paying a data API, a paid tool, or another agent); the second is the earn side, turning an agent or a group chat into a paid service.
This page is the integration reference: what the pieces are, how they fit, and where to go for each task. For the step-by-step walkthrough of giving an agent a wallet, see how-to-add-payments-to-autogen-agent; for the same overview in a sibling framework, see crewai-payment-integration. The payment API product page is the broader reference. Here the focus is the shape of an AutoGen integration end to end.
The Node proxy reality
Start with the one fact that shapes everything else: AutoGen 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 AutoGen directly.
Instead, the payment work runs in a small Node process and AutoGen 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, both keep every payment identifier on the verified Node surface, and both are the honest pattern until a Python client ships. Knowing this up front explains why the integration is "AutoGen function tool plus a Node process" rather than an import, and it is the same shape used across the Python-framework integrations.
The pay side
To let an AutoGen agent pay, register a function tool whose body calls the local proxy. The proxy is the ~30-line Node service from the walkthrough, built on createX402Client.
import requests
from autogen import AssistantAgent
def pay_and_fetch(url: str) -> str:
"""Fetch a URL, paying in USDC if it requires payment. Returns the body."""
res = requests.post("http://127.0.0.1:8787", json={"url": url}, timeout=30)
return res.text if res.status_code == 200 else f"Failed: {res.status_code}"
assistant = AssistantAgent(name="researcher")
assistant.register_for_llm(name="pay_and_fetch", description="Fetch a URL, paying in USDC if required.")(pay_and_fetch)The agent calls pay_and_fetch like any tool; the proxy settles any 402 in USDC on Base and returns the result. The payment is invisible to the planner, which sees a tool that returns data, and the wallet's spend limit is the backstop on what it can spend.
The earn side
To charge for what your AutoGen agent or group produces, put a small Node gateway in front of its HTTP endpoint. The gateway runs createX402Plugin, returns the 402, verifies payment, and proxies paid requests to your agent service.
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.20", 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.
Per-agent wallets in a group chat
AutoGen's strength is multi-agent group chats, and the integration respects that: each agent should have its own wallet, not a shared one. On the pay side, run one proxy per agent on its own port with that agent's key, and register each agent's pay_and_fetch against its own proxy port.
def make_pay_tool(port: int):
def pay_and_fetch(url: str) -> str:
res = requests.post(f"http://127.0.0.1:{port}", json={"url": url}, timeout=30)
return res.text if res.status_code == 200 else f"Failed: {res.status_code}"
return pay_and_fetch
researcher_pay = make_pay_tool(8787) # researcher's proxy/wallet
writer_pay = make_pay_tool(8788) # writer's proxy/walletTwo agents, two proxies, two wallets, the same factory. The dashboard attributes spend per agent, and a compromised agent can only spend its own balance. In a GroupChat, this keeps the books and the blast radius per agent rather than pooling everyone's money behind one key.
Verify on testnet first
Whichever side you wire, prove it on Base Sepolia before any real money moves. Use a sk_test_ key on the proxy or gateway, fund the agent's wallet with test USDC, and run the loop once. On the pay side, confirm the agent's pay_and_fetch call hits a 402, settles, and returns the result, then check the dashboard for a matching payment.sent on that agent. On the earn side, confirm an unpaid request gets a 402 and a paid one runs your agent, with the settlement landing on the receiving agent's profile.
That single end-to-end pass is the contract. Once it holds on testnet, swapping each key's prefix from sk_test_ to sk_live_ moves the same flow to Base mainnet with no other code change, since the network is read from the key. Do the pay side and the earn side as separate checks if you run both, so a failure points at one path rather than two.
Compatibility
The integration works across AutoGen's surfaces because it lives in a function tool (pay) or a gateway (earn), not in the framework internals.
| AutoGen surface | Works? | Notes |
|---|---|---|
AssistantAgent function tool |
Yes | Register pay_and_fetch on the agent |
UserProxyAgent executing tools |
Yes | It executes the function that calls the proxy |
GroupChat / GroupChatManager |
Yes | One proxy and tool per agent |
| Earning from an agent endpoint | Yes | Front it with the Node gateway |
| Payment package language | Node | Python AutoGen talks to it over localhost |
When this fits
The integration fits when AutoGen agents need to pay for what they call, when you want to charge for what they produce, or both, and you are comfortable running one or two small Node processes alongside the Python. That is most agent workloads that touch money: a research group paying for data, an agent selling its output, a marketplace of agents that both buy and sell.
It fits less well when the agents never touch paid resources (no wallet needed) or when a single large human-approved payment is the only money movement (a traditional rail may suit). For per-call machine payments at agent scale, the proxy-and-gateway integration is the path that fits AutoGen's Python, multi-agent 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 group where only some agents move money only incurs fees for those agents.
What to ship today
For the pay side, start a proxy with a sk_test_ key, register pay_and_fetch on an AssistantAgent, and make one paid call on Base Sepolia; the walkthrough is how-to-add-payments-to-autogen-agent. For the earn side, front an endpoint with the Node gateway and confirm an unpaid call gets a 402. For the sibling-framework overview see crewai-payment-integration. Pricing is on the pricing page.