Пользователь дошёл до оплаты в вашем приложении — самый ценный момент всей воронки. И тут его встречает форма ввода 16 цифр карты с крошечными полями, переход в браузер и возврат «в никуда». Каждый лишний шаг здесь стоит заказов: на мобильном экране терпение короче, а конкурент с оплатой в одно касание — на расстоянии свайпа. Оплата в приложении — это не «та же оплата, что на сайте», а отдельная инженерная задача.
Разберём, как сделать оплату в мобильном магазине быстрой и надёжной: СБП с диплинками, сохранённые карты по токенам, кассовые чеки по 54-ФЗ и, главное, честный статус заказа на основе вебхуков. Всё это опирается на серверную логику магазина на 1С-Битрикс, а серверную часть и обмен помогает выстроить автоматизация продаж и склада на 1С.
Коротко
- Оплата в приложении должна минимизировать шаги: СБП через диплинк в банк и сохранённые карты по токену без повторного ввода.
- Магазин не хранит номера карт — только токен на стороне провайдера; полные реквизиты через ваш сервер не проходят.
- Статус «оплачено» ставится по вебхуку от провайдера, а не по нажатию кнопки; обязательна защита от двойных списаний.
- Нужен фискальный чек по 54-ФЗ, а заказ и оплата уходят в 1С тем же обменом, что и заказы с сайта.
Почему оплата в приложении — отдельная задача
На вебе привычна модель «уход на страницу банка и возврат по ссылке». В приложении такая схема ощущается неуклюже: каждый переход в браузер и обратно — это трение и риск потерять пользователя. Мобильный сценарий строится иначе: оплата должна происходить внутри приложения или через быстрый прыжок в банковское приложение и обратно, без ручного ввода данных.
При этом бизнес-логика заказа остаётся общей с сайтом: корзина, скидки, статусы и обмен с учётной системой живут на сервере в модуле «Интернет-магазин». Приложение — это новая витрина оплаты поверх той же серверной логики, а не отдельный магазин. Такое разделение и делает проект поддерживаемым.
Способы оплаты в мобильном магазине
Набор способов оплаты в приложении обычно короче и «мобильнее», чем на сайте:
- СБП. Оплата по Системе быстрых платежей через диплинк в банковское приложение — быстро и без карты.
- Сохранённая карта. Повторная оплата по токену прошлой карты в одно-два касания.
- Новая карта. Ввод карты через защищённую форму провайдера с возможностью сохранить её.
- Оплата при получении. Наличными или картой курьеру — без онлайн-платежа, но со своими правилами учёта.
Приоритет в мобильном сценарии — СБП и сохранённые карты: они дают самый короткий путь к оплате.
Оплата по СБП и диплинки
СБП в приложении работает через связку с платёжным провайдером и диплинки. Приложение запрашивает у провайдера платёжную ссылку по заказу и открывает банковское приложение пользователя, где тот подтверждает платёж. Дальше — ключевой момент: результат приложение узнаёт не от того, что пользователь вернулся, а от вебхука провайдера.
- Создание платежа. Приложение отправляет заказ на сервер, сервер создаёт платёж у провайдера и получает СБП-ссылку.
- Переход в банк. Приложение открывает диплинк, банк подтверждает оплату у пользователя.
- Возврат. Пользователь возвращается в магазин на экран ожидания.
- Подтверждение. Сервер получает вебхук об успехе и обновляет статус заказа, приложение показывает результат.
Сохранённые карты и токены
Сохранённая карта — это не номер карты в вашей базе, а токен, который выдаёт платёжный провайдер. При первой оплате пользователь вводит карту в защищённой форме провайдера, соглашается сохранить её, и вам возвращается токен, привязанный к пользователю. При следующей покупке оплата идёт по токену — без повторного ввода реквизитов.
Кассовые чеки по 54-ФЗ
Оплата в приложении — это эквайринговое поступление, поэтому по 54-ФЗ на него нужен фискальный чек. Чек обычно пробивает облачная касса, подключённая к платёжному или фискальному провайдеру: после успешной оплаты формируется чек, а его реквизиты возвращаются в заказ и покупателю.
| Элемент чека | Что важно |
|---|---|
| Позиции | Совпадают с составом заказа, корректные наименования |
| Ставка НДС | Соответствует товару, берётся из карточки/1С |
| Признак предмета расчёта | Товар, услуга, предоплата — по типу позиции |
| Контакт покупателя | Email или телефон для отправки чека |
| Момент расчёта | Полная оплата или предоплата |
Ставки НДС и признаки предмета расчёта удобно вести на стороне учёта и передавать на сайт обменом, чтобы касса пробивала корректные чеки без ручного вмешательства.
Вебхуки и достоверный статус заказа
Самое частое и дорогое заблуждение — считать заказ оплаченным сразу после нажатия «Оплатить». Нажатие лишь запускает платёж; успех подтверждается асинхронно, вебхуком от провайдера. Именно вебхук — единственный достоверный источник статуса. Пользователь может не вернуться в приложение, потерять сеть, отменить оплату в банке — а вебхук всё равно расскажет серверу правду.
Как построить приём вебхуков безопасно — с проверкой подписи, защитой эндпоинта и повторной обработкой — мы разбирали в статье про REST, вебхуки и безопасность в Битрикс. Там же — почему нельзя доверять данным, пришедшим «от клиента», и как отличать настоящий вызов провайдера от подделки.
Идемпотентность и защита от двойных списаний
В мобильной среде связь рвётся, пользователь жмёт кнопку повторно, вебхук приходит дважды — всё это норма, и система должна её переживать без последствий. Ключевое свойство — идемпотентность: повторная обработка одного и того же платежа не должна ни списывать деньги дважды, ни пробивать второй чек, ни создавать дубль заказа.
- Уникальный ключ платежа. Один заказ — один платёжный идентификатор; повтор с тем же ключом игнорируется.
- Блокировка кнопки. После нажатия «Оплатить» повторная попытка запрещена до ответа сервера.
- Дедупликация вебхуков. Повторный вебхук по тому же платежу не меняет статус ещё раз.
- Единичный чек. Чек пробивается один раз на успешную оплату, даже если подтверждение пришло несколько раз.
UX экрана оплаты и ожидания
Пока платёж обрабатывается, пользователь не должен теряться в догадках. Хороший экран ожидания честно говорит «Проверяем оплату», не показывает повторную кнопку оплаты и сам обновляет статус — опросом сервера или по push-уведомлению. Когда приходит подтверждение, экран сменяется на успех с номером заказа и чеком.
Если ответ задерживается, скажите об этом прямо: «Оплата обрабатывается, мы пришлём уведомление». Это снимает тревогу и, что важнее, предотвращает повторные попытки оплаты, ведущие к двойным списаниям и путанице в заказах.
Связь приложения с 1С-Битрикс и API
Приложение общается с магазином через API: получает каталог, создаёт заказ, инициирует платёж и узнаёт статусы. Серверная логика остаётся в 1С-Битрикс — это гарантирует, что заказы из приложения и с сайта идут единым потоком и попадают в учёт одинаково. Проектировать такой API и его безопасность лучше заранее.
Подходы к построению серверной части на современном ядре мы описывали в материале про D7 и ORM в Битрикс, а вопросы стабильного развёртывания обновлений бэкенда — в статье про CI/CD и деплой в Битрикс. Платёжный контур — та часть, где выкатывать изменения нужно особенно аккуратно.
Передача оплаты и чеков в 1С
Факт оплаты, реквизиты чека и статус заказа должны дойти до учётной системы без дублей и потерь. Обычно заказ уходит в 1С обменом, а статус оплаты обновляется отдельно, когда приходит подтверждение от провайдера. Важно согласовать, что именно и в какой момент передаётся, чтобы в учёте не появлялись «оплаченные без денег» или задвоенные заказы.
Навести порядок в этом потоке — от статусов оплаты до выгрузки чеков — помогает услуга автоматизации продаж и склада на 1С. Если обмен уже работает нестабильно, начать стоит с аудита и оптимизации 1С, иначе платежи будут «теряться» на стыке систем.
Безопасность платёжного контура
Платёжный контур — самая чувствительная часть приложения, и к нему предъявляют повышенные требования:
- Никаких карт на своём сервере. Реквизиты вводятся только в форме провайдера, у вас — токен.
- Проверка подписи вебхуков. Каждый вызов провайдера проверяется, чтобы исключить подделку.
- Суммы считает сервер. Цену и итог заказа определяет бэкенд, а не то, что прислало приложение.
- Шифрованный канал. Весь обмен — по защищённому соединению, без исключений.
- Аккуратный деплой. Изменения в оплате выкатываются с проверкой, чтобы не сломать приём платежей.
Частые ошибки
- Статус по нажатию кнопки. Заказ помечен оплаченным до подтверждения — в итоге «оплаченные без денег».
- Нет идемпотентности. Повторный вебхук или клик приводит к двойному списанию и второму чеку.
- Хранение карт у себя. Реквизиты проходят через свой сервер — лишний риск и нарушение требований.
- Забыли про чек. Оплата прошла, а фискальный чек по 54-ФЗ не пробит.
- Суммы считает клиент. Итог заказа берётся из приложения, а не с сервера, — путь к подмене цены.
- Нет экрана ожидания. Пользователь не понимает, прошла ли оплата, и жмёт «оплатить» снова.
Чек-лист внедрения
- СБП через диплинк. Оплата открывает банковское приложение и возвращает пользователя на экран ожидания.
- Сохранённые карты. Повторная оплата по токену, реквизиты хранит провайдер, не вы.
- Статус по вебхуку. Заказ помечается оплаченным только после подтверждения провайдера.
- Идемпотентность. Повторные клики и вебхуки не приводят к двойным списаниям и чекам.
- Чек по 54-ФЗ. Касса пробивает корректный чек с верными ставками НДС и признаками расчёта.
- Экран ожидания. Понятный статус оплаты без кнопки повторной оплаты.
- Единый поток в 1С. Заказы из приложения и с сайта попадают в учёт одинаково, без дублей.
- Безопасность. Суммы считает сервер, вебхуки проверяются, канал шифрован.
Вывод
Оплата в мобильном приложении — это не перенос вебовой формы на телефон, а отдельный сценарий, где выигрывает самый короткий путь к деньгам: СБП через диплинк и сохранённые карты по токену. Но скорость витрины бессмысленна без надёжного бэкенда: статус заказа определяется вебхуком, а не нажатием, система идемпотентна, а чек по 54-ФЗ пробивается ровно один раз.
Держите серверную логику и обмен на стороне 1С-Битрикс, не храните карты у себя и передавайте оплату в учёт единым потоком с сайтом. Тогда оплата в приложении станет самым сильным, а не самым слабым звеном вашей мобильной коммерции.
