Можно ли создать интернет-магазин с нуля с помощью ИИ?

Да. Кодинг-агент может написать страницы товаров, корзину, интеграцию платежей и админ-экраны. Но платежи, остатки и юридические части вы должны понимать и тестировать сами: ошибки, которые лишь выглядят как работающие, стоят настоящих денег.

Что выбрать: Shopify или собственный магазин?

Если нужно быстро начать продавать несколько товаров, готовая платформа обычно безопаснее и требует гораздо меньше работы. Своя разработка оправданна, если вам нужны сценарий, дизайн или структура затрат, которых платформа не даёт.

Можно ли хранить данные карт в собственной базе?

Не стоит. Данные карты должны вводиться в форму или на страницу вашего платёжного провайдера и никогда не попадать на ваш сервер; так большая часть требований PCI DSS остаётся на стороне провайдера.

Как узнать, что платёж действительно прошёл?

Не доверяйте тому, что клиент попал на вашу страницу «успех»; доверяйте подписанному вебхуку, который платёжный провайдер присылает на ваш сервер. Помечайте заказ оплаченным только после проверки подписи этого вебхука.

Какие юридические страницы нужны интернет-магазину?

Как минимум политика конфиденциальности, условия продажи, политика возвратов и возмещений, обычно уведомление о cookie и понятные контактные данные продавца. Требования зависят от страны: можно попросить ИИ набросать тексты, но пусть их проверит квалифицированный специалист.

Интернет-магазин с ИИ: платежи и безопасность

Чтобы создать интернет-магазин с ИИ, вы шаг за шагом поручаете кодинг-агенту написать каталог товаров, корзину и оформление заказа; типичный набор — Next.js, база данных и платёжный провайдер вроде Stripe. Агент пишет код быстро, но правила задаёте вы: цены считаются на сервере, платежи подтверждаются вебхуком, данные карт не хранятся. Часть работы — сначала решить, не покрывает ли ваши нужды готовая платформа вроде Shopify.

Руководство начинается с этого решения, а затем по порядку проходит сборку собственного магазина с агентом: модель данных, корзина, оформление заказа, вебхуки, остатки, письма, юридические страницы и развёртывание. К каждому шагу есть промпты, которые можно скопировать. В конце список самых частых ошибок ИИ в e-commerce и чек-лист безопасности.

Первое решение: готовая платформа или своя разработка?

Честный ответ часто звучит «готовая платформа». Shopify, WooCommerce и похожие платформы берут на себя платежи, склад, интеграции доставки, налоги и обновления безопасности.

	Готовая платформа	Своя разработка (с кодинг-агентом)
Время до первой продажи	Дни	Недели
Платежи, безопасность, обновления	Задача платформы	Ваша задача
Свобода дизайна и сценария	В пределах тем и приложений	Неограниченная
Структура затрат	Ежемесячная плата, иногда комиссии с транзакций	Хостинг + комиссии платёжного провайдера + ваше время
Переносимость	Привязка к платформе	Код принадлежит вам

Своя разработка оправданна, когда ваш сценарий продаж не поддерживается (скажем, подписки плюс конфигуратор товаров под заказ), когда вы добавляете магазин внутрь существующего приложения или когда хотите учиться и сохранить полный контроль. Именно этот путь разбирает руководство. Если лучше начать с обычного маркетингового сайта, сначала прочитайте как создать сайт с ИИ.

1. Стек и подготовка

Для проекта в стиле vibe coding я советую стек, который агенты хорошо знают и который подробно документирован:

Next.js (App Router): страницы, серверный код и маршруты API в одном проекте.
PostgreSQL: управляемый сервис (Supabase, Neon и подобные) или Docker локально.
ORM (Prisma или Drizzle): схема и миграции лежат в файлах, так что вы и агент читаете один источник.
Платёжный провайдер: обычный выбор Stripe; в некоторых странах стандартом остаются местные провайдеры (например, в Турции iyzico или PayTR). У всех общее: карта вводится в форме провайдера, а результат приходит на ваш сервер уведомлением.
Сервис транзакционной почты: для подтверждений заказа и уведомлений об отправке.

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

2. Первый промпт: сначала план, потом код

Если сказать агенту «построй мне магазин», вы получите всё за один проход, а критические части будут сделаны небрежно. Сначала попросите план:

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.

Прочитайте план, поправьте то, что не нравится, а затем реализуйте по частям: модель данных, потом каталог, потом корзина, платежи в последнюю очередь. После каждой части делайте коммит.

