Checkout agéntico

TL;DR — El checkout agéntico es el momento de «compra por mí» de las compras con IA. Cuando un asistente encuentra un producto y completa la compra, ese paso final es el checkout agéntico. En el flujo de pagos delegados de OpenAI, el agente usa un token limitado en lugar del número real de la tarjeta y devuelve el control a una persona ante un inicio de sesión o una verificación adicional. Es una pieza de ACP y UCP, no un protocolo independiente.

Qué es el checkout agéntico

La mayor parte de las compras con IA consiste en descubrir productos: se pide una recomendación, el asistente lee los feeds de los comercios y propone opciones. El checkout agéntico llega después: el agente crea el pedido, elige el envío, calcula impuestos y portes, entrega el pago y finaliza la compra.

La palabra clave es «paso». El checkout agéntico no es un producto ni una empresa aparte, sino la capacidad de completar la transacción dentro de ACP, de OpenAI y Stripe, y UCP, de Google y Shopify. Esta página se concentra en la mecánica del checkout.

Las tres ideas equivocadas más comunes

• «La IA compra sin intervención humana». No exactamente: ambos protocolos incluyen una pausa para pedir un inicio de sesión, una verificación de tarjeta o una confirmación.\n- «La IA ve mi tarjeta». No: el pago viaja como un token limitado a un comercio, un importe, un periodo y un solo uso; el número real nunca llega al agente.\n- «Esto ya es normal». Tampoco: a mediados de 2026 la adopción seguía siendo temprana.

¿Quién responde si algo sale mal?

La tienda donde se compra sigue siendo la responsable, lo que se denomina comercio de registro. Gestiona el pedido, los reembolsos y las disputas como en cualquier compra en línea. La parte difícil es el cargo impugnado cuando quien «compró» fue un agente de IA.

¿Quieres ver la máquina de estados, el alcance de los tokens, los puntos de intervención y las pruebas del comercio? Cambia a la versión avanzada.

TL;DR — El checkout agéntico completa una transacción: crea, actualiza, completa o cancela una sesión, delega el pago y confirma el pedido. Es un bloque de ACP y UCP, no un protocolo independiente. Su columna vertebral es una máquina de estados y puede detenerse para una escalación o autenticación. Los tokens están limitados por comercio, importe, tiempo y uso único; el agente nunca conserva una tarjeta. La confirmación llega mediante webhooks HMAC con el objeto completo. El comercio conserva la responsabilidad de registro y contracargos, aunque el marco probatorio sigue abierto. La integración reconoce not_ready_for_payment, ready_for_payment, requires_escalation, authentication_required, completed, incomplete, ready_for_complete.

Alcance: es el paso de transacción, no todo el protocolo

El checkout agéntico es una capacidad. En ACP aparece como el bloque Agentic Checkout, junto a Product Feed, Delegate Payment, Delegate Authentication y Orders/Webhooks. En UCP es una capacidad dentro de una especificación más amplia. Aquí interesan ciclo de vida, pago delegado, intervención, confirmación y responsabilidad. El ejemplo utiliza /.well-known/ucp.

Los agentes operan contra feeds y API, no contra el HTML rastreado. Por eso aquí se optimiza la fiabilidad del checkout, no el texto de la página.

La máquina de estados de la sesión de checkout

La diferencia que muchas explicaciones omiten es que un checkout es una sesión con estado. Ese estado avanza por una máquina definida y cada transición debe ser visible.

La referencia de Checkout de ACP enumera los estados y distingue un camino feliz corto de las ramas terminales. La opción de fulfillment lleva la sesión hacia el pago; si falla, puede volver a estar lista para reintentarlo. La receta comprueba incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress, expired.

Esta revisión técnica aborda el checkout agéntico aquí: Los estados explican espera, fallo y finalización.

• Escalación o autenticación requerida: el agente necesita una persona o una comprobación.\n- Aprobación pendiente: espera una autorización B2B.\n- Expirada: la sesión superó su plazo. El seguimiento registra requires_escalation, authentication_required, pending_approval, expired, CheckoutSession, expires_at.

El checkout de UCP aplica el mismo diseño: una sesión incompleta puede pedir una escalación y volver a la finalización mediante una URL de continuación. Dos protocolos convergen en que no siempre se puede terminar sin preguntar a una persona. La entrega incluye incomplete, requires_escalation, ready_for_complete, continue_url.

