(3 votes, average: 3.67 out of 5)
Loading...
, Автор: Fondy

Jak akceptować płatności w aplikacji mobilnej: tokenizacja, NFC, skanowanie optyczne i inne w jednym pakiecie SDK

Pokazałem już na przykładzie SDK Androida jak zintegrować natywne narzędzie płatności banku w aplikacji mobilnej nie ograniczając się do frame oraz WebView oraz nie ryzykując audytu PCI DSS. Od tego czasu nasze SDK rozwinęło się znacznie i zwykły widżet wprowadzania karty został rozwinięty o następujące funkcje:

How to accept payments in a mobile app: tokenization, NFC, optical scanning and other benefits in one SDK

— Biblioteka React Native library dls Android oraz iOS

— personalizowanie ułożenia formularza danych karty

— skanowanie optyczne karty

— przyjmowanie płatności zbliżeniowych w Androidzie dzięki technologii NFC

W tym artykule wyjaśnię ogólnie co można zaimplementować w płatnościach w aplikacjach mobilnych, opowiem o istniejących life hackach i problemach, oraz przedstawię przykład kod aplikacji demo i jak odpisać dług przyjaciela używając czytnika NFC Twojego smartfona.

Przypadek 1. Jak podłączyć kartę bankową klienta do back-endu w celu regularnego pobierania płatności lub płatności jednym przyciskiem

Trzeba pamiętać o tym że jeśli nie posiadasz certyfikatu PCI DSS, nie masz prawa zapisywać numeru karty ani daty ważności w Twojej bazie danych. Z tego powodu, zanim podłączymy kartę do konta klienta, trzeba ją ztokenizować. Aby to zrobić, musisz wykonać pierwszą płatność z udziałem klienta, oraz, najlepiej przy użyciu 3D-Secure. Przy tej płatności, powinieneś zablokować małą sumę, na przykład 1 jednostkę waluty. Po pierwsze, w tym przypadku 3D Secure działa jako ochrona dla sprzedawcy przed obciążeniem zwrotnym (chargeback) kolejnych regularnych płatności. Po drugie, umożliwia konwersję gdyż, na przykład, transakcje z karty Privatbank na Ukrainie nie mogą być wykonane bez 3D-Secure w większości przypadków.

Aby utworzyć token karty, powinieneś przenieść charakterystykę weryfikacji requiredRecTokenand (po więcej informacji jak zrobić aplikację mobilną, odnieś się do artykułu wspomnianego na początku oraz do kodu demo na GitHub’ie):

order.setRequiredRecToken(true)
order.setVerification(true)

Parametr RequiredRecToken żąda zwrócenia tokenu karty jeśli autoryzacja przebiegła pomyślnie, a weryfikacja ustanawia że nie trzeba od razu pobierać środków a zamiast tego je zablokować i zwrócić je później (bramka płatnicza sama przeprowadzi zwrot).

W odpowiedzi, bramka płatnicza zwróci parametry recToken – token karty, recTokenLifeTime – okres wygaśnięcia tokenu (czyli okres wygaśnięcia karty) oraz maskedCard – zamaskowany numer karty który powinien być podłączony do token w backendzie aby później pokazać go użytkownikowi kiedy ten wybiera metodę płatności.

Dzięki posiadaniu tokenu karty, w każdej chwili na życzenie klienta lub po prostu wtedy kiedy należy się płatność, możesz użyć obciążenia tokenu przez API serwer-serwer i pobrać żądaną kwotę.

Problemy:

Nasze statystyki pokazują że dość pokaźna liczba posiadaczy karty nie może zapłacić przez 3DSecure z urządzenia przenośnego z kilku powodów niezwiązanych z samym użytkownikiem lub bramką płatności.

  • SMS może nie dojść lub użytkownik zgubi hasło 3D-Secure przełączając między SMSami i Twoją aplikacją, bo formularz otwiera się w WebView lub przeglądarce systemu
  • Wygląd strony 3D Secure banku jest zepsuty na smartfonie lub tablecie (banki rzadko dostosowują te strony)
  • Serwer banku wyłączył wsparcie protokołu TSL1.0 który uniemożliwia płatności 3D-Secure w Android ver. <4.1

Lifehack:

Jesteśmy w stanie włączyć / wyłączyć 3D-Secure w bramce płatniczej jeśli klient nie może zapłacić, i dostosować się do klienta i spróbować przetworzyć płatność bez hasła 3D-Secure.