3. База данных товаров

На что я обращаю внимание в модели данных:

Деньги это целое число. 14,90 $ хранится как 1490. Stripe и большинство провайдеров в любом случае ждут суммы в минимальной единице валюты.
Позиции заказа копируют цену. Заказ хранит название и цену товара на момент покупки, так что завтрашнее изменение цены не перепишет прошлые заказы.
Остаток хранится у варианта. «Синяя футболка, размер M» это отдельная строка остатков.
Статус заказа это явный список: pending, paid, shipped, cancelled, refunded и так далее.

Когда агент пишет миграцию, прочитайте файл. Если она удаляет таблицу или столбец, где уже есть данные, остановитесь и спросите.

4. Корзина

Корзина в браузере (или в базе для вошедших пользователей) должна хранить только ID товаров или вариантов и количества. Цены и итоги показываются в корзине, но всегда читаются с сервера.

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. Оформление заказа: цены всегда считаются на сервере

Правило номер один в e-commerce: никогда не доверяйте цене от клиента. Любое значение в браузере можно изменить; любой может открыть инструменты разработчика и поставить итог в 1 $. Правильный порядок:

Клиент отправляет серверу только список variantId и quantity.
Сервер читает цену и остаток каждой позиции из базы и сам считает итог.
Сервер создаёт заказ со статусом pending.
Сервер создаёт у провайдера платёжную сессию (Stripe Checkout Session или платёжную форму местного провайдера) и прикрепляет к ней ID заказа.
Клиента перенаправляют на страницу или iframe провайдера, и карту он вводит там.

Сокращённая идея серверного кода:

// 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
})

Промокоды подчиняются тому же правилу: код приходит от клиента, но действителен ли он и сколько скидывает, решает сервер.

6. Вебхуки: оплачено или нет?

То, что клиент попал на вашу страницу «платёж прошёл», не доказывает, что платёж состоялся: страницу можно открыть вручную, а клиент мог закрыть вкладку. Источник истины это уведомление, которое провайдер присылает на ваш сервер (в Stripe это вебхук, у других провайдеров его часто называют callback).

Объясните это агенту для эндпоинта вебхука:

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.

Чтобы тестировать локально, Stripe CLI может пересылать события на вашу машину:

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

В тестовом режиме Stripe тестовые карты вроде 4242 4242 4242 4242 позволяют пройти весь процесс без настоящих денег. У других провайдеров тоже есть песочницы; пусть агент прочитает их документацию о проверке подписи или хеша уведомления.

7. Остатки

Остатки это то место, где двое могут купить последний экземпляр в один момент. Агенты обычно пишут «прочитать, потом записать», и между этими шагами остаётся состояние гонки. Делайте проверку и уменьшение одним атомарным запросом:

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

Уменьшать остаток после подтверждения платежа (в вебхуке) — простой вариант; для очень ограниченных товаров можно ещё и держать короткий резерв при открытии платёжной сессии. Скажите агенту явно, какой вариант вам нужен.

8. Письма

Нужны минимум два: подтверждение заказа и уведомление об отправке. Отправляйте подтверждение из вебхука, а не со страницы успеха, чтобы оно уходило только по действительно оплаченным заказам. API-ключ почтового сервиса остаётся на сервере. Если вы пропустите записи SPF/DKIM, которые почтовый провайдер просит добавить для вашего домена отправителя, письма могут попадать в спам.

9. Юридические страницы

Это не код, но часть магазина. Что именно требуется, зависит от того, где находитесь вы и ваши клиенты, но большинству магазинов нужны:

Политика конфиденциальности (что вы собираете и зачем, плюс GDPR или местные аналоги, где они применяются)
Уведомление о cookie, где оно требуется
Условия продажи
Политика возвратов и возмещений, включая установленный законом срок отказа от покупки
Данные продавца: юридическое название, адрес и контактная информация

Если вы продаёте в Турции, ожидайте уведомление о конфиденциальности по KVKK, договор дистанционной продажи и форму предварительной информации, которую клиент подтверждает перед заказом. Агент может добавить флажки согласия при оформлении заказа и сохранять согласие вместе с заказом. ИИ может набросать эти тексты, но перед запуском их должен проверить юрист или бухгалтер; у них же спросите об обязанностях по счетам и налогам.

10. Развёртывание

Самый короткий путь: приложение Next.js на Vercel и база на управляемом PostgreSQL. Перед запуском:

