Приём платежей на сайте и в боте · рекуррентные платежи · вебхуки · 54-ФЗ
Подключаю приём платежей к сайту, боту или сервису: разовые оплаты, подписки с автопродлением, обработку уведомлений провайдера и чеки по 54-ФЗ. Проектирую так, чтобы баланс сходился, а любую операцию можно было объяснить постфактум.
Опыт из продакшена: две платёжные интеграции с рекуррентными списаниями на платформе подписок — ~6 000 подписчиков, оборот около 3 млн ₽ в месяц. Двойные списания исключены на уровне модели данных.
Оплата заказа, услуги или доступа: платёжная форма провайдера на странице или переход на его платёжную страницу. Статус заказа меняется по уведомлению провайдера на сервер, а не по возврату покупателя на сайт.
платёжная форма · статусы заказа · вебхуки
02
Рекуррентные платежи и подписки
Покупатель один раз соглашается на автосписания, дальше подписка продлевается без его участия. Полный жизненный цикл: оформление, продление, неудачное списание, отмена.
автопродление · тарифы · история операций
03
Оплата в Telegram- и MAX-боте
Та же схема в мессенджерах: бот выдаёт ссылку на оплату, после уведомления провайдера открывает доступ к каналу или контенту.
Фискализация через облачную кассу провайдера в той же интеграции: чек уходит покупателю автоматически при каждом списании.
54-ФЗ · облачная касса
05
Несколько провайдеров в одной системе
Две и больше платёжных интеграции на одном бэкенде: подписки и платежи от всех провайдеров видны в одной админ-панели. В кейсе так работают CloudPayments и Rocketr.
CloudPayments · Rocketr · общая модель платежей
06
Биллинг и движение средств
Расчёт и списание, финансовые лимиты, распределение средств между участниками, история операций — когда задача не заканчивается на «деньги пришли».
Laravel · PostgreSQL · очереди · идемпотентность
Что входит в интеграцию
под ключ
Платёж
создание платежассылка или платёжная формастатусы
Вебхуки
проверка подписиидемпотентность по external_idповторные уведомления
Подписки
согласие на автосписанияпродлениенеудачное списаниеотмена
54-ФЗ
облачная касса провайдерачек при каждом списании
Учёт
история операцийсверка расхожденийадмин-панельроли и права
Качество
автотесты на списания и вебхукиручная приёмка сценариев
сайт или бот создаёт платёж→покупатель платит у провайдера→провайдер шлёт вебхук→сервер проверяет подпись и пишет платёж один раз→заказ оплачен, чек у покупателя
Где ошибка стоит денег
что закладываю заранее
01
Повторные уведомления
Провайдер может прислать одно и то же уведомление несколько раз. Обработка идемпотентна по идентификатору операции у провайдера: повтор не создаст второй платёж и не продлит подписку дважды.
вебхуки · external_id · модель данных
02
Ответы не по документации
Отдельно закладываю поведение на случай, когда внешний сервис отвечает не так, как обещал в документации: подпись запросов, лимиты частоты, повторы, отказы.
REST / JSON API · повторы · таймауты
03
Сверка расхождений
Каждая операция остаётся в истории, поэтому расхождение между системой и провайдером можно найти и объяснить постфактум.
история операций · сверка
04
Автотесты на деньги
Списания, продления и обработку ответов провайдера закрываю автотестами: PHPUnit и Pest на бэкенде, Jest или Vitest в Node-части. Перед релизом прогоняю сценарии руками.
PHPUnit · Pest · Jest / Vitest
Как идёт работа
пять этапов
01
Разбор задачи
Созвон на двадцать минут: что продаёте, разово или по подписке, где принимаете оплату — на сайте, в боте или в приложении, какой провайдер уже подключён.
02
Выбор провайдера и схемы
Подбираем провайдера под продукт и правовую форму: способы оплаты, автосписания, чеки. Договор с провайдером заключает заказчик, я готовлю техническую часть.
03
Разработка
Модель платежей и подписок, создание платежа, обработка вебхуков, чеки, админ-панель. Если сайт уже работает, встраиваю платежи в существующий код.
04
Тесты и приёмка
Списания, продления и обработку ответов провайдера закрываю автотестами. Перед релизом прогоняю сценарии руками.
05
Запуск и поддержка
Мониторинг, разбор спорных операций, доработки под новые тарифы.
Сроки и стоимость
по задаче
Цена зависит от числа провайдеров, сложности тарифов, нужны ли подписки и чеки, есть ли уже бэкенд. После созвона присылаю оценку по этапам.
Типовое решение
как это может выглядеть
Типовое решение
Приём оплаты в интернет-магазине
Пример задачи и архитектуры, а не проект из портфолио
Задача
Магазин принимает заказы на сайте, а оплату — переводом по реквизитам. Менеджер сверяет поступления вручную, чеки выбивает отдельно.
Как собрать
Платёжный провайдер с картами и СБП, оплата сразу при оформлении заказа. Вебхук провайдера меняет статус заказа и запускает сборку на складе, чек по 54-ФЗ формирует облачная касса провайдера. Возвраты и частичные возвраты — из админки.
Что получит заказчик
Оплаченный заказ сам доходит до склада, чек — до покупателя, а сверка занимает минуты вместо часов.
Laravel или Node.js · PostgreSQL · платёжный провайдер · 54-ФЗ
Реальный проект: финансовое API
интеграция с биржей
01
Бэкенд сервиса автоматизации фьючерсной торговли
tradingforce.io · проект закрыт
Единственный backend-разработчик в команде из четырёх
Интеграция с торговым API Bybit: подписанные запросы, автоматические stop-loss и take-profit, дедупликация запросов с кешированием ответов, чтобы не упираться в лимиты биржи. Торговая логика закрыта автотестами.
3торговых бота
1backend-разработчик
Node.js · TypeScript · Redis · PostgreSQL · Bybit API
Зависит от продукта, правовой формы и нужных способов оплаты. Для подписок проверяем, умеет ли провайдер автосписания, для приёма оплаты от физлиц — формирует ли он чеки по 54-ФЗ. Договор с провайдером заключает заказчик, я готовлю техническую часть.
Как работают рекуррентные платежи?
При первой оплате покупатель соглашается на автосписания, и провайдер сохраняет привязку карты. Следующие списания проходят без участия покупателя, а сервер получает уведомление о каждом — успешном или нет — и продлевает подписку или отмечает неудачное списание.
Зачем нужны вебхуки?
Вебхук — уведомление, которое провайдер присылает на ваш сервер, когда меняется статус платежа. Именно по нему система узнаёт, что деньги пришли: покупатель может закрыть вкладку и не вернуться на сайт. Уведомления обрабатываются идемпотентно, поэтому повторное не создаст второй платёж.
Нужны ли чеки по 54-ФЗ при оплате на сайте?
Если вы как ИП или компания принимаете оплату от физлиц, по 54-ФЗ нужен чек. Многие провайдеры формируют его через свою облачную кассу, это подключается в той же интеграции. Самозанятые выдают чеки через «Мой налог».
Можно ли подключить оплату к уже работающему сайту?
Да. Работаю с чужим и legacy-кодом: разбираюсь в существующей системе и встраиваю платежи в неё. Что придётся поменять, становится понятно после разбора.
Сколько стоит интеграция платёжной системы?
Цена зависит от числа провайдеров, сложности тарифов, нужны ли подписки и чеки, есть ли уже бэкенд. После короткого созвона присылаю оценку по этапам.
Подключим приём платежей
Напишите в Telegram, что продаёте и где принимаете оплату: на сайте, в боте или в приложении. Отвечу, какую схему выбрать и что войдёт в первую версию.