Supabase и Stripe за вечер с Claude Code — и три вещи, которые агент сделает не так

Коротко (TL;DR)

Добавить приложению постоянное хранилище (Supabase) и приём платежей (Stripe) с помощью Claude Code реально за один вечер. Но безопасность здесь держится не на коде, который агент напишет, а на трёх настройках, которые он по умолчанию сделает неправильно, если его не проверить. Эта статья — не «сгенерируй и задеплой», а рабочий маршрут связки supabase stripe интеграция с разбором, что доверить агенту, а что закрыть руками.

Что важно понять сразу:

• Supabase — это управляемый Postgres с готовыми авторизацией, файловым хранилищем и авто-API. Stripe — приём карт, подписки и вся бухгалтерия платежей. Claude Code выступает не «волшебником», а исполнителем, который пишет SQL-миграции, серверные функции и обработчики вебхуков по вашим инструкциям — на модели уровня Claude Sonnet 5.
• Главная ловушка — Row Level Security (RLS). Публичный ключ Supabase (anon key) виден в коде фронтенда по дизайну — это не утечка. Данные защищает не сокрытие ключа, а RLS-политики на таблицах. Забудете их — база читается анонимно. Именно так утекли данные из 170 проектов в одном задокументированном CVE (разбор ниже).
• Доступ к платному функционалу выдаёт вебхук, а не страница «спасибо за оплату». Это вторая ловушка, на которой спотыкаются почти все вайб-кодеры.
• Реальная комиссия Stripe на подписках — 4,5–6,5%, а не «2,9% + 30¢» из заголовка. Считаем ниже, вместе с альтернативами.

Уровень — продвинутый: предполагается, что у вас уже есть приложение (например, MVP, собранный с ИИ-агентом) и вы умеете запускать его локально.

Что мы соберём и что доверить агенту

Итоговая связка выглядит так: пользователь регистрируется через Supabase Auth → его данные лежат в таблицах Postgres под защитой RLS → при оплате он уходит в Stripe Checkout → Stripe присылает вебхук на ваш сервер → сервер отмечает подписку активной в базе → приложение открывает платный доступ.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

Ключевой принцип работы с Claude Code здесь — разделение доверия. Агент прекрасно пишет шаблонный код: схему таблиц, компоненты Checkout, каркас обработчика вебхука. Но он системно недооценивает три вещи из области безопасности, потому что в обучающих данных полно туториалов, где эти шаги пропущены. Поэтому маршрут такой:

Монтаж видео кодом: пайплайн из Deepgram, FFmpeg и Remotion

Деплой на Vercel через GitHub: как выложить проект по шагам

Spec-driven development: от идеи до архитектуры продукта с ИИ

AWS Continuum придёт в Claude Code и Codex: поиск дыр прямо в редакторе

OpenClaw на Claude отменил чужую бронь, чтобы поднять хозяина с 4-го места на 3-е

• Доверяем агенту: генерацию SQL-миграций, серверную функцию создания Checkout-сессии, React-компоненты формы оплаты, парсинг тела вебхука, черновик схемы данных.
• Проверяем руками (или явно требуем в промпте): включён ли RLS на КАЖДОЙ таблице, проверяется ли подпись вебхука, где хранится service_role-ключ, защищены ли RPC-функции.

Дальше — по шагам, с этими проверками встроенными в маршрут.

Подготовка: аккаунты, ключи и Stripe MCP

Что понадобится: аккаунт Supabase, аккаунт Stripe (в тестовом режиме карты не нужны), Node-проект и Claude Code. Времени — вечер.

1. Проект Supabase. Создаём проект на бесплатном тарифе. Free даёт 500 МБ базы, 1 ГБ файлового хранилища, 5 ГБ исходящего трафика, до 50 000 активных пользователей в месяц и 500 000 вызовов Edge Functions (на 12 июля 2026). Ограничение, о котором молчат: бесплатный тариф держит только 2 активных проекта, а проект без запросов неделю уходит в автопаузу — для пет-проекта нормально, для демо клиенту неудобно. Платный Pro — от $25/мес плюс $10/мес компьют-кредита на инстанс.

