Płacisz zbliżeniowo telefonem? Zobacz jak to działa

16.11.2022 | Krzysztof Parusel

Wstęp

Choć smartfony dość dawno zagościły na stałe w naszym życiu, a technologia NFC (z ang. Near Field Communication) towarzyszyła nawet wcześniejszym telefonom, to jej zastosowanie do płatności zbliżeniowych telefonem jest stosunkowo nowym wynalazkiem.

Jak to w przypadku wielu technologicznych nowinek bywa, całość zaczęła się od dwóch zdeterminowanych Amerykanów pracujących w małym start-upie, którzy w 2011 r. korzystając z open-sourceowego charakteru androida zemulowali kartę na urządzeniu z tym systemem operacyjnym. Google poparł ich pomysł i zgodził się wspierać to rozwiązanie (HCE - z ang. Host Card Emulation) w Androidach od wersji 4.4 KitKat. W 2014 pierwsze banki uruchomiły płatności oparte o tą technologię (w tym bank w Polsce), a dwie główne organizacje płatnicze VISA i Mastercard zaczęły wdrażać bezpieczne i ustandaryzowane platformy do obsługi tokenizacji (czyli utworzenia w urządzeniu cyfrowej wersji karty – tokena): VTS – Visa Token Service oraz MDES – Mastercard Digital Enablement Service.

 

Tyle o historii HCE, ale czy wcześniej nie było już innych podobnych technologii płatniczych? Czym się różni HCE od Apple Pay, Google Pay, Garmin Pay i innych Payów?

Zatem po kolei. Zanim powstało HCE, do wsparcia płatności mobilnych telefonem próbowano używać chipa, który znajduje się na karcie SIM. Rozwiązanie simcentryczne miało jednak wiele wad. Banki musiały dogadywać się z operatorami GSM, potrzebne było dodatkowe oprogramowanie do zarządzania kartami, a na klienta czekały dodatkowe utrudnienia – konieczna bowiem była wymiana karty SIM. Po wejściu technologii emulacji kart na telefonie wszystko stało się prostsze.

 

Czym różnią się technicznie poszczególne rozwiązania?

Największą różnicą jest technologia przechowywania „postaci wirtualnej” karty (jej kopii). W rozwiązaniu simcentrycznym, tzw. Secure Element to nic innego jak chip na karcie SIM, HCE – jak sama nazwa wskazuje, przechowuje dane w software’owo zabezpieczonym elemencie bezpiecznym (rozwiązanie używane na Androidach – aplikacje bankowe / Google Pay), są również rozwiązania z wbudowanym, hardware’owym zabezpieczeniem – tzw. Embaded Secure Element (np. Apple Pay, Garmin Pay).

Inny podział to portfele: zewnętrzne (z ang. 3rd party wallets) i wewnętrzny – w naszym przypadku Moje ING mobile (zwany również z ang. Single Issuer Wallet). Czym to się różni? Obecnie banki oferujące portfel wewnętrzny korzystają z technologii HCE (zatem dla urządzeń z Androidem), gdyż jest ona powszechnie dostępna. Bank, który wprowadza takie rozwiązanie musi zadbać o bezpieczne przechowywanie tokena, zarządzanie nim oraz umożliwić aplikacji komunikację z terminalem płatniczym. Na rynku istnieje wiele firm, które oferują bezpieczną bibliotekę SDK, pozwalającą na przechowywanie wirtualnej postaci karty, komunikację z terminalem i organizacjami płatniczymi. Korzystanie z takiej biblioteki pozwala na łatwiejszą adaptację płatności mobilnych do aplikacji bankowej oraz gwarantuje bezpieczeństwo rozwiązania (biblioteki są bowiem certyfikowane przez organizacje płatnicze i na bieżąco wspierane przez laboratorium oferujące taką bibliotekę).  Jeśli bank decyduje się na swoje rozwiązanie, o powyższe musi zadbać na własną rękę. Samo przypisanie karty do telefonu (z ang. Enrollment) dla Single Issuer Wallet i zarządzanie tokenami jest realizowane w aplikacji mobilnej banku lub aplikacji tworzonej tylko na potrzeby płatności kartą w telefonie. W ING Banku Śląskim obsługujemy wszystkie główne portfele dostępne na polskim ryku (Apple Pay, Google Pay i Garmin Pay) oraz swój wewnętrzny portfel dla wybranych kart VISA i Mastercard.

 

