Diseño de un proceso de pago gestionado por agentes: autoridad delegada, cotizaciones obsoletas, intentos de reintentar.

Diseñar un sistema de pago solía ser una pregunta sencilla en las entrevistas, ya que existía una solución de referencia disponible por todas partes y un candidato competente podía reproducirla en veinte minutos. La variante actual introduce un agente de software entre el comprador y el vendedor, lo que hace que casi todas las suposiciones inherentes a la solución memorizada fallen. No existe un artículo canónico que memorizar al respecto, y esa es precisamente la razón por la cual se sigue planteando esta pregunta.

Por qué surgió

Tres avances ocurrieron en un corto período de tiempo.

Primero, un estándar abierto. El Agentic Commerce Protocol, gestionado conjuntamente por OpenAI y Stripe, especifica cómo los compradores, sus agentes, los vendedores y los procesadores de pagos se comunican entre sí. En su núcleo se encuentra un token de pago compartido: el agente puede finalizar una compra sin siquiera ver los datos de la tarjeta, mientras que el vendedor mantiene el rol de comerciante registrado.

En segundo lugar, un diseño rival. El Protocolo de Pagos Agentes de Google trata la autorización como mandatos firmados, transmitidos mediante JWTs de divulgación selectiva. Un mandato demuestra que el usuario aprobó la compra y otro demuestra la aprobación del pago; cada uno puede ser abierto, con las restricciones registradas de antemano, o cerrado, vinculado a un carrito final.

En tercer lugar, la investigación en seguridad avanzó rápidamente. Un estudio sistemático de AP2 enumera 48 amenazas distintas agrupadas en cinco familias, ocho de las cuales tienen una gravedad alta; todas han sido probadas en un entorno real y no se limitan a descripciones teóricas. Para un entrevistador, este es material ideal, ya que los modos de fallo son reales y específicos, y no se necesita ningún truco para dar profundidad a la pregunta.

La solicitud tal como llega

Las palabras varían, pero los requisitos suelen ser similares a estos:

1. Un comprador pide a un asistente que compre algo, posiblemente estableciendo límites como un precio máximo o una fecha límite de entrega.
2. El agente examina a varios vendedores, evalúa las opciones y elige uno.
3. La transacción se realiza sin que el agente tenga acceso a los datos brutos de la tarjeta.
4. El comprador puede revisar lo que fue aprobado, y las disputas se pueden resolver posteriormente.
5. Ninguna compra se duplica ni se lleva a cabo más allá de lo que el comprador realmente ha consentido.

El quinto requisito merece una segunda lectura, porque allí se encuentra todo lo difícil. Estas cinco líneas generan cada subproblema complejo que existe, y un candidato que comienza presentando esa comparación en lugar de dibujar cuadros ya se ha separado de la mayoría de los competidores. Practicar preguntas relacionadas con infraestructuras de pagos reales es una forma rápida de dominar el vocabulario necesario, ya que conceptos como libros contables, idempotencia y liquidación aparecen aquí en su forma relacionada con agentes.

Problema uno: autoridad delegada

El comprador está ausente en el momento de la compra, por lo que algo debe sustituir su consentimiento.

La respuesta deficiente mantiene un método de pago registrado para que el agente lo cobre después de que el usuario diga sí. Esto falla porque un “sí” a las 10:00 para una molinilla de café de menos de 80 libras no cubre lo que el agente elija a las 10:04. Un modelo, una cadena de herramientas y quizás una descripción del producto manipulada pueden quedar dentro de esa brecha.

Las normas lo abordan de tres maneras:

• El permiso se convierte en un objeto firmado con un alcance definido, en lugar de ser simplemente la posesión de una credencial.
• Ese objeto separa la intención de la ejecución: un mandato abierto establece límites como un techo de precio y una categoría, mientras que un mandato cerrado se asocia a un carrito final específico.
• Las credenciales de pago se reemplazan por un token válido para un único comerciante y una única transacción, de modo que un token robado permite comprar un solo artículo una sola vez.