2. Ключи Supabase. В проекте будет два ключа. anon (публичный) — уходит в фронтенд, это нормально и ожидаемо. service_role — административный, игнорирует RLS целиком и должен жить только на сервере. Никогда не кладите service_role в клиентский код и не вставляйте его в промпт агенту без явного «это серверный секрет».

3. Ключи Stripe. Здесь есть свежий нюанс, который пропускают почти все туториалы: с мая 2026 Stripe для новых интеграций рекомендует Restricted API Keys (RAK) — ключи с ограниченными правами — вместо старого «всемогущего» sk_.... Аккаунты старше могут ещё показывать unrestricted-ключ, но для нового проекта заведите RAK ровно с теми правами, что нужны (обычно — запись Checkout и чтение подписок).

4. Stripe MCP — чтобы агент работал с документацией и тестами прямо в терминале. Stripe хостит официальный удалённый MCP-сервер. Подключается одной командой:

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

claude mcp add --transport http stripe https://mcp.stripe.com/

Плюс есть официальный плагин Stripe для Claude (маркетплейс Anthropic) с командами /explain-error (расшифровать ошибку Stripe) и /test-cards (подставить тестовые карты). Это тот случай, когда MCP реально экономит время: агент не выдумывает названия параметров API, а сверяется с живой докой. Если не знаете, что такое MCP и как его подключать, у нас есть отдельный разбор коннекторов Claude.

База данных: схема и RLS с первого коммита

Просим Claude Code сгенерировать схему. Хороший промпт задаёт не только таблицы, но и политику доступа: «Создай таблицы profiles и subscriptions, свяжи с auth.users, включи RLS на обеих и напиши политики: пользователь видит только свои строки».

И здесь — ловушка №1, самая дорогая. В Supabase поведение RLS зависит от того, КАК создана таблица:

• Таблица, созданная через визуальный Table Editor, получает RLS включённым по умолчанию.
• Таблица, созданная сырым SQL (а Claude Code почти всегда пишет миграции именно SQL-файлами), RLS автоматически НЕ включает. Нужен явный ALTER TABLE ... ENABLE ROW LEVEL SECURITY.

То есть типичный сценарий «агент сгенерировал schema.sql, я применил миграцию» оставляет таблицы открытыми на чтение всем, у кого есть публичный anon-ключ — а он, напомню, лежит в коде фронтенда. Настройка supabase auth и rls — не опциональный финальный штрих, а часть той же миграции. Правило простое: в каждом SQL-файле, где есть CREATE TABLE, должен быть и ENABLE ROW LEVEL SECURITY с политиками. Проверяйте это глазами в каждом дифе от агента.

Чтобы понять цену вопроса — реальный кейс в разделе рисков ниже.

Приём платежей: Checkout и подписки

Дальше — деньги. Базовый поток для SaaS: Stripe Checkout + подписка. Просим агента сделать серверную функцию, которая создаёт Checkout-сессию, и фронтенд-кнопку, которая на неё ведёт.

Пара практических деталей 2026 года, которые стоит заложить сразу:

• Embedded вместо Hosted. Раньше Checkout был отдельной страницей на stripe.com (Hosted). Сейчас Stripe направляет новые интеграции на Embedded Checkout (ui_mode: 'embedded', компоненты EmbeddedCheckoutProvider/EmbeddedCheckout) — форма оплаты живёт на вашем домене, а не уводит пользователя. Hosted всё ещё работает, но Embedded ощущается цельнее.
• Тестовый режим. Карта 4242 4242 4242 4242 — успешный платёж в test mode. stripe listen из Stripe CLI печатает тестовый секрет вебхука прямо в терминал — это пригодится через абзац.

Связка stripe checkout подписка вебхуки работает только если правильно замкнуть последнее звено — и вот тут ловушка №2.

Ловушка №2: доступ выдаёт вебхук, а не «спасибо за оплату»

