What integration means
Integrating payments into n8n means two related things: letting a workflow (often via its AI Agent node) pay for what it calls, and, when you want it, charging other callers for running a workflow. The first is the common case, an agent or workflow paying a data API or another service; the second is the earn side, turning a workflow into a paid endpoint.
This page is the integration reference, framed for n8n's no-code model. For the same overview in code-first frameworks, see crewai-payment-integration and agno-payment-integration. The payment API product page is the broader reference. Here the focus is how payment fits a workflow tool, where you wire nodes rather than write agent code.
A service the workflow calls
The fact that shapes the integration is that n8n is a no-code workflow tool, so you do not import a payment library into a workflow; you run a small x402 service and have the workflow call it over HTTP. The service is the same small Node process used across integrations, built on createX402Client for paying and createX402Plugin for earning, holding the wallet and doing the real work.
n8n then talks to it with the nodes it already has: an HTTP Request node (or the HTTP Request tool on the AI Agent node) to pay, and a Webhook node plus a gateway to earn. This keeps the workflow no-code while every payment identifier stays on the verified Node surface inside the service. If your n8n instance allows custom code, a Code node could call the client directly, but the HTTP-Request-to-a-service pattern is the clean default and works on any instance.
The pay side
To let an n8n AI Agent node pay, add an HTTP Request tool to the agent pointed at your x402 service. The service exposes one endpoint that takes a target URL, settles any payment, and returns the result.
AI Agent node
└─ Tool: HTTP Request
Method: POST
URL: http://127.0.0.1:8787
Body (JSON): { "url": "{{ the URL the agent wants to fetch }}" }
→ returns the response body, having settled any 402 in USDC on BaseThe service behind that URL is the proxy built on createX402Client: it receives the target, answers the 402 by settling in USDC on Base, retries, and returns the body. To the agent it is an ordinary HTTP Request tool that returns data; the payment happens in the service, and the wallet's spend limit is the backstop. A plain workflow can use an HTTP Request node the same way when no agent is involved, paying for a step in an automation.
The earn side
To charge for running a workflow, give it a Webhook node so it has an HTTP endpoint, then front that endpoint with a small Node gateway running createX402Plugin.
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 /run": { amountUsdc: "0.10", payToAddress: process.env.B0X_PAYTO_ADDRESS!, paymentRequestId: "pr_n8n" } },
});
app.post("/run", async (req) => {
const r = await fetch("http://127.0.0.1:5678/webhook/your-workflow", { method: "POST", body: JSON.stringify(req.body) });
return await r.json();
});
await app.listen({ port: 8080 });An unpaid call to the gateway gets a 402; a paid one triggers your n8n webhook and returns its result. The workflow does not change; the gateway is the paywall in front of its webhook. Keep a free route describing what the workflow does so callers can decide before paying.
Keep keys in credentials
n8n has a credentials system, so use it rather than pasting keys into nodes. Store the x402 service URL and any auth in n8n credentials and reference them from the HTTP Request node, and keep the wallet's sk_ key only in the service's own environment, never in a workflow. The workflow should know the service's address, not the wallet key.
That separation matters because workflows get exported, shared, and duplicated, and a key pasted into a node travels with them. Keeping the key in the service and only a service URL in the workflow means sharing a workflow never leaks a wallet. Bind the service to localhost or a private network so only your n8n instance can reach it, and treat it as the credential-holding component it is. This keeps the no-code convenience without turning a shared workflow into a leaked key.
Pay per step, earn per run
It helps to keep the two sides straight, because n8n makes both easy to reach. On the pay side, the unit is a step: a single HTTP Request call to the service settles one payment for one fetched resource, so a workflow that calls three paid APIs pays three times, each bounded by the wallet limit. On the earn side, the unit is a run: the gateway charges once for triggering the whole workflow through its webhook, regardless of how many steps run inside.
That asymmetry is usually what you want. You pay granularly for the inputs your workflow consumes and charge a single clear price for the outcome it produces. Set the per-run price above the typical per-step costs the workflow incurs, and the workflow earns more than it spends on a normal run, which is the simple economics that makes a paid n8n workflow worth running at all.
Compatibility
The integration works across n8n's surfaces because it uses the nodes n8n already has to call a service.
| n8n surface | Works? | Notes |
|---|---|---|
| AI Agent node + HTTP Request tool | Yes | The agent calls the x402 service to pay |
| Plain HTTP Request node | Yes | Pay for a step in any workflow |
| Webhook node + Node gateway | Yes | Charge per workflow run |
| Code node calling the client | Yes | Only if your instance allows the package |
| Payment package language | Node | The service and gateway are small Node processes |
When this fits
The integration fits when an n8n workflow or its AI Agent needs to pay for what it calls, when you want to charge for running a workflow, or both, and you can run a small service alongside n8n. That suits automations that hit paid APIs, agent nodes that pay for data, and workflows you want to sell access to per run.
It fits less well when nothing in the workflow touches paid resources or when a single human-approved payment is the only money movement. For per-call machine payments in a no-code workflow, the HTTP-Request-to-a-service pattern, plus a gateway to earn, is the integration that fits n8n without leaving its visual model.
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 you pay for the workflows that actually move money.
What to ship today
Run a small x402 service with a sk_test_ key, add an HTTP Request tool to an AI Agent node pointed at it, and make one paid call on Base Sepolia. To earn, put a Webhook node on a workflow and front it with the Node gateway. Keep the wallet key in the service, not the workflow. For code-first overviews see crewai-payment-integration and agno-payment-integration. Pricing is on the pricing page.