Bankowe API w praktyce. Jak łączą systemy i partnerów?

API to uzgodniony sposób rozmowy

Wyobraź sobie aplikację, która ma wyświetlić historię rachunku użytkownika. Potrzebuje danych z banku, ale nie powinna znać szczegółów jego systemu centralnego ani struktur wewnętrznych baz danych. API określa, o co może zapytać, w jakim formacie i jaką odpowiedź otrzyma.

Po obu stronach istnieje wspólna umowa techniczna: nazwy operacji, pola danych, reguły uwierzytelniania i sposób informowania o błędach. Dzięki temu zespoły mogą rozwijać systemy niezależnie, zachowując uzgodniony interfejs.

Kto uczestniczy w tym połączeniu?

W uproszczonym scenariuszu otwartej bankowości występują trzy role. Użytkownik korzysta z usługi i udziela odpowiednich uprawnień. Bank prowadzi rachunek i udostępnia określone operacje. Uprawniony partner buduje aplikację lub usługę korzystającą z interfejsu banku.

Pomiędzy nimi działa infrastruktura techniczna: warstwa API, mechanizmy uwierzytelniania i integracja z systemami banku. Dla zespołów partnera równie ważne są dokumentacja oraz środowisko testowe.

Dobre API pomaga obu stronom wiedzieć, co ma się wydarzyć — także wtedy, gdy coś pójdzie inaczej niż planowano.

Dane i płatności to różne scenariusze

AIS, czyli usługa dostępu do informacji o rachunku, dotyczy pozyskiwania określonych informacji. Mogą one służyć na przykład do prezentacji finansów użytkownika. PIS, czyli usługa inicjowania płatności, rozpoczyna zlecenie płatnicze na wniosek użytkownika.

Te scenariusze mają różne cele i przebiegi. Nie można utożsamiać możliwości odczytu danych z prawem do zlecania płatności. Rola dostawcy i zakres dostępu muszą odpowiadać danej usłudze.

Po co wspólny standard?

Gdy każdy bank opisuje podobną operację inaczej, partner musi obsługiwać wiele wariantów. Standard, taki jak PolishAPI, pomaga uzgodnić wspólny język interfejsu. Ogranicza różnice w specyfikacji i daje zespołom punkt odniesienia.

Nie usuwa jednak całej pracy integracyjnej. Nadal trzeba rozumieć wersję interfejsu, obsługiwane scenariusze, zakres danych i zachowanie konkretnego wdrożenia. Dlatego testowanie poprawnego przebiegu i sytuacji błędnych jest równie istotne jak przeczytanie specyfikacji.

Co decyduje o jakości integracji?

W praktyce liczy się kilka elementów jednocześnie:

• Dokumentacja — opisuje rzeczywiste działanie i jest aktualna.
• Sandbox — pozwala sprawdzić scenariusze, a jego ograniczenia są znane.
• Błędy — mają znaczenie, które zespół partnera potrafi obsłużyć.
• Uprawnienia — są spójnie egzekwowane w całym przebiegu.
• Monitoring i kontakt — pomagają zlokalizować problem i przypisać odpowiedzialność.

Przegląd API warto zacząć od rzeczywistych przykładów: żądania, odpowiedzi, czasu wykonania i kontekstu zgłoszenia. To lepsza podstawa diagnozy niż ogólne stwierdzenie, że „integracja nie działa”.