Интуитивный (и неверный) способ: пользователь оплатил → Stripe редиректит его на success_url → на этой странице приложение открывает платный доступ. Так делать нельзя.

Redirect на success-страницу — ненадёжный триггер. Пользователь может закрыть вкладку до редиректа: деньги списались, доступа нет. Или, наоборот, открыть success-URL руками без оплаты. Реальный источник истины о платеже — серверное событие вебхука checkout.session.completed (или invoice.paid для продлений), пойманное на вашем сервере. Доступ выдаёт обработчик вебхука, который пишет в базу «подписка активна», а не страница в браузере.

Это тот случай, где стоит прямым текстом сказать агенту: «Доступ выдавай в обработчике вебхука по событию checkout.session.completed, не на success-странице». Иначе он с высокой вероятностью сгенерирует именно небезопасный вариант — он частотнее в туториалах.

И сразу — проверка подписи вебхука, без которой эндпоинт может дёрнуть кто угодно. Stripe подписывает каждый вебхук заголовком Stripe-Signature; на сервере его надо проверять через constructEvent(requestBody, signature, endpointSecret), где секрет начинается с whsec_ и отдельный от API-ключей. Важная тонкость: constructEvent требует сырое тело запроса (raw body), а не распарсенный JSON — частая причина, по которой проверка «не проходит» на локальной отладке.

Чтобы не собирать это вручную, можно поставить официальный open-source stripe-sync-engine от Supabase — он зеркалит данные Stripe (клиенты, подписки, инвойсы) в таблицы Postgres через вебхуки плюс периодический backfill, есть как one-click интеграция. Для стандартного SaaS это снимает половину ручной работы.

Ключи и секреты: что публично, а что нет

Сведём модель доступа в таблицу — это то, что агент почти никогда не объясняет, а именно на ней держится безопасность.

Главное заблуждение новичка звучит так: «мой anon-ключ виден в браузере — меня взломают». Нет. Видимость anon-ключа — норма; защита данных — это RLS, а не секретность ключа. А вот service_role, случайно попавший в клиентский бандл или в лог, — это полный админский доступ к базе для любого, кто его найдёт.

Ловушка №3: RLS не защищает RPC-функции

Даже если вы аккуратно включили RLS на всех таблицах, остаётся дыра, которую легко упустить. Postgres-функции (RPC), вызываемые через supabase.rpc(), могут быть доступны без аутентификации, даже когда RLS на таблицах настроен идеально. RLS защищает строки таблиц, но не логику внутри функции.

Если вы (или агент по вашей просьбе «вынеси это в функцию для скорости») завели RPC, внутри неё нужна отдельная проверка — например, auth.uid() IS NOT NULL или проверка роли. Промпт «включи RLS» эту точку не закрывает: Claude Code включит RLS на таблицах и честно отчитается, а RPC останется открытой. Это отдельный пункт вашего чек-листа ревью.

Сколько это реально стоит: комиссия Stripe против альтернатив

Теперь про экономику — то, что «евангелисты» показывают заголовком «всего 2,9% + 30¢». Для подписочного SaaS реальная эффективная ставка выше:

Данные на 12 июля 2026. Откуда у Stripe набегает: базовые 2,9% + 30¢ — это для карт своей страны; международные карты добавляют +1,5%, конвертация валюты +1%, а подписки (Stripe Billing) — ещё +0,7% к каждому периодическому платежу. На потоке международных мелких подписок эффективная ставка легко уходит к 6%.

Развилка для вайб-кодед SaaS: Stripe даёт максимум контроля и лучший API для агента, но налоги (VAT в ЕС, sales tax в США) — ваша забота. Merchant-of-Record сервисы (Lemon Squeezy, Paddle) берут номинально дороже, но сами становятся продавцом и решают за вас налоговую отчётность по всему миру — для соло-разработчика из Украины, продающего на мир, это часто перевешивает лишний процент. Если считаете unit-экономику — считайте по эффективной ставке, а не по headline.

Чек-лист ревью перед деплоем