Una solicitud mal formada devuelve un error HTTP, mientras que un problema comercial dentro de una sesión válida llega como MessageError en messages[]. La integración debe tratar ambos caminos. La verificación reúne type, invalid_request, request_not_idempotent, processing_error, service_unavailable, MessageError, messages[].

Cómo funciona la delegación del pago

La delegación existe para que los datos brutos de la tarjeta nunca lleguen al agente. Los datos de pago se convierten en un token con alcance limitado.

Según OpenAI, el payload va al PSP o a la bóveda del comercio, que devuelve un token acotado fuera del alcance de PCI. Ese sistema lo limita en cuatro dimensiones.

• Motivo: uso único.\n- Importe máximo: impide cobrar más que el total.\n- Vencimiento: fija la fecha límite.\n- Comercio y sesión: vincula el token con ambos. La ficha conserva reason, "one_time", max_amount, expires_at, merchant_id, checkout_session_id.

El token está bloqueado al comercio, limitado por importe y tiempo, y destinado a un único uso. Así el agente compra sin recibir una credencial reutilizable. Stripe describe Shared Payment Token como una implementación compatible; UCP separa instrumentos y handlers.

El alcance de PCI es una decisión real. Una integración directa puede manejar datos del titular y exigir PCI DSS de nivel 1. Para la mayoría, el camino tokenizado deja los datos en el PSP. Elegir entre manejar CHD o dejar que el PSP tokenice es la decisión inicial.

Cuándo todavía debe intervenir una persona

Decir que «el comprador todavía lo autoriza» es impreciso. Los activadores son concretos; nombrarlos permite diseñar la transferencia de control en vez de llegar a un callejón sin salida.

• 3-D Secure y step-up: ACP modela capacidades, niveles y contextos; el resultado puede ser autenticado, denegado, rechazado, abandonado, cancelado o no compatible.\n- Escalación: indica que falta una persona o comprobación.\n- Aprobación B2B: los datos pueden incluir orden de compra y condiciones.\n- UCP: una URL de continuación permite terminar el inicio de sesión o la confirmación. La referencia mantiene InterventionCapabilities, 3ds, address_verification, enforcement, always, conditional, optional, display_context, native, webview, modal, redirect, AuthenticationResult, authenticated, denied, rejected, abandoned, canceled, not_supported, requires_escalation, authentication_required, approval_required, PaymentData, purchase_order_number, payment_terms, due_date, continue_url.

Una transacción que escala de forma limpia es mejor que una que termina silenciosamente. Las rutas de escalación deben diseñarse como flujos principales.

La confirmación del pedido es un envío, no una consulta

Después de una compra, la plataforma no tiene que consultar continuamente la API. El comercio envía webhooks firmados y la superficie del agente recibe la verdad del pedido.

La referencia de ACP define eventos de pedido para mantener sincronizado el fulfillment. Hay eventos de creación y actualización; importan la firma, el objeto completo y la respuesta. La validación comprueba order_create, order_update, created, manual_review, confirmed, canceled, shipped, fulfilled.

• Firma: la cabecera HMAC debe validarse.\n- Objeto completo: data contiene el objeto Order entero.\n- Respuestas: trata éxito, firma inválida y limitación. La descripción retiene Merchant-Signature, 401, data, 200, 429.

La plataforma sabe que el pedido salió adelante porque el comercio lo comunica con un POST firmado que contiene el objeto completo y respeta los reintentos. El inventario enumera 429.

Fraude, contracargos y responsabilidad: qué está resuelto y qué no

Esta revisión técnica aborda el checkout agéntico aquí: El reintento evita pérdida y duplicación.

Resuelto: el comercio de registro. La especificación de OpenAI indica que OpenAI no es el comercio de registro. El comercio aporta su PSP y conserva liquidación, reembolsos, contracargos y cumplimiento.

Abierto: la prueba de un contracargo. Saber quién absorbe una disputa no explica cómo ganarla cuando el comprador fue mediado por IA. Los registros del agente son otra clase de evidencia y las reglas de las redes no se escribieron para ellos.

