Rozwiązanie funkcjonalne

Proces uwierzytelnienia PSU po stronie ASPSP został opracowany w oparciu o metodę authorization code, zdefiniowaną w standardzie OAuth 2.0. Poniżej diagram obrazuje sekwencję komunikacyjną, która prowadzi do nawiązania sesji z interfejsem XS2A, z uwzględnieniem uwierzytelnienia PSU metodą redirection

 
jak zacząć ilustracja 1

 

1. Uzyskanie dostępu do API

Dostęp do API możliwy jest po uprzednim zarejestrowaniu się na Portalu deweloperskim i uzyskaniu danych dostępowych (ClientID i ClientSecret). W tym celu należy zarejestrować aplikację i zasubskrybować na wybrane API. W dalszej kolejności dane te przesyłane są w ramach nagłówków X-IBM-Client-Id i X-IBM-Client-Secret i umożliwiają zidentyfikowanie aplikacji TPP.

 

Po spełnieniu wymagań związanych z bezpieczeństwem (nawiązanie połączenia MutualTLS), zarejestrowana aplikacja będzie mogła uzyskać dostęp do API autoryzującego w celu uzyskania tokena dostępowego (access token), który z kolei uprawnia do wywołania API AIS lub PIS zabezpieczonego tymże tokenem. W ramach tokena dostępowego zakodowane są zgody klienta na wykonanie zapytania przez TPP, który token uzyskał.

 

Ze względu na wymóg zapewnienia niezaprzeczalności w komunikacji http stosowana będzie jedynie metoda POST pozwalającą na złożenie podpisu w formacie JWS Signature. W ramach operacji kontekst konkretnego użytkownika określany jest na podstawie tokena dostępowego. Ta zasada dotyczy zarówno żądań wysyłanych przez TPP do interfejsu XS2A ASPSP, jak i żądań przesyłanych z ASPSP do interfejsu XS2A wywołań zwrotnych, udostępnianego przez TPP.

 

Musisz podpisać dane wysyłane w zapytaniu, a Bank podpisze dane odpowiedzi. Podpis zapytania i odpowiedzi znajduje się w sygnaturze JWS w nagłówku HTTP o nazwie “X-JWS-SIGNATURE”.

 

Do generacji podpisu JWS należy użyć certyfikatu Qualified Electronic Seal Certificate (QsealC).

 

W przypadku PolishAPI do komunikacji są wymagane dwa osobne certyfikaty - QWAC i QSealC, nie jest dozwolone użycie jednego certyfikatu do obydwu zastosowań.

 

Podpis JWS składa się z trzech części: nagłówka, podpisywana treść i podpisu. Każda z części jest kodowana za pomocą Base64. Wszystkie części są rozdzielone od siebie za pomocą kropek. Podpisywana treść zawiera dokładnie te same informacje co komunikat. Aby nie duplikować wysyłanych danych podpis JWS w PolishAPI jest w wersji „Detached”, czyli nie zawiera podpisywanej treści, w związku z tym podpis wygląda w następujący sposób:

[header]...[signature]
 

HEADER: ALGORITHM & TOKEN TYPE (NAGŁÓWEK)

{ "b64": false, "http://openbanking.org.uk/iat": 1543587262, "crit": [ "b64", "http://openbanking.org.uk/iat", "http://openbanking.org.uk/iss" ], "kid": "nWNjoBVmFEhkEI-YPmgOXlTniTU", "typ": "JOSE", "http://openbanking.org.uk/iss": "C=GB, O=OpenBanking, OU=0015800001ZEZ3WAAX, CN=4tHCFYzhmRTp5ed7Tr5IN6", "alg": "RS256" }

PAYLOAD: DATA (TREŚĆ)
{} ...

VERIFY SIGNATURE (PODPIS)
RSASHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
[Klucz publiczny lub certyfikat. Wprowadź go zwykłym tekstem tylko wtedy, gdy chcesz zweryfikować token],
[Prywatny klucz. Wprowadź go zwykłym tekstem tylko wtedy, gdy chcesz wygenerować nowy token. Klucz nigdy nie opuszcza Twojej przeglądarki.]
)

