Sandbox wersja 2_1.5

1. Jakie są dostępne dane Użytkowników testowych?

Udostepniamy dwóch Użytkowników do testów sandbox
 
Użytkownik z segmentu detalicznego, dostępne konta
• PL16160010420002014739310011
• PL60160037856089653937406221
• PL44160084586221235245815289
 
Użytkownik z segmentu korporacyjnego
• PL84160049715996515293291378
• PL29160067992774956903060251

2. Jak zalogować się do zaślepki autoryzacyjnej?

Po połączeniu z zaślepką autoryzacyjną ekran logowania jest pomijany i jest prezentowany zakres zgody do zatwierdzenia

3. Jak można uzyskać zgodę na usługi CAF?

W środowisku sandbox tylko dla rachunku PL16160010420002014739310011 istnieje aktywna zgoda CAF

4. Jakie typy formularza podatkowego są dostępne do testów dla przelewów typu tax?

odpowiedz.Zostały udostępnione dwa typy formularza do testów
• VAT (przelew na konto indywidulane)
• AKC (przelew na konto do Urzędu Skarbowego PL84101012700008242224000000)

5. Czy wszystkie usługi są dostępne w sandbox?

W wersji sandbox 2_1.5 nie ma możliwosci przetestowania paczek płatnosci (bundle payments). Pracujemy nad dodaniem tego zakresu do sandbox.

6. Czy jest możliwość przetestowania procesu odrzucenia płatności?

Udostępniliśmy negatywny przypadek do testów, który zakończy się odrzuceniem płatności (status REJECTED). Wystarczy wprowadzić kwotę przelewu w wysokości 666.00

7. Czy na środowisku sandbox jest walidowany podpis JWS?

Tak. W zakresie JWS, korzystamy z formatu detached (standard RFC 7515), tak więc w X-JWS-SIGNATURE należy podać:
• Base64URLencode(JWSHeader) + ".." + Base64URLencode(sign(Base64URLEncode(JWSHeader) + "." + Base64URLencode(payload)))
• Podpisany payload i payload z zapytania nie mogą się różnić nawet na poziomie białych znaków, tj. spacje, tab, CR, LF
 

8. Jak zostały zgrupowane usługi w ramach grup: AS, AIS, PIS, CAF dla usprawnienia ich wyboru?

Usprawniliśmy wybór naszych usług, które zostały zgrupowane  w ramach grup: AS, AIS, PIS, CAF. Zgodnie z poniższym schematem:
 
• PolishAPI v2_1.5
  • AS v2_1.5
  • AIS v2_1.5
  • PIS v2_1.5
  • CAF v2_1.5

 

Proces rejestracji

W celu otrzymania dostępu do środowiska API PSD2 (w zakresie usług AIS, PIS lub CAF) należy:
  1. Zarejestrować się w API Portalu:  → Zarejestruj 
  2. w przypadku podmiotów posiadających status TPP
    1. przesłać na adres open-banking@bnpparibas.pl dokument potwierdzający posiadanie zezwolenia wydanego przez Komisję Nadzoru Finansowego lub inny właściwy organ krajowy państwa członkowskiego lub
    2. przedstawić się certyfikatem eIDAS zgodnym z art. 34 RTS
  3. w przypadku podmiotów ubiegających się o status TPP (dostęp tylko do Sandbox)
    1. przesłać na adres open-banking@bnpparibas.pl potwierdzenie złożenia wniosku we właściwym organie lub
    2. przedstawić się testowym certyfikatem eIDAS zgodnym z art. 34 RTS
 

Produkcja wersja 2_1.5

1. Jaka jest wspierana wersja PolishApi?

Wersja swaggera 2_1.5 wzorowane jest na standardzie PolishaPI 2.1. Wprowadziliśmy część usprawnień, które pochodzą z późniejszej wersji PolishaPI 2.1.1

2. Jaki jest stosowany format podpisu JWS?

W zakresie JWS, korzystamy z formatu detached (standard RFC 7515), tak więc w X-JWS-SIGNATURE należy podać:
• Base64URLencode(JWSHeader) + ".." + Base64URLencode(sign(Base64URLEncode(JWSHeader) + "." + Base64URLencode(payload)))
• Podpisany payload i payload z zapytania nie mogą się różnić nawet na poziomie białych znaków, tj. spacje, tab, CR, LF

3. W jaki sposób uzyskać dostęp do środowiska produkcyjnego API?

a. Aby uzyskać dostęp do produkcyjnego API, należy w pierwszej kolejności dostarczyć certyfiakty produkcyjne.
b. Następnie należy przełączyć wszystkie wykorzystywane usługi na plan “Produkcyjny” w API Portalu  (Aplikacje -> Edycja -> Zarządzanie API -> Zmień Plan). Po akceptacji przez pracownika Banku, zostanie wysłana wiadomość e-mail z potwierdzeniem zmiany planu API.
c. Jeżeli chcą Państwo przepiąć aplikację, która była wykorzystywana do testowania na poziomie Sandboxa, to należy zmodyfikować parametry tej aplikacji tak, aby odpowiadały środowisku produkcyjnemu (np. tppId, URL żądania zwrotnego). Nowe parametry odświeżają się w przeciągu 5 minut. Jeżeli chcą Państwo zachować komunikację zarówno ze środowiskiem Sandbox jak i produkcyjnym, to należy utworzyć odrębne aplikacje do komunikacji z każdym ze środowisk.

4. Czy jest mozliwośc wprowadzenia większej ilości adresów redirect_uri?

W API Portalu (Aplikacje -> Edycja ->) jest możliwość podania kilku adresów redirect rozdzielanych spacją lub przecinkiem (obydwie formy są poprawne). 

