Dentro de ACP: el pago delegado de OpenAI y Stripe para agentes

Cuando ChatGPT compra un par de zapatos en tu nombre, una credencial de pago pasa por cuatro partes sin que el agente vea jamas el numero de tu tarjeta. El protocolo que gobierna ese movimiento vale la pena leerlo con cuidado.

El Agentic Commerce Protocol (ACP) es el estandar que OpenAI y Stripe publicaron para que los agentes completen una compra contra un merchant. Es open source bajo Apache 2.0, versionado por fecha, y lo bastante pequeno para leerlo en una tarde. Tambien es un diseno distinto al que corre esta plataforma. Hemos escrito sobre el rail en stablecoins — x402, EIP-3009, AP2. ACP es el rail de tarjeta. Entender donde divergen los dos, y donde coinciden en silencio, dice mucho sobre como se van a liquidar realmente los pagos de agentes.

Que es ACP en realidad

ACP son dos especificaciones OpenAPI y un modelo de governance, nada mas. La primera spec, la Agentic Checkout Specification, define un contrato REST que un merchant implementa para que un agente arme un carrito, lo cotice y coloque una orden. La segunda, la Delegated Payment Specification, define como se acuna y se entrega una credencial de pago acotada. Los founding maintainers son OpenAI y Stripe. Las versiones llevan fecha: el release inicial fue 2025-09-29, y el snapshot estable actual es 2026-04-17, que agrego cart, feed, orders, delegated authentication y una superficie MCP.

Esa superficie MCP importa. ACP se puede exponer como una API HTTP simple o como un servidor Model Context Protocol. La capacidad de comercio se vuelve solo otro conjunto de tools que el modelo puede llamar. El transporte es intercambiable; las estructuras de datos no.

El principio rector esta dicho sin rodeos en la spec: el merchant sigue siendo el system of record de todas las ordenes, pagos, impuestos y compliance. El agente orquesta. Nunca se convierte en merchant of record, y nunca sostiene el instrumento de pago crudo.

La spec de checkout: cinco endpoints

Un merchant que quiere vender dentro de un agente implementa cinco endpoints. Cada llamada corre sobre HTTPS, devuelve JSON y lleva un header API-Version. Los montos siempre son enteros en unidades minimas — centavos, no dolares — lo que elimina en la frontera del protocolo toda una clase de bugs de redondeo de punto flotante.

# Create — devuelve 201 con un checkout_session_id
POST /checkout_sessions

# Update — reemplaza items, direccion u opcion de fulfillment
POST /checkout_sessions/{checkout_session_id}

# Retrieve — estado autoritativo de la sesion (200, o 404)
GET  /checkout_sessions/{checkout_session_id}

# Complete — lleva el token de pago, acuna la orden
POST /checkout_sessions/{checkout_session_id}/complete

# Cancel — 200 si es cancelable, 405 si ya es terminal
POST /checkout_sessions/{checkout_session_id}/cancel

Cada respuesta devuelve el estado completo del carrito: line items, precios, impuestos y fees, opciones de envio, descuentos, totales y un status. No hay estado parcial que reconstruir del lado del cliente. El agente lee la sesion; el merchant es dueno de la verdad. Los updates son reemplazos totales — el array items que envias sobrescribe la lista entera, lo que hace cada llamada idempotente en intencion en vez de incremental.

Los errores siguen una forma fija: { type, code, message, param }, donde param es un JSONPath RFC 9535 que apunta al campo ofensor. El type sale de un conjunto cerrado — invalid_request, request_not_idempotent, processing_error, service_unavailable. Los eventos de ciclo de vida de la orden (order_create, order_update) se empujan al webhook receiver de la plataforma del agente con un header de firma HMAC. Es una API REST aburridamente convencional, y ese es el punto. La novedad no esta en la superficie de checkout. Esta en como se mueve el dinero.

La spec de pago delegado: un vault token acotado

La llamada complete necesita una credencial de pago. ACP se niega a dejar que el agente cargue un numero de tarjeta. En su lugar define un unico endpoint obligatorio que convierte una credencial real en un token estrechamente acotado:

POST /agentic_commerce/delegate_payment

La llamada va de la plataforma del agente a un payment provider, y es la request mas sensible en seguridad de todo el protocolo. Por eso va firmada. El cliente calcula una firma detached sobre el body de la request con su llave privada, la codifica en base64url, y la envia en un header Signature. El provider anuncia los algoritmos aceptables fuera de banda — Ed25519 o ES256. La request tambien lleva un Timestamp en RFC 3339, un Idempotency-Key, un Request-Id para tracing, un token bearer Authorization, y el mismo pin de API-Version.

