прием платежей в мобильном приложении
Как принимать платежи в мобильном приложении: токенизация, NFC, оптическое сканирование и другие плюшки в одном SDK
Кейс 1. Привязываем карту клиента к бэкенду для регулярных списаний или платежей в 1 клик.
Тут важно понимать, что если ваш бэкенд не сертифицирован по PCI DSS, то номер карты и ее срок действия вы не можете хранить в своей базе данных. Поэтому, прежде чем привязать идентификатор карты к аккаунту клиента, необходимо сначала карту токенизировать. Для этого вам необходимо осуществить через мобильное приложение первый платеж с участием клиента, и желательно с 3D-Secure, заблокировав на карте небольшую сумму, например 1 единицу валюты. 3D-secure в данном случае необходим в первую очередь, чтобы обезопасить себя, как торговую точку, от финансовых претензий (чарджбеков) по будущим рекурентным списаниям, а во вторую очередь — чтобы улучшить конверсию, так как например по картам Сбербанка в России и Приватбанка в Украине в большинстве случаев транзакция без 3D-Secure не пройдет.
Итак, чтобы получить токен карты, необходимо передать параметры requiredRecToken и verification (более подробно как создать мобильное приложение смотрите в статье, ссылку на которую я указал в начале, а также в коде демо-приложения на github):
Параметр requiredRecToken требует возвратить токен карты при успешной авторизации карты, а verification — что средства с карты списывать не нужно, а достаточно их заблокировать, а потом вернуть (платежный шлюз возвращает их автоматически).
В ответ платежный шлюз вернет параметры recToken — токен карты, recTokenLifeTime — срок действия токена (по сути срок действия карты) и maskedCard — маскированный номер карты, который необходимо привязать в бекенде к токену для дальнейшего отображения клиенту при выборе способа оплаты.
Теперь, имея токен карты вы можете в любой момент по требованию клиента или при наступлении срока оплаты, вызвать метод списания по токену через server-to-server API и списать необходимую сумму.
Подводные камни:
По нашей статистике у довольно значимой части картодержателей не получается оплатить через 3DSecure на мобильном устройстве по ряду причин, от него и шлюза не зависящих:
— может не приходить SMS, или пользователь переключаясь между SMS-приложением и вашим, потерял форму с вводом пароля 3D-Secure, так как она открывается в WebView или системном браузере
— полезла верстка 3D-Secure страницы банка на смартфоне или планшете (банки очень редко адаптируют такие страницы)
— веб-сервер банка отключил поддержку небезопасного протокола TSL 1.0, что делает 3D-Secure недоступным для Android версии Пример демо-приложения для использования NFC
Встраиваем прием платежей в мобильное приложение, или почему можно забыть про PCI DSS и PA DSS
А нужен ли PCI DSS?
Рано или поздно большинство владельцев и разработчиков интернет-магазинов и мобильных приложений, принимающих платежи в онлайне, задаются вопросом: «должен ли мой проект соответствовать требованиям стандартов PCI DSS?».
PCI DSS — это стандарт безопасности, который применяется для всех организаций сферы обработки платежных карт: торговых точек, процессинговых центров, финансовых учреждений и поставщиков услуг, а также других организаций, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.
Стандарт PA-DSS распространяется на поставщиков приложений и иных разработчиков приложений, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.
С веб-сайтом все довольно просто: при интеграции достаточно воспользоваться техническим решением, которое перенаправляет плательщика на форму ввода данных карты, расположенной на сайте PCI DSS сертифицированного платежного шлюза или загружает эту страницу во фрейме также с сертифицированного сайта. В этом случае торговец не подпадает под действия стандарта безопасности, так данные карты не хранятся и не передаются через его сервера, а к фрейму платежного шлюза сайт торговца не имеет доступа в силу политик безопасности web-браузеров.
С мобильным приложением все немного сложнее. Существует популярное заблуждение, что если мобильное приложение запрашивает данные карты, то оно автоматом подпадает под действие стандарта PCI DSS. Но, на самом деле, организация, разрабатывающая стандарты PCI DSS (PCI SSC — Payment Card Industry Security Standards Council) до сих пор не выпустила отдельных требований стандартов для мобильных приложений. А это значит, что стандарт по-прежнему несет не обязательный, а рекомендательный характер для самой популярной категории мобильных приложений, а именно:
Категория 3. Платежные приложения, работающие на каких-либо бытовых карманных устройствах (например, смартфонах, планшетах, КПК), функционал которых ограничен не только принятием платежей.
Но поскольку мобильное приложение не может существовать без бэкенда (серверной стороны, обслуживающей биллинг и основную бизнес-логику), то, так или иначе, информацию, необходимую для обработки платежа оно передает на сервер торговца. Тут и кроется нюанс — чтобы намеренно или случайно разработчик мобильного приложения не запрограммировал приложение на передачу данных платежных карт на какой-нибудь несертифицированный сервер, платежное мобильное SDK должно сделать данные карты недоступными для считывания. Такое ограничение обеспечивает отмену действия требований PCI DSS:
PCI DSS может не распространяться непосредственно на поставщиков платежных приложений, если они не хранят, не обрабатывают или не передают данные держателей карт, или не имеют доступа к данным держателей карт своих клиентов.
Рассмотрим как это реализовано в мобильном SDK платежного сервиса Fondy на примере Android-решения (есть также и iOS SDK).
Решение заключается в том, чтобы данные карты вводились в View, созданным библиотекой SDK, а мобильное приложение использовало публичные методы этого View, для инициализации платежа, стилизации формы и получения информации о завершении оплаты.
Пример demo-приложения для Android
Для начала создадим визуальную структуру нашей платежной формы — layout (кстати, весь исходный код demo-приложения можно найти в github):
Обратите внимание, что все элементы, кроме карточных данных в приложении свои, а форма для ввода номера карты, срока действия и CVV2 инкапсулированы в классе com.cloudipsp.android.CardInputView. Выглядит это примерно так (для тестов можно использовать реквизиты, указанные в документации: https://www.fondy.eu/ru/info/api/v1.0/2):
При этом все элементы, в том числе и принадлежащие классу com.cloudipsp.android.CardInputView, могут быть легко стилизованы под дизайн основного приложения. Также для дальнейшей работы приложения с картами, подключенными к 3DSecure, нам понадобится элемент класса com.cloudipsp.android.CloudipspWebView — это WebView, в котором плательщик будет перенаправлен на сайт своего банка-эмитента для ввода персонального пароля (на данной картинке — страница эмулирующая работу 3dsecure сервера банка эмитента карты:
Теперь перейдем к основному нашему классу, который будет реализовывать логику приложения: public class MainActivity. Инициализируем объект класса Cloudipsp:
Далее навешиваем на объект класса com.cloudipsp.android.Card хендлер для получения результата ввода номера карты:
Теперь мы будем знать, когда пользователь завершит ввод данных, или, в случае ошибки — получим информацию о проблеме. После того, как данные карты введены, мы можем создать заказ:
Как можно видеть, интеграция довольна простая и не требует особых усилий со стороны разработчика приложения. При этом SDK решает две задачи одновременно — дает торговцу инструмент для приема платежей по платежным картам и избавляет его от необходимости проходить сертификацию на стандарты безопасности.
Три способа принимать платежи клиентов через смартфон
Для продавцов и предпринимателей смартфон заменяет кассу и делает продажи мобильней. У бизнеса есть три способа, как превратить гаджет в инструмент для приема платежей.
В 2017 году в Чёрную пятницу 40% продаж было проведено через мобильные устройства. Это на 10% больше показателей прошлого года. Покупатели уже оценили удобство работы со смартфонами.
У продавцов смартфон редко ассоциируется инструментом платежа. Но гаджет заменят кассу, банковский терминал, систему аналитики. Ниже рассмотрены три способа взаимодействия с покупателями через мобильное приложение, сайт или смартфон.
Прием платежей через мобильные приложения
Мобильные приложения помогают покупателям выбрать и оплатить товары из любого места, где есть доступ к интернету. Крупные продавцы обзавелись собственными приложениями, например, DNS, Спортмастер, Стройландия.
Функцию приёма платежей можно встроить как на стадии разработки мобильного приложения, так и в уже работающее приложение. Для этого составьте техническое задание для программистов, указав необходимость включения модуля в приложение.
Модуль не пишется с нуля, а предоставляется платёжными провайдерами. Программисты встраивают модуль оплаты в мобильное приложение с помощью готовых инструментов разработчика (SDK). С их помощью мобильное приложение передает данные о покупке банку-эквайеру, а затем платежной системе и банку-эмитенту, который выпустил карту покупателя.
Платёжный провайдер определяет банк клиента, выпустившего банковскую карту — банк-эмитент, и направляет запрос на авторизацию финансовой организации, в которой обслуживается продавец — банку-эквайеру. Эта финансовая организация передает через платежную систему запрос банку-эмитенту держателя карты. Если у владельца карты достаточно средств на счету, банк-эмитент перечисляет средства на расчётный счёт компании через платёжного провайдера.
SDK позволяет также привязать к мобильному приложению несколько банковских карт клиента. Сами данные карт хранятся в зашифрованном виде на сервере платежного провайдера или в облачном хранилище платежных систем Visa или MasterCard. Покупателю не нужно каждый раз заново вводить данные для оплаты, а достаточно выбрать карту, которой он хочет воспользоваться.
Платёжными провайдерами выступают банки, а сама услуга называется интернет-эквайринг. Например, «Тинькофф» готовы помочь во внедрении приёма платежей за 1,59% и выше от оборота компании, а Альфа-Банк просит за те же услуги фиксированную комиссию в 50 рублей с каждого платежа.
Для начала работы с платёжными провайдерами придётся приехать в офис банка и оформить договор.
Прием платежей через мобильную версию сайта
Встроить приём платежей можно на мобильную версию сайта, если у компании нет мобильного приложения. Для этого используются платёжные шлюзы или агрегаторы.
Платёжный шлюз
Платёжный шлюз отвечает за передачу данных об оплате между покупателем, банком-эмитентом, банком-эквайером, платежной системой и продавцом.
Владелец сайта или команда разработчиков встраивает форму приёма платежей. Форма по протоколу SSL (Secure Socket Layer) передаёт в банк запрос об оплате покупки. Криптографический протокол SSL зашифровывает данные для оплаты. Номер карты, CVV-код и инициалы владельца не узнают третьи лица, даже если данные перехватят злоумышленники.
К платёжным шлюзам относятся компании Assist, Fondy, PayOnline, ChronoPay.Не все компании готовы публично разглашать тарифы обслуживания клиентов. Так сервис ChronoPay сохраняет не раскрывает публично стоимость обслуживания. У Assist стоимость подключения на март 2018 года составила 2 950 рублей, но данные о комиссионном вознаграждении не раскрываются. Открытыми в этом вопросе оказались Fondy и PayOnline — у первого комиссия составляет от 3% с оборота, у второго комиссия от 2,9% и дополнительная абонентская плата до 2 990 руб.
Для начала работы с платёжными шлюзами необходимо подать заявку с сайта системы. Подключение занимает от 1 до 3 рабочих дней.
Платёжный агрегатор
Платёжные агрегаторы предоставляют сайту готовую форму для проведения платежей. В неё вписывается сумма за выбранный товар и предоставляется выбор подходящего способа оплаты, например: банковская карта, электронные деньги, мобильные платежи. Покупатель сам выбирает подходящий способ и подтверждает оплату.
Механизм подобной оплаты выглядит следующим образом: платежный агрегатор, который обслуживает сайт исходя из выбранного способа оплаты, предлагает покупателю форму для ввода платёжных реквизитов и передаёт реквизиты платёжной системе. Агрегатор получает подтверждение, что на счету покупателя достаточно средств, получает средства и переводит их на расчетный счёт продавца.
Пример платежных агрегаторов: Robokassa, PayU и «Яндекс.Касса». PayU скрыл тарифы от пользователей сайта. У Robokassa комиссия за проведение платежа зависит от выбранного покупателя инструмента. Например, «Яндекс.Деньги» — до 9%, Qiwi — до 8%, банковская карта — до 5%. У «Яндекс.Касса» комиссия с «Яндекс.Денег» составит — 3,5%, Qiwi — 6%, банковской карты — 3,5%.
Для подключения платежного агрегатора необходимо подать заявку через сайт системы. Robokassa дополнительно требует прислать документы в бумажном виде. Подключение занимает от 1 до 3 рабочих дней.
Прием платежей через мобильное устройство
Смартфон продавца с помощью приложений и аксессуаров можно превратить в полноценный терминал для приёма оплаты. Установленное приложение позволит использовать NFC-модуль телефона для приёма платежей с бесконтактных банковских карт или мобильных устройств покупателей. При этом смартфоны или планшеты покупателей должны поддерживать мобильные платежные системы Apple Pay, Samsung Pay и Android Pay.
NFC-модуль от телефона покупателя передаёт через радиосигнал данные о платежной операции на мобильное устройство продавца. Заранее установленное на мобильное устройство продавца приложение расшифровывает реквизиты и формирует запрос в банк покупателя на перевод денежных средств за покупку или услугу. Аналогичный механизм работает при использовании банковских карт, поддерживающих бесконтактные способы оплаты. Информация о платежной операции также передаётся через NFC.
Примером подобного решения могут быть приложения Fondy Merchant Portal, My Business Mobile или Merchant App. Последние два решения работают только на заграничных рынках. Fondy за проведение платежей берёт от 3% с оборота, My Business Mobile представляет собой пилотный проект и предоставляет приложение бесплатно и без комиссий.
В качестве физического решения применяется дополнительное устройство, которое позволяет считать данные с банковской карты клиентам. Устройство соединяется со смартфоном через порт.
Например, подобный гаджет есть у «Яндекс.Касса». Стоимость устройства составляет 4 600 рублей, а комиссия — 3,5%. Для украинских предпринимателей мини-терминал предлагает ПриватБанк за 49 грн, комиссия — 2,75%.
Для получения приложений необходимо подать заявку через их официальные сайты.
Смартэкономика
Если ваша компания использует мобильные устройства для приема платежей, то:
Как принимать платежи в мобильном приложении
Я уже рассказывал ранее на примере Android SDK, как не ограничиваясь фреймом и WebView, встроить нативную форму приема платежей по банковской карте в мобильное приложение, и при этом не попасть под аудит PCI DSS. С тех пор наше SDK довольно существенно расширилось и к обычной форме ввода карты в Android и iOS добавился такой функционал:
— React Native библиотека для Android и iOS
— кастомизация верстки layout формы с реквизитами карты
— функция оптического сканирования карты
— прием бесконтактных платежей в Android по технологии NFC
В этой публикации я расскажу что вообще можно делать с платежами в мобильных приложениях, какие есть лайфхаки и подводные камни, и напоследок приведу пример кода демо-приложения и расскажу, как списать карточный долг с друга при помощи NFC ридера своего смартфона.
Кейс 1. Привязываем карту клиента к бэкенду для регулярных списаний или платежей в 1 клик
Тут важно понимать, что если ваш бэкенд не сертифицирован по PCI DSS, то номер карты и ее срок действия вы не можете хранить в своей базе данных. Поэтому, прежде чем привязать идентификатор карты к аккаунту клиента, необходимо сначала карту токенизировать. Для этого вам необходимо осуществить через мобильное приложение первый платеж с участием клиента, и желательно с 3D-Secure, заблокировав на карте небольшую сумму, например 1 единицу валюты. 3D-secure в данном случае необходим в первую очередь, чтобы обезопасить себя, как торговую точку, от финансовых претензий (чарджбеков) по будущим рекурентным списаниям, а во вторую очередь — чтобы улучшить конверсию, так как например по картам Сбербанка в России в большинстве случаев транзакция без 3D-Secure не пройдет.
Итак, чтобы получить токен карты, необходимо передать параметры requiredRecToken и verification(более подробно как создать мобильное приложение смотрите в статье, ссылку на которую я указал в начале, а также в коде демо-приложения на github):
Кейс 2. Кастомизируем верстку формы ввода номера карты
Часто возникает необходимость разместить поля для ввода номера карты, срока действия и cvv2 в другой последовательности, чем это предусмотрено стандартным layout в SDK. Но из-за требований PCI DSS вы не можете просто взять, и заменить поле ввода номера карты на стандартный компонент EditText. Для этих целей мы разработали flexible layout. Flexible layout наследует стили вашего мобильного приложения и позволяет располагать элементы формы в любой последовательности и в любом дизайне и при этом предотвращает случайную передачу карточных данных на сторону вашего бекэнда.
Для организации ввода карты в SDK есть два механизма:
CardInputView — готовый view для использования;
CardInputLayout — лишь layout wrapper для потроение view в собственном стиле разметки.
По сути CardInputView = CardInputLayout + CardNumberEdit + CardExpMmEdit + CardExpYyEdit + CardCvvEdit.
Упрощенную структуру CardInputView в XML можно запиться так:
com.cloudipsp.android.CardInputLayout > com.cloudipsp.android.CardNumberEdit /> LinearLayout android:orientation = «horizontal» > com.cloudipsp.android.CardExpMmEdit /> com.cloudipsp.android.CardExpYyEdit /> LinearLayout > com.cloudipsp.android.CardCvvEdit /> com.cloudipsp.android.CardInputLayout >
Следовательно можно абсолютно свободно кастомизировать и располагать элементы ввода на сколько хватит фантазии. Есть лишь одно правило которое нужно соблюдать — каждый из элементов ввода (CardNumberEdit,CardExpMmEdit,CardExpYyEdit,CardCvvEdit) должен быть в CardInputLayout один раз, при этом не играет роли уровень вложенности View.
Вот как это может выглядеть:
Подводные камни:
Кастомизируя поля ввода стоит помнить:
— cvv2 может быть длиной как 3, так и 4 символа
— номер карты может быть от 14 до 19 символов
— можно добиться максимально точной кастомизации к вашему дизайну, сделав форк SDK и внеся изменения уже в своей реализации layout (это не запрещено делать, если вы не начинаете пропускать реквизиты карты через свой бэкенд). Но сделав форк вы теряете поддержку обновлений SDK со стороны шлюза и интеграцию новых фич
Лайфхак:
Часто можно встретить на форме ввода реквизитов карты инпуты для ввода имени и фамилии картодержателя и его ZIP кода. Для платежей по СНГ нет практической необходимости это делать в 99% случаев — только некоторые банки США, Канады и Великобритании поддерживают эту технологию, которая называется Address Verification System, при этом чтобы проверка сработала, ее должны поддерживать как банк-эквайер, так и банк-эмитент.
Кейс 3. Подключаем возможность сканирования карты через камеру и NFC
Функция оптического сканирования карты реализована для Android в библиотеке android-sdk-optical, для iOS в библиотеке CloudipspOptical с использованием card.io SDK.
NFC сканирование реализовано при помощи библиотек android-sdk-nfc и react-native-cloudipsp-nfc и доступно только для Android. Хотя Apple и открыла начиная с версии iOS 11+ сторонним разработчикам возможность читать RFID метки, но чтение EMV тегов с банковских карт по прежнему остается недоступным.
Пример демо-приложения для использования NFC
Отличается от обычной реализации наличием NfcCardBridge и навешиванием Intent на него для ожидания события, что карта прочитана (readCard)
Подводные камни:
Хотя считывание карты и выполняется посредством NFC, протоколом финансовой авторизации карты по-прежнему служит обычный card not present. Т.е. для полноценной работы этой функциональности, карта должна быть открыта для платежей в интернет.