Покупатель не может оплатить в приложении: чем заменить Apple Pay ритейлу
После ухода Apple Pay и Google Pay из России в 2022 году ритейл переходит на приём оплаты через СБП по QR-коду и диплинку, MirPay, SberPay и сохранённую карту с токенизацией внутри самого мобильного приложения. Эти способы закрывают тот же сценарий бесконтактной оплаты в одно касание и не зависят от западных сервисов.
Почему возникает разрыв на экране оплаты после ухода Apple Pay и Google Pay
Покупатель в пятницу вечером докладывает в корзину мобильного приложения строительного магазина цемент, шпаклёвку и малярный скотч. Доходит до экрана оплаты, привычно тянется к кнопке с яблоком или похожим значком Google — но кнопки нет. Google Pay перестал принимать российские карты ещё в 2022 году, Apple Pay — тогда же. Место, где раньше был удобный способ заплатить, теперь пустое.
Дальше развилка. Если в приложении заранее продумана замена, покупатель платит СБП или сохранённой картой за несколько секунд и не замечает разницы. Если замены нет, человек закрывает приложение и ищет тот же товар там, где оплата работает привычно — поэтому корзина с наполненными позициями превращается в ничто, а бюджет, потраченный на то, чтобы привести этого покупателя в приложение, — на рекламу, на SEO, на push-уведомление, — уходит впустую.
В поддержку интернет-магазинов такой сценарий приходит регулярно одним и тем же вопросом в чате: «а как у вас оплатить, если Apple Pay не работает». Каждое такое сообщение — уже покупатель, который не бросил корзину сразу, а попытался разобраться сам. Но большая часть людей вопрос в поддержку не пишет, а просто закрывает приложение — и эту часть воронки видно только по разнице между количеством открытых корзин и количеством оплаченных заказов.
Ставка здесь не абстрактная. Каждый экран оплаты без рабочей кнопки — это заказ, который состоялся бы в браузере или у другого продавца, но не в вашем приложении. Для розницы с сотнями заказов в день это ежедневная утечка, которую не видно в общей воронке: она происходит на последнем шаге, где аналитика обычно перестаёт объяснять причину отказа.
Как исправить приём платежей: какие способы реально работают в мобильном приложении
Рабочих альтернатив у российского ритейла четыре, и они закрывают разные сценарии покупателя — от быстрой оплаты в один жест до безопасного хранения карты для повторных заказов.
СБП: оплата по QR-коду и диплинку
Система быстрых платежей — самый универсальный вариант: покупатель сканирует QR-код или переходит по диплинку в приложение своего банка, подтверждает платёж и возвращается в ваше приложение. Подключение идёт через банк-эквайер, обычно требует договора и доработки на стороне приложения — формирования QR-кода и обработки статуса оплаты через вебхук.
MirPay и SberPay: бесконтактный аналог NFC-кошелька
MirPay ближе всего к привычному сценарию Google Pay — покупатель просто прикладывает телефон к терминалу, только карта должна быть выпущена платёжной системой «Мир», а телефон должен работать на Android. SberPay встроен в приложение Сбербанка и в кнопку оплаты на сайтах и в приложениях партнёров — для покупателя это оплата в два касания без ввода номера карты.
Сохранённая карта и токенизация: оплата в одно касание
Покупатель вводит номер карты один раз, приложение через SDK эквайера сохраняет не сам номер, а токен, и дальше оплата занимает одно нажатие. Это самый привычный сценарий для повторных покупок, но требует, чтобы хранение и передача платёжных данных соответствовали требованиям 152-ФЗ и стандарту PCI DSS — этим обычно занимается сам банк-эквайер, а не разработчик приложения.
Как выбрать набор способов под свой ассортимент
Магазину с частыми повторными покупками — доставке продуктов, аптеке, товарам для дома — токенизация карты окупается быстрее всего: покупатель платит один раз внимательно, а дальше нажимает одну кнопку. Разовым и крупным покупкам, вроде мебели или стройматериалов, важнее СБП: пользователь может открыть банк-приложение с большим лимитом, не думая о лимите привязанной карты. MirPay и SberPay стоит подключать вторым слоем — они закрывают тех, кто просто привык платить телефоном и не станет разбираться в альтернативах.
| Способ оплаты | Что делает покупатель | Подключение для бизнеса | Комиссия | Ограничение |
|---|---|---|---|---|
| СБП (QR / диплинк) | сканирует QR или жмёт кнопку своего банка | договор с банком-эквайером, доработка приёма QR в приложении | ниже, чем по картам | нужен стабильный интернет у покупателя |
| MirPay | прикладывает телефон к терминалу | от бизнеса действий почти не требует | как у обычной карты «Мир» | только карты «Мир» и Android |
| SberPay | подтверждает оплату в приложении Сбербанка | подключение эквайринга Сбербанка | стандартная ставка эквайринга | нужно приложение Сбербанка у покупателя |
| Сохранённая карта / токенизация | вводит карту один раз, дальше платит в одно касание | интеграция SDK эквайера в приложение | стандартная ставка эквайринга | требования 152-ФЗ и PCI DSS к хранению токена |
| Оплата при получении | платит курьеру наличными или картой | терминал эквайринга у курьера или наличный расчёт | комиссия терминала или без комиссии | не подходит для предоплаты и удалённых заказов |
Что делать, если ошибка оплаты повторяется у одного и того же покупателя
Один сорванный платёж — случайность: банк покупателя завис, интернет моргнул. Повторный отказ у одного и того же человека почти всегда упирается в одно из трёх мест, и каждое проверяется отдельно.
Первое — таймаут QR-кода СБП: если код действует пять минут, а покупатель отвлёкся на звонок, приложение должно не показывать бесконечный спиннер, а явно предложить сгенерировать новый код или переключиться на другой способ оплаты. Второе — вебхук от эквайера не долетает до сервера приложения, и статус заказа зависает в «оплата обрабатывается», хотя деньги уже списаны — это лечится очередью повторных запросов статуса, а не единственной попыткой получить вебхук. Третье — токенизированная карта: банк отклоняет повторное списание из соображений антифрода, и здесь помогает только явный текст ошибки от эквайера вместо общего «оплата не прошла», чтобы покупатель понимал, звонить в банк или пробовать другую карту.
Практически всегда это решается на уровне логов: если система фиксирует не только «оплата не прошла», а конкретный код ответа от эквайера — «недостаточно средств», «отклонено банком-эмитентом», «таймаут» — поддержка перестаёт гадать и сразу видит, куда направить покупателя. Без такого лога каждая повторная жалоба превращается в отдельное расследование, а разработчик тратит время на переписку вместо исправления.
Если разбор по этим трём пунктам ничего не даёт, а жалобы продолжают идти именно с определённых моделей телефонов или версий приложения, вероятная причина — устаревший SDK эквайера или конфликт с сертификатом безопасности на старой версии Android. Это уже вопрос к тому, кто вёл разработку: обновление платёжного модуля не входит в разовую доработку и требует отдельного тестового цикла на реальных, а не эмулированных устройствах.
Как предотвратить потерю заказов из-за неудобной оплаты
Дешевле один раз заложить в приложение несколько работающих способов оплаты, чем потом разбирать, почему конверсия на последнем шаге просела и никто не может сказать, с какого именно дня это началось.
Отдельно стоит закладывать проверку после каждого крупного обновления мобильных ОС — Apple и Google меняют политику работы с фоновыми процессами и уведомлениями почти в каждом крупном релизе, и платёжный SDK может неожиданно перестать корректно возвращать статус оплаты именно на новой версии системы, а не из-за ошибки в вашем коде.
- ✓не завязывать оплату на один способ — если недоступна СБП, у покупателя должна остаться хотя бы сохранённая карта;
- ✓тестировать оплату на реальных картах «Мир» и реальных устройствах, а не только в песочнице эквайера;
- ✓синхронизировать статус оплаты с учётной системой в реальном времени, чтобы склад не отгружал заказ, который по факту не оплачен — здесь помогает интеграция приложения с 1С, где статус платежа сразу попадает в документ реализации;
- ✓смотреть конверсию по каждому способу оплаты отдельно, а не по общей воронке — падение именно на SberPay видно только так.
Сколько стоит внедрить приём платежей без Apple Pay и Google Pay в приложении
Если мобильного приложения пока нет, разработку розничного приложения с каталогом, личным кабинетом и оплатой заказывают от 500 000 ₽ — итоговая цифра зависит от количества способов оплаты и от того, нужна ли интеграция с учётной системой. Срок работ обычно занимает от нескольких недель для добавления ещё одного способа оплаты в уже существующее приложение до нескольких месяцев для приложения с нуля.
Для розницы, которая уже ведёт товар и заказы в 1С, разумно сразу проектировать B2B-приложение с 1С — тогда оплата, остатки и статус заказа живут в одном контуре, а не сверяются вручную. Компаниям, которым нужен быстрый пилот без полной нативной разработки, стоит посмотреть в сторону 1С:Мобильной платформы — она позволяет собрать рабочий каталог с оплатой быстрее, чем нативное приложение с нуля.
Точный список способов оплаты, сроки и стоимость по конкретному сценарию — в тарифах на разработку, а общий процесс работы над мобильным приложением расписан на странице разработки мобильных приложений.
❓ Частые вопросы
Можно ли просто оставить в приложении кнопку Apple Pay, если часть покупателей пользуется VPN?
Технически кнопка Apple Pay для российских карт не активируется — Apple отключила поддержку в 2022 году независимо от VPN покупателя. VPN обходит географические ограничения контента, но не восстанавливает работу платёжного протокола. Единственный рабочий путь — подключить СБП, MirPay, SberPay или токенизированную карту.
Нужна ли отдельная лицензия, чтобы принимать оплату через СБП в своём приложении?
Отдельная лицензия не нужна — приём СБП оформляется через банк-эквайер, с которым магазин уже работает или подключается заново. Банк выдаёт технические реквизиты для формирования QR-кода и диплинка, а всю регуляторную часть перед Банком России берёт на себя эквайер.
Сколько времени занимает добавить приём оплаты через MirPay в уже готовое приложение?
Если приложение уже подключено к эквайрингу, добавление MirPay обычно занимает от пары недель — большую часть работы делает SDK банка-эквайера, а разработчику нужно встроить кнопку и обработать статус платежа. Полный аудит текущей платёжной логики иногда увеличивает срок.
Что делать, если приложение уже есть, но оплата в нём реализована криво и покупатели жалуются?
Сначала стоит собрать логи отказов по каждому способу оплаты за пару недель — это покажет, теряются ли деньги на таймауте СБП, на вебхуках или на отклонённых токенах. По логам понятно, чинить существующую логику или переписывать платёжный модуль заново.
Дороже ли подключить сразу несколько способов оплаты, чем один?
Дороже на этапе разработки — каждый способ требует своей интеграции с SDK эквайера и своей ветки обработки статуса. Но один способ означает риск потерять заказ, если у конкретного покупателя он не сработает, поэтому для розницы обычно окупается набор из двух-трёх вариантов сразу.
Или позвоните: +7 906 045-28-27 — в рабочее время с 9:00 до 19:00
Остались вопросы? Нужна помощь?
Менеджеры компании с радостью ответят на ваши вопросы, произведут расчет стоимости услуг и подготовят индивидуальное коммерческое предложение.
Бесплатная консультация