POST /agentic_commerce/delegate_payment
Authorization: Bearer <psp_api_key>
API-Version: 2025-09-29
Signature: <base64url ed25519 sobre el body>
Timestamp: 2026-07-18T14:03:11Z
Idempotency-Key: 5f2b9c1a-...

{
  "payment_method": {
    "type": "card",
    "card_number_type": "network_token",
    "number": "...", "exp_month": 11, "exp_year": 2028,
    "cryptogram": "...", "eci_value": "05"
  },
  "allowance": {
    "reason": "one_time",
    "max_amount": 4999,
    "currency": "usd",
    "checkout_session_id": "cs_...",
    "merchant_id": "acme",
    "expires_at": "2026-07-18T14:18:11Z"
  },
  "risk_signals": [ { "type": "...", "score": 12, "action": "authorized" } ],
  "metadata": { }
}

La respuesta, en 201, es deliberadamente delgada: un id que empieza con vt_, un timestamp created, y un eco de metadata. Ese valor vt_ es el vault token. Es el unico artefacto de pago que el agente toca jamas, y su poder esta acotado por completo por el objeto allowance con el que fue acunado.

Lee el allowance con atencion, porque es todo el modelo de seguridad. reason es one_time — el unico valor que la spec acepta hoy. max_amount pone techo al cargo. currency fija la denominacion. expires_at pone un muro duro: el token debe volverse invalido en o despues de ese instante. Y merchant_id ata el token a un solo negocio. Un vault token es una credencial de tarjeta envuelta en un sobre de gasto que nombra al merchant, el techo y la fecha limite. Robalo y podras hacer exactamente una cosa que el comprador ya aprobo, a exactamente un merchant, por unos minutos.

Hoy se soporta un tipo de credencial: card. El card_number_type puede ser un fpan — el numero de cuenta primario real — o un network_token, el rail tokenizado propio de las redes de tarjetas. Esa segunda opcion es la senal. ACP esta construido para montarse sobre la tokenizacion agentica de Visa y Mastercard, no para rodearla.

Shared Payment Token: la implementacion de Stripe

La spec define la forma; un payment provider la rellena. El Shared Payment Token (SPT) de Stripe es la primera implementacion compatible con la Delegated Payment Spec. Lleva las mismas propiedades que la spec exige: un solo uso, limitado en tiempo, acotado a un negocio, monitoreado via eventos de webhook, y revocable. La credencial subyacente nunca se expone al agente, y Stripe diseno el token para que sea compatible con los tokens agenticos de las redes de tarjetas.

Del lado del merchant, aceptar uno es un cambio pequeno. El vault token se vuelve el payment_method de un PaymentIntent, con confirm en true y request_delegated_payment habilitado en las opciones de card. El merchant nunca guarda el token. Y algo clave: un negocio que no procesa con Stripe igual puede reenviar el token a su propio vault u otro procesador — la credencial es portable entre los rails existentes del merchant.

ACP no es x402, y la diferencia es el punto

Es tentador archivar ACP y x402 bajo un solo titulo — "pagos de agentes" — y seguir. No lo hagas. Resuelven problemas distintos en rails distintos, y las brechas entre ellos definen a donde pertenece cada uno.

ACP es un rail de tarjeta. El instrumento de fondeo del comprador es una credencial Visa o Mastercard sostenida en un PSP. La liquidacion corre sobre la red de tarjetas existente, con su interchange, sus chargebacks, sus ventanas de disputa, y su aprobacion con humano en el loop — hoy, cada cargo ACP todavia espera revision del comprador. El merchant of record es la tienda. El agente es un comprador de buen comportamiento que nunca toca el dinero directo. Esta optimizado para retail: una persona le dice a un asistente que compre un bien fisico, y el asistente completa un checkout que el merchant ya entiende.

x402 es un rail de stablecoin. El agente sostiene una wallet. El pago es una respuesta HTTP 402, una autorizacion EIP-3009 firmada, y una transferencia on-chain liquidada por un facilitator — sin red de tarjetas, sin interchange, sin custodio que mueva fondos en nombre de nadie. Esta optimizado para machine-to-machine: un agente paga una fraccion de centavo por llamar una API, leer una pagina o correr un modelo, miles de veces, sin humano en el loop en absoluto.