Los marcos emergentes no están terminados. Visa presenta Trusted Agent Protocol para verificar identidad e intención. Mastercard Agent Pay y Agentic Tokens forman otra línea. La atribución de terceros debe tratarse como reportada, no confirmada.

Qué deben implementar y probar los comercios

El contenido existente aconseja feeds limpios y programas de fidelidad. La capa operativa añade qué construir y verificar antes de activar el checkout agéntico.

• Postura de PCI: compara tokens del PSP con el manejo directo de CHD.\n- Reintentos: una clave repetida no debe duplicar cargos.\n- Webhooks: valida HMAC.\n- Escalaciones: fuerza autenticación y 3DS.\n- Precios: feed y checkout deben coincidir.\n- Atribución: registra el origen en OMS. La arquitectura considera request_not_idempotent, Merchant-Signature, 200, 429, requires_escalation, authentication_required, AuthenticationResult, denied, rejected, abandoned, authenticated.

Esta revisión técnica aborda el checkout agéntico aquí: Una integración fiable registra contexto antes de operar.

Situación a mediados de 2026

La adopción real era temprana. Solo una fracción pequeña de comercios de Shopify usaba checkout con IA y OpenAI había devuelto Instant Checkout hacia descubrimiento y redirección por problemas de incorporación, precisión y carritos con varios artículos.

Eso no convierte el checkout agéntico en humo. Crear, actualizar y completar una sesión con pago delegado y webhooks firmados está especificado; lo que cambia es si termina en el chat o en el sitio.

Resumen de IA

Esta es una síntesis de la versión avanzada: el checkout agéntico es una sesión gobernada por estados, permisos limitados y confirmación asíncrona.

• Función: el agente crea, actualiza, completa o cancela una sesión.\n- Estados: modela camino feliz, escalación, aprobación y expiración.\n- Persona: inicio de sesión, 3DS, dirección y aprobación B2B son pausas válidas.\n- Pago: el token se ata al comercio y sesión, limita importe y tiempo, y se usa una vez.\n- Pedido: los webhooks HMAC llevan el objeto completo.\n- Responsabilidad: el comercio conserva registro y contracargos, pero la evidencia sigue abierta.\n- Prueba: comprueba idempotencia, firmas y escalaciones. El resumen enumera not_ready_for_payment, ready_for_payment, requires_escalation, authentication_required, completed, canceled, expired, pending_approval, incomplete, ready_for_complete, approval_required, continue_url, merchant_id, checkout_session_id, max_amount, expires_at, reason: one_time, Merchant-Signature, order_create, order_update, 200, 401, 429, request_not_idempotent.

Documentación oficial

Documentación de fuentes primarias para entender la mecánica del checkout.

ACP: checkout, ciclo de vida y webhooks. Estas referencias cubren endpoints, estados, errores, transiciones y webhooks. El contrato exige CheckoutSession, MessageError, RiskSignals, AuthenticationResult, InterventionCapabilities, ready_for_payment, order_create, order_update, Merchant-Signature, fuente, fuente, fuente, fuente.

OpenAI y Stripe: delegación del pago. Estas referencias explican el token, autorización, PCI y comercio de registro. La referencia mantiene max_amount, expires_at, merchant_id, checkout_session_id, reason, fuente, fuente, fuente, fuente.

UCP: máquina paralela. La guía resume elegibilidad y el papel del comercio de registro. La evidencia conserva fuente.

Plataforma y redes. Shopify y Visa aportan requisitos y contexto sobre identidad del agente. La guía explicita fuente, fuente.

Citas de la fuente

Declaraciones registradas sobre el funcionamiento del checkout agéntico y sobre las preguntas abiertas. Los enlaces profundos llevan al pasaje citado.

ACP y OpenAI: la especificación

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (traducción) «El comercio mantiene el control total del inventario, los precios, los impuestos y el procesamiento del pago.».
• “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (traducción) «La enumeración distingue estados incompletos, de pago, escalación, autenticación, aprobación, progreso, finalización, cancelación y expiración.».
• “OpenAI is not the merchant of record.” (traducción) «OpenAI no es el comercio de registro.».
• “payment token scoped to the delegated payment” (traducción) «token de pago limitado al pago delegado». — Referencias de ACP y OpenAI. Ir a la fuente Ir a la fuente Ir a la fuente Ir a la fuente

