Мобильные платежи стремительно набирают популярность, вытесняя традиционные десктопные методы. Объемы мобильных платежей практически сравнялись с традиционными, и прогнозируется их дальнейший рост. Мобильные приложения становятся отраслевым стандартом, поэтому важно понимать, как правильно реализовать платежный функционал в мобильном приложении.
Варианты реализации мобильных платежей
Существует несколько способов реализации мобильных платежей. Рассмотрим каждый из них:
Адаптивный сайт + платежный агрегатор
Это наиболее простой способ. Заключив договор с агрегатором (список агрегаторов см. в дополнительных материалах), вы устанавливаете форму оплаты на сайте. Оплата с любого устройства происходит аналогично десктопной версии: пользователь выбирает способ оплаты, вводит данные, и деньги списываются.
Адаптивный сайт + платежный шлюз
Принцип работы схож с агрегатором: подключается услуга, интегрируется форма на сайт (чаще всего через API). Разница в том, что агрегатор аккумулирует средства клиента, а шлюз — посредник между банком и интернет-магазином. Комиссия шлюза ниже, но интернет-магазину потребуется самостоятельно договариваться с банком-эквайером. Популярные шлюзы: PayPal, PayOnline, Фонд, Assist, ChronoPay, Stripe, Braintree.
Недостаток шлюза — более сложная интеграция, чем у агрегатора.
Мобильное приложение с платежным функционалом
Этот вариант актуален, когда сайт не удовлетворяет потребности покупателей. Рынок мобильных приложений активно развивается, и многие компании создают собственные приложения для iOS и Android.
Типы мобильных приложений
Существуют два подхода к разработке мобильных приложений:
- Нативные приложения: написаны на нативных языках программирования (Java/Kotlin для Android, Swift/Objective-C для iOS). Основной функционал доступен оффлайн, на сервере хранятся только базы данных.
- Гибридные приложения: данные и функции (кроме связанных с железом) хранятся на сервере.
В гибридных приложениях возможны как in-app purchases, так и стандартные механизмы оплаты.
Варианты оплаты в мобильном приложении
Рассмотрим варианты оплаты внутри мобильного приложения:
- Переход в интерфейс платежной системы: простая интеграция, но возможна потеря покупателей из-за перехода в непривычный интерфейс и сложности с оплатой (отсутствие доступа к cookies и механизмам авторизации).
- Платёжные решения Сбербанка: авторизация по электронной почте или телефону, запоминание введенных карт.
- Deep linking/универсальные ссылки: перевод пользователя в конкретный раздел приложения (например, в приложение Сбербанк Онлайн для оплаты билета). Простота, но пользователь может не вернуться в исходное приложение.
- Интеграция с агрегатором или шлюзом через API: распространенная и рекомендуемая практика. Требует ручной реализации всех форматов оплаты и получения сертификата PCI DSS для работы с платежными данными.
- Мобильные SDK: программные библиотеки, упрощающие работу разработчиков. Данные банковских карт не проходят через бэкенд интернет-магазина, поэтому сертификация PCI DSS не требуется. Примеры: Яндекс.Касса, CloudPayments, PayMeWay, Тинькофф.
Ошибки при реализации оплаты в приложениях
При разработке системы оплаты следует избегать следующих ошибок интерфейса:
- Переход пользователя в другие приложения или на подозрительные страницы.
- Проблемы с привязкой карт.
- Неудобная клавиатура, перекрывающая поля ввода.
- Невидимые поля на маленьких экранах.
- Потеря данных при переходе между шагами ввода.
- Длинные выпадающие списки.
Тренды и удержание покупателей
Популярные способы оплаты: банковские карты, электронные кошельки (Qiwi, Яндекс.Деньги). Для удержания пользователей:
- Персонализация.
- Система статусов и скидок.
- Push-уведомления о распродажах и акциях.
Выбор между Web View, мобильным SDK или мобильным терминалом для курьеров зависит от ресурсов и требований. Мобильные SDK более ресурсоемки на этапе разработки, но обеспечивают лучший пользовательский опыт.