Standard Polish API opisuje interfejs służący do komunikacji pomiędzy bankami a podmiotami trzecimi (TPP) w związku z realizacją usług wykorzystujących dostęp do rachunku (XS2A), czyli nowych usług wprowadzonych przez dyrektywę PSD2 (PIS - usługa inicjowania transakcji płatniczej, AIS - usługa dostępu do informacji o rachunku).
Jest to wspólna odpowiedź znacznej części banków, instytucji płatniczych, związków i organizacji sektora płatniczego na konieczność implementacji rozwiązań zgodnych z regulacyjnymi standardami technicznymi dotyczącymi dyrektywy PSD2.
Stworzenie wspólnego standardu dla sektora płatniczego usprawnia wdrażanie interfejsów programowania aplikacji udostępnianych podmiotom trzecim przez podmioty prowadzące rachunki. Ujednolicenie bankowych API jest istotnym ułatwieniem dla podmiotów trzecich podczas budowy rozwiązań korzystających z XS2A.
Każdy podmiot prowadzący rachunek płatniczy (ASPSP - może to być bank lub inna instytucja płatnicza) jest zobowiązany do udostępnienia swojego API podmiotom trzecim. Interfejs musi odpowiadać określonym standardom technicznym. Nie ma tu jednak obowiązku stosowania standardu Polish API. Przykładowo rozwiązania banków Citi Handlowy i Volkswagen Financial Services zostały stworzone bez opierania się o standard Polish API.
Wspólnym elementem dla wszystkich implementacji interfejsów komunikacyjnych jest wymóg posiadania przez ASPSP oraz TPP certyfikatów służących do wzajemnej identyfikacji wystawionych przez kwalifikowanych dostawców usług zaufania.
Środowiska testowe API
Podmioty prowadzące rachunki udostępniają pomiotom trzecim środowiska testowe swoich API. Wynika to przede wszystkim z obowiązku, jaki nałożyła dyrektywa PSD2 w tym zakresie - każdy podmiot prowadzący rachunek był zobowiązany do wdrożenia takiego środowiska do 14 marca 2019.
Kto może testować bankowe API?
Zasadniczo banki udostępniają swoje środowiska testowe tylko podmiotom posiadającym już status TPP, czyli tym z uprawnieniami do świadczenia usług PIS/AIS oraz podmiotom, które są w trakcie uzyskiwania takich uprawnień.
Niektóre banki (np. mBank) udostępniają API także innym podmiotom, które w ich ocenie mogą tworzyć interesujące rozwiązania.
Uwierzytelnianie użytkowników
Standard Polish API uwzględnia dwie metody uwierzytelniania klienta, dzięki któremu dostęp do rachunku będzie możliwy za pośrednictwem podmiotu trzeciego.
Pierwsza z nich zakłada przekierowanie na stronę ASPSP w celu podania loginu i hasła. Tutaj procedura przypomina rozwiązanie znane z płatności za pomocą pay-by-linków. Dane uwierzytelniające podawane są wyłącznie na stronie dostawcy usług płatniczych.
Druga metoda wymaga użycia zewnętrznego narzędzia autoryzacyjnego (EAT, External Authorization Tool) odpowiadającego za generowanie i wyświetlanie użytkownikowi kodów.
Do tego narzędzia użytkownik także musi się zalogować. Wygenerowany w nim kod należy podać w formularzu dyspozycji na stronie lub aplikacji TPP.
TPP wraz z żądaniem nawiązania sesji z XS2A przekazuje kod EAT podmiotowi prowadzącemu rachunek. ASPSP inicjuje weryfikację otrzymanego kodu, komunikując się z EAT. W narzędziu EAT zostaną wyświetlone użytkownikowi informacje o wykonywanej transakcji. Informacja o poprawnej weryfikacji kodu EAT jest wysyłana do ASPSP. Po tym procesie, w uproszczeniu, następuje nawiązanie sesji XS2A i wywołanie żądanej usługi interfesju.
Zgodnie z zapowiedziami autorów Polish API, w jego kolejnych wersjach mają pojawić się inne metody uwierzytelniania użytkowników.