Введите переменные окружения (URL базы, ключи платежей и почты, секрет вебхука) в панели хостинга.
Зарегистрируйте боевой URL вебхука в панели платёжного провайдера; не путайте тестовые и боевые ключи.
Запускайте миграции на проде осознанно и сначала сделайте резервную копию.
Сделайте небольшой настоящий заказ на проде, верните деньги и проверьте весь процесс (письмо, остаток, статус заказа) своими глазами.

В чём ИИ ошибается в e-commerce

Считает итог на клиенте и отправляет на сервер. Самое опасное. Найдите в коде price или total, приходящие от клиента, и уберите их.
Помечает заказ оплаченным на странице успеха. Без вебхука статус заказа меняться не должен.
Пропускает проверку подписи вебхука или разбирает тело как JSON до проверки, а потом отключает проверку, потому что «не работает».
Числа с плавающей точкой для денег. Проблема 0.1 + 0.2 попадает в счета.
Нет идемпотентности. Один и тот же вебхук приходит дважды, остаток падает дважды, уходят два письма.
Незащищённая админка. Он строит страницу /admin, но забывает проверки прав на маршрутах API. Убедитесь, что каждый админский API проверяет роль на сервере.
Запуск с тестовыми ключами или наоборот, боевые ключи во время разработки.

Безопасность

Никогда не храните, не логируйте и не собирайте данные карт собственной формой. Используйте размещённую платёжную страницу или форму провайдера; так область действия PCI DSS остаётся минимальной.
Секреты в .env, а .env в .gitignore. Никогда не кладите секретный ключ (вроде sk_...) в клиентский код или в публичные переменные окружения (в Next.js это переменные с префиксом NEXT_PUBLIC_).
Никогда не вставляйте API-ключи в чат. Называйте агенту имя переменной, а не значение.
Читайте, что запускает агент. В терминале, подключённом к боевой базе, не одобряйте автоматически миграции, DROP и массовые UPDATE.
Читайте каждый diff, особенно код платежей и авторизации. Здесь жизненно важен второй взгляд; о том, как его организовать, рассказывает статья ревью кода с ИИ.
Собирайте как можно меньше персональных данных и держите собранное под ограниченным доступом.

Как это делается в AgentVera

В проекте магазина помогает разделение нескольких агентов, и я делаю это в AgentVera:

Бэкенд и интерфейс в разных worktree. Агент Claude Code занимается платежами, вебхуками и моделью данных, пока агент Codex строит страницы товаров и интерфейс корзины. Каждый работает в своём git worktree, и всё в одном рабочем пространстве.
Менеджер баз данных. Смотрите таблицы, заказы и остатки, созданные агентом, в менеджере баз данных, не открывая другой инструмент; он поддерживает PostgreSQL, MySQL и SQLite.
DB Guard. Он проверяет миграции, которые агент написал, в конце хода; DB Guard заранее показывает риски вроде DROP или UPDATE без WHERE.
Ревью кода и предпросмотр. Когда ход заканчивается, ревью кода отдаёт его на взгляд второй модели; окружения предпросмотра запускают сервер разработки каждого worktree на отдельном адресе. Diff платежей перед слиянием вы всё равно читаете сами.

Ничто из этого не делает работу правильной за вас; оно лишь облегчает заметить, что изменилось.

Краткий чек-лист

Выбор между готовой платформой и своей разработкой сделан осознанно
Цены это целые числа в минимальной единице; позиции заказа копируют цену
Корзина хранит только ID и количества; итог считается на сервере
Заказ становится «оплаченным» только через вебхук с проверенной подписью; вебхук идемпотентен
Остаток уменьшается атомарным запросом
Письмо с подтверждением отправляется из вебхука; SPF/DKIM настроены
Политика конфиденциальности, условия, политика возвратов и данные продавца опубликованы и проверены
Данных карт нигде нет; секреты только на сервере
Настоящий заказ на проде сделан и возвращён

Подводим итоги

Интернет-магазин с ИИ создать можно, и агент быстро напишет большую часть кода. Но доверие к магазину рождается не из того, что агент делает сам: цены считаются на сервере, платежи подтверждаются вебхуком, остатки уменьшаются атомарно, данные карт не хранятся, а нужные юридические страницы на месте. Заложите эти правила в первый промпт, проверяйте каждый шаг в тестовом режиме и всегда читайте код платежей перед слиянием.