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

URL: https://agentvera.dev/ru/blog/build-ecommerce-store-with-ai/ · Опубликовано: 2026-10-11

Интернет-магазин с ИИ: Shopify или своя разработка, Next.js и Stripe, корзина, цены на сервере, вебхуки, остатки, письма, юридические страницы и правила PCI.

**Коротко:**

- Готовая платформа вроде Shopify часто безопаснее и быстрее; своя разработка оправданна, если вам нужны сценарий, дизайн или структура затрат, которых платформа не даёт.
- В собственном магазине корзина хранит только ID товаров и количества, цены это целые числа в минимальной единице валюты, а итог всегда считается на сервере.
- Помечайте заказ оплаченным только через идемпотентный вебхук с проверенной подписью, уменьшайте остатки одним атомарным запросом и никогда не храните и не собирайте данные карт сами.

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

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

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

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

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

Своя разработка оправданна, когда ваш сценарий продаж не поддерживается (скажем, подписки плюс конфигуратор товаров под заказ), когда вы добавляете магазин внутрь существующего приложения или когда хотите учиться и сохранить полный контроль. Именно этот путь разбирает руководство. Если лучше начать с обычного маркетингового сайта, сначала прочитайте [как создать сайт с ИИ](/ru/blog/build-website-with-ai/).

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

Для проекта в стиле [vibe coding](/ru/glossary/vibe-coding/) я советую стек, который агенты хорошо знают и который подробно документирован:

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

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

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

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

```text
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 товаров или вариантов и количества**. Цены и итоги показываются в корзине, но всегда читаются с сервера.

```text
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 $. Правильный порядок:

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

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

```ts
// 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).

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

```text
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 может пересылать события на вашу машину:

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

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

## 7. Остатки

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

```sql
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, особенно код платежей и авторизации.** Здесь жизненно важен второй взгляд; о том, как его организовать, рассказывает статья [ревью кода с ИИ](/ru/blog/ai-code-review/).
- **Собирайте как можно меньше персональных данных** и держите собранное под ограниченным доступом.

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

В проекте магазина помогает разделение нескольких агентов, и я делаю это в [AgentVera](/ru/download/):

- **Бэкенд и интерфейс в разных worktree.** Агент Claude Code занимается платежами, вебхуками и моделью данных, пока агент Codex строит страницы товаров и интерфейс корзины. Каждый работает в своём [git worktree](/ru/glossary/git-worktree/), и всё в одном [рабочем пространстве](/ru/features/workspace/).
- **Менеджер баз данных.** Смотрите таблицы, заказы и остатки, созданные агентом, в [менеджере баз данных](/ru/features/database-manager/), не открывая другой инструмент; он поддерживает PostgreSQL, MySQL и SQLite.
- **DB Guard.** Он проверяет миграции, которые агент написал, в конце хода; [DB Guard](/ru/features/db-guard/) заранее показывает риски вроде `DROP` или `UPDATE` без `WHERE`.
- **Ревью кода и предпросмотр.** Когда ход заканчивается, [ревью кода](/ru/features/code-review/) отдаёт его на взгляд второй модели; [окружения предпросмотра](/ru/features/preview-environments/) запускают сервер разработки каждого worktree на отдельном адресе. Diff платежей перед слиянием вы всё равно читаете сами.

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

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

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

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

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

## Частые вопросы

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

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

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

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

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

---

**Об AgentVera.** AgentVera — настольное приложение для macOS, Windows и Linux от Solviera Teknoloji. Оно запускает 18 ИИ-агентов для программирования (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) рядом, по проектам, в настоящих терминалах с собственными установками CLI и входами пользователя. В бесплатном тарифе количество агентов не ограничено. Скачать: https://agentvera.dev/ru/download/ · Цены: https://agentvera.dev/ru/pricing/