Jak to wygląda w ING?

Architektura rozwiązania płatności zbliżeniowych telefonem w ING jest dość oryginalna. Otóż wszystkie elementy wspólne konieczne do enrolmentu i zarządzania tokenami, zostały wydzielone do odrębnego komponentu. Łączymy się zatem nie bezpośrednio z organizacjami płatniczymi, a z tym komponentem, który odpowiadają za dalszą komunikację. End-pointy, które zostały przygotowane, również zostały jak najbardziej ujednolicone tak, abyśmy mogli zlecać digitalizację kart jednym interfejsem zarówno dla VISA jak i Mastercard. Ciekawostką jest fakt, iż na czas wdrożenia płatności mobilnych z Mastercard serwisy obsługujące tokenizację bazowały tylko na komunikatach ISO 8583 (jak standardowa komunikacja płatnościowa dla kart), podczas gdy nasz backend od początku pracował przez Web Service’y – translacja następuje po stronie wydzielonego komponentu. Ogólny zarys architektury modułów związanych z płatnościami mobilnymi ING obrazuje Rysunek 1. 

 

Źródło: opracowanie własne 

 

Dodanie karty do telefonu

Postaram się tutaj prosto wyjaśnić jak wygląda digitalizacja karty w naszym portfelu i w portfelach zewnętrznych.

Dodanie karty do portfela Moje ING mobile (Rysunek 2):

1. Aby umożliwić digitalizację karty dla klienta, najpierw aplikacja mobilna weryfikuje czy urządzenie mobilne klienta spełnia wymagania dotyczące płatności HCE – są to:

• system operacyjny android >= 4.4 (a od jakiegoś czasu android > 7.0)
• antena NFC
• brak roota na urządzeniu

Następnie LBE (Local Backend) płatności mobilnych sprawdza w swojej konfiguracji oraz w odpowiednich systemach czy digitalizacja dla danej karty i danego klienta jest możliwa.

2. Rozpoczęcie procesu digitalizacji zaczyna się od rejestracji aplikacji w VISA lub MC (jeśli wcześniej nie była zarejestrowana), następnie wysyłamy zaszyfrowane dane o karcie i urządzeniu do organizacji płatniczych. W międzyczasie wykonywane są sekwencje zadań w bibliotece obsługującej płatności polegające m.in. na utworzeniu obiektu nowej karty wirtualnej i przygotowaniu jej do zasilenia tokenem.
3. Zanim token zostanie dostarczony do telefonu, VISA/MC wysyłają do LBE prośbę o zgodę na tokenizację. Na podstawie tego requestu uruchamiamy szereg walidacji i jeśli wszystkie przejdą pozytywnie, zaczyna się proces dostarczenia tokena na urządzenie klienta (a konkretniej do biblioteki odpowiedzialnej za płatności mobilne) po czym aplikacja mobilna wykonuje dodatkowo sekwencję operacji tj.:

• ustawienie metody płatności dla karty (obecnie skonfigurowane w ING płacenie możliwe po podświetleniu ekranu),
• weryfikacja czy nowa karta jest jedyna w bibliotece, jeśli tak, to ustawienie jej jako aktywna do płatności,
• sprawdzenie czy aplikacja Moje ING mobile jest ustawiona jako domyślna do płatności telefonem,
• sprawdzenie czy jest włączona antena NFC w telefonie.

 

Źródło: opracowanie własne

Dodanie karty do portfela zewnętrznego /3rd party wallet/ (Rysunek 3):

