Прием платежей для SaaS: как настроить подписки, продления и вебхуки статусов

Что нужно SaaS-сервису для приёма платежей по подписке

У SaaS платёж — не разовая покупка, а событие в жизни аккаунта: оплата тарифа, продление, смена плана, возврат. Поэтому от платёжного шлюза нужна не только кнопка «Оплатить», но и понятный API, статусы платежей и надёжные уведомления.

Минимальный набор для приёма платежей по подписке выглядит так:

• создание платежа через REST API с привязкой к вашему аккаунту и тарифу;
• несколько способов оплаты: СБП, карты РФ и USDT, чтобы клиент не уходил из-за неудобного метода;
• подписанные вебхуки с повторной доставкой, чтобы не потерять ни одну оплату;
• тестовый режим для отладки продлений без реальных денег;
• возвраты через кабинет и API;
• понятный вывод выручки.

Всё это есть в Paydex — платёжном шлюзе для сайтов, онлайн-сервисов и Telegram-ботов. ИП и ООО для подключения не нужны: мы работаем с обычными физическими лицами, а деньги выводятся в USDT (TRC20, BEP20) и в рублях на карту или по СБП. Так что оплата SaaS без ИП — рабочий сценарий, а не лазейка.

Какие модели оплаты бывают у SaaS и какую выбрать

Прежде чем писать интеграцию, определитесь с моделью. От неё зависит, сколько логики будет в вашем коде, а сколько — на стороне платёжного шлюза.

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

Как работает продление подписки без ручной работы

Главная идея: на каждый период создаётся отдельный платёж, а ваш сервис сам решает, что с ним делать. Клиенту не нужно писать в поддержку, вам — вручную включать доступ.

1. Клиент выбирает тариф в личном кабинете вашего сервиса. Вы создаёте платёж через API и сохраняете у себя связь «платёж — аккаунт — тариф — период».
2. Клиент попадает на страницу оплаты и платит удобным способом: СБП, картой РФ или в USDT.
3. Paydex отправляет подписанный вебхук. Ваш сервер проверяет подпись и сдвигает дату окончания подписки на один период.
4. За 3–5 дней до конца периода сервис отправляет напоминание с новой платёжной ссылкой: письмом, в Telegram или уведомлением в интерфейсе.
5. Если оплаты нет, включается льготный период в 1–3 дня, после чего доступ ограничивается. Данные клиента при этом лучше не удалять — так проще вернуть его в сервис.

Для первых клиентов можно обойтись вообще без интеграции: платёжные ссылки и страница оплаты работают без кода. Ссылку отправляете в письме или чате, оплату подтверждаете по уведомлению — и уже потом переходите на автоматику через API.

Вебхуки статусов: что обрабатывать и как не сломать продление

Вебхук — главный источник правды об оплате. Редирект клиента на страницу «Спасибо» ничего не гарантирует: он мог закрыть вкладку, потерять связь или подменить адрес. Продлевайте доступ только по вебхуку.

Что делать при получении уведомления

1. Проверьте подпись запроса ключом проекта. Без этого любой желающий сможет «оплатить» тариф обычным запросом на ваш адрес.
2. Найдите платёж в своей базе и убедитесь, что сумма и тариф совпадают с ожидаемыми.
3. Проверьте, не обрабатывался ли этот платёж раньше.
4. Продлите подписку и отметьте платёж как обработанный в одной транзакции базы данных.
5. Быстро верните успешный ответ. Всё тяжёлое — письма, документы, интеграции с CRM — вынесите в очередь.

Почему важна идемпотентность

Paydex повторно доставляет вебхуки, если ваш сервер не ответил или временно упал. Это защита от потерь, но у неё есть обратная сторона: одно и то же уведомление может прийти дважды. Без проверки на повтор клиент получит два периода вместо одного. Формат подписи и правила доставки описаны в документации: вебхуки Paydex.

Какие статусы учитывать в логике подписки

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

