HUB USŁUG MOBILNYCH

HUB USŁUG MOBILNYCH

Hub Usług Mobilnych jest systemem agregującym Usługi mobilne Dostawców celem ich udostępnienia w systemach (aplikacjach mobilnych) Partnerów - Odbiorców. System udostępnia dwa niezależne kanały dystrybucji Usług mobilnych. Pierwszym z nich jest dedykowana aplikacja mobilna, która umożliwi dystrybucję Usług w oparciu o wewnętrzną Bazę Użytkowników Systemu, ze wsparciem zintegrowanych z Systemem metod płatności (karty płatnicze, przelewy P2P, Blik). Drugim interfejsem udostępnianym przez system jest API dla funkcjonalności frontendowych, dedykowany Odbiorcom, którzy posiadają własne rozwiązanie w oparciu o własną bazę użytkowników oraz własne mechanizmy płatności. W takim modelu Usługa bazuje na wydawaniu produktów wybranego Dostawcy oraz ich zbiorczym rozliczeniu.

USŁUGA MOBILNA

Hub Usług Mobilnych dedykowany jest dla Usług mobilnych będących biletami komunikacji miejskiej, jednak budowa modułowa oraz otwarta architektura Systemu umożliwia jego rozbudowę o innego rodzaju Usługi mobilne.

DOSTAWCY

Na chwilę obecną System dedykowany jest dla Dostawców będących przewoźnikami lub organizatorami komunikacji miejskiej. W ramach integracji oferujemy konfigurację Państwa taryfy biletowej, zintegrowania modelu kontroli biletowej oraz przygotowania dedykowanej aplikacji mobilnej zawierającej Państwa ofertę w obszarze publicznego transportu zbiorowego.

ODBIORCY

Odbiorcom oferujemy dwa modele wspłópracy. Pierwszym z nich jest działalność operatorska w obszarze publicznego transportu zbiorowego w ramach oferty wybranego Dostawcy, poprzez dedykowaną aplikację mobilną będącą integralnym elementem systemu Hub Usług Mobilnych. Drugim modelem współpracy jest integracja w systemach Odbiorcy Usług mobilnych udostępnionych przez nas API dla funkcjonalności frontendowych.

SCHEMAT BLOKOWY HUBA USŁUG MOBILNYCH

APLIKACJE DEDYKOWANE

INTEGRACJA

Z OPERATORAMI PŁATNOŚCI

APLIKACJE ZEWNĘTRZNE

BAZA DOSTAWCÓW I

KONFIGURACJA USŁUG

KONFIGURACJA ODBIORCÓW

REJESTR TRANSAKCJI KORELUJĄCY:

dostawców, produkty, kanały dystr.

BACKEND SYSTEMU SPRZEDAŻY

DLA APLIKACJI WŁASNEJ I WL

PANEL ADMINISTRACYJNY

API

DLA APLIKACJI DEDYKOWANYCH

(np. bankowe)

API

DLA FUNKCJONALNOŚCI

FRONTENDOWYCH

KOMPONENTY HUBA USŁUG MOBILNYCH

Moduł Bazy Dostawców i konfiguracji Usług

Moduł rejestracji Dostawców Usług oraz konfiguracji Produktów, co oznacza możliwość skonfigurowania Dostawcy w Systemie (np. przewoźnik komunikacji miejskiej, Zarząd Transportu Miejskiego, itp.) oraz implementację jego kompletnej taryfy biletowej (w obszarze komunikacji miejskiej). Moduł zapewni także wsparcie w procesie kontroli biletów. System wspiera następujące metody kontroli:

• skanowanie kodu QR generowanego przez system lub pobranego z systemów Dostawcy,

• kontrola wzrokowa biletu na podstawie charakterystycznych zabezpieczeń na ekranie telefonu pasażera,

• dedykowana integracja z urządzeniami kontrolerskimi Dostawcy poprzez protokół NFC.

Moduł Konfiguracji Odbiorców

Moduł pozwoli na rejestrację Odbiorców, wskazanie modelu współpracy, wskazaniu usług, które będą dostępne w kanale Odbiorcy oraz ustalenie parametrów autoryzacyjnych dla:

• dostępu do API dla funkcjonalności frontendowych,

• panelu administracyjnego.

Moduł Rejestru Transakcji

Baza transakcji dokonanych w ramach Huba Usług Mobilnych, niezależnie od kanału dystrybucji. Transakcja w systemie będzie korelowała następujące parametry usługi:

• Dostawcę i rodzaj usługi (np. typ biletu),

• Użytkownika HUM zarejestrowanego w ramach Backendu Systemu Sprzedaży (jeżeli transakcja zainicjowana została w dedykowanej aplikacji mobilnej),

• kanał dystrybucji.

W przypadku Usług dystrybuowanych za pośrednictwem API dla funkcjonalności frontendowych w procesie transakcyjnym nie bierze udział

Użytkownik HUM. Po stronie Odbiorcy w takim modelu należy właściwa identyfikacja swojego użytkownika.

KOMPONENTY HUBA USŁUG MOBILNYCH

Moduł Backendu Systemu Sprzedaży

Komponent umożliwiający realizację kompleksowego procesu sprzedaży w oparciu o dedykowaną aplikację mobilną. Moduł wystawia interfejs (API) dla dedykowanych aplikacji mobilnych. Backend Systemu Sprzedaży składa się z następujących modułów:

Moduł Bazy Użytkowników Systemu

Moduł umożliwiający rejestrację użytkowników końcowych i nadanie im praw dostępu do aplikacji mobilnej. Użytkownicy identyfikowani w Systemie są poprzez ich numery telefonów. Moduł zapewni też odpowiednie parametry bezpieczeństwa związane z przechowywaniem parametrów płatniczych, historii zakupionych biletów, listy aktywnych biletów celem ich okazania do kontroli.

Transakcje związane z zakupem biletów procesowane są przez Moduł Rejestracji Transakcji, w którym to identyfikowany jest Użytkownik końcowy

Systemu.

Moduł Integracji z zewnętrznymi operatorami płatności

Ponieważ płatność będzie integralną częścią procesu zakupu biletu z wykorzystaniem dedykowanej aplikacji mobilnej, Backend Systemu

Sprzedaży zintegrowany jest z zewnętrznym operatorem płatności w obszarach realizacji płatności.

KOMPONENTY HUBA USŁUG MOBILNYCH

Moduł API dla funkcjonalności frontendowych

Moduł umożliwi implementację procesu sprzedaży w zewnętrznych aplikacjach mobilnych Dostawców. W modelu tym System nie nakłada ogranicza na interfejs użytkownika, którego projekt i implementacja pozostaje całkowicie po stronie Dostawcy. Ponadto System nie wymusza rejestracji użytkownika HUM oraz nie narzuca metody płatności. Powyższe obszary pozostają całkowicie pod kontrolą Dostawcy, a rolą Systemu w tym modelu jest wydawanie biletów oraz zbiorcze rozliczenie się z Odbiorcą. API umożliwia także zbudowanie efektywnie działającego rozwiązania

„smart city” udostępniającego użytkownikom urządzeń komórkowych usługi różnych operatorów w jednym miejscu.

Aplikacje mobilne

Dedykowane aplikacje mobilne w obrębie danego Dostawcy, umożliwiające prezentację, zakup i kontrolę biletów komunikacji miejskiej, w ustalonej kolorystyce i identyfikowane logo Dostawcy/Odbiorcy. Aplikacje mobilne przygotowane są na następujące mobilne systemy operacyjne:

• iOS,

• Android.

Panel administracyjny

Narzędzie oferujące odrębne zakresy funkcjonalne dla poszczególnych uczestników Systemu:

• Super Admin – narzędzia rejestracji Dostawcy oraz Odbiorcy w Systemie, wgląd we wszystkie modele transakcyjne oferowane przez System,

• Administrator Dostawcy/Odbiorcy – wgląd udostępniane/procesowane we własnym kanale transakcje, raportowanie,

• Użytkownik końcowy – logując się numerem telefonu oraz hasłem, użytkownik uzyskuje wgląd we własne transakcje biletowe dokonywane w