Voces de la industria: la responsabilidad

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (traducción) «El comercio agéntico aporta eficiencia, pero también una capa de fraude y confusión que los sistemas heredados no interpretan.».
• “there are no clean answers yet” (traducción) «todavía no hay respuestas sencillas».
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (traducción) «Ambos protocolos mantienen al comercio como comercio de registro, responsable del fulfillment, los contracargos y las disputas.». — Voces de Chargeflow y Rye. Ir a la fuente Ir a la fuente Ir a la fuente

Redes de pago: marcos emergentes

• “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (traducción) «un marco basado en estándares para verificar en tiempo real la identidad y la intención del agente, evitar la suplantación y preservar la experiencia.». — Visa, informe sobre amenazas y riesgos del comercio agéntico. Ir a la fuente

Realidad de la adopción

• “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (traducción) «La normalización en tiempo real de catálogos con decenas de millones de SKU es un problema de décadas que Google ya resolvió con Merchant Center, y los consumidores siguen eligiendo flujos de checkout de confianza: Apple Pay, Google Wallet y el pago en un clic de Amazon.». — Leigh McKenzie, Semrush, a través de Search Engine Land. Ir a la fuente

Nota: algunas páginas cargan documentación con JavaScript y dificultan la verificación. Los enlaces con fragmento deben confirmarse en las páginas activas. La cifra de comercios y el cambio de OpenAI se transmiten mediante Search Engine Land. La atribución de Mastercard procede de terceros y se presenta como reportada, no confirmada. La observación conserva #:~:text=.

¿Qué ruta de integración de pagos conviene elegir?

La primera decisión de arquitectura es cómo delegar el pago, porque determina el alcance de PCI y cuánto código opera el comercio. El árbol ordena esa decisión.

Pruebas previas al lanzamiento del checkout agéntico

Ejecuta estas comprobaciones en sandbox antes de producción. El objetivo es verificar el flujo operativo y los fallos previsibles.

1. Crea una sesión: confirma el estado inicial y pago listo.\n2. Verifica totales: subtotal, impuestos, fulfillment, descuentos y total deben coincidir.\n3. Completa: procesa pago y crea pedido.\n4. Cancela: libera inventario.\n5. Fuerza escalaciones: prueba 3DS y resultados.\n6. Prueba idempotencia: repite con la misma clave y confirma un pedido.\n7. Separa errores: verifica MessageError.\n8. Comprueba firmas: acepta válido, rechaza alterado y exige Order completo.\n9. Prueba presión: reintenta con espera.\n10. Confirma atribución: etiqueta el pedido en OMS. La ficha conserva POST /checkout_sessions, 201, not_ready_for_payment, incomplete, ready_for_payment, totals[], POST /checkout_sessions/{id}/complete, completed, POST /checkout_sessions/{id}/cancel, requires_escalation, authentication_required, AuthenticationResult, denied, rejected, abandoned, canceled, not_supported, authenticated, request_not_idempotent, MessageError, messages[], order_create, Merchant-Signature, 200, 401, 429.

Errores comunes y qué hacer en su lugar

Suponer autonomía total. Las especificaciones conservan una costura de autorización. Diseña escalaciones, 3DS y aprobaciones como flujos principales. El contrato exige requires_escalation, authentication_required, approval_required, continue_url.

Tratarlo como normal. La adopción es pequeña. Construye contra la capacidad real y planifica como integración temprana.

Creer que comercio de registro resuelve toda la responsabilidad. Determina quién responde, pero no cómo demostrar autorización. Conserva logs y señales de riesgo.

Asumir que el agente evita siempre el sitio. La experiencia puede terminar en chat o redirección. Mantén sólido el checkout alojado.

Pensar que el agente maneja la tarjeta. El diseño usa tokens delegados. Enruta por el PSP y mantén pequeño el alcance de PCI.

Ignorar la idempotencia. Las redes repiten solicitudes. Exige claves y devuelve el mismo resultado para la misma clave. La validación comprueba request_not_idempotent.

Hoja de referencia del checkout agéntico

Enum de estados de la sesión de checkout de ACP

