Shared Payment Tokens de Stripe: cómo cobrar un pago que hizo un agente de IA (2026)

Qué acaba de lanzar Stripe (y por qué importa)

El 3 de marzo de 2026, Stripe amplió sus Shared Payment Tokens (SPT) para cubrir los agentic network tokens de Mastercard Agent Pay y Visa Intelligent Commerce, más tokens de BNPL de Affirm y Klarna, todo a través de un solo primitive (según Stripe). Esa última parte es la noticia para quienes construimos: con un mismo mecanismo cubres tanto pagos con tarjeta de red como financiamiento. (Confirma fechas y estado actual contra los docs oficiales.)

El titular para builders es directo: un agente de IA ahora puede completar una compra en nombre de un cliente sin ver nunca la tarjeta ni las credenciales subyacentes. El cliente da permiso, Stripe entrega al agente un token acotado, y el agente paga. Tú, el vendedor, recibes un pago válido sin que el agente toque datos sensibles.

Vale la pena enmarcar esto con honestidad, porque hay mucho ruido. SPT no es un “rail” nuevo que compite contra Visa y Mastercard. Es el primitive de integración para developers que provisiona los agentic network tokens de Visa y Mastercard. Las redes emiten y operan el token; Stripe es la capa que tú integras para provisionarlo y verificarlo. No es una pelea de tres bandos: son capas que encajan.

Y SPT no vive solo. Es la pieza de pago dentro del Agentic Commerce Protocol (ACP), el lenguaje común open-source (Apache 2.0) que Stripe construyó con OpenAI para que agentes y negocios coordinen el checkout y compartan credenciales de pago de forma segura. Si ya integraste Stripe en tu SaaS, esto extiende esa misma base —vale la pena tener fresca la integración de Stripe que esto amplía.

Cómo fluye realmente un pago con SPT

El flujo de punta a punta tiene cinco momentos, y entenderlos te ahorra confusión cuando veas los objetos en tu dashboard.

Primero, el cliente autoriza a un agente a comprar en su nombre, eligiendo un método de pago y un alcance: por ejemplo, un límite de gasto o una compra específica. Segundo, Stripe provisiona un agentic network token (de Mastercard o Visa) acotado a esa intención y se lo comparte al agente como un Shared Payment Token. Tercero, el agente presenta ese SPT a cualquier vendedor que acepte pagos agénticos, en cualquier lugar donde se acepte Mastercard o Visa; el vendedor nunca recibe los datos de la tarjeta.

El cuarto momento es el que más te importa como vendedor: el alcance se hace cumplir mediante usage_limits sobre el token otorgado —la moneda (currency), el monto máximo en centavos (max_amount) y la expiración como timestamp Unix (expires_at). Tú debes respetar esos límites. Quinto, como ese mismo primitive también cubre BNPL (Affirm, Klarna), el agente puede presentar financiamiento sin que tú construyas una integración separada.

Qué cambia para ti, el vendedor

En un checkout normal hay un humano presente que confirma el PaymentIntent en tu UI. Con un pago de agente no hay humano en tu checkout: el agente llega con un token preautorizado en la mano. Ese es el cambio mental de fondo.

Lo que no cambia: sigues creando un PaymentIntent, sigues tratando el webhook verificado como la única fuente de verdad, y sigues cumpliendo el pedido solo después de que el pago se confirma. La disciplina de verificar la firma del webhook de Stripe aplica igual aquí —de hecho, importa más, porque del otro lado hay un cliente autónomo y no un humano que pueda corregir a mano.

Lo nuevo: recibes un token otorgado (tipo de objeto shared_payment.granted_token), y debes verificar su alcance —currency, max_amount, expires_at— antes de cobrar. El monto que pide el agente tiene que caber dentro de la autorización del cliente. Si el pedido excede el max_amount o el token ya expiró, rechazas.

Y hay un nuevo modo de falla: los tokens se desactivan. Se consumen, expiran o se revocan. Tienes que escuchar shared_payment.granted_token.deactivated y dejar de usar ese token de inmediato. El modelo mental correcto es tratar el SPT como un nuevo método de pago, no como magia: la misma disciplina que con tarjetas, más un paso de verificación. Si quieres ver el contexto de qué es exactamente un agente de IA que compra, ahí está el fondo.

