Як приймати платежі в мобільному додатку

Ми вже розповідали раніше на прикладі 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, при цьому, щоб перевірка спрацювала, її повинні підтримувати і банк-еквайр, і банк-емітент.