Стартапу нужна не платёжная инфраструктура, а первая оплата — доказательство, что за продукт готовы платить. Поэтому разумный путь такой: за вечер выставить платёжную ссылку и проверить спрос вручную, а API и вебхуки подключить тогда, когда ручной режим начнёт мешать. Главное — с самого начала завести у себя нормальный заказ с уникальным номером, чтобы переход на автоматизацию не превратился во вторую интеграцию с нуля.
Ниже — что делать на каждой стадии, сколько это занимает и какие решения потом дорого переделывать.
Первая оплата за один вечер
Порядок для MVP, у которого ещё нет ни бэкенда, ни личного кабинета:
- Опишите оффер. Что продаёте, за сколько, что человек получает сразу после оплаты. Без этого не пройдёт модерация и не поймёт покупатель.
- Оформите статус продавца. Самозанятость подходит для соло-основателя, ИП — если есть команда или перепродажа. Подробности — на странице про приём платежей без ИП.
- Подайте заявку и дождитесь проверки. Категорию проекта, доступные методы и условия подтверждает модерация, обычно это один-два рабочих дня.
- Выпустите ссылку и продайте вручную. Десять диалогов в личке дадут больше данных о продукте, чем месяц разработки биллинга.
Бот-магазин пресетов так и запускался: первые сорок продаж основатель провёл вручную, отправляя ссылку в ответ на сообщение. К моменту, когда он сел писать интеграцию, он уже знал реальные цены, самые частые вопросы и то, что половина покупателей платит с телефона по СБП.
Ссылка, кнопка или API: что выбрать на текущей стадии
| Стадия | Чем принимать | Сколько занимает |
|---|---|---|
| Проверка спроса, 0–20 продаж | Ссылка вручную из личного кабинета | Час после проверки проекта |
| Лендинг с одним тарифом | Кнопка на статичной ссылке или форма | Полдня вёрстки |
| Продукт с личным кабинетом | Создание платежа по API и колбэк на сервер | Вечер разработчика плюс день на тесты |
| Подписки и продления | API плюс собственный планировщик счетов | Спринт |
Ошибка новичков — сразу писать биллинг на подписки, когда ещё непонятно, какой тариф покупают. Это две-три недели, которые почти всегда выбрасывают после первого разговора с клиентами.
Модель заказа, которую не придётся переписывать
Единственное, что стоит сделать правильно с первого дня, — это ваша собственная таблица заказов. Она стоит полчаса работы и экономит недели потом.
orders
id uuid -- ваш order_id, уходит в платёж
user_id uuid
product text -- что купили
amount numeric -- сколько, в рублях
status text -- pending | paid | canceled | expired
payment_id text -- пришёл в ответе на создание платежа
granted_at timestamp -- когда выдали доступ, NULL пока не выдали
created_at timestampТри правила вокруг этой таблицы. Первое: order_id генерируете вы, а не платёжный сервис, и он не меняется никогда. Второе: статус заказа меняет только серверное событие, а не действие пользователя в браузере. Третье: выдача привязана к granted_at — если поле уже заполнено, повторное событие ничего не делает.
При такой модели переезд с ручной ссылки на API — это добавление одного HTTP-запроса. Всё остальное уже на месте.
Что именно пишет разработчик
Создание платежа: POST /api/v1/payments, заголовки X-API-Key с ключом кассы и X-Nonce — свежий UUID на каждый запрос. Nonce живёт 10 минут, повтор того же значения вернёт 401 "nonce already used". В теле — amount строкой вроде "1500.00", payment_currency: "RUB", ваш order_id и по желанию metadata с любыми внутренними полями: они вернутся в колбэке.
В ответе — payment_id, status, expires_at и pay_url. Ссылку отдаёте покупателю, остальное сохраняете в заказ. Если payment_method не указывать, покупатель выберет СБП или карту сам — на раннем этапе так и стоит делать, меньше поводов потерять оплату.
Приём результата: колбэк на ваш URL с заголовком X-Signature, событиями payment.paid, payment.canceled и payment.expired. Отвечайте 200 быстро, тяжёлую работу уносите в очередь. Готовые примеры кода есть в разборе API приёма платежей.
Как менять цены и тарифы, не ломая уже оплаченное
Стартап меняет прайс каждые пару месяцев, и это нормально — ненормально, когда после смены цены у купивших слетает доступ. Правило простое: цена и состав тарифа фиксируются в заказе в момент создания платежа, а не читаются из справочника при выдаче.
То есть в строке заказа лежит не ссылка plan_id = pro, а слепок: название тарифа, цена, срок и список того, что входило на момент покупки. Меняете прайс — старые заказы даже не замечают этого.
Тот же приём спасает при возвратах и спорах: вы всегда можете показать, за что человек заплатил именно ту сумму.
Сколько это реально стоит по времени
- подготовка оффера и описания продукта — 1–2 часа;
- заявка и проверка проекта — обычно 1–2 рабочих дня;
- первая ссылка и продажа вручную — час;
- интеграция создания платежа и обработчика колбэка — вечер;
- тестовые сценарии: успех, отмена, истечение, повтор колбэка — ещё полдня;
- подписки и продления — от недели, и раньше времени за них лучше не браться.
Тестовый прогон часто пропускают, а зря: три четверти проблем на запуске — это не оплата, а выдача доступа. Как собрать проверочный набор сценариев, показано в статье про тестовый режим платежей.
Когда пора выключать ручной режим
Не по календарю, а по симптомам:
- Вы отправляете больше десяти ссылок в день. Дальше начнутся опечатки в суммах.
- Покупатели ждут доступ дольше пяти минут. Ночные оплаты копятся до утра и превращаются в возвраты.
- Вы не можете за минуту ответить, сколько заработали за неделю. Значит, данные живут в переписке, а не в базе.
- Появился второй продукт или второй тариф. Ручная выдача перестаёт помещаться в голову.
Любого одного пункта достаточно, чтобы потратить вечер на автоматизацию. Если проект дорос до тарифных планов и продлений, дальше смотрите решение для платежей и биллинга в B2B SaaS.
Где стартапы спотыкаются чаще всего
Идентификатор заказа из платёжного сервиса. Проект берёт payment_id как первичный ключ, а потом переезжает на другой способ приёма — и вся история продаж повисает в воздухе. Свой order_id с первого дня снимает эту проблему.
Выдача из фронтенда. Открылась страница успеха — выдали доступ. При такой схеме доступ получают и те, кто просто открыл ссылку вида /success руками. Выдавайте только по подписанному событию с сервера.
Отсутствие обработки повторов. Колбэк может прийти дважды: сеть моргнула, ответ не дошёл, сервис повторил доставку. Если не смотреть на отметку об уже выданном доступе, клиент получит два письма, а иногда и две подписки.
Запуск без условий возврата. Их спрашивает и модерация, и первый недовольный покупатель. Один абзац на лендинге закрывает вопрос до того, как он станет спором.