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.

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.

Temat mobilnych płatności pojawia się w mediach średnio raz w miesiącu. Większość publikacji ma charakter bardziej sensacyjny niż merytoryczny. Myślą przewodnią artykułów jest zbudowanie potencjału biznesowego pewnej firmy czy rozwiązania technologicznego. Czasem zaś chodzi o zwykłą promocję.

Świadomie postanowiłem nie pisać o rozwiązaniach technicznych, ale o modelu biznesowym dla usług m-płatności, którego zrozumienie jest kluczowym czynnikiem sukcesu dla rozwoju tych serwisów. Robię tak, gdyż nie do końca czuję, że jestem ekspertem w tych sprawach, a ponadto mój znajomy, będący wysokiej klasy informatykiem powiedział, iż obecnie wszystko w technologiach jest możliwe. To tylko kwestia pieniędzy i czasu potrzebnego na wdrożenie.

Mobilne płatności to temat, o którym się dyskutuje od początku powstania pierwszych sieci komórkowych. Na początku 2003 roku cztery największe grupy telekomunikacyjne w Europie założyły konsorcjum Simpay, którego celem było opracowanie systemu płatności przy użyciu telefonu komórkowego i karty SIM. Dodam, że system w założeniach miał replikować model transakcyjny stosowany przez Visa i Mastercard. Konsorcjum działało do lata 2005 roku, nie zostawiając po sobie nic konkretnego poza setkami prezentacji i analiz. Moim zdaniem, głównym powodem porażki była koncentracja na poszukiwaniu rozwiązania technicznego pozwalającego na zreplikowanie systemu płatniczego kart kredytowych i płatniczych.

Rok 2009 jest przełomowy dla rozwoju usług płacenia komórką w Polsce. Dwa kluczowe wydarzenia dają prawo do nadziei, że może tym razem coś się uda zrobić na skalę komercyjną. Pierwsze to powstanie wspólnej inicjatywy operatorów komórkowych, aby znaleźć rozwiązanie biznesowe nie będące elementem walki konkurencyjnej, a chęcią zrobienia wspólnie nowej grupy usług. Drugim spektakularnym wydarzeniem jest heroiczna walka firmy M-pay, aby komórką dało się płacić za parkowanie i przejazdy komunikacją miejską w Warszawie. Już raz udało się operatorom komórkowym znaleźć wspólne podejście do usług. W roku 2001 Idea, a 2 tygodnie później Era i Plus uruchomiły usługę smsowego głosowania w pierwszej edycji Big Brothera. Udało nam się ustalić plan numeracji dla usług opartych o SMS o podwyższonej opłacie, taką samą taryfikację dla klientów i podobny model biznesowy dla partnerów świadczących te usługi. Zasady, jakie udało nam się wtedy uzgodnić działają skutecznie do dziś i pozwalają nam realizować usługi wspólne dla wszystkich abonentów komórkowych w Polsce, a czasem wyłącznie dla klientów konkretnego operatora. Dlaczego o tym wspominam? Dlatego, że identyczna funkcjonalność dla klientów płacących i sprzedawców akceptujących transakcje płatnicze jest warunkiem koniecznym, aby sposób płacenia przy pomocy telefonu komórkowego stał się standardem w Polsce, a może i poza granicami kraju.

Okazując szacunek M-payowi za jego dokonania, chciałbym bez fałszywej skromności przypomnieć starszym klientom pamiętającym sieć Idea, o usłudze parkowania Idea Wapark SMS w Warszawie, którą wdrożyłem w 2002 roku i która działała kilkanaście miesięcy zanim zmiany prawne w zakresie pobierania opłat komunalnych nie zmusiły nas do jej zamknięcia. Idea miała w tamtych czasach tylko ok. 20 proc. rynku i z wiadomych przyczyn Plus i Era nie miały ochoty tej usługi wspierać, stąd nie udało się uzyskać masowości dla tej użytecznej skądinąd usługi.

M-płatności dla swojego rozwoju potrzebują czterech rzeczy:

1.Modelu biznesowo dającego wartość dodaną klientom, sprzedawcom, bankom i operatorom komórkowym

2.Systemu informatycznego i organizacji procesu otwartego na wszystkich jego uczestników, szczególnie płatników, sprzedawców i wszystkie banki.

3.Aplikacji płatniczych działających w oparciu o telefony komórkowe i karty SIM, wykorzystujących wszelkie metody wymiany informacji, jakie oferuje technologia GSM/UMTS i NFC (Near Field Communication).

4.Bezpieczeństwa transakcji adekwatnego do jej ryzyka i certyfikacji, co najmniej jednej organizacji płatniczych, która pozwoli na szerokie stosowanie i szybki rozwój nowej metody płatności.

W kolejnych odsłonach opiszę wszystkie cztery konieczne elementy, aby marzenia o płatnościach komórką na szeroką skalę stały się rzeczywistością.