Комментарии
Как реализовать, какие есть варианты и что учесть при разработке
Мобильные платежи и оплата в приложении
Сибирикс
Мобильные платежи и оплата в приложении
Как реализовать, какие есть варианты и что учесть
при разработке
Ещё каких-то два-три года назад пользователи предпочитали выбирать и оплачивать онлайн-покупки с десктопа, но статистика 2018 года говорит, что оплаты с мобилок почти сравнялись с более привычными платежами с ПК, и прогнозируется дальнейший рост этой тенденции. А значит, скоро мобильные платежи станут стандартном отрасли.

Вариантов их реализации несколько: подключить услуги агрегатора или шлюза и довольствоваться адаптивной версией или — создать собственное приложение с продуманным механизмом оплаты (можно быстро и с ограничениями, можно — дольше, дороже и функциональнее). Ниже поговорим подробнее о способах реализации платежей на мобильных устройствах и внутри приложений, а также о том, что стоит учитывать при разработке оплаты с мобилок.
Варианты мобильных платежей
Адаптивный сайт + платёжный агрегатор

Ничего сверхъестественного — заключаете договор с одним из популярных агрегаторов, устанавливаете форму оплаты на сайте. Готово — при покупке с любого устройства всё работает так же, как с десктопа: пользователь выбирает один из способов оплаты, вводит нужные данные, нажимает кнопочку, деньги списываются, а ему приходит электронный чек.


Адаптивный сайт + платёжный шлюз

Принцип работы — такой же, как и у агрегатора: подключаете услугу, интегрируете форму на сайт (чаще всего по API), и пользователи шлют вам денежки — с любого устройства.

Разница между шлюзом и агрегатором в том, что агрегатор аккумулирует у себя денежные средства клиента (имеет статус НКО), а платёжный шлюз — всего лишь посредник между банком и интернет-магазином. Это значит, что комиссия шлюза ниже, раз он берёт плату лишь за свои услуги. Но при этом, интернет-магазину приходится самостоятельно договариваться об условиях с банком-эквайером.

Плюс шлюза помимо более выгодных тарифов ещё и в том, что он не замораживает деньги на счёте (агрегаторы переводят их обычно только спустя 1−3 суток). Минус — быстро подключить такое платежное решение не получится.

Популярные шлюзы: PayPal, PayOnline, Fondy, Assist, ChronoPay. Среди зарубежных можно посмотреть Payline, Authorize, Stripe.
Мобильное приложение с платёжным функционалом

Предыдущие варианты хороши, когда покупателям достаточно вашего сайта. Но постойте, а точно достаточно?! Другая статистика говорит, что приложения захватывают рынок, и ключевые игроки e-commerce давно это поняли — и создали собственные приложухи под айфоны и андроиды.
Кое-что о гибридных и нативных приложениях
Существует две классификации приложений. В первой их делят на нативные и ненативные по способу разработки: по умолчанию нативными считаются приложения, написанные с использованием нативного языка программирования (Java и Kotlin для Андроида, Swift или Objective C для iOS).

Во второй классификации приложения делят на нативные и гибридные по месту хранения основного контента. В нативных основные функции приложения доступны офлайн, в серверной части хранятся, например, только базы данных. В гибридных на сервере хранятся данные и реализуются все функции, не связанные с «железом» (например, каталоги и карточки товаров в приложении интернет-магазина).
Если мы говорим о нативном приложении, там как таковой оплаты быть не может (иначе, какое же оно нативное?!). Что там может быть, так это InAppPurchase — покупки в приложении (какой-то дополнительный функционал, стикеры или какая-то внутриигровая валюта). Это реализуется с помощью SKU маркетплейса (AppStore либо PlayMarket, в зависимости от платформы). В гибридном же приложении может быть как InAppPurchase, так и привычный механизм оплаты.

Алексей
Разработчик
Оплата в мобильном приложении — варианты
WebView

Один из самых популярных способов реализации мобильных платежей — пользователь переходит из интерфейса мобильного приложения в интерфейс платёжной системы.


Плюсы

Просто интегрировать за счёт того, что почти весь контент и функционал встраивается в приложение с вашего сайта (фактически это браузер, встроенный в приложение).


Минусы

Возможна потеря покупателя из-за перехода в непривычный интерфейс («а вдруг мошенники?!») и сложностей с оплатой — у WebView нет доступа к браузерным куки и механизма авторизации для некоторых способов оплаты, поэтому оплатить покупки иногда довольно муторный процесс. Бывает, что привязанные карты слетают или вообще не сохраняются в куки — приходится каждый раз заново вводить данные. А при оплате средствами электронного кошелька ещё и авторизоваться нужно дополнительно.
У Сбербанка сейчас есть клевое платежное решение для сайтов и приложений, которое авторизует пользователя по электронной почте или телефону и может запоминать введенные карты. Соответственно, в WebView вводишь свой телефон, авторизуешься по смс и видишь список привязанных карт к своему аккаунту. На emex.ru оплаты таким образом раньше были сделаны. А значит, в WebView можно «притянуть» этот агрегатор.

Алексей
Разработчик
Диплинк в другое приложение (банка, ApplePay, GooglePay и т. д.)

