Как принимать платежи в мобильном приложении

Мы уже рассказывали ранее на примере Android SDK, как, не ограничиваясь фреймом и WebView, встроить нативную форму приема платежей по банковской карте в мобильное приложение и при этом не попасть под аудит PCI DSS. С тех пор наше SDK довольно существенно расширилось и к обычной форме ввода карты в Android и iOS добавился такой функционал:

• React Native библиотека для Android и iOS
• кастомизация верстки layout формы с реквизитами карты
• функция оптического сканирования карты
• прием бесконтактных платежей в Android по технологии NFC

В этой статье мы расскажем, что вообще можно делать с платежами в мобильных приложениях, какие есть лайфхаки и подводные камни, и напоследок приведем пример кода демоприложения и расскажем, как списать карточный долг с друга при помощи NFC-ридера своего смартфона.

Параметр requiredRecToken требует возвратить токен карты при успешной авторизации карты, а verification – что средства с карты списывать не нужно, а достаточно их заблокировать, а потом вернуть (платежный шлюз возвращает их автоматически). В ответ платежный шлюз вернет параметры recToken – токен карты, recTokenLifeTime – срок действия токена (по сути срок действия карты) и maskedCard – маскированный номер карты, который необходимо привязать в бэкенде к токену для дальнейшего отображения клиенту при выборе способа оплаты.

Теперь, имея токен карты, вы можете в любой момент по требованию клиента или при наступлении срока оплаты вызвать метод списания по токену через server-to-server API и списать необходимую сумму.

Подводные камни

По нашей статистике, у довольно значимой части картодержателей не получается оплатить через 3D Secure на мобильном устройстве по ряду причин, от него и шлюза не зависящих:

• может не приходить SMS или пользователь, переключаясь между SMS-приложением и вашим, потерял форму с вводом пароля 3D Secure, так как она открывается в WebView или системном браузере
• полезла верстка 3D Secure страницы банка на смартфоне или планшете (банки очень редко адаптируют такие страницы)
• веб-сервер банка отключил поддержку небезопасного протокола TSL 1.0, что делает 3D Secure недоступным для Android версии <4.1

Лайфхак

Мы на платежном шлюзе умеем включать/отключать 3D Secure на лету, и если все-таки у клиента не получается оплатить, мы под него подстраиваемся и пытаемся сделать оплату без 3D Secure пароля. Также стоит помнить, что если вы сохраняете токены одного платежного провайдера в своей системе, то использовать их на другом провайдере уже не получится, разве что провайдеры договорятся между собой о миграции токенов, что в принципе в нашей практике уже было несколько раз.

Следовательно можно абсолютно свободно кастомизировать и располагать элементы ввода, насколько хватит фантазии. Есть лишь одно правило, которое нужно соблюдать, – каждый из элементов ввода (CardNumberEdit, CardExpMmEdit, CardExpYyEdit, CardCvvEdit) должен быть в CardInputLayout один раз, при этом не играет роли уровень вложенности View.

Вот как это может выглядеть:

Подводные камни

Кастомизируя поля ввода стоит помнить:

1. CVV2 может быть длиной как 3, так и 4 символа.
2. Номер карты может быть от 14 до 19 символов.
3. Можно добиться максимально точной кастомизации к вашему дизайну, сделав форк SDK и внеся изменения уже в своей реализации layout (это не запрещено делать, если вы не начинаете пропускать реквизиты карты через свой бэкенд). Но сделав форк, вы теряете поддержку обновлений SDK со стороны шлюза и интеграцию новых фич.

Лайфхак

Часто на форме ввода реквизитов карты можно встретить инпуты для ввода имени и фамилии картодержателя и его ZIP-кода. Для платежей по СНГ нет практической необходимости это делать в 99% случаев – только некоторые банки США, Канады и Великобритании поддерживают эту технологию, которая называется Address Verification System, при этом чтобы проверка сработала, ее должны поддерживать как банк-эквайер, так и банк-эмитент.