Какие способы оплаты можно подключить
Набор способов оплаты зависит от платёжного провайдера и вашей аудитории. Чем меньше шагов от корзины до подтверждения, тем меньше брошенных заказов, поэтому стоит предложить клиенту привычные варианты.
- Банковские карты, включая «Мир», — через эквайринг платёжного сервиса.
- СБП — оплата по номеру телефона через банковское приложение клиента, без ввода реквизитов карты.
- Сохранённые карты для повторных покупок в одно касание.
- Регулярные платежи — для подписок, абонементов и членства.
- Оплата при получении — если она нужна, её тоже стоит отразить в статусах заказа и чеках.
- Бонусы и частичная оплата баллами — в связке с программой лояльности.
В мобильном приложении оплата через СБП обычно выглядит так: клиент нажимает «Оплатить через СБП», выбирает свой банк, подтверждает платёж в банковском приложении и возвращается обратно — уже с подтверждённым заказом.
Правила App Store, Google Play и RuStore для платежей
Прежде чем подключать оплату, важно понять, что именно вы продаёте. От этого зависит, можно ли использовать собственный платёжный сервис.
Физические товары и офлайн-услуги — еда, одежда, доставка, запись в салон, такси — оплачиваются через ваш платёжный сервис, и магазины приложений комиссию с них не берут. Это самый частый сценарий для бизнес-приложений.
Цифровые товары и контент внутри приложения — подписки на материалы, онлайн-курсы, внутриигровые покупки — по правилам App Store и Google Play, как правило, должны продаваться через встроенные покупки магазина. У RuStore есть собственный платёжный инструмент для цифровых покупок. Правила различаются по странам и регулярно меняются, поэтому схему монетизации цифрового контента мы проверяем под каждый проект отдельно.
Как выбрать платёжный сервис
Мы работаем с ЮKassa, CloudPayments, Сбером, Т-Банком и Робокассой. Все они поддерживают карты и СБП, но отличаются тарифами, требованиями к подключению, удобством личного кабинета и дополнительными сервисами.
Выбор зависит от вашего банка, юридической формы, оборота и задач. Если расчётный счёт уже открыт в банке с эквайрингом, часто проще подключиться у него. Если нужны рекуррентные платежи, сплит-платежи между несколькими получателями или встроенная касса — сравниваем предложения под эти функции.
| На что смотреть | Почему это важно |
|---|---|
| Комиссия за карты и СБП | Напрямую влияет на маржу, тарифы у сервисов разные |
| Срок зачисления денег | Важно для оборотных средств |
| SDK для мобильных приложений | Готовые компоненты ускоряют разработку и упрощают оплату |
| Рекуррентные платежи | Нужны для подписок и абонементов |
| Встроенная онлайн-касса | Избавляет от отдельной интеграции с кассой |
| Возвраты и частичные возвраты | Должны делаться в пару действий из админки |
Актуальные тарифы лучше уточнять у самих провайдеров на момент подключения: они периодически меняются и зависят от вида деятельности.
Онлайн-касса и чеки по 54-ФЗ
Если вы принимаете оплату от физических лиц — картой, через СБП или другим электронным способом, — по 54-ФЗ, как правило, нужно сформировать кассовый чек. При онлайн-оплате в приложении чек отправляется покупателю в электронном виде на почту или телефон и одновременно передаётся в налоговую через оператора фискальных данных (ОФД).
Для приложений и интернет-продаж обычно используют облачную кассу: физический аппарат стоит у провайдера, а приложение или сервер отправляет ему данные о покупке. В чеке должны быть корректные реквизиты: наименования товаров или услуг, ставки НДС, признак способа и предмета расчёта.
Есть и исключения — например, расчёты между организациями и ИП без участия физлиц. Нужна ли касса в вашей конкретной схеме, лучше подтвердить у бухгалтера: от этого зависит архитектура платёжного контура.
- Чек при оплате заказа — полный расчёт или предоплата.
- Чек при возврате — его тоже нужно сформировать.
- Чеки при предоплате и последующей доставке — отдельный сценарий, который важно предусмотреть.
- Корректные наименования и ставки НДС — данные часто берутся из 1С или каталога.
Как устроен платёжный контур в приложении
Надёжная оплата — это не только кнопка «Оплатить». За ней стоит цепочка: приложение создаёт заказ на сервере, сервер создаёт платёж у провайдера, клиент подтверждает оплату, провайдер присылает серверу уведомление, сервер меняет статус заказа, формирует чек и сообщает об этом клиенту.
Важно, что статус оплаты подтверждает сервер, а не приложение на телефоне. Так исключаются ситуации, когда заказ считается оплаченным, хотя деньги не поступили, или наоборот.
- Статусы платежа: создан, ожидает подтверждения, оплачен, отменён, возвращён.
- Обработка ошибок: отказ банка, недостаточно средств, прерванная связь.
- Повторная попытка оплаты без создания дубля заказа.
- Возвраты полные и частичные — из админ-панели.
- Уведомления клиенту о результате оплаты: экран, push, письмо с чеком.
- Передача оплаченного заказа в CRM или 1С.
Подписки и регулярные платежи
Для абонементов в фитнес-клуб, подписок на доставку или членства в клубе нужны регулярные списания. Клиент один раз привязывает карту и соглашается на автоплатёж, а дальше сервер списывает оплату по расписанию и формирует чеки.
Здесь особенно важны прозрачность и удобство отмены: клиент должен видеть дату следующего списания и иметь возможность отключить подписку в приложении. Это и требование здравого смысла, и защита от споров и возвратов.
Сколько стоит подключение оплаты и кассы
Платёжный контур мы собираем из модулей. Цены ориентировочные, итог зависит от выбранного провайдера и сценариев (предоплата, возвраты, подписки).
| Модуль | Что входит | Цена, ₽ |
|---|---|---|
| Онлайн-оплата и СБП | Карты, СБП, статусы платежей, возвраты | от 45 000 |
| Онлайн-касса и чеки | Фискализация по 54-ФЗ, электронные чеки | от 30 000 |
| Корзина и заказ | Оформление, состав, статусы | от 40 000 |
| Подписки | Регулярные платежи и управление доступом | от 50 000 |
| Бонусная программа | Начисление и списание баллов | от 45 000 |
Помимо разработки, учитывайте комиссии платёжного сервиса, тариф облачной кассы и договор с ОФД — это регулярные расходы по тарифам провайдеров.
Частые ошибки при приёме платежей в приложении
Первая ошибка — считать заказ оплаченным по сигналу из приложения, а не по уведомлению платёжного сервиса. Это открывает дорогу к «оплаченным» заказам без денег. Вторая — забыть про чеки при возвратах и предоплате: формально касса подключена, но часть операций проходит без фискализации.
Третья — длинная форма оплаты. Каждый лишний экран между корзиной и подтверждением увеличивает вероятность, что клиент передумает. СБП и сохранённые карты заметно сокращают этот путь. Четвёртая — отсутствие понятного сообщения при ошибке: клиент не знает, списались ли деньги, и звонит в поддержку или уходит к конкурентам.
Все эти ситуации мы закладываем в сценарии ещё на этапе проектирования, а затем проверяем в тестовом режиме платёжного сервиса до выхода в магазины.
Что подготовить до подключения оплаты
Подключение платёжного сервиса требует действий с вашей стороны, и часть из них занимает время. Лучше начать параллельно с разработкой: заключить договор с провайдером, пройти проверку, подключить облачную кассу и ОФД, подготовить оферту, политику возвратов и реквизиты для страницы оплаты.
Мы подскажем, какие документы и настройки нужны для выбранного сервиса, и проверим весь контур в тестовом режиме до релиза: успешные оплаты, отказы, возвраты и корректность чеков.