Cómo agregar pagos x402 a un servidor MCP: guía para builders sobre pagos de agentes
Escrito por Alchemy
La mayoría de las APIs cobran haciéndote registrarte primero: crear una cuenta, obtener una clave, recibir la factura después. x402 se salta todo eso. Un servidor puede cobrar por solicitud en su lugar, sin registro, sin clave y sin factura. Y ya está funcionando en producción: Coinbase lo lanzó en mayo de 2025, Cloudflare lo integró en su Agents SDK, y nuestro agent gateway lo usa para cobrarles a los agentes por RPC y acceso a datos.
Esta guía es para cualquiera que esté construyendo cualquiera de los dos lados de ese intercambio: un servidor MCP o una API que quiera cobrar por llamada, o un agente que necesite pagar una. Vamos a recorrer el ciclo de solicitud y respuesta, y luego mostrar código real para cobrar por una tool call, medir y liquidar por llamada en USDC, darle a un agente una wallet con la cual pagar, y dónde encajan otros protocolos de pago como AP2.
¿Qué hace x402 exactamente?
HTTP 402 Payment Required existe en la especificación HTTP desde los años 90 y nunca se implementó. x402 es el protocolo que finalmente lo usa:
- Un servidor responde a una solicitud sin pago con el estado 402 y un precio legible por máquina
- El cliente adjunta un pago firmado y reintenta
- El servidor verifica, liquida y devuelve el recurso en el mismo intercambio
No hay sesión, tarjeta almacenada ni dashboard, y la wallet es la cuenta. En x402 v2, la información relevante se almacena en headers HTTP:
Los tres headers nunca cambian. Lo que cambia es el campo scheme dentro del JSON que lleva PAYMENT-REQUIRED, que le indica al cliente qué modelo de facturación usa esa llamada en particular. En todos los esquemas, la misma tercera parte hace la verificación y el movimiento de dinero: un facilitator, un servicio que verifica el pago firmado del cliente y envía la liquidación onchain, de modo que ni el vendedor ni el cliente tienen que hacer ninguna de las dos cosas por sí mismos. Lo que difiere de un esquema a otro es solo qué verifica el facilitator y cuándo liquida.
La mayoría de las llamadas usan exact: el precio es fijo y se conoce de antemano, así que el cliente firma por ese monto exacto y se liquida ese monto exacto. El payload se ve así, recortado a los campos que importan. amount es 10,000 unidades atómicas, que equivale a $0.01 USDC:
{
"accepts": [{
"scheme": "exact",
"amount": "10000",
"asset": "0x036C...F7e",
"payTo": "0x2096...87C"
}]
}Algunas llamadas cuestan un monto variable que solo se conoce después de que se completa el trabajo, como salidas de un LLM facturadas por tokens generados. Para esos casos, el servidor usa upto. El payload se ve casi idéntico, pero amount ahora representa un tope que el cliente acepta, no un precio. Aquí ese tope es $5.00:
{
"accepts": [{
"scheme": "upto",
"amount": "5000000",
"asset": "0x036C...F7e",
"payTo": "0x2096...87C"
}]
}El cliente firma una sola vez contra ese tope. Después de que el servidor hace el trabajo, el facilitator liquida el monto real (digamos $1.20 de uso real) y verifica que esté en o por debajo del tope firmado antes de mover cualquier dinero. El cliente nunca firma dos veces; solo el paso de liquidación completa el número real.
Un tercer esquema, batch-settlement, es para cargos de alta frecuencia y menos de un centavo, donde pagar gas fees en cada llamada costaría más que la llamada misma. En el esquema de x402, el comprador deposita una vez en un contrato de escrow, firma vouchers off-chain por solicitud, y los vendedores los redimen en lotes onchain. Circle Gateway usa un patrón de nanopagos relacionado para la misma función.
El facilitator nunca retiene fondos por sí mismo; solo verifica instrucciones firmadas y las ejecuta. x402.org opera un facilitator público gratuito solo para desarrollo y testnet, y el CDP de Coinbase opera un facilitator de producción alojado con revisión de cumplimiento. Puedes apuntar tu código a cualquiera de los dos.
¿Cómo funciona el ciclo de solicitud y respuesta de x402?
El handshake tiene nueve pasos:
- El cliente solicita un recurso sin ningún pago adjunto.
- El servidor responde
402 Payment Requiredcon un precio, una dirección de destino y los esquemas de pago que acepta. - El cliente firma un pago para uno de los esquemas aceptados y reintenta la solicitud con la firma adjunta.
- El servidor le pide al facilitator que verifique el pago firmado contra sus requisitos declarados.
- El facilitator devuelve un resultado de verificación.
- El servidor hace el trabajo (ejecuta la query, llama al modelo, genera el reporte).
- El servidor le pide al facilitator que liquide el pago onchain.
- El facilitator devuelve el resultado de la liquidación.
- El servidor devuelve el recurso, junto con el recibo de liquidación.
Sobre HTTP, ese ciclo se ejecuta mediante headers HTTP (PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE). Sobre MCP, esos mismos nueve pasos se ejecutan sobre JSON en su lugar:
- Una llamada sin pago devuelve un resultado con
isError: truey un payloadPaymentRequired(equivalente aPAYMENT-REQUIRED) - El cliente reintenta la misma llamada con el pago firmado adjunto en
_meta["x402/payment"](equivalente aPAYMENT-SIGNATURE) - El servidor devuelve el resultado real con la información de liquidación en
_meta["x402/payment-response"](equivalente aPAYMENT-RESPONSE)
¿Cómo agrego pagos con x402 a un servidor MCP?
Este ejemplo refleja un caso real común: un servidor MCP con una mezcla de tools pagadas y gratuitas, como un servidor de investigación o datos que ofrece búsquedas básicas gratis pero cobra por un reporte generado más profundo.
En este ejemplo, generate_report cuesta $0.01 por llamada y ping se mantiene gratis, construido sobre los x402 Foundation SDKs abiertos (agnósticos al facilitator, así que puedes empezar contra el facilitator público gratuito y cambiar a uno comercial después) con una smart account de Wallet APIs como la dirección que recibe el pago.
Primero, aprovisiona la wallet que recibirá el pago. @alchemy/wallet-apis (v5) te da una dirección de smart account sin tocar una clave privada en tu servidor:
// wallet.ts
import { createServerSigner } from "@account-kit/signer";
import { createSmartWalletClient, alchemyWalletTransport } from "@alchemy/wallet-apis";
import { baseSepolia } from "viem/chains";
const signer = await createServerSigner({
auth: { accessKey: process.env.ALCHEMY_ACCESS_KEY! },
connection: { apiKey: process.env.ALCHEMY_API_KEY! },
});
const walletClient = createSmartWalletClient({
transport: alchemyWalletTransport({ apiKey: process.env.ALCHEMY_API_KEY! }),
chain: baseSepolia,
signer,
});
export const receiverAccount = await walletClient.requestAccount();
// receiverAccount.address is the payTo address for every quote you issue belowAhora conecta esa dirección a una tool MCP protegida por x402. @x402/core construye y verifica los requisitos de pago, @x402/evm implementa el esquema exact para chains EVM, y @x402/mcp envuelve un tool handler para que una función simple se convierta en una pagada:
// server.ts
import { createServer } from "node:http";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { x402ResourceServer } from "@x402/core/server";
import { HTTPFacilitatorClient } from "@x402/core/facilitator";
import { createPaymentWrapper } from "@x402/mcp";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { z } from "zod";
import { receiverAccount } from "./wallet";
// Base Sepolia for testing; swap to eip155:8453 for Base mainnet
const NETWORK = "eip155:84532";
// Start against the free public facilitator, then swap the url for a
// commercial facilitator (compliance screening, higher throughput, an
// SLA) for production.
const facilitator = new HTTPFacilitatorClient({
url: "https://x402.org/facilitator",
});
const resourceServer = new x402ResourceServer(facilitator);
resourceServer.register(NETWORK, new ExactEvmScheme());
await resourceServer.initialize();
const accepts = await resourceServer.buildPaymentRequirements({
scheme: "exact",
network: NETWORK,
payTo: receiverAccount.address,
price: "$0.01",
});
const paid = createPaymentWrapper(resourceServer, { accepts });
const server = new McpServer({
name: "paid-report-server",
version: "1.0.0",
});
server.tool(
"generate_report",
"Generate a research report on a topic. Costs $0.01 in USDC.",
{ topic: z.string() },
paid(async ({ topic }) => ({
content: [
{
type: "text",
text: "Report on " + topic + ": trending up, no anomalies.",
},
],
})),
);
server.tool("ping", "Free health check", {}, async () => ({
content: [{ type: "text", text: "pong" }],
}));
const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined,
});
await server.connect(transport);
createServer((req, res) => {
const path = new URL(req.url ?? "/", "http://localhost").pathname;
if (path === "/mcp") {
void transport.handleRequest(req, res);
return;
}
res.writeHead(404).end();
}).listen(3000);server.connect(transport) solo conecta el protocolo al transport. El listener HTTP de Node es lo que realmente abre el puerto 3000 y reenvía /mcp hacia transport.handleRequest(...), que es el endpoint que llama el cliente de abajo.
Todo lo que no envolviste con paid(...) se mantiene gratis, así que puedes mezclar tools con precio y sin precio en el mismo servidor. Pruébalo con curl o cualquier cliente MCP sin pago adjunto primero: deberías recibir un resultado de pago requerido en lugar del reporte, lo cual confirma que la protección está activa antes de conectar un cliente que sí pague.
Si prefieres no gestionar una relación con un facilitator tú mismo, y quieres aceptar x402 junto con otros protocolos de pago para agentes emergentes sin elegir uno, para eso está AgentPay: apúntalo a tu endpoint existente y él maneja la traducción de protocolos entre x402, ACP, MPP y AP2 desde una sola integración.
¿Cómo mido y cobro a los agentes por llamada?
Un precio fijo por llamada es el caso base. Los servidores en producción también necesitan rastrear quién pagó y cuánto, y no deberían depender del reporte de liquidación del facilitator como única prueba de que el dinero realmente se movió. Para verificarlo, lleva registro de:
- Forma del precio. Usa
exactpara un precio fijo por llamada, el patrón de arriba. Usauptocuando el costo varía según la llamada (un reporte más largo cuesta más tokens que uno corto) y quieres autorizar un tope de antemano pero liquidar el uso real. Usabatch-settlementcuando las llamadas son frecuentes y lo suficientemente baratas como para que liquidar cada una onchain individualmente costaría más que la llamada misma. - Atribución y registro contable. El payload de pago que firma el cliente incluye la dirección que paga. Regístrala junto con el nombre de la tool, el precio y el resultado de liquidación cada vez que una llamada se liquide, y tendrás un libro de uso por agente gratis:
const paid = createPaymentWrapper(resourceServer, {
accepts,
hooks: {
onAfterSettlement: async ({ toolName, settlement }) => {
await usageLedger.record({
payer: settlement.payer,
tool: toolName,
amountUsd: 0.01,
txHash: settlement.transaction,
settledAt: new Date(),
});
},
},
});No te quedes solo confiando en la respuesta de liquidación como tu única señal. Un facilitator puede reportar settled: true mientras una solicitud todavía devuelve un código distinto de 200, o viceversa; verifica ambos antes de contar el ingreso. Para un pase de reconciliación periódico, nuestra Transfers API te permite confirmar de forma independiente qué llegó realmente a tu dirección receptora, lo cual detecta el caso poco frecuente en que el reporte de liquidación de un facilitator y la realidad onchain no coinciden:
const res = await fetch("https://base-sepolia.g.alchemy.com/v2/" + apiKey, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
method: "alchemy_getAssetTransfers",
params: [{
toAddress: receiverAccount.address,
category: ["erc20"],
contractAddresses: [USDC_ADDRESS],
withMetadata: true,
}],
id: 1,
}),
});
const { result } = await res.json();
// result.transfers is the ground truth for what actually arrived onchain,
// independent of what any single facilitator reported settling¿Cómo le doy a un agente una wallet en USDC con la cual pagar?
Un agente que necesita pagarle a un endpoint con paywall, tuyo o de cualquier otra persona, necesita una wallet fondeada y código (o una CLI) que pueda firmar un pago cuando recibe un 402.
Para un agente operado por un humano o probado localmente, el camino más rápido es la Alchemy CLI. Crea una sesión de wallet con alcance limitado que el agente puede usar sin tocar nunca una clave privada:
npm i -g "@alchemy/cli@latest"
alchemy auth
alchemy wallet connect --mode session --instance-name "my-agent"
# decode a quote without paying anything, useful for a first look at an unfamiliar endpoint
alchemy x402 request "https://api.example.com/report" --estimate
# pay it for real, with a hard spend cap; required for any non-interactive run
alchemy --json --no-interactive x402 request "https://api.example.com/report" --max-payment 0.01--max-payment establece el máximo que la CLI pagará jamás, y nada de lo que el servidor devuelva puede subir ese número. Si ejecutas el comando sin ningún humano ahí para aprobarlo (--no-interactive) y olvidas fijar --max-payment, la CLI simplemente se detiene en lugar de pagar, porque el precio en una respuesta 402 proviene de un servidor que no controlas, y nada debería pagarlo sin que tu límite lo verifique primero. Consulta los docs de la CLI de pagos x402 para ver la superficie completa de comandos.
Para un agente backend totalmente autónomo que necesita pagar sin que un humano apruebe cada sesión, envuelve fetch (o tu cliente MCP) con un manejador de pagos respaldado por un signer. Si el agente está llamando endpoints HTTP pagados, usa @x402/fetch:
import { x402Client } from "@x402/core/client";
import { wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";
const signer = privateKeyToAccount(process.env.AGENT_WALLET_KEY as `0x${string}`);
const client = new x402Client();
registerExactEvmScheme(client, { signer });
const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const response = await fetchWithPayment("https://api.example.com/report");Si el agente está llamando tools pagadas en un servidor MCP en lugar de un endpoint HTTP simple, envuelve el cliente MCP de la misma manera en lugar de fetch. CDP documenta el mismo patrón para compradores en MCP:
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { x402Client } from "@x402/core/client";
import { wrapMCPClientWithPayment } from "@x402/mcp";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";
const signer = privateKeyToAccount(
process.env.AGENT_WALLET_KEY as `0x${string}`,
);
const paymentClient = new x402Client();
registerExactEvmScheme(paymentClient, { signer });
const mcp = wrapMCPClientWithPayment(
new Client(
{ name: "my-agent", version: "1.0.0" },
{ capabilities: {} },
),
paymentClient,
{ autoPayment: true },
);
await mcp.connect(
new StreamableHTTPClientTransport(
new URL("http://localhost:3000/mcp"),
),
);
const report = await mcp.callTool({
name: "generate_report",
arguments: { topic: "USDC on Base" },
});Una clave privada sin cifrar en una variable de entorno puede estar bien para una primera prueba en testnet, pero es inaceptable en producción. Para un agente en producción, coloca una smart account de Wallet APIs o una sesión de Agent Wallet detrás de la misma interfaz de signer, de modo que el agente pueda firmar bajo las reglas que establezcas sin retener nunca la clave privada él mismo.
¿Cómo liquido en USDC sin que los agentes tengan que retener gas?
Toda transacción onchain necesita gas: un token nativo como ETH, en manos de quien envía la transacción, para pagarle a la network que la procese. Eso es un problema para un agente que paga por llamada a la API. No puede detenerse a adquirir un token de gas antes de cada pago de $0.01, y mantener una reserva de ese token por si acaso anula el sentido de un flujo automatizado.
La liquidación en USDC evita esto con EIP-3009 (transferWithAuthorization): permite que el agente firme una transferencia sin enviar él mismo una transacción ni retener ningún token de gas. El agente solo firma; el facilitator es quien envía esa transacción onchain y paga su gas. Las liquidaciones exact y upto típicamente usan EIP-3009 para USDC y Permit2 para cualquier otro ERC-20 que no soporte EIP-3009. batch-settlement todavía hace que el agente firme por solicitud, y después el vendedor redime un lote onchain más tarde en lugar de liquidar cada llamada por separado. Circle Gateway usa un patrón de nanopagos relacionado para ese mismo caso de alta frecuencia. Que USDC tenga precio en dólares también simplifica las cosas: ninguno de los dos lados tiene que hacer cálculos de tipo de cambio en un cargo de $0.01.
Eso cubre el pago en sí. Si tu dirección receptora es una wallet plana externally-owned, esa es toda la historia: simplemente recibe USDC, sin ningún paso de deployment involucrado. Si es una smart account como la que se construyó antes en esta guía, sí toca gas en otros dos momentos fuera del flujo de x402: una vez para desplegarse onchain la primera vez que recibe fondos, y otra vez cada vez que barres el USDC recolectado hacia una wallet de tesorería. Nuestro Gas Manager puede patrocinar gas para esos dos momentos; de cualquier forma, no está involucrado en liquidar el pago de x402 en sí, ya que el facilitator ya cubre eso.
Base es la network por defecto en la mayoría de las herramientas, ya que ahí es donde funciona el facilitator de referencia original y donde ya viven la mayoría de las integraciones de x402 existentes, pero x402 v2 no está limitado a Base. También cubre cualquier chain EVM (incluyendo Ethereum mainnet y Polygon) además de Solana, TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium y XRPL, con más chains esperadas conforme los facilitators agreguen soporte. Que "pagar en USDC en Ethereum" funcione específicamente para ti hoy depende de si el facilitator que elegiste implementó esa network, no del protocolo en sí.
¿Dónde encaja x402 en el stack más amplio de pagos para agentes?
x402 es un protocolo dentro de un campo en rápido movimiento, no el único.
- Stripe y Tempo construyeron MPP como una versión del mismo patrón 402 que no está atada a stablecoins, donde un vendedor puede aceptar tarjetas o stablecoins bajo el mismo flujo (y MPP es compatible hacia atrás con el flujo
exactde x402, así que un cliente construido para uno generalmente puede hablar con un servidor construido para el otro). - ACP de OpenAI y Stripe cubre un caso distinto: checkout para compras impulsadas por IA en lugar de pagos de API por solicitud.
- AP2 de Google cubre un problema completamente diferente: probar que un usuario autorizó a un agente a gastar, usando Checkout mandates y Payment mandates firmados, sin importar si el método de pago es una tarjeta, una transferencia bancaria o una stablecoin. AP2 no es un riel de liquidación competidor; cuando un flujo de AP2 necesita liquidar en stablecoins, lo hace a través de la extensión A2A x402 que Google construyó junto con Coinbase, la Ethereum Foundation y MetaMask, así que x402 es el riel cripto por debajo en lugar de una alternativa.
A medida que evoluciona el panorama de protocolos, AgentPay existe como un proxy agnóstico al protocolo que ayuda a los comercios a integrarse una sola vez y soportar todos ellos.
Si estás eligiendo entre x402 y MPP para un proyecto específico, consulta nuestra comparación x402 vs MPP. Si estás eligiendo un proveedor de infraestructura, consulta nuestra comparación de capas de wallet, gas y datos entre Alchemy, Coinbase's Developer Platform, Circle, Crossmint, Privy y Turnkey.
Errores comunes que evitar
- Nunca firmes una cotización que no hayas verificado tú mismo. Una respuesta 402 es solo un número enviado por un servidor que no controlas; confirma la network, el asset y el monto antes de firmar, de la misma forma en que la Alchemy CLI verifica una cotización localmente antes de firmar contra ella.
- No trates una respuesta 200 como prueba de pago, ni el
settled: truede un facilitator como la única prueba que necesitas. Verifica el recibo de liquidación en sí, y reconcilia periódicamente contra la realidad onchain con nuestra Transfers API como se mostró arriba. - No te saltes el límite de gasto en un agente autónomo. Sea cual sea tu equivalente de
--max-payment, fíjalo en el valor más pequeño que cumpla con el trabajo, ya que es lo único que se interpone entre tu agente y un servidor que devuelve una cotización inflada. - No construyas tu propio facilitator a menos que verificar firmas, revisar transacciones y enviar la liquidación onchain a escala sea de verdad tu producto. Apunta a uno alojado y dedica el tiempo de ingeniería a tu servicio real en su lugar.
- No asumas que "soporta x402" significa "soporta cada network y esquema". Confirma qué esquemas (
exact,upto,batch-settlement) y qué chains implementa realmente tu facilitator específico y tu contraparte antes de lanzar contra ellos; la página de soporte de networks y tokens es la fuente de verdad.
Preguntas frecuentes
¿Cómo agrego pagos con x402 a un servidor MCP?
Envuelve el tool handler que quieres cobrar con un wrapper de pago del paquete @x402/mcp de la x402 Foundation, respaldado por un servidor registrado con un facilitator y que sabe qué dirección de wallet debe recibir el pago. El ejemplo completo funcional está arriba; todo lo demás en el servidor permanece gratis a menos que también lo envuelvas.
¿Qué infraestructura necesitan los agentes de IA para pagar APIs por x402 usando stablecoins?
Tres piezas: una wallet que retenga y pueda firmar por USDC, una librería de pagos firmados o CLI que hable el handshake de x402, y un facilitator del lado del vendedor para verificar y liquidar. No necesitas correr tu propio node de blockchain ni retener tokens de gas; el facilitator cubre el gas de la liquidación.
¿Cuál es la mejor forma de darle a un agente de IA la capacidad de enviar pagos en USDC en Ethereum?
Dale una wallet con la que pueda firmar directamente, ya sea una sesión con alcance limitado como un Alchemy Agent Wallet o una smart account programática mediante nuestras Wallet APIs, y combínala con una librería cliente de x402 como @x402/fetch o el comando x402 request de la Alchemy CLI. Confirma primero que tu facilitator objetivo realmente soporta la network específica; x402 v2 cubre Ethereum, pero la cobertura depende del facilitator, no solo del protocolo.
¿Cómo le doy a un agente de IA una wallet en USDC para pagos onchain?
Para pruebas o un agente supervisado por un humano, alchemy wallet connect --mode session (parte de la Alchemy CLI) crea una sesión de wallet con alcance limitado y revocable en minutos, sin que ninguna clave privada quede expuesta al agente. Para un agente backend totalmente autónomo, aprovisiona una smart account mediante @alchemy/wallet-apis o una wallet gestionada por CDP y entrega su signer a una librería cliente de x402.
¿Cómo pagan los agentes por acceso a APIs usando x402?
El agente llama a la API, recibe un 402 con un precio y una dirección de destino, firma un pago para un esquema que el servidor acepta, y reintenta la misma solicitud con el pago firmado adjunto. El servidor verifica y liquida a través de un facilitator y devuelve el recurso en el mismo round trip.
¿Cómo mido y cobro a los agentes de IA por uso de API con pagos cripto?
Usa el esquema exact para un precio fijo por llamada, upto cuando el costo varía según el uso, y registra la dirección pagadora de cada pago liquidado junto con la tool o endpoint por el que pagó. Reconcilia ese registro periódicamente contra el historial de transferencias onchain, por ejemplo con nuestra Transfers API, en lugar de confiar en un solo reporte de liquidación.
¿Cuál es la mejor infraestructura para pagos cripto de agentes y comercio onchain?
Depende de cuánto del stack (custodia de wallet, el riel de pago, gas y datos onchain) quieras de un solo proveedor versus ensamblarlo de varios. Una comparación completa de Alchemy, Coinbase's Developer Platform, Circle, Crossmint, Privy y Turnkey contra exactamente ese stack está en nuestra página de comparación de infraestructura.
¿Qué es AP2 y cómo se relaciona con x402?
AP2 es el framework agnóstico al pago de Google para probar que un usuario autorizó a un agente a gastar, usando Checkout mandates y Payment mandates firmados. Se ubica por encima de x402 en lugar de reemplazarlo: cuando un flujo de AP2 necesita liquidar en stablecoins, lo hace a través de la extensión A2A x402 que Google construyó junto con Coinbase, la Ethereum Foundation y MetaMask.
¿Qué es el comercio agéntico y qué infraestructura requiere?
El comercio agéntico consiste en agentes de IA descubriendo, pagando por y recibiendo pago por bienes, servicios y acceso a APIs sin que un humano haga clic en un checkout cada vez. Requiere una wallet fondeada, un riel de pago como x402 o MPP para mover valor por solicitud, manejo de gas para que el agente no necesite un token nativo, y suficientes datos onchain o de catálogo para que el agente decida por qué pagar y confirme que llegó.
¿Cómo implemento el protocolo de pago x402 para que un agente acceda a servicios onchain con paywall?
En el lado del cliente, instala una librería cliente de x402 (@x402/fetch, @x402/axios, o el wrapper de cliente MCP), registra un esquema de pago con un signer de wallet, y envuelve con él tu cliente HTTP o cliente MCP existente; el pago ante un 402 se vuelve automático a partir de ahí. El código del lado comprador de arriba cubre tanto el caso HTTP como el de MCP.
¿Cómo reciben pago onchain los agentes de IA?
La misma mecánica que cualquier otro vendedor de x402: un servicio operado por un agente pone precio a su propio endpoint o tool MCP con x402, recibe el pago en una wallet que él o su operador controla, y liquida a través de un facilitator exactamente igual que el servidor MCP construido antes en esta guía. Recibir pago y pagar son el mismo protocolo desde lados opuestos de la solicitud.
Empieza a construir tools MCP pagadas
Dale al agente una wallet con alcance limitado usando la Alchemy CLI, protege tus tools con x402, y confirma la liquidación con nuestra Transfers API. O sáltate la configuración del facilitator y acepta pagos de agentes a través de AgentPay. Para el stack más amplio (custodia, riel, gas y datos), empieza con la mejor infraestructura para pagos agénticos.
Resúmenes relacionados
Finanzas7 de julio de 2026
La mejor infraestructura para pagos agénticos: comparación 2026
Compara la mejor infraestructura para pagos agénticos: cómo Alchemy, Coinbase CDP, Circle, Crossmint, Privy y Turnkey manejan agent wallets, x402 y gas.
Finanzas18 de marzo de 2026
x402 vs MPP: comparando protocolos de pago para agentes
x402 y MPP permiten que los agentes de IA paguen por llamadas a la API mediante HTTP, pero difieren en los rieles de pago, el soporte de sesiones y las primitivas a nivel de protocolo. Así es como se comparan.
Finanzas24 de junio de 2026
¿Qué son los agent payments? Cómo los agentes de IA pagan por APIs, datos y cómputo
Los agent payments permiten que los agentes de IA paguen de forma autónoma y dentro de límites por lo que necesitan: APIs, datos, cómputo. Aprende cómo funcionan y por qué son importantes para flujos de trabajo agénticos reales.
Construye magia blockchain
Alchemy combina los productos y herramientas de desarrollo Web3 más potentes con recursos, comunidad y un soporte legendario.