Диплинк, или универсальная ссылка, — это ссылка, которая в один клик переносит вас на конкретный экран приложения. Пример: вы на сайте с афишей решили купить билет на концерт, кликаете на кнопку «оплатить», и вас переносит в приложение Сбербанк-онлайн. А если такового у вас не установлено — в магазин приложений на страницу Сбербанка для его установки. Или — в браузер, где есть тот же функционал.

Плюсы

Несмотря на переход в другое приложение, пользователю не страшно — приложением Сбербанка и всякими -Pay он сто раз пользовался.

Минусы

Пользователь уходит из текущего приложения и может туда уже не вернуться, плюс диплинки не всегда работают так, как задумано (особенно на разных устройствах). Ещё минус — если диплинк отправит покупателя на страницу приложения, которым он никогда не пользовался, вряд ли тот совершит покупку.
В приложении Avito можно оплачивать несколькими способами: на первых двух скринах видно, что при оплате картой Сбербанка оплата по диплинку в приложении Сбербанка, на вторых двух — внутри приложения с помощью WebView
Популярные сервисы для создания универсальных ссылок — Branch, Deeplink, Firebase.
Интеграция с агрегатором/шлюзом по API

Отличия от процесса оплаты на сайте минимальные — с агрегатором тоже заключается договор на предоставление услуг для приложения, форма для оплаты тоже интегрируется по API. Но в этом случае придётся ручками реализовывать все формы оплаты (данные карты — номер, дата, CVC, емейл или телефон и т. д.). Вот техническая документация, например, от «Яндекс.Кассы», CloudPayments или WalletOne.

Но у интеграции по API есть один жирный минус — сертификат PCI DSS, который обязательно нужно получить, чтобы подключиться к услугам той же «Яндекс.Кассы». Для среднего и малого бизнеса это довольно сложно, но выполнимо, хотя может быть сопряжено с неделями проверок приложения на соответствие нужных параметрам.
Кое-что о гибридных и нативных приложениях
PCI DSS — стандарт безопасности для всех организаций, которые хранят, обрабатывают или передают данные держателей карт и (или) другие аутентификационные данные.
Мобильный SDK

SDK — программная библиотека под iOS и Android, которая упрощает жизнь владельцам и разработчикам приложений. В отличие от API, который больше похож на готовые строительные блоки, функционал SDK шире, сравним с целой мастерской, где полно разных инструментов для создания чего угодно.

Соответствие PCI DSS не требуется: данные банковских карт клиентов не пропускаются через бэкенд-систему интернет-магазина, а значит, и сертификацию проходить не понадобится. За магазин это сделает компания, которая предоставляет SDK-решение — например, «Яндекс.Касса», CloudPayments, PayAnyWay или Тинькофф. Оплата происходит в нативном интерфейсе приложения — пользователю не нужно переходить в веб.
Как это выглядит у CloudPayments и у Яндекс.Кассы
Что учесть при реализации оплаты в приложениях
Ошибки интерфейса

Вы уже поняли, что перекидывания пользователя из приложения в приложение или на подозрительную страницу платежного сервиса — плохая идея. А что ещё им точно не понравится?

  • когда привязанная карта слетает или такой привязки вообще нет;

  • когда клавиатура при вводе закрывает часть полей, а прокрутки нет или пользоваться ей адски неудобно;

  • когда на мелких экранах в форме для ввода данных карты ничего не видно (не у всех 10-й айфон, но разработчики об этом забывают);

  • когда ввод данных разбит на шаги, но при переключении между ними введенные данные не сохраняются (одна из самых бесящих штук);

  • длиннющие выпадающие списки там, где можно набрать 2 цифры вручную (например, для полей с окончанием срока действия карты).


Тренды отрасли

Среди самых популярных способов оплаты — по-прежнему банковские карты, но это не значит, что можно заключить договор на эквайринг с банком и расслабиться. В приложении не помешают Qiwi-кошелёк, Яндекс. Деньги и вот это вот всё.
Статистика Robokassa по покупкам в интернете — источник
Способы удержания покупателей внутри приложения

Даже если процесс оплаты реализован ну очень просто и классно, это ещё не всё — пользователей нужно «ворошить» и возвращать к покупкам снова и снова. Что точно стоит реализовать:

  • систему персональных рекомендаций,

  • разные статусы пользователей и скидки по мере продвижения по шкале «успешности»,

  • push-уведомления (о распродажах, новых коллекциях и особых предложениях).


Наверняка вы в курсе, что приложение — дорогое удовольствие. Но если ваши топовые конкуренты давно им обзавелись, стоит задуматься: возможно, потребителю так действительно удобнее совершать покупки.

Не хотите слишком заморачиваться — подойдёт WebView, хотя с точки зрения UX это не самое лучшее решение (особенно в процессе оплаты покупок). Мобильный SDK — помасштабнее и потребует больше ресурса на этапе создания приложения, но и итоговый результат будет более жизнеспособным и комфортным с точки зрения пользователя. А вообще — всегда есть вариант вручить мобильный терминал курьеру и тратиться лишь на услуги мобильного эквайринга :)