| Estado | Significado |\n| --- | --- |\n| incomplete / not_ready_for_payment | El carrito todavía se reúne |\n| ready_for_payment | El fulfillment está definido |\n| requires_escalation / authentication_required | Necesita una persona o verificación |\n| pending_approval | Espera aprobación B2B |\n| complete_in_progress / in_progress | La finalización está en curso |\n| completed | Terminal: se creó el pedido |\n| canceled | Terminal: se liberó inventario |\n| expired | La sesión agotó su plazo | La integración reconoce incomplete, not_ready_for_payment, ready_for_payment, requires_escalation, authentication_required, pending_approval, complete_in_progress, in_progress, completed, canceled, expired, expires_at.

La máquina de UCP es una sesión incompleta que pide escalación humana mediante una URL de continuación y después queda lista. La señal incluye incomplete, requires_escalation, continue_url, ready_for_complete.

Endpoints de checkout de ACP\n- Crear sesión.\n- Recuperar sesión.\n- Actualizarla.\n- Procesar pago y crear pedido.\n- Cancelar y liberar inventario. La recuperación conserva POST /checkout_sessions, 201, GET /checkout_sessions/{id}, POST /checkout_sessions/{id}, POST /checkout_sessions/{id}/complete, POST /checkout_sessions/{id}/cancel.

Token de pago limitado: cuatro límites\n- Comercio y sesión.\n- Tope de importe.\n- Vencimiento.\n- Uso único. El ejemplo utiliza merchant_id, checkout_session_id, max_amount, expires_at, reason: "one_time".

Webhooks de pedido de ACP\n- Creación y actualización.\n- Firma HMAC obligatoria.\n- Objeto Order completo.\n- Respuestas de éxito, firma inválida y limitación. El diagnóstico muestra order_create, order_update, Merchant-Signature, 200, 401, 429, created, manual_review, confirmed, canceled, shipped, fulfilled.

Activadores de intervención humana\n- Escalación o autenticación.\n- Capacidades para 3DS y dirección.\n- Resultados de autenticación.\n- Aprobación B2B y URL de continuación. La arquitectura considera requires_escalation, authentication_required, InterventionCapabilities, 3ds, address_verification, always, conditional, optional, AuthenticationResult, authenticated, denied, rejected, abandoned, approval_required, continue_url.

Responsabilidad de un vistazo\n- El comercio conserva liquidación, reembolsos y contracargos: resuelto.\n- La evidencia para compradores-agente: abierta.\n- Visa TAP y Mastercard Agent Pay: marcos emergentes.

Fragmentos para trabajar con checkout agéntico

Estos fragmentos sirven para inspeccionar y probar la integración, no para comprar en vivo. Usa credenciales de sandbox.

Verificar una firma de webhook (Node.js, HMAC)

Rechaza cualquier petición cuya firma Merchant-Signature no coincida y compara los valores en tiempo constante. La verificación reúne Merchant-Signature.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Consultar el estado de una sesión de checkout (shell)

Observa cómo una sesión de sandbox recorre la máquina de estados durante la prueba.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Enviar una creación con una clave de idempotencia (Python)

Demuestra que un reintento con la misma clave produce un pedido y no dos.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Fragmento de consola: buscar un perfil UCP .well-known

Comprobación rápida en DevTools para saber si un comercio expone el descubrimiento de UCP.

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Marcador: saltar al enum de estados de checkout en la documentación de ACP

Guarda este marcador para abrir la referencia de Checkout de ACP en la lista de estados.

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Fallos habituales del checkout agéntico

Un reintento crea dos pedidos o cargos

Síntoma: la sesión genera pedidos duplicados tras un reintento. Causa: las llamadas no usan claves. Solución: exige idempotencia y confirma en sandbox un solo pedido.

El checkout nunca queda listo para el pago

Síntoma: la sesión permanece no lista o incompleta. Causa: falta fulfillment, dirección o regla. Solución: revisa campos y messages[] y confirma el avance. La recuperación conserva not_ready_for_payment, incomplete, messages[], ready_for_payment, ready_for_complete.

Una solicitud válida parece correcta, pero el carrito no termina

Síntoma: HTTP funciona, pero la sesión contiene un artículo agotado. Causa: el cliente ignora mensajes. Solución: procesa transporte y estado. El diagnóstico muestra MessageError.

La verificación humana termina en un callejón sin salida