Puntos que vale la pena mencionar en voz alta: limite cada subsidio por monto, comerciante, categoría y fecha de vencimiento; exija la forma cerrada antes de que se transfiera cualquier dinero, para que el documento firmado y el artículo adquirido sean idénticos; y considere la orden como el registro de autorización en sí, no como un envoltorio que facilita el uso de la tarjeta.

Segundo problema: la vinculación estatal, o por qué los agentes meticulosos se deciden por datos obsoletos

Casi nadie plantea esto sin que se le pregunte, y se puede medir.

Un agente de compras diligente lee muchas ofertas antes de elegir. La oferta ganadora fue leída al inicio de la comparación, lo que significa que cuanto más meticuloso sea el agente, más obsoletos serán sus datos más precisos.

Una simulación adjuntó una figura a esto. El agente consulta a cada vendedor uno tras otro, dedicando de tres a ocho segundos a cada uno, luego analiza todo durante cinco a quince segundos y toma una decisión. Los precios y las existencias cambian según un proceso de Poisson, y el resultado es la probabilidad de que la oferta elegida ya haya cambiado para el momento de tomar la decisión.

Lo que destaca es el patrón. Pasar de un vendedor a veinte multiplica la probabilidad de una decisión obsoleta en aproximadamente cinco veces para cada tasa de cambio, por lo que el mismo comportamiento que desean los compradores socava las propias indicaciones del agente. Con una fijación de precios dinámica bastante agresiva, uno de cada tres comparativos cuidadosos termina con una oferta que ya ha cambiado.

Las consecuencias en el diseño son concretas:

• Las cotizaciones son objetos emitidos por el servidor, cada uno con un ID y una vida útil breve.
• La autorización final está vinculada a un hash del carrito completado, que es exactamente lo que proporciona un mandato cerrado.
• Al procesar el pago, el vendedor verifica nuevamente el precio y las existencias, y rechaza la transacción en caso de cualquier discrepancia en lugar de completarla silenciosamente.
• Si el cambio viola los límites establecidos, se vuelve a cotizar y se envía un mensaje al comprador indicando el rechazo.

Los candidatos tienden a olvidar el último punto: rechazar un pedido obsoleto es una conducta correcta, y sin un bucle de re-cotización, un error en los precios se convierte simplemente en un problema de fiabilidad.

Problema tres: los intentos repetidos y la clave de idempotencia inútil del agente

Las claves de idempotencia se mencionan en todas las respuestas, pero existe un problema oculto en la configuración habitual.

Normalmente, el cliente genera una clave y envía la misma al intentar de nuevo. Los agentes socavan esto. Si una respuesta desaparece, un agente a menudo no vuelve a enviar la solicitud idéntica; planea de nuevo, lo que genera una nueva solicitud con una nueva clave, y el servidor la trata como una intención nueva.

Ese comportamiento se modeló directamente en lugar de asumirlo, con un 5% de respuestas perdidas después de que ya se hubiera realizado el cobro y hasta tres intentos:

• Cuando el agente genera una nueva clave en cada intento, el 4.98% de los pedidos se cobran dos veces, lo que resulta en un promedio de 1.052 cobros por pedido.
• Cuando la clave se obtiene en el servidor a partir de la vinculación del carrito, las duplicaciones disminuyen al 0.00% y cada pedido se cobra exactamente una vez.

El 4.98% simulado coincide con la probabilidad exacta del 5.00%, lo cual tiene sentido porque una duplicación ocurre justo cuando la primera respuesta desaparece.

Conclusión: construya la clave de idempotencia a partir de algo que haya sido aprobado por el comprador, no de algo inventado por quien realiza la solicitud. El hash que relaciona la orden finalizada con el carrito ya cumple esa función, por lo que no se necesita trabajo adicional.

Problema cuatro: ¿quién es el comerciante registrado?

Se trata de una cuestión empresarial disfrazada de problema técnico, y es la que determina el modelo de datos.

• Con un token compartido, el vendedor sigue siendo el comerciante registrado, de modo que la plataforma de agentes evita responsabilidades relacionadas con liquidaciones, impuestos y devoluciones.
• Si en cambio la plataforma compra y revende, la vida del agente se vuelve más fácil, aunque surge un área completamente regulada.
• Debería establecerse esta suposición desde el principio, en un plazo de dos minutos, ya que los reembolsos, impuestos y disputas dependen directamente de ella.

