Checkout para agentes: aprueba el total y verifica el pago

Una persona pide al asistente un cargador compatible por un máximo de 60. El producto cuesta 49; envío 6 e impuesto supuesto 11: total 66. Aún no es un problema de pago agéntico: es una oferta fuera del presupuesto. Las cifras usan una moneda sin especificar y son un ejemplo, no una recomendación fiscal.

Supongamos ahora que el comprador aprueba el total revisado de 66 por una ruta compatible. La petición de pago agota el tiempo. ¿Falló, o el proveedor cobró y se perdió la respuesta? «Reintentar» es peligroso si crea otro pago.

Estos dos momentos explican mejor el checkout para agentes que una colección de logos. Primero acredita que la compra actual está permitida; después establece lo ocurrido. La tienda de electrónica es ficticia y didáctica, no un resultado comercial observado.

Cotiza toda la compra, no solo el artículo

El límite original de 60 no cubre 66; faltan 6. No lo reinterpretes en silencio como presupuesto solo del artículo ni dividas el pago para eludirlo. Presenta una alternativa permitida u obtén nueva aprobación. Cambiar entrega, cantidad, conector, moneda o vendedor también puede cambiar lo aprobado.

Una cotización útil identifica variante, compatibilidad, importes, descuentos, impuestos, envío, moneda, entrega estimada y otros cargos aplicables. Explica vigencia y condiciones de reserva. Si cambia una condición relevante, revalida y renueva autoridad; no cobres una cotización obsoleta. El carrito no garantiza reserva.

No todos necesitan la misma ruta: checkout propio, transferencia de carrito o integración elegible dentro del asistente. La guía de checkout nativo de Google describe un ciclo compatible, no inscripción universal. Confirma ruta y versión disponibles para tu comercio.

Haz cuatro preguntas distintas de confianza

Reconocer al solicitante, probar autoridad del comprador, validar credenciales y evaluar la transacción son controles relacionados, no sustitutos. La tabla los separa. Un agente auténtico puede pedir una compra no autorizada; aprobarla tampoco evita una negativa exigida por controles normales.

El modelo de mandatos AP2 distingue aprobar directamente un carrito de delegar instrucciones para actuar después. Aplica el mandato compatible y sus límites; una conversación no es por sí sola un mandato verificado.

El anuncio de FIDO de abril de 2026 describe desarrollo de estándares con aportaciones AP2 y Verifiable Intent. No certifica interoperabilidad actual de toda integración comercial.

Pregunta	Evidencia	Qué no sustituye
¿Quién solicita?	Verificación compatible de solicitante/sesión	Autoridad del comprador ni cada permiso
¿Qué permitió el comprador?	Carrito exacto actual o delegación limitada	Procesamiento ni control de fraude
¿Puede usarse la credencial?	Alcance, importe y validez verificados	Idoneidad ni toda la intención del cliente
¿Qué ocurrió?	Registros verificados del proveedor y comercio	Por sí solos, liquidación, entrega o disputa

El token limita acceso, no lo prueba todo

La guía actual de Stripe para vendedores describe Shared Payment Tokens por vendedor, con límites de uso y caducidad, incluidas configuraciones recurrentes. No presupongas una credencial bancaria universal de un uso y treinta minutos.

Pregunta qué proveedor valida el permiso, vendedor y moneda cubiertos, importe, usos y aplicación de caducidad o revocación. Vincula la credencial a la compra aprobada y permisos actuales. Una credencial válida no demuestra compatibilidad ni cantidad deseada.

No pongas credenciales en prompts, memoria del modelo, capturas, analítica o logs normales. Guarda solo referencias protegidas y pruebas necesarias bajo la política aplicable. La tokenización no elimina control de acceso, manejo seguro ni obligaciones de pago del flujo elegido. Usa bibliotecas compatibles, sin inventar criptografía.

Un timeout deja el resultado desconocido hasta conciliar

Antes de la petición relevante, crea una referencia local duradera ligada al pedido y payload aprobados. Repetir esa operación no debe crear cargos. Protege también peticiones simultáneas contra duplicados; una clave nueva por clic derrota el objetivo.