La integración: aceptar, verificar, cobrar

Veamos el lado del vendedor con código ilustrativo. Recuerda: estas son formas de la API en versión preview (2026-04-22.preview al momento del lanzamiento) y pueden cambiar antes de GA —fíjalas explícitamente y verifica contra los seller docs.

Primero recuperas el token otorgado para inspeccionar su alcance. El id se ve como spt_123. El endpoint REST canónico verificado es GET /v1/shared_payment/granted_tokens/{id}; el path exacto del helper del SDK no está garantizado en preview.

// Ilustrativo — formas de API en versión preview; verifica vs los seller docs de Stripe.
// El path del helper del SDK NO está garantizado en preview.
// Endpoint REST canónico verificado: GET /v1/shared_payment/granted_tokens/{id}
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY, {
  apiVersion: "2026-04-22.preview", // fíjala explícitamente
});

// 1. Recupera el token otorgado para inspeccionar su alcance
const token = await stripe.sharedPayment.grantedTokens.retrieve("spt_123");

// 2. Verifica el alcance antes de cobrar
const { currency, max_amount, expires_at } = token.usage_limits;
const now = Math.floor(Date.now() / 1000);

// Nota: deactivated_at es un timestamp Unix (o null), por eso el check truthy
// es intencional. La API también expone deactivated_reason, útil para loguear.
if (
  token.deactivated_at ||           // ya consumido, expirado o revocado
  expires_at < now ||               // fuera de tiempo
  currency !== order.currency ||    // moneda no coincide
  order.amount > max_amount         // el pedido excede la autorización
) {
  throw new Error("SPT fuera de alcance: rechaza el pago");
}

Si el token pasa la verificación, creas el PaymentIntent pasando el token vía payment_method_data[shared_payment_granted_token]. Stripe clona el PaymentMethod subyacente y lo procesa.

// 3. Crea el PaymentIntent con el token otorgado (idempotente)
const paymentIntent = await stripe.paymentIntents.create(
  {
    amount: order.amount,
    currency: order.currency,
    confirm: true,
    payment_method_data: {
      shared_payment_granted_token: token.id,
    },
  },
  { idempotencyKey: `pi_${order.id}` } // los agentes reintentan: clave por pedido
);

Dos reglas que no cambian: confirma el cumplimiento solo a partir del webhook verificado, nunca solo de la respuesta síncrona de la API; y trata cada campo de la API preview (shared_payment.granted_token, el endpoint de retrieve de granted tokens, el campo payment_method_data) como algo que puede moverse antes de GA. Hay más patrones de cobro en mis guías de integraciones de pagos.

Por qué la idempotencia y un feature flag no son negociables

Los agentes reintentan. Un cliente autónomo reenvía una petición ante un timeout mucho más fácil que un humano que hace clic en un botón. Por eso pasas una Idempotency-Key en la llamada de creación del PaymentIntent: para no cobrar dos veces el token acotado del cliente. Sin esa clave, un reintento del agente es un doble cargo esperando a pasar.

Haz tu cumplimiento idempotente también del lado tuyo: ánclalo al id del PaymentIntent, de modo que un webhook reproducido no envíe el pedido dos veces. Esta es la misma higiene de siempre, pero con agentes el costo de no tenerla sube, porque nadie del otro lado va a notar el cargo duplicado y reclamar a tiempo.

Opinión (etiquetada): constrúyelo detrás de un flag. Los rails salieron en 2026 y están tempranos —disponibilidad, cobertura por país y adopción de agentes siguen creciendo. Un flag te deja habilitar el checkout agéntico por región o por vendedor, y apagarlo rápido si algo se comporta mal. No es paranoia; es cómo se opera tecnología nueva en producción sin sustos.

Y verifica la disponibilidad por país antes de habilitarlo para clientes de LATAM. La aceptación agéntica se está desplegando mercado por mercado y todavía no es uniforme.

El ángulo LATAM y de stablecoins