Problema cinco: la auditabilidad como requisito

Una de las cinco familias de amenazas en el análisis AP2 se refiere exclusivamente a la rendición de cuentas, es decir, al almacenamiento de pruebas y a la posibilidad de realizar auditorías. La gente suele pasarla por alto, pero es ella quien determina si una disputa podrá resolverse seis meses después.

Por cada transacción, almacene de forma inmutable:

• Las dos versiones del mandato firmado, el abierto y el cerrado.
• El hash exacto del carrito que fue aprobado, junto con su contenido.
• El ID de la cotización, así como la fecha en que se emitió y la fecha de vencimiento.
• La versión del agente y del modelo que intervinieron, además de la delegación bajo la cual actuaron.
• Cada rechazo y su motivo, ya que los rechazos demuestran que los controles estaban funcionando.

Un camino de referencia

Una respuesta clara implica seguir un proceso completo desde el inicio hasta el final de una compra:

1. El comprador establece un objetivo con límites, y la plataforma emite un mandato abierto delimitado por monto, categoría y fecha de vencimiento.
2. El agente recopila ofertas de los vendedores candidatos, y cada vendedor responde con una cotización que incluye un ID y una fecha de vencimiento.
3. El agente elige una de ellas y solicita un carrito final, que el vendedor firma.
4. La plataforma crea un mandato cerrado vinculado al hash de ese carrito, verificándolo en relación con los límites del mandato abierto.
5. Se emite un token de pago exclusivamente para ese vendedor y por esa cantidad.
6. El vendedor verifica nuevamente el precio y las existencias, y luego procesa la transacción con una clave de idempotencia derivada del hash del carrito.
7. Todos los registros de los pasos uno a seis se guardan en el almacén de auditoría antes de enviar cualquier respuesta.
8. Si hay una discrepancia en el paso seis, se vuelve al paso dos, o al comprador si el cambio supera sus límites.

Cada uno de los ocho pasos existe porque, de lo contrario, algún fallo específico quedaría sin protección, y lo que realmente evalúa el entrevistador es la relación entre cada paso y su correspondiente fallo.

Evaluación de una respuesta de práctica

Se otorgan puntos a las respuestas que:

• explican el modelo de delegación en dos minutos como máximo y se adhieren a él;
• separan la concesión abierta del compromiso cerrado y explican por qué ambos son necesarios;
• mencionan el problema de obsolescencia por iniciativa propia, idealmente con una cifra aproximada;
• construyen la idempotencia a partir del estado aprobado, y no de lo que proporciona quien llama;
• tratan el registro de auditoría como un requisito y no simplemente como un registro.

Se pierden puntos con las respuestas que:

• imaginan al agente como una persona rápida, cuando la mayor parte de las dificultades proviene de sus diferencias con una persona real;
• le otorgan al agente cualquier tipo de credencial reutilizable;
• suponer que un intento de reintentar es simplemente el mismo pedido enviado nuevamente;
• diseñar un rechazo sin paso siguiente;
• dejar para el final las cuestiones relacionadas con la responsabilidad y el comerciante registrado, aunque son ellas las que determinan el modelo de datos.

Por qué vale la pena prepararse para esta pregunta

El polaco dejó de ser una señal útil para la contratación en cuanto se hizo disponible una respuesta impecable a cada pregunta clásica de forma gratuita. El proceso de pago basado en agentes es un caso actual en el que falta ese atajo. Los protocolos tienen solo unos meses de antigüedad, la investigación sobre amenazas es aún más reciente, y los equilibrios entre opciones no se han establecido aún.

Eso hace que la instrucción recompense aquellos bancos de preguntas basados en estándares de habilidad que ya no se utilizan: el razonamiento a partir de restricciones realmente comprendidas. Aprenderlo bien también prepara para cualquier pregunta que lo sustituya, ya que el paso fundamental no cambia. Pregúntese qué cambiará una vez que lo que esté al otro lado de la API ya no sea un ser humano.