Точные названия статусов и поля уведомлений сверяйте с документацией, а не с примерами из чужих статей.

Как хранить подписки и считать апгрейды, даунгрейды и пробный период

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

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

Апгрейд, даунгрейд и пробный период

При апгрейде посчитайте остаток текущего периода и выставите платёж на доплату. Шлюзу вы передаёте уже итоговую сумму. Сумму всегда считайте на сервере, а не берите из запроса браузера, иначе её можно подменить.

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

Возвраты

Клиент оплатил не тот план или передумал в первые дни — для SaaS это обычная ситуация. В Paydex возвраты покупателям делаются через кабинет и API, поэтому кнопку возврата можно встроить в вашу админку: возвраты через API. Условия возврата обязательно пропишите в оферте — блок «Возврат» нужен и для модерации проекта.

Какие способы оплаты подключить для аудитории SaaS

Чем больше удобных способов на странице оплаты, тем меньше клиентов отваливается на последнем шаге. Логика на вашей стороне при этом остаётся одной: вы ждёте вебхук об успешной оплате.

• СБП (QR и ссылка) — быстро и привычно для клиентов из России, особенно в B2C и небольших командах;
• банковские карты РФ — универсальный вариант для тех, кто платит из браузера на ноутбуке;
• USDT (TRC20, BEP20) — удобно разработчикам, фрилансерам и клиентам, которые предпочитают криптооплату.

Выручка копится на балансе в USDT. Выводить её можно в USDT или в рублях — на карту либо по СБП. Абонентской платы и платы за подключение у Paydex нет, комиссия зависит от оборота и тематики проекта. Актуальные условия смотрите на странице тарифов, а не в сравнениях третьих сторон.

Как подключить приём платежей для SaaS за один день

Платёжный шлюз для SaaS подключается без бумажной волокиты. Путь выглядит так:

1. Зарегистрируйтесь в Paydex и создайте проект — сайт вашего сервиса или Telegram-бот.
2. Подтвердите домен или бота.
3. Подготовьте проект к модерации: работающий сервис, список тарифов с ценами, публичная оферта с блоком «Возврат», контакты. Что именно проверяют — в требованиях к сайту.
4. Дождитесь модерации — обычно она занимает до суток. В это время можно писать интеграцию: есть SDK для Node.js, PHP и Python.
5. Получите ключи API и отладьте сценарии в тестовом режиме: создание платежа, успешная оплата, повторный вебхук, неуспешная оплата, возврат.
6. Переключитесь на боевой режим и проведите первый платёж на минимальную сумму.
7. Выведите выручку в USDT или в рублях и убедитесь, что вся цепочка работает.

Если вы строите сервис для других компаний или агентств, посмотрите White Label: страницы оплаты можно оформить под свой бренд и домен.

Частые ошибки при приёме платежей за подписки

• Продление по редиректу. Клиент закрыл вкладку — оплата есть, доступа нет. Или наоборот: вручную открыл страницу успеха без оплаты.
• Нет проверки подписи. Любой запрос на ваш адрес превращается в «оплаченный» платёж.
• Нет защиты от повторов. Повторная доставка вебхука начисляет лишний период.
• Сумма берётся с фронтенда. Клиент может подменить цену тарифа.
• Нет напоминаний. Без них клиенты забывают продлить подписку и уходят молча.
• Нет льготного периода. Доступ отключается в ту же секунду, и поддержка получает волну обращений.
• Оферта без блока «Возврат». Проект может не пройти модерацию, а спорные ситуации с клиентами решаются сложнее.

Если что-то не получается, пишите в поддержку Paydex в Telegram. Другие разборы по платежам и интеграциям собраны в блоге.

Итог простой: для SaaS нужны платёж на каждый период, подписанный вебхук как единственный источник правды, идемпотентная обработка и аккуратная логика тарифов. Остальное — вопрос аккуратной настройки, а не сложной инфраструктуры.