Hay que ser exacto con la disponibilidad, porque este post apunta a builders en México y LATAM. Hoy, al momento de escribir (lanzamiento 2026), los docs de Stripe declaran que SPT está disponible solo en EE. UU. para agentes, clientes y vendedores. Es decir: la capa SPT todavía no está disponible en México ni en el resto de LATAM. No la des por integrable aquí aún; verifica el estado actual contra los docs oficiales antes de planear nada.

Dicho eso, la noticia de alcance prospectivo es buena: los pagos agénticos viajan sobre la misma aceptación de Visa y Mastercard que ya tienes, así que cuando el rollout llegue a tu mercado, la cobertura de red de fondo será amplia. El trabajo de hoy es estar listo y vigilar el despliegue país por país, no asumir disponibilidad parcial.

La UX en español sigue importando. Si un agente está comprando para un cliente mexicano, tu cumplimiento, tus recibos y tus estados de error deben seguir localizados. El agente es un canal, no una excusa para bajar la calidad de la experiencia. El humano dueño de ese agente va a leer el recibo en español, y va a juzgar tu marca por él.

Sobre stablecoins, alguien te va a preguntar si los agentes pueden liquidar en stablecoins bajo las reglas mexicanas. Aquí ve con cuidado, en dos frentes. Primero, no he visto confirmado que SPT/ACP ofrezca hoy una ruta de liquidación agéntica en stablecoin —no se lo atribuyas a Stripe como capacidad ya integrable. Segundo, el panorama regulatorio —incluida la Ley Fintech— está evolucionando y la disponibilidad por país no está garantizada. Consigue asesoría legal y de compliance calificada antes de construir un camino de liquidación en stablecoin. No tomes la palabra de un blog (incluido el mío) como consejo legal. El movimiento pragmático hoy es preparar el camino agéntico de tarjeta y BNPL para cuando esté disponible en tu mercado, y vigilar las reglas de stablecoins en lugar de apostar a ellas.

Preguntas frecuentes

¿El agente ve la tarjeta de mi cliente? No. Ese es el punto entero de SPT: el agente recibe un token acotado; la tarjeta y las credenciales nunca se le exponen.

¿Es un rail nuevo que compite con Visa y Mastercard? No. SPT es el primitive de integración que provisiona los network tokens de Visa Intelligent Commerce y Mastercard Agent Pay. Las redes siguen emitiendo y operando los tokens.

¿Qué tengo que construir como vendedor? Aceptar el token otorgado (idealmente vía ACP), verificar sus usage_limits y su estado activo, crear un PaymentIntent con el token, y cumplir de forma idempotente desde el webhook verificado.

¿Los agentes pueden pagar con BNPL? Sí. Stripe amplió SPT para cubrir tokens de Affirm y Klarna a través del mismo y único primitive (según Stripe).

¿Está disponible en México? No al momento de escribir. Según los docs de Stripe, SPT está disponible solo en EE. UU. en el lanzamiento. Vigila el rollout país por país y confirma el estado actual contra los docs oficiales.

¿Está listo para producción? Está vivo pero temprano (2026), lanzado sobre una versión de API preview y limitado a EE. UU. Trátalo como algo que se puede enviar detrás de un flag, no como una funcionalidad terminada y universalmente disponible. Todas las fechas y capacidades aquí: confirma el estado actual contra los docs oficiales.

Lánzalo detrás de un flag

El futuro en el que el agente paga por el cliente es real y parcialmente enviable hoy —en EE. UU. al momento de escribir, con LATAM pendiente del rollout. SPT es el primitive más limpio que he visto para lograrlo —un solo mecanismo que cubre tanto network tokens como BNPL, sin exponer credenciales.

Haz bien la parte poco glamorosa: verifica el alcance del token, cumple idempotente desde el webhook verificado, y mantenlo detrás de un flag hasta que la adopción y la disponibilidad alcancen el ritmo. Prepara el camino de tarjeta y BNPL ahora; rastrea las reglas de stablecoins y la disponibilidad por país en lugar de apostar a ellas. Los ingenieros que traten esto como un método de pago más —con un paso extra de verificación— van a enviar con calma mientras los demás siguen discutiendo el hype.