• klient dodając kartę do portfela zewnętrznego (w zależności od możliwości technicznych portfela i implementacji w danym banku) ma możliwość skorzystania z 2 ścieżek:
  • wpisanie danych ręcznie w aplikacji dostawcy portfela (w zależności od portfela, oprócz w pełni manualnego podania danych karty można wybrać opcję ich sczytania OCR – przez zrobienie zdjęcia karty lub pobranie danych za pomocą czytnika NFC – w takim przypadku wystarczy zbliżyć kartę do telefonu, aby jej dane zostały pobrane i wyświetlone do edycji).
  • skorzystanie z mechanizmów pobrania danych przez bank w aplikacji mobilnej banku lub nawet z poziomu bankowości elektronicznej (z ang. in-app provisioning / push provisioning) – w takim aplikacja Banku przekazuje zaszyfrowane dane karty klienta do aplikacji portfela. Klient kończy proces w aplikacji portfela. Warto tutaj wspomnieć, że dostawca portfela wcale nie musi przekierowywać do swojej aplikacji (np. Google Pay) i przy odpowiedniej implementacji w aplikacji banku można dodać kartę bez przechodzenia między aplikacjami.

Z uwagi na to, że różnica pomiędzy dwiema w/w metodami sprowadza się głównie do rodzaju wprowadzenia danych do portfela, poniżej opiszę jak proces wygląda, gdy klient korzysta z aplikacji dostawcy portfela:

• Klient loguje się do aplikacji dostarczającej portfel zewnętrzny i wybiera opcję dodania karty płatniczej. Następnie podaje szczegóły karty.
• Dane są wstępnie weryfikowane przez organizację płatniczą:
  • czy dany produkt kartowy jest skonfigurowany do płatności mobilnych,
  • czy są spełnione podstawowe reguły zdefiniowane dla danej karty, w tym reguły bezpieczeństwa.
  • dodatkowo w tym punkcie następuje też przyporządkowanie grafiki, kolorów (na wypadek gdyby nie udało się pobrać grafiki), opisu produktu kartowego oraz szeregu innych informacji związanych z obsługą portfela i klienta w kontekście, których jest dodawana karta (m.in. dane kontaktowe, polityki i regulaminy).
  • jeśli dodawana karta – jej BIN/range (unikalny identyfikator produktu kartowego) – nie została uruchomiona do płatności w danym portfelu, klient otrzymuje komunikat na ekranie aplikacji portfela, że dana karta nie jest obsługiwana.
• Po zaakceptowaniu przez klienta regulaminu do banku zostaje wysłane żądanie digitalizacji karty (przez wydzielony komponent). Bank waliduje kartę oraz klienta czy spełniają warunki formalne i nieformalne związane z możliwością dodania karty do portfela (np. zgoda rodzica dla osoby niepełnoletniej czy posiadanie bankowości elektronicznej), a po prawidłowym zweryfikowaniu karty/klienta, bank wysyła zgodę na jej enrolment. Jeśli algorytmy sprawdzające stwierdzą, że dodanie karty jest całkowicie bezpieczne, w zależności od portfela może dojść do sytuacji, gdy dodatkowe potwierdzenie nie będzie wymagane. Najczęściej jednak bank poprosi klienta o zautoryzowanie operacji (jest to opisane w kolejnych krokach). Jeśli bank uzna dodanie karty za zbyt ryzykowne (np. klient wpisał nieprawidłowe dane karty lub karta jest zastrzeżona), proces zostanie odmownie przerwany.
• W kolejnym kroku do banku wysyłana jest prośba o przedstawienie dostępnych metod potwierdzenia dodania karty przez klienta. W ING obsługujemy obecnie możliwość aktywacji na SMS oraz poprzez aplikację mobilną (tzw. In-app Verification). W zwracanych metodach może pojawić się również nr telefonu do Contact Center. Aplikacja z portfelem zewnętrznym prezentuje listę metod autoryzacji, a klient wskazuje, której chce użyć.

W przypadku gdy:

• klient wybierze SMS:
  • organizacja płatnicza przesyła kod do banku, a bank wysyła go do urządzenia klienta. Klient wpisuje kod w aplikacji, która przekazuje wpisany kod do organizacji płatniczej – jeśli wysłany kod zgadza się z wpisanym przez klienta, token jest aktywowany.
  • klient wybiera autoryzację przez aplikację mobilną Moje ING mobile - kierowany jest do specjalnego procesu, w którym wybiera karty, jakie chce aktywować (w zależności od portfela, do którego klient dodaje kartę, jednym potwierdzeniem można w tym procesie aktywować większą ilość kart z danego banku). Następnie potwierdza operację wpisując PIN do aplikacji. Aplikacja mobilna po potwierdzeniu poprawnie wpisanego PINu wysyła do backend żądanie aktywowania tokena, które jest wysyłane do organizacji płatniczej.

 

Źródło: opracowanie własne 

 

Karta dodana, ruszamy na zakupy – czyli jak działa płatność

Zanim w kilku słowach opiszę co dzieje się przy płatności kartą w telefonie, chciałem przybliżyć dwa terminy – mianowicie FPAN (PAN), i DPAN (token).

FPAN (z ang. Funding Primary Account Number) to nic innego jak numer naszej karty wydrukowany na jej awersie. Składa się z 16. znaków i jednoznacznie identyfikuje czy karta wydana jest przez VISA czy przez MC oraz Bank jaki z niej korzysta.

DPAN (z ang. Device Primary Account Number) natomiast oznacza wirtualny numer karty, przypisany do danego urządzenia, a raczej aktualnej digitalizacji danej karty w danym portfelu.

 

FPAN = główny numer karty

DPAN = wirtualny numer karty oznaczający aktualne przypisanie jej w danym portfel

 

Zatem, podczas gdy karta ma jeden główny numer (FPAN), może posiadać wiele wirtualnych numerów (DPAN), a w przypadku gdy użytkownik korzysta z kilku portfeli na jednym urządzeniu, jedna karta może mieć przypisanych kilka aktywnych tokenów (DPAN) dla jednego urządzenia. Dodatkowo usunięcie tokena (DPAN) nie wpływa w żaden sposób na kartę (FPAN), ale zamknięcie karty powoduje już zamknięcie dla niej wszystkich tokenów i brak możliwości utworzenia nowego tokena dla danej karty.

Jeśli chodzi o płatność, to w zależności od rozwiązania (portfela), przed przyłożeniem telefonu do terminala należy:

• uruchomić aplikację portfela (np. na zegarku),
• wybudzić aplikację z portfelem (np. Apple Pay – choć i bez tego telefon wejdzie w tryb płatności) lub
• podświetlić ekran telefonu (Moje ING mobile lub Google Pay).

Następnie zbliżamy telefon do terminala płatniczego (POS – z and. Point of Sale) i urządzenie zaczyna „rozmawiać” z terminalem. Warto tutaj wspomnieć, że płatności mobilne z założenia działają on-line czyli saldo rachunku, do którego podpięta jest karta musi mieć środki do pokrycia danej transakcji. Może się zatem zdarzyć, że nie będzie możliwości dokonania transakcji na terminalu niepołączonym z siecią, choć w takich przypadkach też mogą być zastosowane software’owe rozwiązania pozwalające obejść ten problem.

W bibliotece odpowiedzialnej za płatności wykonywane są polecenia APDU (z and. Application Protocol Data Unit), które analogicznie jak dla karty fizycznej przetwarzane są przez bibliotekę Contactless na terminalu płatniczym. Jedyna różnica jest taka, że urządzenie mobilne „przedstawia się” tokenem, czyli wirtualnym numerem karty. Jak to jest w standardowej płatności, komunikat płatniczy wędruje najpierw do dostawcy terminala (Acquier’a), następnie do organizacji płatniczej, aby stamtąd trafić do Issuera (czyli wydawcy karty – tutaj ING). VISA/MC rozpoznają, że płatność wykonana była tokenem i dzięki platformie tokenizacyjnej wiążą ją z głównym numerem karty, aby na ten numer wysłać bankowi płatność do akceptacji. Komunikat płatniczy różni się od tradycyjnego dodatkowymi danymi dotyczącymi tokena (m.in. jego numer, portfel, z którym jest powiązany itp.). Warto tutaj dodać, że każda płatność zabezpieczona jest dodatkowymi kluczami kryptograficznymi, które uzupełniane są w bibliotece odpowiedzialnej za płatności w aplikacji portfela.

 

