Pagos con agentes de IA en Android: wallets, límites e intención verificable

Del asistente de compras a la autoridad para pagar

El cambio importante en el comercio con IA no consiste en que un asistente encuentre productos más deprisa. La cuestión decisiva es qué autoridad recibe para seleccionar una oferta, abrir una sesión de checkout, presentar un medio de pago y completar la operación. Cuando un agente interviene en esos pasos, la conversación se convierte en una cadena de decisiones que debe atribuirse al usuario y quedar respaldada por pruebas comprensibles.

La documentación de pagos para agentes de Alipay, actualizada el 23 de julio de 2026, explica que los comercios con una aplicación, un Mini Program o un sitio web existentes pueden hacer que sus productos y servicios sean invocables por un agente. Alipay completa el pago después de que el usuario lo confirme. Este diseño enlaza el descubrimiento y la selección con un checkout real, pero mantiene una decisión humana reconocible antes del cargo.

Google amplía el marco con la versión 0.2 de Agent Payments Protocol, anunciada el 28 de abril de 2026. AP2 contempla operaciones denominadas Human Not Present basadas en instrucciones previamente autorizadas. También introduce Verifiable Intent: un registro resistente a manipulaciones que vincula la actuación del agente con la voluntad expresada por la persona. No basta, por tanto, con guardar un historial de chat; hay que demostrar qué se autorizó, durante cuánto tiempo y con qué condiciones.

Para los pagos con agentes de IA en Android, estas señales trasladan el centro de gravedad desde la recomendación hacia la responsabilidad operativa. El agente necesita conocer su alcance y el teléfono debe mostrar cuándo una sugerencia pasa a ser una acción con consecuencias económicas. La colaboración entre servicios y dispositivos tiene además límites propios; nuestro análisis sobre OPPO y Alipay AI Agents: intención y ejecución profundiza en ese traspaso sin confundirlo con una autorización de pago universal.

Wallet, asistente y agente de pago no son lo mismo

¿Qué es exactamente una wallet para agentes de IA? No es simplemente una aplicación que almacena tarjetas. Es un sistema capaz de asociar un instrumento de pago con instrucciones utilizables por un agente, límites definidos y evidencia de autorización. La wallet protege y presenta las credenciales; el agente interpreta la tarea; el checkout calcula el importe y las condiciones; el mecanismo de autenticación valida la intervención del usuario cuando corresponde.

Esta separación evita un error frecuente: suponer que comprender una petición equivale a tener permiso para ejecutarla. Un modelo puede entender «compra el mismo café de la semana pasada», pero todavía faltan el comercio autorizado, la variante exacta, el precio máximo, la dirección, el método de pago y la confirmación aplicable. Tampoco una wallet decide por sí sola si el producto satisface la intención original.

El Universal Commerce Protocol, presentado por Google Developers el 11 de enero de 2026, busca normalizar intercambios comerciales mediante APIs, A2A y MCP, y es compatible con AP2. Su valor está en estructurar la comunicación entre participantes. La compatibilidad técnica no sustituye las reglas de autoridad de cada operación. Para entender cómo la búsqueda y la cesta preceden al pago, puede consultarse nuestra guía Agentes de compras con IA: qué enseñan JD, Tencent y el control desde el móvil.

Quién autoriza el pago y bajo qué límites

La pregunta práctica es sencilla: ¿puede pagar un agente si el usuario no está presente? AP2 v0.2 describe esa posibilidad cuando existe una instrucción previa verificable, pero no convierte cualquier petición antigua en un permiso permanente. Una autorización útil debe expresar el objetivo y acotar la capacidad del agente para que una compra inesperada no parezca equivalente a la tarea original.

Con el usuario presente, el recorrido puede terminar en una pantalla que muestre comercio, artículos, impuestos, entrega, importe total y medio de pago. La persona revisa esos datos y se autentica antes de confirmar. Es el patrón más claro para compras ocasionales, proveedores nuevos, cambios de precio, sustituciones y cualquier operación cuyo contexto no se pueda anticipar con precisión.

Una operación preautorizada necesita más estructura. Puede limitarse a un importe máximo por compra y por periodo, una lista de comercios o categorías, productos concretos, una dirección autorizada y una fecha de caducidad. También debe admitir revocación inmediata. Por ejemplo, «reponer este producto cuando queden menos de dos unidades, hasta 25 euros, durante los próximos 30 días y solo en estos comercios» expresa mucha más autoridad comprobable que «encárgate de mis compras».

Las excepciones deben devolver el control a la persona. Un precio superior al límite, un comercio distinto, gastos de envío inesperados, una suscripción, un cambio de cantidad o la ausencia del artículo elegido requieren una nueva decisión. La autorización tampoco debe ampliarse silenciosamente porque el agente encuentre una alternativa parecida. La relación entre identidad, alcance y registro se desarrolla en Identidad, permisos y auditoría de agentes IA: la capa de seguridad que necesita un teléfono.

Así, la autonomía no se mide por cuántas pantallas evita el sistema, sino por la precisión con que ejecuta una intención autorizada. Un buen diseño permite delegar tareas repetitivas sin perder la capacidad de detenerlas, revisar su fundamento o exigir confirmación cuando aparece una condición nueva.

La cadena completa de una transacción en Android

En Android, el pago es el último tramo de un recorrido con varias piezas. Primero se registra la intención: qué necesita la persona, con qué preferencias y presupuesto. Después llega la información comercial, que identifica vendedor, producto, disponibilidad, impuestos, entrega y políticas aplicables. Solo entonces debe crearse una sesión de checkout con un total actualizado.

