What the integration covers

The LangChain payment integration is a pattern, not a package. You wrap the x402 client from @blockchain0x/x402 inside a LangChain Tool, and that gives a LangChain agent four capabilities it lacks by default: the ability to pay third parties per tool call, an identity counterparties can verify, a wallet-enforced spend limit, and an audit trail indexed by agent rather than by user. None of it touches the agent's reasoning loop, the prompt chain, or the model behind it.

This is the integration-cluster reference: what the integration is, what it touches, and the trade-offs against alternatives. For the task-oriented walkthrough (install, wrap a tool, ship), the companion how-to-add-payments-to-langchain-agent is the step-by-step version. The LangChain integration page is the canonical feature reference.

Compatibility matrix

Because you are wrapping a fetch inside a Tool, anything that calls the Tool works. What that covers today:

What is not in scope:

• Tools that bypass the Tool interface and call HTTP directly. The wrapper lives in the Tool's func, so wire the payment API yourself there.
• Pure LCEL chains with no Tools. There is no Tool boundary to attach a per-call price to.

Surface area in one screen

The whole integration fits on one screen. Build the client once, wrap its fetch in a Tool.

import { DynamicStructuredTool } from "@langchain/core/tools";
import { createClient } from "@blockchain0x/node";
import { createX402Client } from "@blockchain0x/x402/client";
import { z } from "zod";

const sdk = createClient({ apiKey: process.env.B0X_API_KEY! });
const fetchWithPay = createX402Client({ sdk });

const paidTool = new DynamicStructuredTool({
  name: "get_quote_realtime",
  description: "Fetch a real-time quote for a stock ticker.",
  schema: z.object({ ticker: z.string() }),
  func: async ({ ticker }) => {
    const res = await fetchWithPay(`https://quotes.example.com/v1/quote?ticker=${ticker}`);
    return res.ok ? await res.text() : `Lookup failed: ${res.status}`;
  },
});

The full walkthrough, including the webhook and the spend-limit pieces, is in how-to-add-payments-to-langchain-agent. The other half of the integration is the spend limit, which you set in the dashboard and read back over the API:

const res = await fetch(
  `https://api.blockchain0x.com/v1/agents/${agentId}/spend-permissions`,
  { headers: { Authorization: `Bearer ${process.env.B0X_API_KEY!}` } },
);
const permissions = await res.json(); // allowance_wei, per_tx_wei, period_seconds, ...

That is the entire surface. No new executor, no replacement agent, no wrapper around LangChain itself, just a Tool whose func pays and a limit you set once.

What the integration does not touch

The pattern stays narrow on purpose. These parts of your stack are untouched:

• The LLM. GPT-4o, Claude, Llama, Mistral, all unchanged.
• The prompt. No extra system-prompt scaffolding; the tool description is what you wrote.
• The executor. AgentExecutor, LangGraph, custom, all see a normal Tool.
• The memory layer. Buffer, vector-store, or custom memory operates independently.
• Streaming, callbacks, tracing. LangSmith, OpenTelemetry, and custom callbacks work as before.
• Other tools. Unwrapped search and retrieval tools coexist with paid ones on the same agent.

It is additive. Introduce it on one tool, validate, expand. There is no rip-and-replace step.

When this is the right integration

Three situations where this pattern beats the alternatives.

Your agent calls paid tools or other paid agents. The wrapper turns each paid call into a wallet-settled transaction. Without it you either bake one credential per provider into each tool, with no unified limit, or proxy every call through your backend, which is more code and loses per-tool attribution. This pattern collapses both.

You want per-agent isolation in a multi-agent system. Each agent or LangGraph node gets its own wallet, its own limit, its own audit trail. A prompt-injected agent spends only its own allowance. Without isolation, one compromised agent risks the whole workspace balance.

Your agent is itself a paid service. Flip the direction: gate your agent's HTTP surface with the x402 server adapter so external callers pay it. Same protocol, other side of the call graph. See how-to-add-payments-to-mcp-server for that receive-side shape.

Where it is not the right pick: a pure-internal agent with one trusted provider and a shared key (it adds nothing), a static LCEL chain with no Tools (nothing to wrap), or a product where a human is billed via Stripe (use the Stripe-to-x402 migration path instead).

A quick way to decide: count the distinct paid endpoints your agent calls and ask whether they share one credential. One endpoint, one key, one trusted provider means you do not need this yet. Two or more providers, or any payee you do not fully control, or any plan to let other agents pay you, and the wallet pattern starts paying for itself almost immediately, because it replaces N per-provider credential paths with one identity and one enforced limit.

Pricing and tier choices

The pattern itself is free; you are just writing code against open packages. What you pay is the wallet platform fee, set by tier on the pricing page: Free is $0 per agent per month at a 5% transaction fee, Pro is $9 per agent per month at 2%, and Business is $29 per agent per month at 1%. Per-agent pricing means you pay for the agents that actually transact, not a flat platform seat.

For a single agent at modest volume, Free is enough to ship. The rough crossover where Pro pays for itself is a few hundred dollars of monthly transaction volume: below that, Free's 5% is cheaper than Pro's monthly fee plus 2%; above it, Pro wins. Run a week on Free, read your real volume, then decide. Do not pre-optimize the tier before you have numbers.

Migration from a homegrown setup

Teams that already built ad-hoc payment glue for a LangChain agent (per-tool credentials, a backend proxy, a hand-rolled rate limiter) usually migrate in an afternoon. The shape:

• Replace your custom tool wrapping with a fetchWithPay call inside the Tool's func. One client handles every paid call.
• Move per-tool credentials out of env vars. The agent's wallet is the single payment identity from then on.
• Delete the agent-side rate limiter. Set the limit in the dashboard instead, where the wallet enforces it server-side, which is the only place a limit actually holds against prompt injection.
• Feed your audit log from the payment.sent and payment.received webhook events, verified with webhooks.verify, rather than a custom log the agent writes itself.

A homegrown setup of a few hundred lines typically shrinks to a few dozen, with stronger guarantees, because policy enforcement moves out of agent-side code and into the wallet. For the parallel pattern on CrewAI, see crewai-payment-integration. For the broader category, the payment API page is the reference.