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 registrar primero: crear una cuenta, obtener una clave, recibir la factura después. x402 se salta todo eso. Un servidor puede cobrar por solicitud en lugar de eso, sin registro, sin clave y sin factura. Y ya está corriendo 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 acceso a RPC y datos.
Esta guía es para cualquiera que construya cualquiera de los dos lados de ese intercambio: un servidor MCP o una API que quiera cobrar por llamada, o un agente que necesite pagarla. Vamos a recorrer el ciclo de solicitud y respuesta, y luego mostrar código real para cobrar por una llamada a una herramienta, medir y liquidar por llamada en USDC, darle a un agente una billetera con la cual pagar, y dónde encajan otros protocolos de pago como AP2.
¿Qué hace exactamente x402?
HTTP 402 Payment Required existe en la especificación HTTP desde los años noventa y nunca se implementó. x402 es el protocolo que finalmente lo usa:
- Un servidor responde a una solicitud sin pagar 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 panel de control, y la billetera es la cuenta. En x402 v2, la información relevante se almacena en encabezados HTTP:
Los tres encabezados nunca cambian. Lo que cambia es el campo scheme dentro del JSON que transporta PAYMENT-REQUIRED, que le indica al cliente qué modelo de facturación usa esa llamada en particular. En todos los esquemas, el mismo tercero se encarga de la verificación y del 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 entre esquemas es únicamente 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 por ese monto exacto. El payload luce así, recortado a los campos que importan. amount son 10,000 unidades atómicas, que equivalen 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 terminar el trabajo, como la salida de un LLM facturada por tokens generados. Para esos casos, el servidor usa upto. El payload luce 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 realiza 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 de menos de un centavo, donde pagar las comisiones de gas 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 custodia, firma vales fuera de cadena por cada solicitud, y los vendedores los canjean en lotes onchain. Circle Gateway usa un patrón de nanopagos relacionado para la misma función.
El facilitator nunca retiene fondos él 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 hospedado con verificación de cumplimiento. Puedes apuntar tu código hacia cualquiera de los dos.
¿Cómo funciona el ciclo de solicitud y respuesta de x402?
El intercambio consta de 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 realiza el trabajo (ejecuta la consulta, llama al modelo, genera el informe).
- 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 encabezados 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 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 herramientas pagas y gratuitas, como un servidor de investigación o de datos que ofrece búsquedas básicas gratuitas pero cobra por un informe generado más profundo.
En este ejemplo, generate_report cuesta $0.01 por llamada y ping se mantiene gratis, construido sobre los SDKs abiertos de x402 Foundation (agnósticos de facilitator, así que puedes empezar contra el facilitator público gratuito y cambiar a uno comercial después) con una cuenta inteligente de Wallet APIs como la dirección que recibe el pago.
Primero, aprovisiona la billetera que recibe el pago. @alchemy/wallet-apis (v5) te da una dirección de cuenta inteligente 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 herramienta MCP protegida con x402. @x402/core construye y verifica los requisitos de pago, @x402/evm implementa el esquema exact para chains EVM, y @x402/mcp envuelve el handler de una herramienta para que una función simple se convierta en una paga:
// 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 adjunta el protocolo al transporte. El listener HTTP de Node es el 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 hayas envuelto en paid(...) se mantiene gratis, así que puedes mezclar herramientas con precio y sin precio en el mismo servidor. Pruébalo con curl o cualquier cliente MCP sin ningún pago adjunto primero: deberías recibir un resultado de pago requerido en lugar del informe, lo que confirma que la puerta está activa antes de conectar un cliente que pague de verdad.
Si prefieres no gestionar tú mismo una relación con un facilitator, y quieres aceptar x402 junto con otros protocolos emergentes de pago de agentes sin tener que elegir uno, para eso está AgentPay: apúntalo a tu endpoint existente y 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 de producción también necesitan rastrear quién pagó y cuánto, y no deberían depender del informe de liquidación del facilitator como única prueba de que el dinero realmente se movió. Para verificarlo, lleva registro de:
- Forma de precio. Usa
exactpara un precio fijo por llamada, el patrón de arriba. Usauptocuando el costo varía por llamada (un informe 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 lo bastante frecuentes y baratas como para que liquidar cada una individualmente onchain costaría más que la llamada misma. - Atribución y contabilidad. El payload de pago que firma el cliente incluye la dirección pagadora. Regístrala junto con el nombre de la herramienta, el precio y el resultado de liquidación cada vez que una llamada se liquida, y tienes un libro de uso por agente sin costo adicional:
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 aún devuelve un código distinto de 200, o viceversa; verifica ambas antes de contabilizar el ingreso. Para una revisión periódica de conciliación, nuestra Transfers API te permite confirmar de forma independiente qué llegó realmente a tu dirección receptora, lo que detecta el caso poco común en que el informe 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 billetera USDC para pagar?
Un agente que necesita pagarle a un endpoint con muro de pago, ya sea tuyo o de alguien más, necesita una billetera fondeada y código (o una CLI) que pueda firmar un pago cuando encuentre 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 billetera 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á en cualquier momento, y nada que el servidor devuelva puede hacer que ese número suba. Si ejecutas el comando sin ningún humano presente para aprobarlo (--no-interactive) y olvidas establecer --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 la documentación de la CLI de pagos x402 para la superficie completa de comandos.
Para un agente backend completamente autónomo que necesita pagar sin que un humano apruebe cada sesión, envuelve fetch (o tu cliente MCP) con un handler de pagos respaldado por un firmante. Si el agente está llamando a endpoints HTTP pagos, 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 a herramientas pagas en un servidor MCP en lugar de un endpoint HTTP simple, envuelve el cliente MCP de la misma forma en lugar de fetch. CDP documenta el mismo patrón para compradores 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 en texto plano dentro de una variable de entorno puede estar bien para una primera prueba en testnet, pero es inaceptable en producción. Para un agente de producción, coloca una cuenta inteligente de Wallet APIs o una sesión de Agent Wallet detrás de la misma interfaz de firmante en su lugar, de modo que el agente pueda firmar bajo las reglas que tú definas sin tener nunca la clave privada en sí.
¿Cómo liquido en USDC sin hacer que los agentes tengan que tener gas?
Toda transacción onchain necesita gas: un token nativo como ETH, en posesión de quien envía la transacción, para pagarle a la red por procesarla. Eso es un problema para un agente que paga por llamada de 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 propósito 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 tener 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 de exact y upto normalmente usan EIP-3009 para USDC y Permit2 para cualquier otro ERC-20 que no soporte EIP-3009. batch-settlement sigue haciendo que el agente firme por solicitud, y luego el vendedor canjea 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 esté cotizado en dólares también simplifica las cosas: ninguna de las partes tiene que hacer cálculos de tipo de cambio sobre un cargo de $0.01.
Eso cubre el pago en sí. Si tu dirección receptora es una billetera simple de propiedad externa, eso es todo: solo recibe USDC, sin ningún paso de despliegue involucrado. Si es una cuenta inteligente como la construida antes en esta guía, sigue involucrando gas en otros dos momentos fuera del flujo de x402: una vez para desplegarse onchain la primera vez que recibe fondos, y de nuevo cada vez que traspasas el USDC recolectado a una billetera de tesorería. Nuestro Gas Manager puede patrocinar el gas para esos dos momentos; de cualquier forma, no está involucrado en liquidar el pago x402 en sí, ya que el facilitator ya cubre eso.
Base es la red predeterminada en la mayoría de las herramientas, ya que ahí es donde corre el facilitator de referencia original y donde ya vive la mayoría de las integraciones existentes de x402, pero x402 v2 no es exclusivo de Base. También cubre cualquier chain EVM (incluyendo Ethereum mainnet y Polygon) más Solana, TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium y XRPL, y se esperan más chains a medida que los facilitators agreguen soporte. Que "pagar en USDC en Ethereum" específicamente te funcione hoy depende de si tu facilitator elegido ha implementado esa red, 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ápida evolución, no el único.
- Stripe y Tempo construyeron MPP como una versión del mismo patrón de 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 comunicarse con un servidor construido para el otro). - ACP de OpenAI y Stripe cubre una porción diferente: el checkout para compras impulsadas por IA en lugar de pagos de API por solicitud.
- AP2 de Google cubre un problema completamente distinto: demostrar que un usuario autorizó a un agente a gastar, usando mandatos firmados de Checkout y Payment, 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 x402 de A2A que Google construyó junto con Coinbase, la Ethereum Foundation y MetaMask, así que x402 es el riel cripto subyacente en lugar de una alternativa a él.
A medida que evoluciona el panorama de protocolos, AgentPay existe como un proxy agnóstico de protocolo que ayuda a los comercios a integrarse una vez y soportarlos todos.
Si estás eligiendo entre x402 y MPP para un desarrollo específico, revisa nuestra comparación de x402 vs MPP. Si estás eligiendo un proveedor de infraestructura, revisa nuestra comparación de capas de billetera, gas y datos entre Alchemy, Coinbase 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 red, el activo y el monto antes de firmar, de la misma forma en que la Alchemy CLI verifica una cotización localmente antes de firmarla.
- 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 concilia periódicamente contra la realidad onchain con nuestra Transfers API como se mostró arriba. - No omitas el límite de gasto en un agente autónomo. Sea cual sea tu equivalente de
--max-payment, ajústalo al valor más pequeño que cumpla con la tarea, 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, filtrar transacciones y enviar la liquidación onchain a escala sea realmente tu producto. Apunta a uno hospedado y dedica el tiempo de ingeniería a tu servicio real.
- No asumas que "soporta x402" significa "soporta cada red 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 redes y tokens es la fuente de verdad.
Preguntas frecuentes
¿Cómo agrego pagos con x402 a un servidor MCP?
Envuelve el handler de la herramienta que quieres cobrar con un wrapper de pago del paquete @x402/mcp de la x402 Foundation, respaldado por un servidor que esté registrado con un facilitator y sepa qué dirección de billetera debe recibir el pago. El ejemplo completo y funcional está arriba; todo lo demás en el servidor se mantiene gratis a menos que también lo envuelvas.
¿Qué infraestructura necesitan los agentes de IA para pagar APIs mediante x402 usando stablecoins?
Tres piezas: una billetera que mantenga y pueda firmar USDC, una librería de pagos firmados o una CLI que hable el handshake de x402, y un facilitator del lado del vendedor para verificar y liquidar. No necesitas correr tu propio nodo de blockchain ni tener tokens de gas; el facilitator cubre el gas de 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 billetera con la que pueda firmar directamente, ya sea una sesión con alcance limitado como un Alchemy Agent Wallet o una cuenta inteligente programática mediante nuestras Wallet APIs, y combínala con una librería de cliente x402 como @x402/fetch o el comando x402 request de la Alchemy CLI. Confirma primero que tu facilitator objetivo realmente soporta la red 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 billetera 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 billetera con alcance limitado y revocable en minutos, sin exponer nunca una clave privada al agente. Para un agente backend completamente autónomo, aprovisiona una cuenta inteligente mediante @alchemy/wallet-apis o una billetera gestionada por CDP y entrega su firmante a una librería de cliente 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 acepte, 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 intercambio.
¿Cómo mido y cobro a agentes de IA por el uso de APIs 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 herramienta o endpoint que pagó. Concilia ese libro periódicamente contra el historial de transferencias onchain, por ejemplo con nuestra Transfers API, en lugar de confiar en un único informe de liquidación.
¿Cuál es la mejor infraestructura para pagos cripto agénticos y comercio onchain?
Depende de cuánto del stack (custodia de billetera, el riel de pago, gas y datos onchain) quieras obtener de un solo proveedor frente a ensamblarlo de varios. Una comparación completa de Alchemy, Coinbase 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 marco agnóstico de método de pago de Google para demostrar que un usuario autorizó a un agente a gastar, usando mandatos firmados de Checkout y Payment. 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 x402 de A2A 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 es que agentes de IA descubran, paguen por, y reciban pagos por bienes, servicios y acceso a APIs sin que un humano tenga que hacer clic en un checkout cada vez. Requiere una billetera 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 qué pagar y confirme que llegó.
¿Cómo implemento el protocolo de pago x402 para que un agente acceda a servicios onchain con muro de pago?
Del lado del cliente, instala una librería de cliente x402 (@x402/fetch, @x402/axios, o el wrapper de cliente MCP), registra un esquema de pago con un firmante de billetera, y envuelve tu cliente HTTP existente o tu cliente MCP con él; el pago ante un 402 se vuelve automático a partir de ahí. El código del lado del comprador de arriba cubre tanto el caso HTTP como el 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 le pone precio a su propio endpoint o herramienta MCP con x402, recibe el pago en una billetera que él o su operador controla, y liquida a través de un facilitator 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 herramientas MCP pagas
Dale al agente una billetera con alcance limitado usando la Alchemy CLI, protege tus herramientas 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: una comparación 2026
Compara la mejor infraestructura para pagos agénticos: cómo Alchemy, Coinbase CDP, Circle, Crossmint, Privy y Turnkey manejan las wallets de agentes, x402 y el 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 por lo que necesitan (APIs, datos, cómputo) de forma autónoma y dentro de límites establecidos. 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.