Прежде чем выкладывать связку база данных для приложения claude code в прод, пройдите глазами (агент это не гарантирует):

1. RLS включён на каждой таблице (ENABLE ROW LEVEL SECURITY в миграции), политики ограничивают строки владельцем.
2. service_role-ключ не попал в клиентский код/бандл/переменные фронтенда.
3. Доступ к платному выдаётся в обработчике вебхука, не на success-странице.
4. Подпись вебхука проверяется (constructEvent, raw body, секрет whsec_).
5. Каждая RPC-функция имеет собственную проверку аутентификации.
6. Stripe-ключ — Restricted (RAK) с минимальными правами.
7. Секреты — в серверных переменных окружения, а не в репозитории.

Риски и безопасность (обязательно прочитать)

Это не абстрактные предостережения — по open-source и вайб-кодед проектам уже собрана статистика утечек.

• CVE-2025-48757 (опубликован 29 мая 2025). Исследователи Matt Palmer и Kody Low (Replit) нашли, что 303 эндпоинта в 170 проектах на платформе Lovable (10,3% из 1645 проверенных) читались анонимно через публичный anon-ключ — ровно из-за выключенного RLS. Это буквально ловушка №1 в проде. Вендор (Lovable) формально оспаривает CVE, перекладывая ответственность на разработчиков проектов, — что сути не меняет: RLS был выключен, и данные читались.
• Независимый пентест ModernPentest (2026): из 107 YC-стартапов на Supabase 28% экспонировали персональные данные через неправильную настройку базы. Другая выборка, тот же корень проблемы.
• service_role в клиенте. Ключ, зашитый в бандл или утёкший в логи, — это полный обход RLS и админ-доступ у любого, кто его достанет.
• Незащищённые RPC. Отдельная точка, которую включение RLS на таблицах не закрывает.
• Приватность данных пользователей. Вы становитесь оператором персональных данных. Минимизируйте, что храните; секреты — только на сервере; не отправляйте боевые пользовательские данные в промпты агенту.

YMYL-вывод простой: платежи и чужие персональные данные — не та область, где «сгенерировал и задеплоил» без ревью допустимо. Claude Code ускоряет сборку в разы, но финальную проверку безопасности по чек-листу выше делаете вы.

FAQ

Можно ли собрать это вообще без знания SQL и бэкенда? Собрать — да, Claude Code напишет и миграции, и серверные функции. Но задеплоить в прод без понимания RLS и вебхуков опасно: три ловушки из этой статьи агент по умолчанию не закрывает. Минимум — пройтись по чек-листу ревью.

Supabase или своя база на Postgres? Для старта Supabase выигрывает: готовые auth, авто-API и RLS из коробки экономят недели. Своя база оправдана, когда упираетесь в лимиты тарифа или нужна инфраструктура, которой у Supabase нет. Для MVP и первых платящих — Supabase.

Stripe или Merchant-of-Record (Paddle/Lemon Squeezy)? Нужен максимум контроля и лучший API — Stripe. Продаёте на весь мир соло и не хотите разбираться с VAT/sales tax — MoR берёт налоги на себя за лишний процент. Для украинского разработчика на международную аудиторию MoR часто удобнее.

Хватит ли бесплатных тарифов, чтобы запуститься? Да. Free Supabase и тестовый режим Stripe закрывают всю разработку. Помните про автопаузу проекта Supabase после недели без запросов и про переход на платный Stripe-режим перед приёмом реальных денег.

Почему мой anon-ключ виден в браузере — это же дыра? Нет, это ожидаемо. Публичный ключ на то и публичный; данные защищает RLS. Опасен не видимый anon-ключ, а выключенный RLS и утёкший service_role.

Что именно диктовать Claude Code, чтобы не нарваться? Три фразы в промпте: «включи RLS и политики на каждой таблице в этой же миграции», «доступ выдавай по вебхуку checkout.session.completed, не на success-странице», «проверяй подпись вебхука через constructEvent с raw body». Это закрывает большинство типовых промахов.