Standard PolishAPI, mając na uwadze względy wydajnościowe komunikacji poprzez interfejsy XS2A oraz wywołań zwrotnych, a także potencjalne trudności w zarządzaniu infrastrukturą kryptograficzną, związane z możliwością wykorzystania nieograniczonej ilości certyfikatów, wprowadza następujący wymóg, będący rozszerzeniem standardu RFC 7515 w kontekście parametrów nagłówka podpisu JWS-SIGNATURE:

 

Sposób nawiązanie komunikacji z interfejsami OpenAPI jest niezależny od tego czy TPP nawiązuje komunikację z API PIS, AIS czy z API autoryzującym użytkownika i wygląda następująco:

 

1. Nawiązanie sesji Mutual TLS

 

TPP nawiazuje sesję MutualTLS przy użyciu certyfikatu kwalifikowanego QWAC, wydanego przez zaufane TSP*

 

2. Przekazanie certyfikatu QSealC TPP i danych uwierzytelniających do PEKAO

 

a. TPP konstruuje komunikat żądania i wysyła go wraz z danymi uwierzytelniający (ClientId, ClientSecret) oraz lokalizacją własnego certyfikatu qseal (x5u) i danymi identyfikującymi ten certyfikat (kid, x5t#s256). Lokalizacja certyfikatu może być wysłana wyłącznie przy pierwszym komunikacie do PEKAO, gdyż taki certyfikat zostanie zbuforowany po stronie PEKAO i będzie wykorzystany podczas obsługi kolejnych komunikatów.

 

b. Pobranie certyfikatu qseal z serwera TPP. Lokalizacja certyfikatu QSealC TPP jest zabezpieczona za pomocą TLS (certyfikat TLS wydany przez zaufane CA **)

 

c. Weryfikacja podpisu komunikatu JWS-Signature, certyfikat qseal TPP musi być wydany przez zaufane TSP***

 

W ramach przekazanego podpisu weryfikowane są uprawnienia TPP do wykonania poszczególnych operacji (AIS, PIS jak również realizacja przepływu OAuth dla AIS, PIS)

 

3. Zwrócenie odpowiedzi do TPP wraz z lokalizacją certyfikatu qseal PEKAO (x5u) oraz danymi identyfikującymi certyfikat (kid, x5t#s256).*, **, *** - w ramach konfiguracji PEKAO do zaufanych, należą TSP określone regulacją PSD2. W przypadku korzystania z certyfikatów wydanych przez inne CA należy ten fakt zgłosić do PEKAO celem weryfikacji możliwości rozszerzenia konfiguracji (dla środowiska SANDBOX).

 jak zacząć ilustracja 2

 

2. Dostępne usługi API

Interfejs oparty jest na PolishAPI w wersji 2.1.1

  • OpenAPI - Authorization Service - umożliwiające przeprowadzenie procesu uwierzytelnienia i autoryzacji PSU i uzyskanie access_tokena.
    • authorize
    • token
  • AIS - Account Information Services - usługa dostępu do informacji o rachunku. Interfejs API umożliwia uzyskanie wybranych informacji dotyczących rachunku płatniczego, uzyskanie danych dotyczących historii transakcji, uzyskanie danych szczegółów operacji. Interfejs zapewnia również mechanizmy filtrowania danych.
    • getAccount, zwraca szczegółowe informacje odnośnie rachunku klienta
    • getAccounts, zwraca listę rachunków klienta
    • getHolds, zwraca listę transakcji zablokowanych
    • getTransactionsDone, zwraca listę transakcji zaksięgowanych
    • getTransactionsRejected, zwraca listę transakcji odrzuconych
    • getTransationDetail, zwraca szczegóły dotyczące pojedynczej transakcji
    • getTransactionsScheduled, zwraca listę transakcji zaplanowanych
    • deleteConsent, umożliwia cofnięcie zgody
  • PIS - Payment Initiation Services - Interfejs API umożliwia zainicjowanie wykonania przelewu pojedynczego: z datą bieżącą, z datą przyszłą, przelewu cyklicznego. Obsługiwane są zlecenia: przelew krajowy (Elixir), przelew krajowy do Organu Podatkowego/Izby Celnej w Polsce, przelew zagraniczny (SWIFT, SEPA).
    • domestic, inicjuje przelew krajowy
    • tax, inicjuje przelew do urzędu skarbowego
    • nonEEA, inicjuje przelew walutowy SWIFT
    • nonEEA, inicjuje przelew walutowy SWIFT
    • EEA, inicjuje przelew walutowy SEPA
    • getPayment, zwraca status pojedynczej płatności
    • recurring, inicjuje przelew cykliczny (zlecenie stałe)
    • getRecurringPayment, zwraca status płatności cyklicznej
    • cancelPayments, odwołuje płatność z datą przyszłą
    • cancelRecurringPayment, odwołuje płatność cykliczną
  • CAF - Confirmation of Availability of Funds - usługa potwierdzania dostępności na rachunku płatniczym płatnika kwoty niezbędnej do wykonania transakcji płatniczej 
    • getConfirmationOfFunds, zwraca informację o dostępności środków

 

3. Procesy udzielenia zgody PSU wspierane przez API

API dla AIS wspiera 2 procesy udzielania zgody na usługę AIS (w opcji z uwierzytelnianiem po stronie ASPSP):

  • z ręcznym wprowadzeniem numeru rachunku (rachunków)
  • z wyborem numeru rachunku (rachunków) po stronie ASPSP

API dla PIS wspiera procesy udzielenia zgody PSU na wykonanie usługi PIS w wariantach zakładających ręczne wprowadzenie numeru rachunku po stronie TPP oraz wybór rachunku po stronie ASPSP.

 

4. Mechanizm uwierzytelnienia

Bank Pekao wykorzystuje jedynie mechanizm uwierzytelniania po stronie ASPSP, co oznacza, że dane uwierzytelniające i autoryzacyjne PSU podawane są wyłącznie na stronie internetowej ASPSP. Uwierzytelnienie PSU przeprowadzane jest w interfejsie ASPSP.

 

5. Mechanizm obsługi zapytań AIS inicjowanych automatycznie przez TPP bez obecności klienta dla zgody wielokrotnej

Dla zapytań w ramach usługi AIS w zakresie Zgodności z PolishAPI wprowadzamy ograniczenie 4 zapytań w ciągu 24 godzin liczonych od momentu przesłania pierwszego zapytania, w przypadku, gdy pobranie danych nie jest inicjowane na żądanie Klienta, ale automatycznie przez TPP (AISP) na mocy zgód wyrażonych uprzednio przez klienta.

Logika biznesowa:

  • Do odczytywania historii transakcji domyślnie będzie ustawiona liczba 90 dni wstecz. Jeśli TPP zapyta o historię AIS dłuższą niż 90 dni takie zapytanie będzie odrzucone z komunikatem błędu "kod 403 - Forbidden".
  • Zliczanie zapytań AIS będzie odbywać się na podstawie 5 minutowych odcinków czasu, obejmujących 24 godziny wstecz. W trakcie 5 minut będzie możliwe wielokrotne wywołanie tej samej operacji.
  • Przekroczenie 4 wywołań w ciągu 24 godzin, spowoduje wystąpienie wyjątku i komunikat błędu „kod 429 – Too Many Requests"

 

6. Odstępstwa od standardu PolishAPI

  • Brak wsparcia dla Przelewu wielokrotny (paczka przelewów) – niedostępny w interfejsie online bankowości elektronicznej dla klientów detalicznych (Pekao24), funkcjonalność obsługi paczek realizowana dla klientów korporacyjnych (PekaoBiznes24)
  • Brak możliwości zainicjowania płatności w systemach SORBNET2, Blue Cash, TARGET funkcje te są niedostępne w Pekao24 (klient detaliczny). Brak obsługi w Interfejsie zainicjowania płatności w systemach Express Elixir i Blue Cash – niedostępne w PekaoBiznes24 (klient korporacyjny);
  • Brak funkcjonalności zapytania o status wielu płatności (getMultiplePayments) – opcja w PolishAPI. Funkcjonalność realizowana dla klientów korporacyjnych.
  • Brak wsparcia obsługi informacji o statusie transakcji dla metod: paymentCallBack, recurringPaymentCallBack – opcja w PolishAPI
  • Przelew zagraniczny EEA i Przelew zagraniczny inny niż EEA – dodanie jako wymagalnego pola Kod kraju odbiorcy przelewu - Zgodny z normą ISO 3166-1 alfa-3 – tutaj zgodność z wersją 2.1.2 PolishAPI - jest to pole wymagane do zlecenia przelewu w systemie Banku.
  • W AIS brak wsparcia dla getTransactionsPending – informacja niedostępna w interfejsie online bankowości elektronicznej dla klientów detalicznych (Pekao24)
  • Brak wsparcia dla mechanizmu uwierzytelniania w zewnętrznym narzędziu autoryzacyjnym (decoupled)
  • Brak wsparcia dla procesu udzielania zgody na usługę AIS z pobraniem listy rachunków. Ten proces jest procesem opcjonalnym i jego implementacja zależy od decyzji ASPSP.
  • Obecnie brak obsługi we frontendach klienckich możliwości wyrażenia zgody na odpytanie o wystarczające dostępne środki na rachunku. Po stronie API jest wystawiona usługa, która umożliwia wysłanie takich zapytań, jednak w odpowiedzi TPP otrzyma obecnie informację o braku możliwość zwrócenia informacji dla danego rachunku.

 

7. Opis SCA w OpenAPI – uwierzytelnienie po stronie ASPSP

W procesie SCA dla OpenAPI dostępne do wyboru przez klienta są 2 metody autoryzacji zgodne z PSD2: kody SMS i autoryzacja mobilna PeoPay.

Mechanizm SCA jest spójny z SCA zastosowanym w interfejsie online bankowości elektronicznej dla klientów detalicznych (Pekao24):

1. PIS – autoryzowanie płatności przez PSU (dalej Klienta):

  • Po inicjacji procesu powiązanego z PSD2 przez Klienta w TPP, Klient zostaje przekierowany do strony logowania w serwisie transakcyjnym (dalej systemie). Klient proszony jest o wprowadzenie numeru Klienta (CIS) oraz maskowanego hasła (zgodnie z obowiązującymi zasadami logowania) - ekran redirection.
  • Po wprowadzeniu powyższych danych uwierzytelniających (CIS + hasło maskowane), system transakcyjny weryfikuje poprawność danych.
  • W przypadku poprawnego logowania, Klient kontynuuje dalszą część procesu poprzez wskazanie rachunku, z którego zostanie zainicjowana płatność dla operacji PIS.
  • W przypadku poprawnego logowania, system wyświetla użytkownikowi szczegóły odwoływanej płatności.
  • W przypadku poprawnego logowania, system wyświetla użytkownikowi szczegółowe informacje o udostępnianym rachunku (dla operacji o ręcznym wyborze rachunku) lub listę wskazanych rachunków (dla operacji wyborem rachunku z listy), w kontekście których Klient chce uzyskać informacje.
  • Po dokonaniu wyboru rachunku system prosi Klienta o dokonanie autoryzacji płatności poprzez wprowadzenie kodu autoryzacyjnego wg obowiązującej metody autoryzacyjnej (SMS lub PeoPay w zależności od wyboru Klienta).

2. PIS – odwołanie płatności przez PSU (dalej Klienta):

  • Po inicjacji procesu powiązanego z PSD2 przez Klienta w TPP, Klient zostaje przekierowany do strony logowania w serwisie transakcyjnym (dalej systemie). Klient proszony jest o wprowadzenie numeru Klienta (CIS) oraz maskowanego hasła (zgodnie z obowiązującymi zasadami logowania) – ekran redirection.
  • Po wprowadzeniu powyższych danych uwierzytelniających (CIS + hasło maskowane), system transakcyjny weryfikuje poprawność danych.
  • Po wyświetleniu szczegółów płatności do odwołania, system prosi Klienta o dokonanie autoryzacji operacji odwołania płatności poprzez wprowadzenie kodu autoryzacyjnego wg obowiązującej metody autoryzacyjnej (SMS lub PeoPay w zależności od wyboru Klienta).

3. AIS – udzielenie zgody przez PSU (dalej Klienta) z ręcznym wyborem rachunku oraz wyborem rachunku z listy (mechanizm wspólny dla
dwóch procesów w ramach operacji AIS):

  • Po inicjacji procesu powiązanego z PSD2 przez Klienta w TPP, Klient zostaje przekierowany do strony logowania w serwisie transakcyjnym (dalej systemie). Klient (na ekranie redirection) proszony jest o wprowadzenie numeru Klienta (CIS) oraz maskowanego hasła (zgodnie z obowiązującymi zasadami logowania) wraz z kodem autoryzacyjnym silnego uwierzytelnienia (SCA) wg obowiązującej metody autoryzacyjnej (SMS lub PeoPay w zależności od wyboru Klienta).
  • Po wprowadzeniu powyższych danych uwierzytelniających (CIS + hasło maskowane), system transakcyjny weryfikuje poprawność danych.

Dodatkowo dla zapytań AIS w przypadku, gdy pobranie danych nie jest inicjowane na żądanie Klienta, ale automatycznie przez TPP (AISP) na
mocy zgód wyrażonych uprzednio przez klienta, co 90 dni dla danej zgody Klient będzie zobligowany przejść procedurę silnego uwierzytelnienia
SCA.

 

8. Weryfikacja scope_details

Błąd walidacji scope_details (400) zostanie zwrócony jeżeli: 

Typ walidacji Przypadki
Niezależne od scope
  • Na liście scope znajdują się scope z różnych grup uprawnień: ais, pis, ais-accounts
  • Element privilegeList jest spoza listy obsługiwanej przez rozwiązanie
  • Jeżeli wartości scope i scopeGroupType są różne
  • Jeżeli w ramach listy rachunków występuje numer rachunku, który nie jest w formacie IBAN (accountNumber i sender w uprawnieniach przelewów domestic, tax, EEA, nonEEA)
  • Jeżeli przekazywane wartości są poza zakresem dopuszczalnych wartości określonych w specyfikacji PolishAPI (swagger)
  • Jeżeli data scopeTimeLimit jest większa niż data bieżąca minus 1 godzina
  • Jeżeli na liście priviliegeList ten sam accountNumber występuje więcej niż 1 raz
Dla scope “ais-accounts”
  • Jeżeli scopeGroupType ma wartość "ais-accounts” i występuje priviligeList ais-accounts:getAccounts i dowolne inne uprawnienie
  • Jeżeli scopeGroupType ma wartość “ais-accounts” i występuje priviligeList ais-accounts:getAccounts i numer konta accou ntNumber jest niepusty
  • Jeżeli scopeGroupType ma wartość “ais-accounts” i występuje priviligeList ais-accounts:getAccounts i zgoda nie jestjednokrotna
  • Jeżeli scopeGroupType ma wartość “ais-accounts” i priviledgeList jest puste
Dla scope “ais”
  • Jeżeli scopeGroupType ma wartość "ais” i występuje priviligeList gdzie numer rachunku accountNumber jest pusty
  • Jeżeli w ramach listy uprawnień w privilegeList parametr maxAllowedHistoryLong ma różną wartość (muszą być identyczne dla wszystkich elementów)
  • Jeżeli w ramach listy uprawnień znajduje się ais:getTransactionsRejected, ais:getHold, ais:getTransactionsPending, ais:getTransactionsCanceled, ais:getTransactionsScheduled i/lub ais:getTransactionsDone i nie występuje ais:getAccount
  • Jeżeli w ramach listy uprawnień znajduje się ais:getTransactionDetail i nie występuje jedno lub wielu zgód z listy ais:getHolds, ais:getTransactionsDone, ais:getTransactionsRejected, ais:getTransactionsPending, ais:getTransactionsCanceled, ais:getTransactionsScheduled
  • Jeżeli generowanie następuje na podstawie exchange_token, scopeGroupType ma wartość “ais” i data w polu scopeTimeLimit jest większa niż data scopeTimeLimit podana dla zgody „ais-accounts” (dla exchange_token)
Dla scope “pis”
  • Jeżeli scopeGroupType ma wartość "pis”, występuje jedno z [pis:domestic, pis:EEA, pis:nonEEA, pis:tax], ale nie występuje pis:getPayment. (Samo pis:getPayment jest poprawne)
  • Jeżeli scopeGroupType ma wartość "pis”, występuje jedno z [pis:domestic, pis:EEA, pis:nonEEA, pis:tax] i dodatkowo występuje pis:cancelPayment (Samo pis:cancelPayment jest poprawne)
  • Jeżeli scopeGroupType ma wartość "pis”, występuje [pis:recurring], ale nie występuje pis:getRecurringPayment. (Samo pis:getRecurringPayment jest poprawne)
  • Jeżeli scopeGroupType ma wartość "pis”, występuje jedno z [pis:recurring] i dodatkowo występuje pis:cancelRecurringPayment (Samo pis:cancelRecurringPayment jest poprawne)
  • Jeżeli scopeGroupType ma wartość "pis”, i występuje więcej niż jedno uprawnienie z grupy [pis:domestic, pis:EEA, pis:nonEEA, pis:tax, pis:recurring, pis:bundle]
  • Jeżeli scopeGroupType ma wartość "pis”, i występuje więcej niż jedno uprawnienie z grupy [pis:cancelPayment, pis:cancelRecurring]
  • Jeżeli scopeGroupType ma wartość "pis” i lista privilegeList posiada więcej niż jeden element
  • Jeżeli scopeGroupType ma wartość "pis” i pola accountNumber i sender-accountNumber są wypełnione i nie są zgodne
  • Jeżeli scopeGroupType ma wartość "pis” i wypełnione jest tylko jedno z pole accountNumber lub sender-accountNumber (dopuszcza się oba puste)
  • Jeżeli scopeGroupType ma wartość "pis” i priviledgeList jest puste
  • Jeżeli żądanie inicjacji płatności ma ustawione pole executionMode = FutureDated i nie jest podana wartość executionDate. (Data powinna być w przyszłości).
  • Jeżeli żądanie inicjacji płatności ma ustawione pole executionMode = Immediate i jest podana wartość executionDate (pole executionDate powinno być puste)
  • Jeżeli zgoda dla inicjacji płatności jest wielokrotna
  • Jeżeli scopeGroupType ma wartość "pis”, występuje jedno z [pis:bundle], ale nie występuje pis:getBundle. (Samo pis:getBundle jest poprawne)

 

9. Znane Problemy

Brak możliwości podłączenia do API - jedną z przyczyn może być standardowy błąd DataPower w przypadku naruszenia limitów antyDDOS (liczba headerów, wielkość żadania) które są ustawiane zanim w ogóle dojdzie do obsługi API. Aktualnie to :

  • Maksymalna liczba headerów HTTP: 25
  • Maksymalna długość nazwy headera HTTP: 100 (znaków)
  • Maksymalna długość wartości headera HTTP: 10000 (znaków)

Przekroczeni jednej z powyższych wartości może skutkować odpowiedzią :

<?xml version='1.0' ?>

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>;

<env:Body>

<env:Fault>

<faultcode>env:Client</faultcode>

<faultstring>Internal Error</faultstring>

</env:Fault>

</env:Body>

</env:Envelope>

 

10. Przypadki testowe

1. AIS z podaniem rachunku przez TPP
Usługi  /authorize, /token, /getAccount, /getHolds, /getTransactionDone. /getTransactionDetail, /getTransactionScheduled, /getTransactionRejected
Nr kroku  Opis kroku  Sterowanie  Request body  Response body
1 Wywołanie usługi /authorize:   - wymagane podanie redirect_uri- podanie nr rachunku- scopeGroupType = "ais" aspspRedirectUri (z identyfikatorem sesji logowania) 
2 Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług. Identyfikator sesji logowania zgodny z poprzednim krokiem   redirectUri zawierający authorizationCode
3 Pobieranie tokena     access_token oraz scope_details zgodne z danymi przesłanymi na początku danego scenariusza
 4

Wywołanie usług AIS:

- /getAccount,

- /getHolds,

- /getTransactionDone

- /getTransactionDetail,

- /getTransactionScheduled,

- /getTransactionRejected

  - podanie nr rachunku- access_token Informacje o rachunku/transakcjach w zależności od usługi.
 
2. AIS z wyborem rachunku/ów po stronie ASPSP
Usługi /authorize, /token, /getAccount
Nr kroku Opis kroku Sterowanie Request body Response body
1 Wywołanie usługi /authorize:   - wymagane podanie redirect_uri
- bez podania nr rachunku
- scopeGroupType = "ais-accounts"
aspspRedirectUri (z identyfikatorem sesji logowania)
2 Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług. Identyfikator sesji logowania zgodny z poprzednim krokiem   redirectUri zawierający authorizationCode
3 Pobieranie tokena   authorizationCode access_token oraz scope_details zgodne z danymi przesłanymi na początku danego scenariusza
4

Wywołanie usług AIS

-/getAccounts

  - access_token Informacje o rachunku/ach
 
3. AIS z podaniem rachunku przez TPP + kolejne odpytanie(refresh_token)
Usługi /authorize, /token, /getAccount, /getHolds, /getTransactionDone. /getTransactionDetail, /getTransactionScheduled, /getTransactionRejected
Nr kroku Opis kroku Sterowanie Request body Response body
1 Wywołanie usługi /authorize:  

- wymagane podanie redirect_uri 

- podanie nr rachunku

- scopeGroupType= "ais"

- scopeUsageLimit = multiple

 

aspspRedirectUri (z identyfikatorem sesji logowania)

2 Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług.  

Identyfikator sesji
logowania zgodny z
poprzednim krokiem

  redirectUri zawierający authorizationCode
3 Pobieranie tokena   authorizationCode

access_token, refresh_token oraz
scope_details zgodne z danymi przesłanymi na początku danego scenariusza

4 Wywołanie usług AIS:

-/getAccount,
-/getHolds,
-/getTransactionDone,
-/getTransactionDetail,
-/getTransactionScheduled,
-/getTransactionRejected

   

- podanie nr
rachunku
- access_token

 

Informacje o rachunku/transakcjach w
zależności od usługi.

5 Wygenerowanie nowego tokena (refresh_token)   refresh_token otrzymany w kroku 3 access_token, refresh_token oraz scope_details zgodne z danymi przesłanymi na pocątku danego scenariusza
6  Wywołanie usług AIS:

-/getAccount,
-/getHolds,
-/getTransactionDone,
-/getTransactionDetail,
-/getTransactionScheduled,
-/getTransactionRejected

   

- podanie nr
rachunku
- access_token

 

Informacje o rachunku/transakcjach w
zależności od usługi.

     
4. PIS inicjalizacja płatności
Usługi /authorize, /token, /domestic /tax, /EEA, /nonEEA

Nr
kroku

Opis kroku

Sterowanie Request body Response body
1 Wywołanie usługi /authorize:  

- wymagane podanie
redirect_uri

- podanie nr
rachunku

- scopeGroupType= "pis"

- executionMode= "Immediate"

aspspRedirectUri (z identyfikatorem
sesji logowania)

2

Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług.

Identyfikator sesji
logowania zgodny z
poprzednim krokiem

 

redirectUri zawierający
authorizationCode

3 Pobieranie tokena   authorizationCode

access_token oraz scope_details
zgodne z danymi przesłanymi na
początku danego scenariusza

4

Wywołanie usług PIS:

-/domestic,
-/tax,
-/EEA,
-/nonEEA

 

- podanie nr rachunku
- access_token
- executionMode= "Immediate"

paymentId oraz generalStatus =
"submitted"

 
5. PIS inicjalizacja płatności przyszłej
Usługi /authorize, /token, /domestic /tax
Nr kroku Opis Kroku Sterowanie Request body Response body
1 Wywołanie usługi /authorize:  

- wymagane podanie
redirect_uri

- podanie nr rachunku

- scopeGroupType= "pis"

- executionMode="FutureDated"

aspspRedirectUri (z identyfikatorem sesji logowania)

2

Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług.

Identyfikator sesji
logowania zgodny z
poprzednim krokiem

 

redirectUri zawierający
authorizationCode

3 Pobieranie tokena   authorizationCode

access_token oraz scope_details
zgodne z danymi przesłanymi na
początku danego scenariusza

4

Wywołanie usług PIS:

-/domestic,
-/tax

 

- podanie nr rachunku
- access_token
- executionMode="FutureDated"

paymentId oraz generalStatus =
"submitted"

 
6. PIS inicjalizacja płatności cyklicznej
Usługi /authorize, /token, /domestic
Nr kroku Opis kroku Sterowanie Request body Response body
1 Wywołanie usługi /authorize:  

- wymagane podanie
redirect_uri

- podanie nr rachunku

- scopeGroupType= "pis"

aspspRedirectUri (z identyfikatorem  sesji logowania)
2 Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług. Identyfikator sesji
logowania zgodny z
poprzednim krokiem
  redirectUri zawierający  authorizationCode
3 Pobieranie tokena   authorizationCode access_token oraz scope_details  zgodne z danymi przesłanymi na początku danego scenariusza
4

Wywołanie usług PIS:

-/domestic

  - podanie nr rachunku
- access_token
paymentId oraz recurringPaymentStatus = "submitted"
 
7. PIS anulowanie płatności
Usługi /authorize, /token, /cancelPayments, /getPayment
Nr kroku Opis kroku Sterowanie Request body Response body
1 Wywołanie usługi /authorize:  

- podanie nr rachunku 

- scopeGroupType= "pis"

- paymentId płatności przyszłej lub recurringPaymentId dla płatności cyklicznej

aspspRedirectUri (z identyfikatorem  sesji logowania)
2 Przejście na identyfikator URI przekierowania autoryzacji, który umożliwia wyrażenie zgody na dostęp do oczekiwanych usług. Identyfikator sesji
logowania zgodny z
poprzednim krokiem
  redirectUri zawierający  authorizationCode
3 Pobieranie tokena   authorizationCode access_token oraz scope_details  zgodne z danymi przesłanymi na początku danego scenariusza
4

Wywołanie usług PIS:

-/cancelPayments

 

- podanie nr rachunku

- access_token

- paymentId płatności przyszłej lub recurringPaymentId dla płatności cyklicznej

Dla płatności przyszłej: HTTP 204 No Content 

Dla płatności cykliczenej: recurringPaymentStatus = "cancelled"

5

Wywołanie usług PIS:

- /getPayment

 

- access_token

- paymentId płatności przyszłej lub recurringPaymentId dla płatności cyklicznej

Dla płatności przyszłej: generalStatus = "cancelled" 

Dla płatności cykliczenej: recurringPaymentStatus = "cancelled"

 
8. PIS/AIS usunięcie zgody
Usługi /authorize, /deleteConsent
Nr kroku Opis kroku Sterowanie Request body Response body
1 Wywołanie usługi /authorize:     aspspRedirectUri (z identyfikatorem sesji logowania)
2

Wywołanie usługi:

- /deleteConsent

  consentId wykorzystany w kroku 1 HTTP 204 No Content
 
9. CAF potwierdzenie dostępności środków
Usługi /confirmationOfFunds
Nr kroku Opis kroku Sterowanie Request body Response body
1

Wywołanie usługi:

- confirmationOfFunds

  - podanie nr rachunku "fundsAvailable": true

 

----

Znalazłeś odpowiedź na pytania? Jesli nie skontaktuj się z nami

NAPISZ WIADOMOŚĆ