(4 votes, average: 4,00 out of 5)
Loading...
, Автор: Maxim

Integrowanie przetwarzania płatności w aplikacjach mobilnych, czyli czemu możesz zapomnieć o PCI DSS / PA DSS

Wcześniej czy później większość właścicieli i deweloperów sklepów internetowych oraz aplikacji mobilnych którzy przyjmują płatności online zada sobie pytanie: “Czy mój projekt powinien spełniać standardy PCI DSS?”

PCI DSS jest standardem bezpieczeństwa używanym przez wszystkie organizacje wykorzystujące płatności kartą: punkty sprzedaży detalicznej, centra autoryzacyjne, instytucje finansowe, dostawców usług i inne organizacje, które gromadzą, przetwarzają lub przekazują informacje o użytkowniku karty kredytowej i/lub ważne dane uwierzytelniania.
Ze stroną internetową wszystko jest proste: Podczas procesu integracji, wystarczające jest użycie technicznego rozwiązania które przekierowuje płatnika do strony certyfikowanej przez PCI DSS bramki płatniczej (zwanych hostowanymi stronami płatności) lub załadować certyfikowaną stronę w ramce na oryginalnej stronie. W każdym razie, kupujący zostaje przekierowany do formularza, gdzie uzupełnia informacje swojej karty kredytowej.

W takich przypadkach, sprzedający nie jest zobowiązany do zastosowania standardów bezpieczeństwa ponieważ nie przechowuje on danych karty, ani nie przechodzą one przez jego serwer. Dodatkowo, dzięki polityce bezpieczeństwa przeglądarek internetowych, nie mają one dostępu do danych bramki płatności

Z aplikacją mobilną te sprawy są bardziej kompleksowe. Istnieje błędne przekonanie, że jeśli aplikacja mobilna wymaga informacji o karcie kredytowej, jest automatycznie zobowiązana do standardów PCI DSS. W rzeczywistości, organizacja stojąca za rozwojem standardów  PCI DSS (PCI SSC – Payment Card Industry Security Standards Council – Urząd Standardów Bezpieczeństwa Sektora Kart Kredytowych) jak dotąd nie wydała osobnych wymogów dla aplikacji mobilnych. Oznacza to, że standardy pozostają nieobowiązkowe i nie są konieczne dla najpopularniejszych kategorii aplikacji mobilnych, w szczególności:

Kategoria 3: Aplikacje płatnościowe funkcjonujące na jakimkolwiek elektronicznym urządzeniu przenośnym  (np. Smartphony, tablety, palmtopy), które nie są dedykowane wyłącznie do akceptacji płatności i przetwarzania transakcji.

Ponieważ aplikacje mobilne nie mogą istnieć bez back-endu (część serwera, która obejmuje kod aplikacji związany z obciążeniem konta), w taki lub inny sposób informacje wymagane do przetworzenia transakcji muszą przejść przez serwer sprzedawcy. Aczkolwiek, jest tutaj niuans: żeby upewnić się, że deweloper – przypadkowo lub umyślnie, nie zaprogramował aplikacji do transmisji danych karty do żadnego niecertyfikowanego serwera, płatności mobilne SDK powinny szyfrować dane kart, aby były niemożliwe do odczytania. Ta restrykcja zapewnia, że wymogi PCI DSS są nieistotne.

Wymogi PCI DSS nie odnoszą się bezpośrednio do dostawców aplikacji płatnościowych jeśli dostawca nie zachowuje, przetwarza lub transmituje danych karty, lub nie ma dostępu do danych karty.

Przetestujmy jak to działa w mobilnym SDK usług płatniczych Fondy, używając wersji Android jako przykładu. Fondy jest międzynarodowym serwisem płatności dostępnym w Europie. Oferuje szeroki zakres rozwiązań, włączając w to:

Standardowa internetowa autoryzacja

Rozwiązania white-label przetwarzania płatności dla stron internetowych i telefonów

Centrum księgowości dla wszystkich typów biznesu on-line, od dostawców usług internetowych i sprzedawców online do portali randkowych i usług taksówkarskich.

Rozwiązanie to wiąże się z przekazaniem informacji o karcie kredytowej do View stworzonego przez bibliotekę SDK, a aplikacja mobilna używa publicznych metod tego View aby zainicjować płatność, stylizować formularz, oraz odebrać informacje o zakończeniu płatności.

Przykład wersji demonstracyjnej aplikacji dla Androida

Aby zacząć – stworzyliśmy wizualna strukturę dla naszej formy płatności – układ (wszystkie kody źródłowe aplikacji demonstracyjnej znajdziecie na github):

layout_new

Upewnij się, że wszystkie elementy w aplikacji, pomijając dane karty, są Twoje oraz formularz do wpisywania numeru karty, daty ważności oraz numeru CVV2 jest zawarty w klasie com.cloudipsp.Android.CardInputView. W przybliżeniu, tak to wygląda (do testów możesz użyć danych pokazanych w dokumentacji: https://docs.fondy.eu/docs/page/2/)

 device-2016-05-08-043635

Jednakże, wszystkie elementy, włączając w to te należące do klasy com.cloudipsp.android. CardlnputView mogą być łatwo stylizowane zgodnie ze wzorem głównej aplikacji. Do dalszej pracy z aplikacją i kartami zarejestrowanymi w 3DSecure, będziemy potrzebować elementów klasy com.cloudipsp.android.CloudipspWebView. Jest to WebView, gdzie płacący jest przekierowany do strony swojego banku emisyjnego, aby wpisać tam swoje hasło.

 device-2016-05-08-043826

Teraz przejdziemy do naszej głównej klasy, która implementuje logikę aplikacyjną: publiczna klasa MainActivity. Inicjujemy obiekt klasy Cloudisp:

 mainactivity

Następnie, nadajemy przewodnika do klasy com.cloudipsp.android. Card aby otrzymać rezultaty wpisania numeru karty.

handler

Teraz wiemy, kiedy użytkownik skończy uzupełnianie danych swojej karty, w przypadku jakiegokolwiek błędu, otrzymujemy informacje o problemie. Po zatwierdzeniu danych karty, możemy skompletować zamówienie.

 order

Jak widzicie, integracja jest jasna i prosta, nie wymaga specjalnego wysiłku ze strony dostawcy aplikacji. Co więcej, SDK rozwiązuje dwa problemy jednocześnie: daje sprzedawcy metodę do akceptowania płatności kartą i oszczędza im ubiegania się o certyfikat bezpieczeństwa.

#about-fondy

Możliwość komentowania jest wyłączona.