ingenieria
Checkout sin página: cómo las conversaciones AI reemplazan el drawer del carrito
Cuando el asistente AI del cliente maneja la compra, tu página /checkout nunca carga. Qué pasa de verdad en el momento del pago.
El checkout clásico es una secuencia de páginas. Carrito, dirección, envío, pago, confirmación. Cada transición es una oportunidad para abandonar. Cada campo es fricción.
La forma nueva
En un checkout agéntico, ninguna de esas páginas se renderiza. El asistente AI ya recolectó la info en la conversación — nombre, dirección por defecto de pedidos previos, método de pago preferido — y manda una sola tool-call:
// tool call del LLM
{
"tool": "create_checkout_session",
"params": {
"items": [{ "sku": "TSHIRT-BLK-M", "qty": 1 }],
"shipping_address_id": "addr_default",
"payment_method_id": "pm_default",
"currency": "EUR"
}
}
Tu storefront devuelve un payment_link (pago delegado — el cliente confirma en Stripe / Apple Pay / wallet) o un committed_order (camino sin contraseña one-tap, donde el AI ya autorizó el pago para compras rutinarias).
Lo que el comerciante debe exponer
Para que esto funcione, el storefront ofrece:
- Un servidor MCP / ACP con tools de lectura (
search_products,get_product_details) y escritura (add_to_cart,create_checkout_session). - Escrituras idempotentes. El modelo reintenta tool-calls fallidas. Si
create_checkout_sessioncorre dos veces, creas un pedido, no dos. - Identidad estable del cliente entre canales. Un cliente que compró en tu web debe ser reconocible para tus tool-calls — mismo
customer_id, misma agenda, mismos métodos de pago.
A dónde se mudó la fricción
La fricción no desapareció; se mudó a la autenticación. La primera vez que el AI del cliente compra en tu tienda, alguien debe autorizar pago + envío. Después la fricción es cero; cada compra siguiente es una tool-call.
La página de checkout no murió. Solo se volvió el camino de fallback para el cliente nuevo o sin asistente AI. El camino aspiracional es "ninguna página carga".