Skip to main content
HomeLanding pagesAutoGen payment integration
LANDING PAGE

AutoGen payment integration

8 min read·Last updated June 2, 2026

Integrating payments into AutoGen means giving its agents a wallet to pay for what they call and, optionally, charging for what they produce. Because AutoGen is Python and the x402 client and adapter are Node, agents pay through a small local Node proxy registered as a function tool, and you earn by fronting an endpoint with a Node gateway. Both settle USDC on Base.

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.

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

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

PYTHON
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/wallet

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

FAQ

Frequently asked questions.

Is there an AutoGen package from Blockchain0x?

No. AutoGen is Python and the x402 client and server adapter ship for Node, so there is no Python package to install. Agents pay by calling a small local Node proxy built on createX402Client from @blockchain0x/x402, registered as an AutoGen function tool. The proxy holds the wallet and does the real payment work over localhost.

How does an AutoGen agent pay for something?

You register a function tool on the agent (commonly an AssistantAgent) whose body posts the target to a local Node proxy. The proxy settles any HTTP 402 in USDC on Base through createX402Client and returns the result. To the agent it is an ordinary tool that returns data; the payment happens inside the proxy, bounded by the wallet's spend limit.

Can an AutoGen agent also earn, not just pay?

Yes. To charge for what an agent or group produces, front its HTTP endpoint with a small Node gateway running createX402Plugin from @blockchain0x/x402. An unpaid request gets a 402; a paid one is proxied to the agent. Paying uses the proxy, earning uses the gateway, and both settle USDC on Base.

Do agents in a group chat share one wallet?

They should not. Run one proxy per agent with that agent's key, and register each agent's tool against its own proxy port. Each agent then pays from its own wallet with its own spend limit, so a GroupChat keeps per-agent attribution and a compromised agent can only spend its own balance.

Which network and token does it use?

USDC, 6 decimals, on Base. A sk_test_ key (on the proxy or gateway) settles on Base Sepolia (eip155:84532), a sk_live_ key on Base mainnet (eip155:8453). The network is read from the key prefix, so the same setup works on either by swapping the key.

Create your free agent wallet in 5 minutes.

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