oparciu o dedykowaną aplikację mobilną.

DODAWANIE I KONFIGURACJA DOSTAWCY

Konfiguracja Dostawcy:

• Kod miasta – trzyliterowy kod (np. POZ)

• Nazwa miasta

• Nazwa dostawcy (np. ZTM, MPK)

• Domena – nazwa poddomeny dla panelu

• Login i hasło do panelu

• Taryfa – plik JSON z taryfą (opisany dalej)

DODAWANIE I KONFIGURACJA DOSTAWCY

Struktura TARIFF zawierająca parametry taryfy biletowej: Struktura TICKET zawierająca parametry biletu:

Parametr	Typ	Opis
tariffkey	STRING(32)	Identyfikator taryfy biletowej
tariff_id	INTEGER	Identyfikator taryfy biletowej w systemie operatora
operator	STRING	Oznaczenie operatora biletów, który w przypadku biletów komunikacji miejskiej jest tożsamy z miastem, oznaczony trzyliterowym skrótem (np. WRO, WAW, KRA)
product	STRING	W przypadku taryfy komunikacji miejskiej, oznaczenie produktu jest tożsame z oznaczeniem operatora, co oznacza, że pole to można pominąć
version*	STRING	Wersja taryfy
hash*	STRING(32)	Parametr pełniący rolę sumy kontrolnej pełnej taryfy miejskiej (dystrybutorowi udostępniana jest taryfa z ograniczoną liczbą biletów – patrz. parametr contracthash). Zmiana parametru, w stosunku do uprzednio zaimportowanej taryfy, oznacza konieczność aktualizacji taryfy.
valid_from	TIMESTAMP	Data rozpoczęcia ważności taryfy
valid_to	TIMESTAMP	Data zakończenia ważności taryfy
description*	TEXT	Opis taryfy (parametr w systemie operatora).
dictionaries*	OBJECT	Słowniki dla taryfy: discounts, zones, etc.
count*	INTEGER	Liczba biletów w taryfie biletowej, tj. liczba rekordów poniższej tablicy contracts
contracthash	STRING(32)	Suma kontrolna wyliczona na podstawie udostępnionych dystrybutorowi biletów (podzbiór pełnej taryfy miejskiej). Zmiana tego parametru oznacza konieczność aktualizacji taryfy.
contracts*	ARRAY of TICKET	Lista biletów w taryfie

Parametr	Typ	Opis
tariffkey	STRING(32)	Identyfikator taryfy biletowej
tariff_id	INTEGER	Identyfikator taryfy biletowej w systemie operatora
ticketkey	STRING(32)	Identyfikator biletu. Parametr ten jest unikatowy globalnie. W przypadku, w którym API zwróci nową taryfę biletową, zmianie ulegnie wartość parametru ticketkey dla biletu analogicznego, który występował w poprzedniej taryfie.
contract	INTEGER	Identyfikator biletu w systemie operatora. Jest to parametr unikatowy tylko w ramach danej taryfy biletowej. W przypadku, w którym API zwróci nową taryfę biletową, numery kontraktów mogą pozostać takie same, co oznacza, że w nowej taryfie dany bilet odpowiada analogicznemu, w poprzedniej taryfie.
symbol	STRING(100)	Skrócony symbol biletu
contract_name	TEXT	Pełna nazwa biletu
full_name_translate*	ARRAY of one OBJECT	Tablica zawierająca obiekt zawierający tłumaczenia nazwy biletów na języki angielski i niemiecki: [{ ”en”: ” english name of ticket”, ”de”: ” deutscher ticket name ” }]
price	INTEGER	Cena biletu wyrażona w groszach (PLN * 100)
unit	INTEGER	Jednostka umożliwiająca wyliczenie ważności biletu: • 0 – miesiąc • 1 – minuta • 2 – godzina • 3 – doba • 7 – jednorazowy
counter	INTEGER	Licznik jednostek umożliwiająca wyliczenie ważności biletu
svalidity_type*	INTEGER	Typ początku ważności biletu: • 0 – ważność biletu od momentu zakupu • 6 – od początku danej jednostki (czyli jeżeli jednostką jest 1 godzina, to bilet zakupiony o 12:05, to jest ważny od 12:00) • 13 – na semestr (4 mies.) • 14 – na semestr (5 mies.)
evalidity_type*	INTEGER	Typ końca ważności biletu: • 1 – do końca jednostki • 2 – nie do końca jednostki, a do czasu wyliczonego