5. Jak można uzyskać zgodę na usługi CAF?

W środowisku produkcyjnym odpytanie o uługę CAF jest możliwe tylko po wcześnejszym wydaniu zgody przez PSU. Zgoda może zostać wydana w Bankowosci Elektronicznej.

6. Jaki zakres zgody jest akceptowany w usłudze authorize?

a. W przypadku zgód w ramach PIS, akceptowany jest jeden zakres zgody. Nie wspieramy możliwości udzielenia zgody na zlecenie przelewu np. krajowego i podatkowego w ramach jednej zgody.
b. W przypadku zgód AIS, jest możliwość zdefiniowania większego zakresu zgód, ale muszą być one podane z tego samego zakresu, czyli: getAccount, getTransactionDone, getTransactionDetail, getTransactionRejected, getHolds 
c. W przypadku zgód AIS-ACCOUNTS akceptowany jest jeden zakres zgody. Nie wspieramy możliwości udzielenia dwóch zgód ais-accounts, czy zgody ais-accounts i np. zgody szczegółowej ais.

7. Czy wspierana jest metoda exchangeToken?

Tak. Metoda exchangeToken słuzy do wymiany zgody ais-accounts na zgody szczegółowe ais. W tym celu wymagane jest pobranie w pierwszej kolejności listy rachunków przez metodę ais-accounts, a następnie przy użyciu metody token z grant_type:exchange_token wystąpić o wymianę zgody na zgody szczegółowe ais podając dla jakiego rachunku i na jaki zakres. Wspieramy metodę exchangeToken zarówno dla zgód jednorazowych (typu single) oraz zgód wielorazowych (typu multiple).
Metoda exchangeToken nie wpływa na wydłużenie czasu ważności zgody, data pozostaje taka sama na jaką wyraził zgodę PSU podczas zatwierdzenia zgody ais-accounts.

8. Czy wspierana jest metoda refreshToken? 

a. Tak. Czas ważności tokena dostępowego wynosi 5 minut, jeżeli upłynie można go odświeżyc przez metodę token w trybie grant_type=refresh_token. Odświeżenie ważności tokena jest możliwe tylko dla zgód wielorazowych (typu multiple) oraz w czasie ważnosci zgody. Należy podać ten sam identyfikator zgody (consentId), który został podany w czasie występowania o zgodę.
b. W przypadku usług PIS, wydawane tokeny są jednorazowe i nie ma możliwości użycia metody refreshToken.
c. Natomiast wspierany jest proces użycia refreshToken w celu wymiany zgody do zlecenia płatności na usługę służącą do pobrania statusu płatności (getPayment), paczki (getBundle) oraz zlecenia stałego (getRecurring). Proces został zaimplementowany zgodnie ze standardem PolishApi 2.1.1

9. W jaki sposób zwracane są dane adresowe w usłudze getAccount?

Sposób zwracania danych adresowych w usłudze getAccount jest stały tzn.
• pierwsza linia adresowa to nazwa firmy/ imię i nazwisko właściciela rachunku
• druga linia to ulica i numer
• trzecia linia to kod pocztowy, miejscowość
• czwarta linia to kraj 
Proszę pamiętać, ze może być sytuacja, w których dana linia w adresie nie zostanie zwrócona. Powodem jest brak danych w kartotece klienta.

10. Jak działa licznik zapytań dla AIS?

a. Zgodnie z wytycznymi, TPP ma możliwość do 4 razy w ciągu 24h pobrać informację o operacjach na rachunku bez udziału PSU. 
b. Licznik dla zgód getAccount, getTransactionsDone, getTRasnactionDetail, getTRansactionsRejected oraz getHolds nadawany jest w ramach danej aplikacji TPP (client_id)  dla  każdego typu zgody w obrębie danego rachunku oddzielnie. W czasie ważności tokena, licznik nie jest podnoszony.
c. Licznik dla zgód getAccounts nadawany jest w ramach danej aplikacji TPP (client_id) oraz identyfikatora zgody (consentId)
d. W przypadku przekroczenia limitu zwracana jest odpowiedz z kodem HTTP 429 wraz z komunikatem informującym, które wywołania (requestId) spowodowały podbicie licznika. Po przekroczeniu licznika, kolejne wywołanie można wykonać po upływie 24h od pierwszego wywołania.

11. W jaki sposób jest możliwość pobrania historii transakcji powyżej 90 dni?

a. Udostępniliśmy możliwość pobrania historii > 90dni w czasie ważności zgody.
b. Należy pamiętać, ze zakres historii transakcji jest definiowany w usłudze authorize w parametrze maxAllowedHistoryLong.
c. Podczas odpytania o szczegóły historii transakcji, jeżeli nie zostaną wprowadzone daty z jakiego przedziału mają zostać zwrócone transakcje, domyślnie zwrócimy transakcje zgodnie z wprowadzoną wartością w parametrze maxAllowedHistoryLong.

12. W jaki sposób zatwierdzić zgodę w ramach klienta z segmentu korporacyjnego?

W usłudze authorize najlepiej uzupełnić parametry:
• isCompanyContext z wartością true.
              Dodatkowe uzupełnienie poniższych parametrów pozwoli na właściwe ustawienie kontekstu firmy:
• psuContextIdentifierType – zgodnie z naszym swaggerem może to być NIP („N”) albo Regon („R”):
• psuContextIdentifierValue - wartość odpowiadająca wskazanemu wcześniej identyfikatorowi (NIP lub REGON)
Po przekazaniu powyższych danych, zostanie zwrócony adres redirectUrl do bankowości korporacyjnej, w której PSU będzie miał możliwość zatwierdzenia zgody