El contraste es nitido en cuatro ejes. Custodia: ACP delega una credencial de tarjeta custodial; x402 mueve stablecoins auto-custodiadas. Involucramiento humano: ACP asume revision por compra; x402 no asume ninguna. Perfil de monto: ACP esta hecho para totales de retail discretos; x402 esta hecho para extracciones sub-centavo de alta frecuencia. Reversibilidad: la liquidacion de tarjeta se puede disputar y revertir; una transferencia de stablecoin liquidada es final. Ninguno es estrictamente mejor. Un agente de compras que compra un sueter quiere la proteccion de disputa del rail de tarjeta. Un agente de investigacion que paga por llamada de API quiere la finalidad y el fee casi nulo del rail de stablecoin.

Donde convergen

Los rails difieren, pero la arquitectura de seguridad esta convergiendo en la misma primitiva. Mira otra vez el allowance de ACP — max_amount, expires_at, merchant_id, un solo uso. Ahora mira los spend permissions que describimos en account abstraction para wallets de agentes: una autorizacion acotada con un techo, un vencimiento y una contraparte atada. Son la misma idea expresada en infraestructura distinta. ACP escribe el sobre en un vault token; ERC-7715 y las session keys lo escriben en un permiso on-chain firmado; la autorizacion por request de x402 lo escribe en una firma EIP-3009. Cada diseno serio de pago de agentes llego de forma independiente a la misma conclusion: nunca le entregues a un agente una credencial permanente; entregale un token acotado a una sola intencion.

La segunda convergencia es la regla de llaves-fuera-del-modelo. ACP mantiene el PAN en el PSP. x402 mantiene la llave privada en una wallet que el LLM no puede leer. Ambos tratan al modelo de lenguaje como un orquestador no confiable que organiza pagos que nunca puede ejecutar de forma unilateral. Ese es el threat model correcto, y ambos bandos aterrizaron en el.

Que significa para LLM4Agents

LLM4Agents liquida en el rail de stablecoin. Los agentes fondean un balance y pagan por llamada de modelo sobre un gateway compatible con OpenAI, con x402 y EIP-3009 debajo. ACP no compite con eso — atiende el checkout de retail, un trabajo distinto. Pero es una senal que vale la pena accionar por tres razones.

Primero, ACP valida el patron de token-acotado-por-allowance a la escala de OpenAI y Stripe. El vault token es, funcionalmente, una autorizacion de gasto por intencion — exactamente la forma que nuestro gateway ya emite cuando un agente extrae contra su balance. Que un protocolo respaldado por la mayor plataforma de IA y la mayor compania de pagos converja en el mismo sobre es confirmacion de que nuestra primitiva es la correcta, no una idiosincrasia.

Segundo, el transporte dual HTTP-o-MCP de ACP es el modelo a seguir. El comercio como conjunto de tools MCP es exactamente como los agentes van a alcanzar servicios, y refleja la superficie MCP que ya enviamos. La leccion: expon capacidad por un contrato REST simple y por un servidor MCP, y deja que el agente elija.

Tercero, los dos rails se van a encontrar en el comprador. Un mismo agente pagara su consumo de API y de modelo en stablecoins mientras completa compras de retail en tarjetas. La plataforma que le permita a un operador razonar sobre ambos flujos de gasto — las extracciones machine-to-machine y los cargos de tarjeta delegados — bajo un solo presupuesto y un solo audit trail gana la confianza del operador. Esa es una posicion que vale la pena construir.

Como mantenerse en la frontera

Pasos concretos, en orden. Primero, formalizar nuestra autorizacion de gasto como un objeto explicito e inspeccionable con los mismos campos que ACP estandarizo — techo, vencimiento, contraparte atada, flag de un solo uso — para que un operador pueda leer exactamente que se le permitio hacer a cada extraccion del agente. Toma prestado el vocabulario del allowance; ya es una lingua franca de la industria.

Segundo, adoptar la disciplina de firma de requests de ACP en nuestras llamadas internas mas sensibles: firmas Ed25519 detached, timestamps RFC 3339, idempotency keys obligatorios, y una version de API fijada. Son baratas de agregar y endurecen el camino de liquidacion contra replay y ataques de confused deputy — las mismas fallas que senalamos en el deep dive de autorizacion de MCP.

Tercero, enviar un adaptador con forma de ACP. Cuando un agente en nuestra plataforma necesite completar una compra de retail, deberia poder hablar el contrato checkout_sessions y entregar un token delegado, mientras sigue fondeando su consumo de API en stablecoins. Un agente, dos rails, un balance. Construye el puente antes de que los operadores lo pidan.

Cuarto, publicar el audit trail como artefacto de primera clase. ACP empuja webhooks order_create y order_update; x402 deja un registro de liquidacion append-only. Un operador corriendo una flota sobre ambos rails necesita un solo ledger reconciliado. Ese ledger es un producto, no un archivo de log.