1. Intención: objetivo, criterios, límites y periodo de validez definidos por el usuario.
2. Selección: producto, cantidad y comercio compatibles con esas instrucciones.
3. Checkout: sesión que presenta el desglose final, la entrega y cualquier condición recurrente.
4. Instrumento: medio de pago admitido, elegido dentro del alcance autorizado.
5. Autenticación: validación del dispositivo o confirmación explícita cuando el recorrido la exige.
6. Resultado: estado inequívoco de aprobación, rechazo, cancelación o espera.
7. Evidencia: recibo, referencia comercial y registro de la intención aplicada.
8. Recuperación: acceso a cancelación, devolución, asistencia o reclamación.

La explicación de los tokens de dispositivo de Google Wallet detalla que estos sustituyen el número real de la tarjeta en las operaciones compatibles. A su vez, la autenticación del dispositivo Android protege el uso de la wallet. Es un mecanismo concreto para reducir la exposición de la credencial subyacente; no autoriza por sí mismo al agente a decidir qué comprar.

Android ofrece además orientación para integrar autenticación biométrica. Su función en esta cadena consiste en verificar la participación de la persona en el momento apropiado. La aplicación todavía debe mostrar con claridad qué acción se está autorizando. Una huella o el reconocimiento facial pierden valor explicativo si la pantalla no identifica el comercio, el importe y la consecuencia.

El registro final debe unir la instrucción con la operación realizada. Conviene conservar el identificador del pedido, el importe, el comercio, la hora, el alcance utilizado, la confirmación y cualquier cambio respecto al plan. Las habilidades que intervienen también necesitan permisos ajustados a su tarea, un aspecto que tratamos en Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real.

Cómo aborda FoneClaw los recorridos que llegan al checkout

En FoneClaw separamos el razonamiento de la acción sobre el teléfono. El modelo compatible que configura el usuario interpreta la petición, reúne el contexto disponible y prepara un plan. FoneClaw lleva ese plan a las acciones Android admitidas, mantiene visible el estado del recorrido, solicita los permisos necesarios y pide confirmación cuando el siguiente paso tiene consecuencias relevantes.

En una compra, ese enfoque permite ayudar con tareas como abrir una aplicación compatible, buscar un artículo, comparar opciones visibles, completar datos admitidos o avanzar hasta la revisión del pedido. Al llegar al checkout o a una pantalla de pago, el usuario debe poder comprobar el comercio, los artículos, la cantidad, el coste total y las condiciones antes de continuar. La interacción final depende de la aplicación, la wallet, el dispositivo y los métodos de autenticación disponibles.

FoneClaw no trata un mensaje ambiguo como autorización económica abierta. Si el precio cambia, falta un dato, aparece una suscripción o la aplicación presenta una alternativa distinta, el recorrido se detiene en un punto comprensible para que la persona decida. Cuando una acción no está disponible, ofrecemos una alternativa práctica: abrir la pantalla correspondiente, presentar la información reunida o indicar el paso manual necesario.

Este diseño mantiene unidos planificación y control. Los resultados visibles permiten saber qué se completó y qué sigue pendiente; los permisos delimitan las funciones accesibles; la confirmación conserva la decisión humana en los momentos decisivos. Para situar estas capacidades dentro del conjunto de acciones móviles, consulte Control del teléfono con agente de IA: qué puede hacer de verdad un phone AI agent.

Las futuras wallets para agentes podrán hacer más cómoda la delegación recurrente, especialmente cuando combinen instrucciones verificables con límites precisos. Nuestro criterio de producto permanece constante: cada ampliación de capacidad debe ir acompañada de un estado más claro, una autoridad mejor definida y una vía directa para intervenir.

Lista de control para usuarios y desarrolladores

Antes de delegar una compra, el usuario debería poder responder qué puede adquirir el agente, dónde, por cuánto dinero y hasta cuándo. Para los desarrolladores, esas mismas preguntas deben convertirse en datos estructurados y controles visibles, no quedar escondidas en una conversación difícil de revisar.

• Identidad: indique qué usuario, agente, comercio y proveedor de pago participan.
• Alcance: defina productos, categorías, comercios, direcciones y acciones permitidas.
• Límites: establezca máximos por operación y periodo, además de reglas para impuestos, propinas y entrega.
• Vigencia: añada fecha de inicio, caducidad y revocación inmediata.
• Evidencia: conserve la instrucción autorizada, sus cambios y la confirmación aplicable.
• Presentación: muestre el total, el vendedor, la recurrencia y las sustituciones antes del paso decisivo.
• Resultado: diferencie con claridad entre operación aprobada, pendiente, rechazada y cancelada.
• Recuperación: facilite recibos, cancelaciones, devoluciones y vías para disputar una acción.

Las suscripciones merecen un tratamiento propio porque una confirmación inicial puede originar cargos posteriores. El checkout debe identificar la periodicidad, el importe previsto, las reglas de renovación y el método para cancelar. Del mismo modo, una devolución no está completa hasta que el sistema muestra su estado y conserva la referencia que permite seguirla.

También conviene probar los límites antes de usar una autorización recurrente: superar deliberadamente un importe de prueba, seleccionar un comercio no permitido, dejar caducar la instrucción y revocarla. El comportamiento correcto es detener el flujo y solicitar una decisión nueva. Esta prueba revela más sobre la calidad del sistema que una demostración donde todos los datos coinciden.

Los pagos con agentes de IA en Android serán útiles cuando reduzcan trabajo sin diluir la responsabilidad. La mejor experiencia no es la que oculta el mayor número de pasos, sino la que convierte la intención en acciones trazables, aplica límites previsibles y devuelve el control a tiempo. Wallet, protocolo, comercio, autenticación y agente del teléfono cumplen funciones distintas; coordinarlos con evidencia y recuperación es lo que transforma una sugerencia de compra en una transacción gobernable.