Crear una tienda online con IA: pagos y seguridad

Para crear una tienda online con IA, haces que un agente de código escriba paso a paso el catálogo de productos, el carrito y el pago; una configuración típica es Next.js, una base de datos y un proveedor de pagos como Stripe. El agente escribe código rápido, pero tú tienes que poner las reglas: los precios se calculan en el servidor, los pagos se confirman por webhook y los datos de tarjeta nunca se guardan. Decidir antes si una plataforma alojada como Shopify ya cubre tus necesidades forma parte del trabajo.

Esta guía empieza por esa decisión y después recorre la construcción de una tienda a medida con un agente, en orden: modelo de datos, carrito, pago, webhooks, stock, correos, páginas legales y despliegue. Cada paso tiene prompts que puedes copiar. Al final hay una lista de los errores que más comete la IA en ecommerce y una lista de comprobación de seguridad.

Primera decisión: ¿plataforma alojada o a medida?

La respuesta honesta suele ser «plataforma alojada». Shopify, WooCommerce y plataformas similares se encargan por ti de los pagos, el inventario, las integraciones de envío, los impuestos y las actualizaciones de seguridad.

Construir a medida tiene sentido cuando tu flujo de ventas no está soportado (por ejemplo, suscripciones más un configurador de productos hechos por encargo), cuando añades una tienda dentro de una app existente o cuando quieres aprender y mantener el control total. Ese es el camino que cubre esta guía. Si prefieres empezar con un sitio de marketing sencillo, lee antes cómo crear un sitio web con IA.

1. Stack y configuración

Para un proyecto de vibe coding sugiero un stack que los agentes conocen bien y que está muy documentado:

• Next.js (App Router): páginas, código de servidor y rutas de API en un solo proyecto.
• PostgreSQL: un servicio gestionado (Supabase, Neon y similares) o Docker en local.
• Un ORM (Prisma o Drizzle): el esquema y las migraciones viven en archivos, de modo que tú y el agente leéis de la misma fuente.
• Un proveedor de pagos: Stripe es la opción habitual; en algunos países los proveedores locales son el estándar (en Turquía, por ejemplo, iyzico o PayTR). Lo que tienen en común es que la tarjeta se introduce en el formulario del proveedor y el resultado llega a tu servidor mediante una notificación.
• Un servicio de correo transaccional: para confirmaciones de pedido y avisos de envío.

npx create-next-app@latest store
cd store
git status   # create-next-app usually initialises git; if not: git init
claude

2. El primer prompt: plan antes que código

Decirle a un agente «constrúyeme una tienda» te da todo de una pasada, con las partes críticas despachadas por encima. Pide primero un plan:

We're building a small ecommerce site with Next.js (App Router), PostgreSQL and Prisma.
Payments will use Stripe Checkout (card data must never reach our server).

Don't write code yet. First produce a plan covering:
1. Data model: product, product variant (size/colour), order, order item, stock.
2. Pages: product list, product detail, cart, checkout return pages, a simple admin.
3. Payment flow: from cart to creating a checkout session to marking the order paid via webhook.
4. Which operations must happen on the server, and why.

Rules:
- Store prices as integers in the smallest currency unit (cents), never floats.
- Never trust a price, total or discount amount sent from the client.
- Secrets live only in .env; no secret ever reaches client code.
Write the plan and wait for my approval.

Lee el plan, corrige lo que no te guste y luego impleméntalo pieza a pieza: primero el modelo de datos, luego el catálogo, después el carrito y los pagos al final. Haz un commit tras cada pieza.

3. La base de datos de productos

Algunas cosas en las que me fijo en el modelo de datos:

• El dinero es un entero. 14,90 $ se guarda como 1490. Stripe y la mayoría de los proveedores esperan los importes en la unidad monetaria mínima de todos modos.
• Las líneas del pedido copian el precio. El pedido conserva el nombre y el precio del producto en el momento de la compra, de modo que un cambio de precio mañana no reescribe los pedidos pasados.
• El stock vive en la variante. «Camiseta azul, talla M» tiene su propia fila de stock.
• El estado del pedido es una lista explícita: pending, paid, shipped, cancelled, refunded y así sucesivamente.

Cuando el agente escriba una migración, lee el archivo. Si elimina una tabla o una columna que ya contiene datos, detente y pregunta.

4. El carrito

El carrito, en el navegador (o en la base de datos para usuarios con sesión iniciada), debería guardar solo IDs de producto/variante y cantidades. Los precios y los totales se muestran en el carrito, pero siempre se leen del servidor.

Implement the cart. Store only a list of {variantId, quantity} in localStorage.
The cart page fetches current prices and the total from the server.
Out-of-stock or deleted products show in the cart with a warning.
Limit quantity to 1–10 and enforce that on the server too.