Kupujesz przez internet? Płać tokenem

Ostatnim tematem jaki chciałbym poruszyć w tym artykule jest powiązanie świata e-commerce z płatnościami telefonem, a bardziej ze światem tokenów.

Rynek handlu w internecie jest coraz bardziej popularny, a pandemia COVID-19 dodatkowo przyspieszyła ekspansję tego rynku. Przyjęta zasada płatności przy zamówieniu (zamiast podczas odbioru towaru) powoduje dodatkowe zwiększenie wagi bezpiecznej płatności w sieci.

W Polsce królują płatności typu Pay By Link – czyli przekierowanie do aplikacji bankowej celem przelania należności, ale obserwuje się również trend wzrostowy płatności BLIK oraz kartami płatniczymi. Temat BLIK nadaje się na odrębny artykuł, tu spróbuję choć trochę przybliżyć co nowego pojawiło się w płatnościach kartą w internecie.

Pierwszym sposobem płatności e-commerce, szczególnie powiązanym z tematem tokenizacji jest metoda in-app payment. Jest to nic innego, jak umożliwienie przekierowania płatności ze sklepu wykorzystującego aplikację mobilną do aplikacji dostawcy portfela zewnętrznego – Apple Pay czy Google Pay. Jeśli dostawca aplikacji oferującej sprzedaż on-line dogada się z firmami obsługującymi portfele, musi zintegrować swoją aplikację, przetestować ją w tym modelu, a po pozytywnym przejściu tej ścieżki może udostępniać szybkie płatności kartą w telefonie w swojej aplikacji. Metoda ta jest zdecydowanie wygodniejsza niż przepisywanie danych karty, a dodatkowo bezpieczniejsza – potwierdzenie płatności jest oparte na standardowe mechanizmy uwierzytelniania płatności w portfelach.

Drugi sposób na wykorzystanie digitalizacji w płatnościach kartą w internecie, to tokenizowanie wprowadzonych raz danych karty w danym sklepie. Taka funkcjonalność znaczenie podnosi bezpieczeństwo zapamiętywania danych karty. Tam gdzie nie została jeszcze wdrożona, dane karty przechowywane są w pliku – jeśli dojdzie do wycieku danych, przestępca będzie mógł próbować ich użyć w innych sklepach. Jeśli dane zostaną stokenizowane, w przypadku wycieku przestępca będzie w posiadaniu jedynie tokenów (DPAN), które dla płatności typu e-commerce są dodatkowo tak zabezpieczone, aby mogły być transakcyjne jedynie w sklepie, w którym zostały zapisane. W obliczu coraz większej ilości usług wymagających podania danych karty przy pierwszym utworzeniu konta (Netflix, Spotify, Uber, elektryczne hulajnogi itp.), takie podejście przechowywania danych karty znacząco podnosi poziom bezpieczeństwa. I choć z punktu widzenia klienta nie ma żadnej różnicy (a można się spodziewać, że w przyszłości będą profity również w tym obszarze), to dane kartowe, które do niedawna były cenną zdobyczą cyberprzestępców, wraz z popularyzacją rozwiązania, zdecydowanie stracą na wadze.

 

Podsumowanie

Płatności kartą w telefonie, a bardziej cały temat tokenizacji na dobre rozgościł się w naszym codziennym świecie. Wygoda i bezpieczeństwo jakie oferują powodują, że jeśli ktoś zaczął z nich korzystać, przestaje używać tradycyjnych metod płatności.

Choć wielki boom na to nowe rozwiązanie mamy już za sobą, nie wiadomo czym rynek i technologia nas jeszcze zaskoczy. Jednego możemy być pewni - jeśli pojawi się coś nowego, to będzie musiało być jeszcze wygodniejsze i co najmniej tak samo bezpieczne.