Síntoma: el checkout entra en escalación o autenticación y no vuelve. Causa: el traspaso se trató como error. Solución: conserva la sesión y maneja cada resultado. La observación conserva requires_escalation, authentication_required, continue_url.

El estado del pedido deja de actualizarse después del pago

Síntoma: el comercio tiene el pedido, pero la superficie sigue pendiente. Causa: falla la firma, se envió un delta o se descartó una respuesta. Solución: firma, envía el objeto completo y reintenta. La tabla muestra 429.

Modelos mentales para el checkout agéntico

El checkout es una máquina de estados, no una sola llamada de API

Cada respuesta debe mover la sesión a un estado conocido o explicar por qué no avanza. Diseña alrededor de transiciones, terminales, reintentos y escalaciones.

La autoridad permanece en el comercio

El agente expresa intención, pero el comercio mantiene autoridad sobre precio, inventario, impuestos, fulfillment, estado y obligaciones de registro. El carrito del comercio es verdad.

La delegación reduce el permiso

Un token limitado está ligado al comercio y sesión, tiene tope, caduca y solo se usa una vez. Evalúa qué puede hacer, para quién, por cuánto y durante cuánto tiempo.

La escalación es una rama válida

La intervención humana no indica que haya fallado el checkout. Una transferencia limpia para 3DS, inicio de sesión, dirección o aprobación B2B es el protocolo funcionando.

Entrega asíncrona tras el pago

Completar el pago no termina la integración. Los webhooks firmados con el objeto completo llevan la verdad del pedido; firma, replay y reintentos forman parte de la fiabilidad.

Métricas del checkout agéntico

Finalización del checkout por estado terminal

• Métrica: sesiones completadas, canceladas o expiradas como proporción de iniciadas.\n- Qué indica: dónde termina la máquina y cuánta intención se pierde.\n- Cómo obtenerla: agrega estados y segmenta por protocolo.\n- Referencia: crea una línea base propia.\n- Cadencia: revisión diaria.

Tasa de recuperación tras una escalación

• Métrica: sesiones escaladas que regresan y terminan después de 3DS, inicio de sesión, dirección o aprobación.\n- Qué indica: si la transferencia es utilizable.\n- Cómo obtenerla: une eventos con transiciones por ID.\n- Referencia: línea base por intervención.\n- Cadencia: revisión semanal.

Tasa de pedidos duplicados y fallos de webhook

• Métrica: pedidos duplicados y webhooks rechazados.\n- Qué indica: si idempotencia y sincronización resisten fallos.\n- Cómo obtenerla: compara claves, IDs, firmas, respuestas y reintentos en logs.\n- Referencia: duplicados deben ser cero.\n- Cadencia: alerta inmediata. La integración reconoce 401, 429.

Recursos que merecen tu tiempo

Escritura relacionada\n- ACP y UCP se explican en artículos hermanos; esta página profundiza en la mecánica.\n- La guía de SEO ecommerce aporta contexto. El diagnóstico muestra fuente, ruta, ruta.

Charlas y demostraciones\n- La explicación de búsqueda aporta contexto para la transacción mediada por agentes. La advertencia es que se trata de una comprensión personal. La arquitectura considera 100, fuente.

Fuentes del sector\n- Estas referencias contrastan ACP, pagos delegados, webhooks, contracargos, identidad de agentes y los marcos de Visa y Mastercard. La observación conserva fuente, fuente, fuente, fuente, fuente, fuente, fuente, fuente.

Estadísticas que merece la pena citar

Estas cifras sitúan el checkout agéntico. Las cantidades transmitidas son orientativas y deben verificarse.

• Adopción: alrededor de una docena de comercios de Shopify usaban checkout con IA.\n- Cambio: Instant Checkout pasó de completar en chat a descubrir y redirigir.\n- Token: importe máximo, vencimiento, comercio o sesión y uso único.\n- Webhook: data lleva el objeto Order completo y toda petición va firmada con HMAC. El modelo conserva max_amount, expires_at, merchant_id, checkout_session_id, reason: one_time, data, fuente, fuente, fuente.

Ponte a prueba: checkout agéntico

Cinco preguntas rápidas sobre la mecánica del checkout. Elige una respuesta y comprueba tu razonamiento.

Registro de cambios