Прием платежей в мобильном приложении: СБП, карты, чеки и возвраты
Платежи в приложении — это не только кнопка оплаты. Нужно продумать провайдера, чеки, возвраты, статусы заказов, поддержку и админ-панель.
Чтобы принимать платежи в мобильном приложении для российского рынка, нужно выбрать платежного провайдера, понять сценарии оплаты, подключить карты или СБП, настроить чеки, статусы платежей, возвраты, уведомления, безопасность и админ-панель. Для цифровых подписок и контента действуют правила магазинов приложений, а для товаров, услуг, записей и заказов чаще используются внешние платежные провайдеры.
Подготовьте запрос на оценку приложения через практичные вопросы
Отметьте нужные функции: аккаунты, корзину, платежи, админку, интеграции, хранение данных и запуск.
Главные выводы
- Платежи нужно проектировать вместе с заказом, чеком, возвратом, поддержкой и админ-панелью.
- СБП, карты и платежные ссылки могут закрывать разные сценарии: быстрая оплата, бронь, заказ, доплата, возврат.
- Для цифрового контента и подписок в App Store и Google Play часто применяются правила покупок внутри приложения.
- Для физических товаров и услуг обычно используются внешние платежные провайдеры, но правила конкретного магазина все равно нужно проверить.
- Самая частая ошибка — не описать, что делать при неуспешной, зависшей или частично возвращенной оплате.
Какие платежные сценарии бывают
| Сценарий | Где встречается | Что нужно продумать |
|---|---|---|
| Разовая оплата | интернет-магазин, запись, доставка, консультация | заказ, статус, чек, отмена, возврат |
| Предоплата или депозит | салон, клиника, бронирование, курс | правила отмены, перенос, частичный возврат |
| Доплата | доставка, кастомный заказ, услуги | изменение суммы, уведомление, подтверждение |
| Подписка | обучение, контент, сервисы, клубы | продление, доступ, отмена, восстановление |
| Платеж по QR или ссылке | офлайн-точка, курьер, менеджер | связь платежа с заказом и админ-панелью |
| Возврат | любые продажи | кто может вернуть, сколько, как фиксируется причина |
СБП, карты и платежные провайдеры
СБП удобна для российских пользователей, особенно когда нужно быстро оплатить заказ или услугу через банковское приложение. На стороне продукта важно не только показать QR-код или кнопку, но и правильно связать платеж с заказом: пользователь оплатил, провайдер прислал подтверждение, серверная часть обновила статус, приложение показало результат.
Платежные провайдеры вроде ЮKassa или CloudPayments помогают не писать весь платежный контур самостоятельно. Например, в документации ЮKassa есть отдельные материалы про мобильные SDK, а у CloudPayments есть документация для интеграций. Для СБП полезно смотреть официальные материалы НСПК.
Выбор провайдера должен учитывать не только комиссию. Смотрите на способы оплаты, чеки, возвраты, подписки, поддержку мобильных сценариев, уведомления о статусах, тестовый режим, документацию и то, как данные будут приходить в вашу админ-панель.
Чеки, 54-ФЗ и бухгалтерия
Для многих российских бизнесов прием платежей связан с онлайн-кассой и фискальными чеками. Это не та часть, которую стоит решать после дизайна. Если чек должен отправляться автоматически, провайдер, касса, номенклатура, email или телефон покупателя и возвраты должны быть учтены заранее.
Проверьте с бухгалтером и платежным провайдером:
- кто формирует чек;
- какие товары или услуги попадают в чек;
- что происходит при частичном возврате;
- нужен ли чек при предоплате;
- как обрабатываются скидки, бонусы и промокоды;
- где менеджер видит историю платежей и возвратов.
Если приложение продает курсы, консультации, товары, бронирования или доставки, платежная логика должна совпадать с реальным учетом бизнеса.
Внешние платежи или покупки внутри приложения
Для физических товаров и услуг мобильное приложение часто использует внешние платежные провайдеры. Для цифрового контента, подписок, премиум-функций и доступа внутри приложения нужно отдельно проверять правила App Store и Google Play. В некоторых случаях магазины требуют использовать покупки внутри приложения.
Это важно до оценки бюджета. Подписка через магазин — это одна логика доступа, продления и отмены. Оплата через внешнего провайдера — другая логика, другие чеки, другие возвраты и другая поддержка.
Если вы продаете образовательный курс, нужно понять, что именно покупает пользователь: доступ к цифровому контенту внутри приложения, офлайн-услугу, консультацию, мероприятие или смешанный продукт. От этого зависит техническая и юридическая схема.
Есть идея приложения и нужен трезвый следующий шаг?
Разобрать идею приложенияЧто должна видеть админ-панель
Хорошая админ-панель для платежей отвечает не только на вопрос "оплачено или нет". Команде нужны статусы и действия.
Минимально полезный набор:
- список заказов и платежей;
- способ оплаты;
- сумма и валюта;
- статус: создан, ожидает оплаты, оплачен, ошибка, отменен, возвращен;
- номер чека или ссылка на чек;
- причина возврата;
- ручная пометка поддержки;
- журнал изменений по спорным ситуациям.
Если поддержки нет, платежные ошибки превращаются в хаос. Пользователь уверен, что оплатил. Банк списал деньги. Заказ в приложении не изменил статус. Без админ-панели менеджер не сможет быстро понять, что произошло.
Как платежи влияют на стоимость
В Appfyl простые MVP-проекты обычно попадают в диапазон 1-1,5 млн рублей. Если платежи простые: один провайдер, разовая оплата, понятный заказ и базовые возвраты, это можно держать в рамках первой версии.
Оценка растет, когда появляются подписки, бонусы, частичные возвраты, несколько провайдеров, сложные чеки, выплаты продавцам или провайдерам, маркетплейс, разные роли, промокоды, рассрочка, платежи в разных странах или подробная админ-панель. Хорошие средние продукты часто попадают в 1,5-3,5 млн рублей, а крупные платежные системы с несколькими ролями могут доходить до 3,5-6 млн рублей.
Чтобы не раздувать бюджет, начинайте с одного основного сценария оплаты. Например: пользователь выбирает услугу, оплачивает депозит, получает подтверждение, а менеджер видит запись и статус платежа. Все сложные бонусы и частичные возвраты можно добавить позже, если бизнес-модель подтверждается.
Как Appfyl подходит к платежам
Мы начинаем не с выбора SDK, а с платежного пути пользователя. Что покупается? Когда деньги списываются? Что считается успешной оплатой? Когда пользователь получает доступ? Что видит поддержка? Как оформляется возврат?
После этого выбирается провайдер, проектируется серверная часть, события аналитики и админ-панель. Такой подход помогает избежать ситуации, когда в интерфейсе платеж выглядит красиво, но менеджеры вручную ищут оплаты в разных кабинетах.
Для первичной оценки можно заполнить бриф Appfyl и отметить платежи, подписки, возвраты, админ-панель и интеграции.
Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.
Используйте эти выводы, чтобы собрать реалистичную первую версию.
Оценить MVPПревратите исследование в план запуска
Appfyl поможет превратить идею в понятный план приложения, список функций первой версии и план первых работ.
Обсудить план приложенияПолезные ссылки
Частые вопросы
Да, обычно через платежного провайдера или банк, который поддерживает сценарии СБП. Важно связать статус платежа с заказом на серверной стороне, а не полагаться только на экран пользователя.
Сложность зависит от провайдера и сценария. Для разработки чаще важны не сами карты или СБП, а статусы, ошибки, чеки, возвраты, поддержка и админ-панель.
Обычно нет. Платежные данные должен обрабатывать сертифицированный провайдер. Приложению чаще нужны статус платежа, сумма, заказ, чек и безопасная связь с серверной частью.
Для тестовой версии иногда можно, но для реального бизнеса админ-панель быстро становится необходимой: нужно видеть оплаты, ошибки, возвраты и спорные ситуации.
Выберите один основной сценарий, который закрывает бизнес-модель. Для записи это может быть депозит, для магазина — разовая оплата заказа, для обучения — покупка курса или подписка.