5. Pago: los precios siempre se calculan en el servidor

Regla número uno del ecommerce: nunca te fíes de un precio que venga del cliente. Cualquier valor del navegador puede cambiarse; cualquiera puede abrir las herramientas de desarrollo y poner el total en 1 $. El flujo correcto:

1. El cliente envía al servidor solo la lista de variantId y quantity.
2. El servidor lee de la base de datos el precio y el stock de cada artículo y calcula él mismo el total.
3. El servidor crea un pedido con estado pending.
4. El servidor crea una sesión de pago con el proveedor (una Checkout Session de Stripe o el formulario de pago del proveedor local) y le adjunta el ID del pedido.
5. El cliente es redirigido a la página o iframe del proveedor y allí introduce su tarjeta.

Una idea resumida del código de servidor:

// app/api/checkout/route.ts (sketch)
const items = await db.variant.findMany({ where: { id: { in: cart.map(c => c.variantId) } } })
const lineItems = cart.map(c => {
  const v = items.find(i => i.id === c.variantId)
  if (!v || v.stock < c.quantity) throw new Error('Out of stock')
  return { price: v.priceCents, quantity: c.quantity }   // price from the DB, not the client
})

Los códigos de descuento siguen la misma regla: el código viene del cliente, pero si es válido y cuánto descuenta lo decide el servidor.

6. Webhooks: ¿pagado o no?

Que un cliente llegue a tu página de «pago correcto» no prueba que el pago se haya completado; esa página puede abrirse a mano y el cliente puede haber cerrado la pestaña. La fuente de verdad es la notificación que tu proveedor envía a tu servidor (un webhook en Stripe, a menudo llamado callback en otros proveedores).

Explícaselo así al agente para el endpoint del webhook:

Write the Stripe webhook endpoint (/api/webhooks/stripe):
- Verify the signature with STRIPE_WEBHOOK_SECRET; reject unsigned or invalid requests.
- Use the raw request body for signature verification.
- On checkout.session.completed, read the order ID from metadata, and inside one
  database transaction mark the order "paid" and decrement stock.
- Make it idempotent: if the same event arrives twice, the second time changes nothing.
- Compare the amount paid with the order total; if they differ, flag the order and log it.

Para probar en local, la CLI de Stripe puede reenviar eventos a tu máquina:

stripe listen --forward-to localhost:3000/api/webhooks/stripe

En el modo de pruebas de Stripe, tarjetas de prueba como 4242 4242 4242 4242 te permiten ejecutar todo el flujo sin dinero real. Otros proveedores también tienen sandboxes; haz que el agente lea su documentación sobre cómo verificar la firma o el hash de la notificación.

7. Stock

El stock es donde dos personas pueden comprar el último artículo en el mismo instante. Los agentes suelen escribir «leer y luego escribir», lo que deja una condición de carrera en medio. Haz en cambio la comprobación y el descuento en una sola consulta atómica:

UPDATE variants SET stock = stock - 2
WHERE id = 'var_123' AND stock >= 2;
-- if zero rows were affected, there wasn't enough stock

Descontar el stock cuando el pago se confirma (en el webhook) es la opción simple; para artículos muy limitados también podrías mantener una reserva corta al abrir la sesión de pago. Dile explícitamente al agente cuál quieres.

8. Correos

Necesitas al menos dos: una confirmación de pedido y un aviso de envío. Envía la confirmación desde el webhook, no desde la página de éxito, para que solo salga en los pedidos realmente pagados. La clave de API del servicio de correo se queda en el servidor. Si omites los registros SPF/DKIM que tu proveedor de correo pide en tu dominio de envío, tus correos pueden acabar en spam.

9. Páginas legales

No es código, pero es parte de la tienda. Lo que se exige depende de dónde estéis tú y tus clientes, pero la mayoría de las tiendas necesitan:

• Una política de privacidad (que explique qué recoges y por qué, con el RGPD o los equivalentes locales donde apliquen)
• Un aviso de cookies donde sea obligatorio
• Condiciones de venta
• Una política de reembolsos y devoluciones, incluido el plazo legal de desistimiento
• Datos del vendedor: razón social, dirección e información de contacto

Si vendes en Turquía, cuenta con un aviso de privacidad de la KVKK, un contrato de venta a distancia y un formulario de información previa que el cliente aprueba antes de pedir. Puedes hacer que el agente añada las casillas de consentimiento en el pago y guarde el consentimiento junto con el pedido. La IA puede redactar estos textos, pero haz que un abogado o un contable los revise antes de salir en vivo, y consúltales sobre facturación y obligaciones fiscales.

10. Despliegue

Poner la app de Next.js en Vercel y la base de datos en un servicio PostgreSQL gestionado es la ruta más corta. Antes del lanzamiento:

• Introduce las variables de entorno (URL de la base de datos, claves de pagos y de correo, secreto del webhook) en el panel de tu alojamiento.
• Registra la URL del webhook en producción en el panel de tu proveedor de pagos; no mezcles las claves de prueba y las de producción.
• Ejecuta las migraciones contra producción de forma deliberada y haz antes una copia de seguridad.
• Haz un pequeño pedido real en producción, reembólsalo y comprueba con tus propios ojos todo el flujo (correo, stock, estado del pedido).

Lo que la IA hace mal en ecommerce

• Calcular el total en el cliente y enviarlo al servidor. El más peligroso. Busca en el código un price o total que venga del cliente y elimínalo.
• Marcar el pedido como pagado en la página de éxito. Sin un webhook, el estado del pedido no debería cambiar.
• Saltarse la verificación de la firma del webhook, o interpretar el cuerpo como JSON antes de verificar y luego desactivar la verificación porque «no funciona».
• Floats para el dinero. El problema de 0.1 + 0.2 acaba en las facturas.
• Sin idempotencia. El mismo webhook llega dos veces, el stock baja dos veces y salen dos correos.
• Un panel de administración sin proteger. Construye una página /admin pero olvida las comprobaciones de autorización en las rutas de API. Asegúrate de que cada API de administración compruebe el rol en el servidor.
• Salir en vivo con claves de prueba, o al revés, usar claves de producción durante el desarrollo.

Seguridad

• Nunca guardes, registres ni recojas datos de tarjeta con tu propio formulario. Usa la página o el formulario de pago alojados por el proveedor; así tu alcance de PCI DSS es lo más pequeño posible.
• Secretos en .env, con .env en .gitignore. Nunca pongas una clave secreta (como sk_...) en código de cliente ni en variables de entorno públicas (en Next.js, las que llevan el prefijo NEXT_PUBLIC_).
• Nunca pegues claves de API en el chat. Dile al agente el nombre de la variable, no el valor.
• Lee lo que ejecuta el agente. En una terminal conectada a una base de datos de producción, no apruebes automáticamente migraciones, DROP ni UPDATE masivos.
• Lee cada diff, sobre todo el código de pagos y autenticación. Aquí es imprescindible un segundo par de ojos; revisión de código con IA explica cómo montarlo.
• Recoge los mínimos datos personales posibles, y guarda lo que recojas tras un acceso limitado.

Hacerlo con AgentVera

Mantener varios agentes separados ayuda en un proyecto de tienda, y yo lo hago con AgentVera:

• Backend e interfaz en worktrees separados. Un agente Claude Code trabaja en los pagos, los webhooks y el modelo de datos mientras un agente Codex construye las páginas de producto y la interfaz del carrito. Cada uno está en su propio git worktree, todos en un solo espacio de trabajo.
• Gestor de bases de datos. Mira las tablas, los pedidos y el stock que creó el agente en el gestor de bases de datos sin abrir otra herramienta; admite PostgreSQL, MySQL y SQLite.
• DB Guard. Analiza las migraciones que escribió el agente al final de un turno; DB Guard saca a la luz de entrada riesgos como un DROP o un UPDATE sin WHERE.
• Revisión de código y vistas previas. Cuando termina un turno, la revisión de código hace que un segundo modelo lo revise; los entornos de vista previa ejecutan el servidor de desarrollo de cada worktree en su propia dirección. Aun así, lees tú mismo el diff de pagos antes de fusionar.

Nada de esto hace que las cosas salgan bien por ti; hace más fácil ver lo que cambió.

Lista de comprobación rápida

• Alojada o a medida decidido a propósito
• Los precios son enteros en la unidad mínima; las líneas del pedido copian el precio
• El carrito guarda solo IDs y cantidades; el total se calcula en el servidor
• Los pedidos pasan a «paid» solo mediante un webhook con firma verificada; el webhook es idempotente
• El stock se descuenta con una consulta atómica
• El correo de confirmación se envía desde el webhook; SPF/DKIM configurados
• Privacidad, condiciones, política de reembolsos y datos del vendedor publicados y revisados
• Ningún dato de tarjeta en ningún sitio; secretos solo en el servidor
• Un pedido real hecho y reembolsado en producción

Para terminar

Puedes crear una tienda online con IA, y un agente escribirá rápido la mayor parte. Pero lo que hace fiable una tienda no es algo que el agente haga por su cuenta: precios calculados en el servidor, pagos confirmados por webhook, stock descontado de forma atómica, ningún dato de tarjeta guardado y las páginas legales adecuadas. Pon esas reglas en tu primer prompt, prueba cada paso en el modo de pruebas y lee siempre el código de pagos antes de fusionarlo.