Jest też ważne aby pamiętać że jeśli zapiszesz tokeny jednego dostawcy płatności w swoim systemie, nie będziesz mieć możliwości używania ich z innym dostawcą, chyba że dostawcy zgodzą się na migrację tokenów, co widzieliśmy już parę razy.

Przypadek 2. Personalizowanie wyglądu formularza danych karty

Często wymagane jest przemieszczenie pól na numer konta, datę ważności oraz CVV2 w miejsca inne niż standardowy wygląd w DSK. Jednakże, wytyczne PCI DSS nie pozwalają na zmianę pola numeru karty na standardowy komponent EditText. Stworzyliśmy elastyczny layout do tych przypadków. Dostosowuje się on do szablonu Twojej aplikacji i pozwala na umieszczenie elementów formularza w jakiejkolwiek kolejności i z dowolnym wyglądem, tym samym zapobiegając przypadkowemu transferowi danych karty do Twojego backendu.

Są dwa mechanizmy ustawienia wprowadzania danych karty do SDK:

CardInputView – widok gotowy do użytku;

CardInputLayout – samo owinięcie aby pozwolić na zbudowanie wyglądu we własnym stylu.

Zasadniczo, CardInputView = CardInputLayout + CardNumberEdit + CardExpMmEdit + CardExpYyEdit + CardCvvEdit.

Uproszczona struktura CardInputView w XML może wyglądać tak:

<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>

W rezultacie, można dowolnie przemieszczać i personalizować elementy. Jest tylko jedna zasada – każdy element (CardNumberEdit,CardExpMmEdit,CardExpYyEdit,CardCvvEdit) może zostać użyty tylko raz w CardInputLayout, niezależnie od poziomu zagnieżdżenia View.  

Oto jak to może wyglądać:

Problemy:

Personalizując pola wprowadzania danych, trzeba pamiętać:

– Numer CVV2 może mieć zarówno 3 jak i 4 cyfry

– Numer karty może mieć od 14 do 19 cyfr

– tworząc rozwidlenie SDK i wprowadzając zmiany w Twojej implementacji layoutu można osiągnąć maksymalny poziom personalizacji (jest to dozwolone jeśli nie przesyłasz danych kart przez Twój backend) Jednakże, tworząc rozwidlenie, tracisz wsparcie SDK i aktualizacji oraz integracji nowych funkcji.

Lifehack:

Często formularz danych karty zawiera pola na imię i nazwisko okaziciela oraz kod pocztowy. W 99% płatności w CIS, nie ma praktycznej potrzeby takiej integracji, ponieważ tylko niektóre banki w USA, Kanadzie oraz UK używają technologii weryfikacji adresu. Dodatkowo, aby weryfikacja zadziałała, bank wydający kartę i bank autoryzacyjny powinny wspierać to rozwiązanie.

Przypadek 3. Dodanie możliwości skanowania karty aparatem i NFC

Funkcja skanowania optycznego karty jest zawarta w Androidzie w bibliotece android-sdk-optical a w iOS w bibliotece CloudipspOptical przy użyciu SDK card.io.

Skanowanie NFC implementuje się przy użycie bibliotek android-sdk-nfc oraz  react-native-cloudipsp-nfc libraries i jest dostępne tylko w Androidzie. Chociaż Apple umożliwiło czytanie tagów RFID deweloperom od iOS11, czytanie tagów EMV kart bankowych nadal jest niedostępne.

Przykład aplikacji demo z użyciem NFC

Różni się od zwykłej implementacji przez Example of demo-app with the use of NFC NfcCardBridge i dodaniem Intent aby poczekać na przeczytanie karty (readCard)

Problemy:

Chociaż odczyt karty zachodzi przez NFC, protokół autoryzacji jest ten sam. Dlatego karta musi być zautoryzowana do płatności internetowych dla pełnego działania tej funkcji.

Lifehack:

Przez stworzenie prostej aplikacji, możesz przelać środki z kogoś karty poprzez zbliżenie karty do telefonu. Może być to wygodne jeśli chcesz ściągnąć dług od znajomego. Z jednej strony będzie to wydajne i wygodne, a z drugiej, dość spektakularne. Aby użyć usługi przelewu z jednej karty na drugą, powinieneś się wcześniej zarejestrować na stronie platformy Fondy i podłączyć kartą bankową na którą mają być przelewane środki. Dla bezpieczeństwa, suma które może zostać pobrana przez NFC bez 3D Secure nie może przekroczyć $4.

Materiały dostarczone przez habrahabr.ru

#e-commerce

Leave a Reply

Your email address will not be published. Required fields are marked *