El problema, dicho en términos de tienda
Todo tu cobro actual supone una persona: alguien abre el checkout, escribe una tarjeta, recibe un código al teléfono, aprieta un botón. Cuando el que compra es un programa, ese camino se cae en el primer paso. No hay teléfono, no hay tarjeta a nombre del agente, y darle a un programa la tarjeta de su dueño es una idea que nadie quiere defender delante de un banco.
x402 responde a eso con algo mucho más viejo que la inteligencia artificial: el código
de estado HTTP 402 Payment Required, que quedó reservado en
la especificación de la web y nunca se usó. La idea es literal. Tu servidor responde
"esto cuesta", y el cliente que quiera continuar paga y vuelve a pedir.
Cómo se ve, sin tecnicismos
- El agente pide tu carrito cotizado.
-
Tu tienda responde
402con las condiciones: cuánto, en qué moneda, a qué dirección. - El agente firma el pago con la llave de su dueño, en el computador de su dueño, y repite la solicitud llevando esa firma.
- Tu tienda comprueba y liquida el pago, y recién entonces crea la orden, con el comprobante de la transacción adjunto.
No hay cuenta que abrir, no hay suscripción entre las partes, no hay acuerdo previo. Es tan anónimo o tan identificado como tú quieras: puedes exigir que el agente firme sus solicitudes y traiga una atestación de su dueño, o puedes vender a quien llegue, como hace tu tienda hoy.
Las tres cosas que le importan a un comercio
Primero, el dinero es tuyo desde el segundo cero. El pago va del comprador a tu wallet dentro de una sola transacción. No pasa por una cuenta intermedia, ni nuestra ni de nadie. No hay saldo que retirar ni plazo de liberación, porque no hubo custodia.
Segundo, la liquidación es la condición, no la promesa. En las tarjetas, la orden se crea con una autorización y el dinero llega después, con la posibilidad de un contracargo semanas más tarde. Aquí el orden es el inverso: primero el pago queda liquidado en la red, después existe la orden. Es una regla dura en nuestro código, no una configuración.
Tercero, no reemplaza nada. Tu checkout, tu pasarela de tarjetas, tus transferencias y tus clientes humanos quedan intactos. Las órdenes de agentes llegan a la misma lista de órdenes de tu tienda, ya pagadas y marcadas para que las distingas.
Qué es USDC, en una línea
Es una moneda estable en dólares: un USDC está pensado para valer un dólar estadounidense. Si tu catálogo está en dólares, el precio en USDC es uno a uno y tú lo confirmas. Si está en otra moneda, el precio lo pones tú, porque solo tú sabes a qué tipo de cambio quieres vender. Ningún precio se publica a un agente sin que un humano lo confirme.
Lo que conviene preguntar antes
- Quién paga las comisiones de red. En este esquema las patrocina el facilitador, es decir quien corre ese servicio. En una transacción real de las nuestras, esa comisión fue de 0,0023 XLM. El punto no es el monto: es saber de quién es la cuenta.
- Qué pasa si el pago no calza. En nuestra implementación, un pago que no coincide con lo cotizado deja la orden en revisión y no se despacha nada. El silencio nunca aprueba.
- Impuestos y facturación. Es una orden pagada normal en tu sistema, con su monto y su comprobante de transacción, y tu proceso tributario habitual aplica igual. Qué tratamiento le corresponde a un pago en moneda estable es una pregunta para tu contador, no para nosotros.
Por qué ahora
Porque ya hay agentes comprando. Que lo hagan bien o mal depende de que existan formatos que los comercios puedan adoptar sin entregar el control: sin ceder la custodia, sin pagar un porcentaje de cada venta y sin entrar a un marketplace ajeno. x402 es la pieza del pago. El catálogo, las reglas de venta, la aprobación humana y el comprobante son las otras, y de esas hablamos en el resto del blog.