Tras el timeout, consulta la referencia existente del proveedor o sesión y procesa evidencia autenticada. Si sigue desconocido, conserva el estado, informa al comprador y programa conciliación limitada con backoff, jitter, máximo de intentos y responsable. No declares fallo, retires todas las salvaguardas ni prepares dos envíos porque terminó la petición.

Las reglas de idempotencia de Stripe varían por versión: v1 puede repetir un error guardado y una clave eliminada generar otra petición. No cambies claves a ciegas para evitar errores.

Distingue autorización, captura, aceptación del pedido, liquidación y preparación del envío. Una pantalla de éxito o el «pagado» del asistente no bastan. La guía de webhooks de Stripe exige verificar firmas y tratar eventos duplicados o desordenados. Valida el estado real y haz repetibles de forma segura los efectos locales.

Conserva el control de fraude y los permisos

Una petición firmada puede identificar al solicitante bajo un esquema compatible. No concede acceso general a productos, pedidos y pagos. Verifica emisor o clave, audiencia y vigencia cuando proceda, y aplica permisos y límites actuales. Un encabezado «AI agent» inventado no prueba nada.

Usa señales de riesgo pertinentes sin decidir solo por ausencia de movimientos de ratón. Un agente verificado sigue necesitando controles; automatización no verificada tampoco equivale automáticamente a fraude. Deniega, solicita verificación adicional compatible o ofrece una ruta normal autorizada según el caso. Confirmar como humano no elimina prohibiciones legales, credenciales robadas ni fallos de seguridad pendientes.

Limita estado y devoluciones al comprador verificado o representante autorizado y al pedido/cuenta correctos. No incluyas stock privado, direcciones, facturas ni datos de pago en descubrimiento público. Aplica límites seguros y vigila repetición, velocidad y múltiples pedidos con una sola aprobación.

Conserva pruebas desde el recibo hasta la disputa

Confirma referencia real, artículos, total, moneda y estado por un canal utilizable para el comprador. Acuerda soporte y contacto; una dirección relay legítima no es inválida por definición. No dependas solo del asistente para entregar el recibo. Seguimiento o estado enviado no prueban entrega.

Al devolver, comprueba política, derechos, bienes recibidos y remedio autorizado aparte del pago. La guía de reembolsos de Stripe distingue método original, reembolsos fallidos y alternativas permitidas. Sigue excepciones documentadas, sin improvisar transferencias ajenas.

Retén cotización/version aprobadas, referencias de autoridad y proveedor, política, comunicaciones y pruebas de entrega con acceso restringido. Un token utilizable no es un adjunto de auditoría. Evita doble abono si coinciden reembolso y disputa, y concilia el resultado final.

Pregunta al adquirente o proveedor quién gestiona cada disputa, autenticación, plazo de pruebas y condición de responsabilidad de tu programa. Un mandato firmado puede ser evidencia sin garantizar ganar ni transferir todas las pérdidas. Un anuncio comercial no establece una regla universal de responsabilidad.

Prueba las rutas de fallo antes de ampliar

Usa sandbox elegible e identidades de prueba aprobadas, no tarjetas reales. Prueba 66 contra el límite original de 60, carrito cambiado, credenciales caducadas/revocadas, vendedor o moneda incorrectos, confirmación duplicada, timeout tras éxito del proveedor, eventos tardíos/repetidos, incompatibilidad, acceso privado y solapamiento de reembolso parcial y disputa.

Pide a un operador demostrar registros completos: una compra aprobada, el resultado de pago previsto, una decisión de preparación y un remedio trazable. Asigna plazo de respuesta, escalado y condición de parada a pagos desconocidos. Pasar sandbox no prueba elegibilidad real ni comportamiento de todos los emisores; confírmalo con el proveedor.

Mide intentos aprobados, capturas, resultados desconocidos, duplicados, errores de preparación, soporte y reembolsos/disputas con denominadores y ventanas explícitos. Amplía cuando el equipo pueda conciliar y recuperarse de fallos. La promesa útil es un recorrido controlado, no una venta autónoma a cualquier precio.

Parte 3. Lee también rutas y preparación del comercio y descubrimiento y GEO.

Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. Escenas e importes son ilustrativos; condiciones y capacidades varían.