Pewnie rozczaruję tych wszystkich, którzy chcą przeczytać w tym odcinku coś na temat architektury serwerów i baz danych albo protokołów wymiany informacji. Te sprawy są wtórne. Rozwiązania technologiczne będą rezultatem wymagań bezpieczeństwa, systemów banków i centrów autoryzacji. Chciałbym zwrócić uwagę na jeden fundamentalny błąd, jaki tkwi w myśleniu twórców rozwiązań płatności komórkowych. Projektanci aplikacji z jakich korzysta użytkownik telefonu komórkowego koncentrują się na BEZPIECZEŃSTWIE, zamiast na analizie RYZYKA. Oczywiście, im system będzie bardziej bezpieczny, tym ryzyko mniejsze. Z punktu widzenia informatyki nie ma problemu, aby stworzyć bezpieczne aplikacje, tylko czy wtedy korzystanie z nich będzie proste? Czy klient płacąc 3 zł za parkowanie zdecyduje się na stratę czasu, aby wstukać PIN autoryzujący transakcję?

System M-płatności będzie składał się z dwóch zasadniczych elementów. Pierwszym z nich będzie Grupa aplikacji klienckich, zainstalowanych na telefonach lub dostępnych po połączeniu z serwerem danej usługi, drugim zaś będzie centrum rozliczeń, do którego będą podłączone z jednej strony aplikacje klienckie, a z drugiej banki i centrum autoryzacji. Centrum rozliczeń musi być fortecą z dwóch istotnych powodów. Po pierwsze, będą w nim numery komórkowe „sparowane” z numerem karty kredytowej, portmonetki, konta osobistego czy innego standardowego instrumentu finansowego. Pozwoli to na „przetłumaczenie” transakcji klienta przesłanej do centrum z identyfikatorem w postaci numeru MSISDN (numer telefonu), na transakcje finansową. Taka translacja jest konieczna, aby banki przetworzyły mobilne transakcje w analogiczny sposób jak przetwarzają przelewy czy transakcje kartami kredytowymi. Nie sądzę, aby banki chciały modyfikować swoje procesy w taki sposób, aby autoryzować transakcje w oparciu o numer MSISDN. Nie sądzę również, aby taka praktyka spodobała się operatorom komórkowym. Dane przechowywane w centrum rozliczeń będą danymi szczególnie wrażliwymi, stąd kwestie bezpieczeństwa są bezdyskusyjne.

Inaczej mają się sprawy z aplikacjami klienckimi. Ich konstrukcja powinna być przede wszystkim przyjazna człowiekowi. Pamiętajmy o tym, że M-płatności mają wypełnić lukę transakcji o małych wartościach do 10-20 zł. Budowanie aplikacji obsługujących transakcje o wyższych płatnościach będzie wypowiedzeniem wojny kartom płatniczym i kredytowym. To się raczej nie spodoba bankom, a na pewno pobudzi wyobraźnię hakerów.Istnieje olbrzymie portfolio dla transakcji o niskich wartościach jak np. parkowanie, maszyny vendingowe, czy też transport publiczny, gdzie M-płatności znajdą dobry grunt, aby rozwijać się. Aplikacje te mogą być w formacie JAVA, ściągnięte i zainstalowane w komórce klienta podobnie jak gry. Można je też wykonać jako aplikacje zainstalowane przez operatora na SIM (tzw. STK simtoolkit), które będą wyświetlały proste menu na ekranie telefonu i klient będzie mógł wybrać odpowiednie pole, kliknąć w nie, kupując tym samym wirtualny bilet do autobusu miejskiego. Mogą to być strony WAP obsługiwane przez przeglądarki telefonów. Aplikacje będą się komunikowały z serwerami usług (serwer usługi parkowania, serwer biletów ZTM itp.) za pomocą SMSów lub połączenia transmisji danych. SMSy mają jedna wadę, która czasami może być niewygodna, w postaci opóźnienia (szczególnie w czasie świąt i popularnych imienin). Zamiast zwykłych SMS-ów aplikacje mogą korzystać z tzw. USSD, najprościej mówiąc SMS-ów przesyłanych w czasie rzeczywistym. Ważne jest, aby zastosowane narzędzia do autoryzacji użytkownika transakcji były adekwatne do ryzyka.

Przykładem takiego zdrowego rozsądku może być rozwiązanie stosowane w Paypass Mastercard. Wystarczy przyłożyć do czytnika kartę Paypass, aby zapłacić 5 zł za hamburgera. Znalazca zagubionej i nie zablokowanej karty Paypass będzie mógł dalej płacić, obciążając w ten sposób rachunek jej właściciela. Dlatego prostota korzystania wymaga jednocześnie odpowiedzialności użytkownika. Te same reguły powinny dotyczyć aplikacji M-płatności. Konieczność logowania do aplikacji czy wklepywania PIN-u automatycznie skazuje ją na wąskie grono desperatów chętnych do jej używania. Czytałem kiedyś wyniki badań, z których wynikało, że utratę telefonu komórkowego zauważamy średnio po 15 min, a utratę karty kredytowej średnio po jednej dobie. Wiecie już, dlaczego banki chętnie obsłużą transakcje wygenerowane za pomocą telefonów?

Świadomy czytelnik mojego bloga zauważy, że smsy czy transmisja danych są przesyłane i przetwarzane przez operatorów komórkowych. Skoro tak, to istnieje ryzyko, że administrator użyje jakiegoś fragmentu sieci, podejrzy jakiś pakiet danych lub podszyje się pod jakiegoś klienta. Tylko, że taka operacja jest jak wejście pojazdem Zaporożec w zakręt z prędkością 120 km/h. Można zrobić taki manewr tylko raz w życiu. Żaden zdrowy na umyśle pracownik operatora nie zaryzykuje swojej reputacji dla hamburgera czy biletu autobusowego. Zresztą hamburgery w większych ilościach są szkodliwe dla zdrowia.