DODAWANIE I KONFIGURACJA DOSTAWCY

zone*	INTEGER	Maska bitowa przedstawiająca ważność biletu w strefach. Przykładowo: Strefa I = 1 (0001b), Strefa II = 2(0010b), na obie Strefy = 1+2 = 3(0011b) – w praktyce w słowniku będzie opisana każda strefa, ale także połączenie stref jednostkowych, czyli w słowniku będą opisane strefy 1(I), 2(II), 3(I i II).
ticket_type*	INTEGER	Typ biletu: • 0 – na okaziciela • 1 – imienny
lines_group*	INTEGER	Grupa linii. W przypadku konieczności deklaracji numeru (numerów) linii na etapie zakupu, wprowadzona linia powinna występować w aktualnym setoflines, a parametr ten powinien być zgodny z analogicznym z setoflines.
discount*	INTEGER	Zniżka biletu. Wykaz zniżek zawarty jest w słownikach (dictionaries) będących składową taryfy biletowej.
lines_type*	INTEGER	typy linii: • 1 – normalne • 2 – pospieszne • 4 – nocne • i kombinacje
workdays*	INTEGER	Ważność biletu w dni: • 1 – robocze • 2 – weekend • 3 – caly tydzień
lines_count*	INTEGER	Parametr informujący na ile linii ważny może być dany bilet. Z reguły oznacza to konieczność wprowadzenia tych numerów przez użytkownika.
special*	INTEGER	Pole, które powinno być ignorowane, niezależnie od tego, czy będzie w taryfie, czy nie oraz jaką przyjmie wartość.
vat_code	STRING(10)	Opis stawki VAT: • B – stawka 8% • A – stawka 23% • zw – zwolniony
future_validity*	INTEGER	Parametr definiujący maksymalne wyprzedzenie zakupu dla danego biletu, wyrażony w sekundach
sale_from*	TIMESTAMP	Przesunięciu rozpoczęcia sprzedaży biletu w stosunku do początku ważności taryfy, np. dzisiaj wchodzi w życie nowa taryfa i nowy bilet okresowy który można kupić już dziś ale z datą początku ważności dopiero od sale_from
sale_to*		Ograniczenie sprzedaży biletu względem daty zakończenia ważności taryfy, np. bilet jest w taryfie jeszcze jakiś czas ważnej ale kupić go można do daty wcześniejszej, określonej jako sale_to
excess_fare*	BOOLEAN	Parametr informujący, czy bilet jest dopłatowy, czy nie

Struktura TICKET ciąg dalszy:

mob_side_no_req *	BOOLEAN	Parametr „numer boczny pojazdu” jest wymagany w procesie zakupu biletu.
mob_name_req*	BOOLEAN	Parametr „imię i nazwisko” jest wymagany w procesie zakupu biletu.
mob_id_document_req*	BOOLEAN	Flaga wymagalności parametru: rodzaj dokumentu tożsamości (wybór z listy słownikowej ‘identity_document’)
mob_max_quantity*	INTEGER	Maksymalna liczba biletów możliwa do zakupienia w pojedynczej transakcji

Przykładowe pliki taryfowe w formacje JSON udostępnione zostaną Dostawcy wraz z kompletem dokumentacji integracyjnej po podpisaniu Umowy współpracy

DODAWANIE I KONFIGURACJA ODBIORCY

Konfiguracja Odbiorcy:

• Nazwa Odbiorcy

• Dane identyfikacyjne (adres, NIP, REGON)

• Biznesowy model współpracy (agent/bank/ inne)

• Dostępne Usługi (wybór z listy Dostawców)

• Domena – nazwa poddomeny dla panelu

• Parametry dostępowe do API dla funkcjonalności frontendowych