Как интегрировать онлайн-платежи в приложение или на сайт: полный чек-лист
Как интегрировать онлайн-платежи в сайт или приложение: выбор эквайринга, СБП и провайдера, backend, webhooks, возвраты, подписки и чек-лист перед запуском.
Онлайн-оплата кажется простой: пользователь нажимает «Оплатить», выбирает способ оплаты и получает подтверждение. Но для бизнеса за этой кнопкой стоит целая система — от выбора платежного решения и организации приема денег до backend, чеков, возвратов и обработки ошибок.
При этом универсальной схемы нет. Интернет-магазину, SaaS-сервису, мобильному приложению с подпиской и B2B-платформе могут потребоваться совершенно разные платежные сценарии.
В этой статье собрали общий чек-лист интеграции онлайн-платежей: что определить до разработки, какие решения рассмотреть, как устроен технический контур и что проверить перед запуском.
1. С чего начать интеграцию онлайн-платежей
Одна из распространенных ошибок — сначала выбрать платежный сервис, а уже потом выяснять, как именно он должен работать в продукте.
Лучше начать с бизнес-сценария. Перед разработкой ответьте на несколько вопросов.
Что вы продаете?
Например:
- физические товары;
- услуги;
- билеты или бронирования;
- цифровой контент;
- доступ к SaaS;
- подписку;
- образовательные программы;
- корпоративные услуги.
Где происходит оплата?
- на сайте;
- в мобильном приложении;
- в Telegram Mini App;
- в нескольких каналах одновременно.
Кто платит?
- физическое лицо;
- юридическое лицо;
- индивидуальный предприниматель.
От этого зависит не только пользовательский сценарий, но и организационная часть приема платежей: юрлицо, счет, эквайринг, касса и договоры.
Как пользователь должен платить?
Например:
- банковской картой;
- через СБП;
- по платежной ссылке;
- через магазин приложений;
- несколькими способами.
Платеж разовый или регулярный?
Если продукт работает по подписке, заранее потребуется спроектировать рекуррентные платежи, продление, отмену и неуспешные списания. Этот сценарий разбираем отдельно в разделе «Если нужна подписка».
Что должно произойти после оплаты?
Например:
Оплата успешна → заказ подтвержден → товар передан в доставку
или:
Оплата успешна → подписка активирована → пользователю открыт доступ
Это принципиально важно: платеж не существует отдельно от продукта. Он должен запускать дальнейшую бизнес-логику.
2. Какое платежное решение выбрать
Конкретный способ зависит от задачи.
| Задача | Что рассматривать |
|---|---|
| Разовая оплата на сайте | Интернет-эквайринг или платежный провайдер |
| Оплата через QR | СБП |
| Регулярная подписка | Рекуррентные платежи |
| Цифровая подписка в мобильном приложении | App Store / Google Play Billing |
| Физические товары или услуги в приложении | Соответствующий внешний платежный сценарий |
| Международные платежи | Провайдер с нужной географией и валютами |
| Несколько способов оплаты | Один или несколько платежных провайдеров |
При выборе платежного решения стоит проверить:
способы оплаты, комиссию, API, webhooks, возвраты, подписки, фискализацию, географию, валюты и стабильность.
Не всегда самый дешевый вариант оказывается подходящим. Если провайдер не поддерживает нужный способ оплаты или сценарий подписки, низкая комиссия не решит проблему.
Для сайта чаще всего достаточно интернет-эквайринга, агрегатора или СБП. Для мобильного приложения выбор зависит еще и от правил магазинов: цифровой контент и внешние товары требуют разных схем.
3. Как устроена онлайн-оплата
Упрощенно техническая схема выглядит так:
Сайт / приложение → Backend → Платежный сервис → Банк
После проведения операции информация возвращается обратно:
Платежный сервис → Backend → Статус заказа → Сайт / приложение
Рассмотрим на простом примере.
Шаг 1. Пользователь создает заказ
Выбирает товар или услугу и нажимает «Оплатить».
Шаг 2. Backend проверяет заказ
Сервер определяет состав заказа и сумму.
Шаг 3. Backend создает платеж
Система передает данные платежному провайдеру.
Шаг 4. Пользователь оплачивает
Вводит данные карты, переходит на платежную страницу, сканирует QR или подтверждает операцию в банковском приложении.
Шаг 5. Провайдер обрабатывает платеж
Платежный сервис взаимодействует с банком и получает результат.
Шаг 6. Backend получает информацию
Например, через webhook.
Шаг 7. Обновляется заказ
Заказ получает статус «Оплачен».
Шаг 8. Запускается бизнес-логика
Пользователь получает товар, услугу или доступ к функциональности.
Почему нельзя просто показать пользователю «Оплачено»
Представим ситуацию: пользователь оплатил заказ, но в этот момент пропал интернет.
Деньги могли списаться, но приложение не получило ответ.
Если ориентироваться только на интерфейс, система может решить, что платеж не состоялся.
Поэтому источником истины должен быть серверный статус платежа, а не только состояние приложения.
Правильная схема:
Платежный сервис → Backend → проверка статуса → изменение заказа
А не:
Пользователь нажал кнопку → приложение показало «Оплачено»
4. Что нужно предусмотреть в технической части
Платежный провайдер — только один элемент платежной системы.
В зависимости от продукта могут понадобиться:
- frontend;
- backend;
- база данных;
- платежный сервис;
- webhooks;
- админ-панель;
- CRM / ERP;
- аналитика;
- система уведомлений;
- фискализация.
Backend связывает платеж с остальным продуктом.
Он должен понимать:
- какой заказ оплачивается;
- какая сумма должна быть списана;
- кто совершает покупку;
- какой статус у платежа;
- можно ли выдать товар или услугу;
- был ли возврат;
- нужно ли активировать подписку.
Webhooks
После изменения статуса платежный сервис может отправить уведомление на backend.
Пользователь оплатил → Платежный провайдер → Webhook → Backend → Заказ «Оплачен»
Это позволяет системе получать актуальные изменения без постоянного опроса API.
При этом нужно учитывать повторную доставку одного и того же события.
Идемпотентность
Еще один важный сценарий:
- пользователь нажал «Оплатить»;
- запрос отправился;
- ответа нет;
- пользователь нажал кнопку повторно.
Без корректной обработки повторных запросов можно получить дублирующую операцию.
Поэтому платежная логика должна быть рассчитана на повторные запросы и повторные уведомления. На практике это часть backend-контура веб-разработки: API, статусы платежей и связь заказа с провайдером.
5. Если нужна подписка
Подписка — это не просто платеж, который повторяется каждый месяц.
У нее есть собственный жизненный цикл:
Выбор тарифа → Первый платеж → Подписка активна → Дата списания → Повторный платеж → Продление
А если платеж не прошел?
Система должна понимать:
- продлена ли подписка;
- нужно ли повторить списание;
- сколько раз повторять попытку;
- нужно ли уведомить пользователя;
- когда ограничить доступ;
- что произойдет после успешного повторного платежа.
Также нужно предусмотреть отмену подписки, смену тарифа и возвраты.
Поэтому подписочную модель лучше проектировать до интеграции платежного сервиса, а не добавлять позже. Это особенно важно для SaaS и Telegram Mini App, где оплата часто встроена в сам продукт.
6. Если платежи будут в мобильном приложении
Для мобильного приложения появляется дополнительный уровень требований — правила магазина приложений.
Здесь главный вопрос:
Что именно покупает пользователь?
Если приложение продает цифровой контент, функции или подписку, могут применяться правила App Store и Google Play относительно использования их платежных систем.
Для физических товаров и услуг, которые потребляются вне приложения, действуют другие сценарии.
Например, платежная модель приложения с цифровыми тренировками будет отличаться от приложения ресторана, через которое пользователь заказывает доставку еды.
Поэтому еще до начала разработки нужно определить:
- что продается;
- где потребляется товар или услуга;
- является ли покупка цифровой;
- для какой платформы создается приложение;
- в каких странах оно будет распространяться;
- какой способ оплаты допустим для конкретного сценария.
Как пройти путь от идеи до публикации и какие требования магазинов учитывать заранее, мы разбирали в статье «Как заказать разработку мобильного приложения». Отдельно о пользе мобильного канала — в материале «Как мобильное приложение повысит эффективность вашего бизнеса».
Если приложение уже готово, проблемы часто всплывают на этапе модерации: неправильный тип покупок, внешняя оплата цифрового контента или неполный сценарий восстановления доступа. Эти требования лучше закладывать в план публикации, а не чинить после отклонения сборки.
7. Что проверить перед запуском
До релиза стоит пройтись по платежному чек-листу. Типичные ошибки на старте продукта мы также разбирали в статье «Самые частые ошибки при запуске продукта».
Бизнес
- Понятно, кто принимает деньги.
- Определены способы оплаты.
- Определены правила возврата.
- Понятно, какие документы и чеки нужны.
- Определен сценарий B2C или B2B.
Продукт
- Понятно, что происходит после успешной оплаты.
- Есть сценарий неуспешного платежа.
- Есть возможность повторить оплату.
- Продуманы возвраты.
- Для подписок предусмотрено продление и отмена.
Backend
- Сумма проверяется на сервере.
- Статус платежа подтверждается сервером.
- Настроены webhooks.
- Обрабатываются повторные уведомления.
- Предусмотрена идемпотентность.
- Платеж связан с конкретным заказом.
Мобильное приложение
- Определен тип покупаемого продукта.
- Проверены требования App Store и Google Play.
- Платежный сценарий соответствует правилам платформ.
- Проверены покупки, возвраты и восстановление доступа — если они применимы.
Платежный сервис
- Поддерживаются необходимые способы оплаты.
- Есть нужные API.
- Работают возвраты.
- Поддерживаются необходимые сценарии подписки.
- Понятно, как работает фискализация.
- Проверены ограничения по странам и валютам.
8. Сколько стоит интеграция онлайн-оплаты
Стоимость зависит не столько от самой платежной формы, сколько от количества сценариев вокруг нее. Из чего в целом складывается бюджет IT-проекта, мы разбирали в статье «Сколько стоит разработка».
На бюджет влияют:
- готовый или новый backend;
- сайт или мобильное приложение;
- количество способов оплаты;
- один или несколько провайдеров;
- подписки;
- возвраты;
- фискализация;
- CRM / ERP;
- админ-панель;
- аналитика;
- международные платежи;
- требования к безопасности.
Условно можно выделить три уровня.
Уровень 01
Простая интеграция
Один провайдер, один-два способа оплаты, создание платежа, получение статуса и базовые возвраты.
Уровень 02
Средняя
Несколько способов оплаты, webhooks, возвраты, фискализация, личный кабинет и административная часть.
Уровень 03
Сложная
Подписки, несколько провайдеров, несколько стран, CRM/ERP и сложная бизнес-логика.
Стоимость может начинаться от нескольких десятков тысяч рублей для простой интеграции и достигать нескольких сотен тысяч рублей и выше для сложных платежных сценариев с подписками, несколькими провайдерами, CRM/ERP и дополнительной бизнес-логикой.
9. Отдельные вопросы: куда идти дальше
Этот материал — общий чек-лист. Если нужно углубиться в конкретный канал или этап разработки, полезны соседние разделы и статьи:
Веб-разработка
Сайт, личный кабинет, backend и интеграции с платежными системами.
Мобильные приложения
iOS и Android, публикация в магазинах и платежные сценарии внутри приложения.
Telegram Mini App
Оплата внутри Telegram: Telegram Payments, ЮKassa, Stripe и другие провайдеры.
Как заказать мобильное приложение
От идеи и Discovery до MVP, тестирования и публикации в App Store, Google Play, RuStore и AppGallery.
Сколько стоит разработка
Из чего складывается бюджет IT-проекта и где обычно растут расходы.
Ошибки при запуске продукта
Что чаще всего ломает релиз, если платежный сценарий не продуман заранее.
Из реализованных платежных продуктов можно посмотреть PayQin — e-wallet и цифровые платежи, Invohub — B2B-инвойсы и онлайн-оплата, и FindSport — бронирование площадок со встроенной оплатой. Все проекты — в разделе «Кейсы».
Как 2people IT интегрирует платежи
В 2people IT мы начинаем не с подключения конкретного платежного сервиса, а с разбора сценария.
Сначала определяем:
- что продает продукт;
- кто платит;
- где происходит оплата;
- какие способы оплаты нужны;
- как формируется заказ;
- когда заказ считается оплаченным;
- нужны ли подписки;
- как работают возвраты;
- какие системы уже используются;
- какие требования есть к платформам и географии.
После этого проектируем техническую схему и определяем, какие компоненты потребуются: backend, база данных, CRM/ERP, админ-панель, аналитика, уведомления, фискализация.
Отдельно прорабатываем нестандартные ситуации: повторную оплату, неуспешные платежи, задержку подтверждения, повторные webhooks, возвраты, отмену подписки и изменение тарифа.
Так платежная система становится частью архитектуры продукта, а не функцией, которую приходится срочно добавлять перед релизом.
Вывод
Интеграция онлайн-платежей — это не подключение одной кнопки.
Перед разработкой нужно определить, что продается, кто платит, где происходит покупка, какие способы оплаты нужны и что должно произойти после успешного платежа.
После этого можно выбрать подходящее платежное решение и спроектировать техническую интеграцию.
Для простого продукта достаточно базового платежного сценария. Для SaaS, подписочного сервиса, мобильного приложения, B2B-платформы или международного продукта потребуется больше компонентов и бизнес-логики.
Главное — учитывать платежи на этапе проектирования продукта, а не после того, как остальная система уже готова.
Часто задаваемые вопросы
Планируете интегрировать онлайн-оплату?
Поможем определить платежный сценарий, выбрать архитектуру и интегрировать оплату в сайт или приложение — от подключения платежного провайдера до backend, возвратов, подписок и интеграций с другими системами.
Оставьте заявку — разберем задачу и предложим подходящий вариант реализации.
