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 надсилає вебхук на ваш сервер → сервер позначає підписку активною в базі → застосунок відкриває платний доступ.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Ключовий принцип роботи з 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-сервер. Під’єднується однією командою:

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

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 автентифікація 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». Це закриває більшість типових промахів.