Cuando el que compra no es una persona sino un agente de IA, el checkout tradicional —cuenta, tarjeta guardada, sesión, botón— deja de tener sentido. Por eso en 2026 se han consolidado dos estándares que resuelven problemas distintos y que conviene no confundir: x402, la forma en que un agente paga un recurso sobre la marcha, y AP2 (Agent Payments Protocol), la forma en que se demuestra que un humano autorizó esa compra. No son rivales: son dos capas del mismo problema. Esta guía explica qué hace cada uno, cuándo usarlos y —lo más importante— cuándo no.
El problema: autorización y liquidación son cosas distintas
Todo pago de un agente responde a dos preguntas separadas:
- ¿Quién autorizó esto y cómo lo pruebo? (autorización y confianza)
- ¿Cómo se mueve el dinero, ahora mismo, por este recurso concreto? (liquidación / rail de pago)
Mezclar las dos es la causa de la mayoría de los análisis confusos que circulan. x402 responde a la segunda; AP2 se centra en la primera. Un producto serio suele necesitar pensar en ambas.
x402: pagar un recurso HTTP sobre la marcha
x402 es un estándar de micropagos construido sobre el código de estado HTTP 402 (Payment Required). Nació en Coinbase y desde abril de 2026 se gobierna en la x402 Foundation bajo la Linux Foundation, con AWS, Cloudflare, Anthropic, Circle y más de 20 miembros. El flujo es deliberadamente simple:
- El cliente pide un recurso con un
GETnormal. - El servidor responde
402con una cabeceraPAYMENT-REQUIRED(precio, token, red, dirección del comercio). - El cliente firma un payload de pago y reintenta con la cabecera
PAYMENT-SIGNATURE. - El servidor verifica (directamente o vía un facilitator) y liquida on-chain.
- Devuelve el recurso con una cabecera
PAYMENT-RESPONSEde confirmación.
La liquidación es en stablecoins —sobre todo USDC— en Base y otras redes EVM (Ethereum, Polygon, Optimism, Arbitrum, Avalanche) además de Solana o Aptos. El facilitator (el público lo opera Coinbase) abstrae la parte de blockchain: verifica y difunde la transacción sin custodiar fondos. La clave arquitectónica: el cliente solo necesita un wallet; ni cuentas, ni API keys, ni sesiones. Cloudflare llevó esto al borde con sus Wallets (reserva de handles abierta el 4 de agosto de 2026), que dan al agente identidad y un gasto acotado usando x402.
AP2: probar que un humano dijo que sí
AP2 es el marco de pagos para agentes de Google, anunciado en septiembre de 2025 con más de 60 socios (Mastercard, PayPal, Coinbase, American Express, Salesforce…). Es agnóstico al método de pago y su núcleo son los mandatos firmados criptográficamente: pruebas verificables de que un humano autorizó una intención ("compra unas zapatillas por menos de 120 €"), un carrito concreto y, finalmente, un pago. Define puntos de extensión para tarjetas, ACH y transferencias, sistemas de pago en tiempo real y activos digitales, incluidas las stablecoins (Coinbase y MetaMask enviaron extensiones de stablecoin desde el lanzamiento).
Ahí está la conexión que a menudo se cuenta mal: existe una extensión x402 para A2A/AP2. Es decir, AP2 puede usar x402 como uno de sus rieles de liquidación cripto. AP2 responde "¿hay autorización humana y cómo la audito, en cualquier método?"; x402 responde "¿cómo pago este endpoint ahora?".
x402 vs AP2, en una tabla
| Dimensión | x402 | AP2 |
|---|---|---|
| Problema que resuelve | Liquidación inline de un recurso HTTP | Autorización y prueba de consentimiento humano |
| Origen / gobierno | Coinbase → x402 Foundation (Linux Foundation) | Google + 60 socios (Mastercard, PayPal…) |
| Métodos de pago | Stablecoins (USDC) on-chain | Agnóstico: tarjeta, banco, RTP, stablecoin |
| Mecanismo central | Cabeceras HTTP 402 + firma + facilitator | Mandatos firmados (intención, carrito, pago) |
| Caso natural | Monetizar APIs/contenido consumidos por agentes | Comercio: el agente compra por ti |
| Necesita cuenta/onboarding | No, solo wallet | Sí, atado a métodos y a identidad del usuario |
Cuándo usar cada uno (y cuándo no)
Usa x402 si monetizas APIs, datos o contenido y tus consumidores pueden ser agentes: cobro por llamada, sin alta previa, ideal para proveedores de API, marketplaces de herramientas y fuentes de datos. Es la vía de menor fricción para que un agente pague por un recurso puntual.
Usa AP2 si construyes agentes de comercio que compran en nombre de un usuario y necesitas una traza auditable de autorización humana y rieles de tarjeta/banco: retail, travel, seguros. Aquí el mandato firmado es tu defensa ante disputas.
Cuándo NO precipitarse: si tus usuarios son humanos con un checkout que funciona, no arranques nada. Los pagos de agentes importan cuando el comprador es un agente; hoy, en la mayoría de productos, no lo es. Y sobre los rieles cripto de x402, sé honesto con las contras: la historia de reembolsos, chargebacks, contabilidad y cumplimiento es inmadura, y la volatilidad y la fiscalidad de las stablecoins añaden carga operativa que un equipo pequeño no siempre quiere. Para flujos de alto importe, regulados o dependientes de chargeback, hoy no migraríamos.
Qué implementar en tu producto
- Decide primero si un agente es comprador en tu producto. Si la respuesta es "todavía no", el mejor código de pagos de agentes es el que no escribes.
- Si monetizas APIs o contenido, pilota x402 detrás de un facilitator: es de bajo compromiso y reversible. Empieza por un endpoint no crítico.
- Si construyes agentes de comercio, diseña la autorización alrededor de los mandatos de AP2 y elige el rail por mercado (tarjeta donde toque, stablecoin donde aporte).
- No hardcodees un solo chain ni un solo facilitator. Mete una abstracción de rieles, igual que ya harías con un LLM gateway para evitar vendor lock-in.
Los pagos de agentes son una de las piezas que faltaban para que la orquestación multiagente salga del laboratorio, y encajan en la conversación más amplia sobre gobernanza neutral y lock-in de los protocolos de agentes. En Dribba diseñamos backend en Go sobre Cloud Run y arquitecturas de agentes para producto fintech, insurtech y retail con equipo 100% senior in-house. Si estás valorando abrir tu producto a compradores-agente, hablémoslo antes de escribir la primera línea.
