Sandbox version 2_1.5

1. What Test Users data are available?

We provide two users for sandbox tests: 
 
User from the retail segment, available accounts
PL16160010420002014739310011
PL60160037856089653937406221
PL44160084586221235245815289
 
User from the corporate segment
PL84160049715996515293291378
PL29160067992774956903060251

2. How to log in to the authorization plug?

After connecting to the authorization plug, the login screen is omitted and the scope of consent is presented for approval.

3. How to log into the sandbox, being a client from the corporate segment?

In the authorize service, the parameters should be completed:
isCorporateContext with the value true.
 
Additional completion of the following parameters will allow you to properly set the context of the company:
psuContextIdentifierType – according to our swagger, it can be NIP ("N") or Regon ("R"):
psuContextIdentifierValue - value corresponding to the previously indicated identifier (NIP or REGON)
 
After submitting the above data, a redirectUrl address will be returned to corporate banking, where the PSU will have the opportunity to approve the consent

4. How can I get approval for CAF services?

In the sandbox environment, there is an active CAF consent only for the account: PL16160010420002014739310011

5. What types of tax forms are available for testing tax transfers?

Two types of form for testing are provided:
VAT (transfer to an individual account)
AKC (transfer to the account of the Tax Office PL84101012700008242224000000)

6. Are all services available in the sandbox?

Yes

7. Is it possible to test the payment rejection process?

We have provided a negative case for testing, which will result in payment rejection (REJECTED status). You need to enter the transfer in the amount of 666.00.

8. Is the JWS signature validated on the sandbox?

Yes. For JWS, we use the detached format (RFC 7515 standard), so in X-JWS-SIGNATURE you should provide:
Base64URLencode(JWSHeader) + ".." + Base64URLencode(sign(Base64URLEncode(JWSHeader) + "." + Base64URLencode(payload)))
The signed payload and payload from the query cannot differ even on the whitespace level, i.e. spaces, tab, CR, LF.
 

9. How were the services grouped within the groups: AS, AIS, PIS, CAF to improve their selection?


We have improved the selection of our services, which have been grouped under the following groups: AS, AIS, PIS, CAF. According to the diagram scheme below:
 
PolishAPIv2_1.5
  • AS v2_1.5
  • AIS v2_1.5
  • PIS v2_1.5
  • CAF v2_1.5

10. Do we have additional data in the AUX Data field?

For getAccount we have a "usedCardLimit" field, i.e. the used limit on the credit card. Applies only to the account related to the credit card, you can test it on the account shared on Sandbox PL60160037856089653937406221.

For other AIS services (getTransactionsDone, getTransactionsRejected, getHolds) we have an additional field "auxData": {"virtualAccount": "16175000120000000038745204"}, thanks to which we receive information about the virtual account number obtained from the MassCollect service.

 

Registration process

In order to get access to the PSD2 API environment (in terms of AIS, PIS or CAF services) you should:
  1. Register in the API Portal → Signup
  2. for entities with TPP status
    1. send to the address open-banking@bnpparibas.pl a document confirming the possession of a permit issued by the Polish Financial Supervision Authority or  other competent national authority of a Member State, or
    2. introduce yourself to the eIDAS certificate in accordance with art. 34 RTS
  3. for entities applying for TPP status (Sandbox access only)
    1. send to the address open-banking@bnpparibas.pl confirmation of submitting the application to the competent authority or
    2. introduce yourself to the eIDAS test certificate in accordance with art. 34 RTS

 

Production version 2_1.5

1. What is the supported version of PolishApi?

Swagger version 2_1.5 is modeled on the PolishAPI 2.1 standard. We have introduced some of the improvements that come from the later version of PolishAPI 2.1.1

2. What is the JWS signature format used?

For JWS, we use the detached format (RFC 7515 standard), so in X-JWS-SIGNATURE you should provide:
Base64URLencode(JWSHeader) + ".." + Base64URLencode(sign(Base64URLEncode(JWSHeader) + "." + Base64URLencode(payload)))
The signed payload and payload from the query cannot differ even on the whitespace level, i.e. spaces, tab, CR, LF.

3. How do I get access to the API production environment?

a. To access the production API, you must first provide the production certificates.
b. Then switch all used services to the "Production" plan in the API Portal (Applications -> Edit -> API Management -> Change Plan). After approval by the Bank's employee, an e-mail will be sent confirming the change of the API plan.
c. If you want to replace the application that was used for testing at the Sandbox level, you should modify the parameters of this application so that they correspond to the production environment (eg tppId, callback URL). The new parameters are refreshed within 5 minutes. If you want to maintain communication with both the Sandbox and production environment, you should create separate applications for communication with each environment.

4. Is it possible to enter more redirect_uri addresses?

In the API Portal (Applications -> Edit ->) it is possible to specify several redirect addresses separated by a space or a comma (both forms are correct).

5. How can I get approval for CAF services?

In the production environment, querying the CAF service is possible only after prior consent of the PSU. The consent may be issued in Electronic Banking.

6. What scope of consent is accepted in the authorize service?

a. In the case of PIS consent, only one scope of consent is accepted. We do not support the possibility of giving consent to order a transfer, e.g. domestic and tax transfer, within one consent.
b. In the case of AIS consents, it is possible to define a larger scope of consents, but they must be given from the same scope, that is: getAccount, getTransactionDone, getTransactionDetail, getTransactionRejected, getHolds
c. In the case of AIS-ACCOUNTS consents, one scope of consent is accepted. We do not support the possibility of granting two ais-accounts consents or ais-accounts consent and e.g. specific ais consent.

7. Is the exchangeToken method supported?

Yes. The exchangeToken method is used to exchange ais-accounts consent into ais specific consents. For this purpose, it is required to first download the list of accounts using the ais-accounts method, and then use the token method from grant_type: exchange_token to request an exchange of consent for specific consents, specifying for which account and for what scope. We support the exchangeToken method for both single and multiple consents.
The exchangeToken method does not extend the validity period of the consent, the date remains the same as the PSU's consent was given when approving the consent of ais-accounts.

8. Is the refreshToken method supported? 

Yes. The validity time of the access token is 5 minutes, if it expires, it can be refreshed by the token method in the grant_type = refresh_token mode. Refreshing the validity of the token is possible only for multiple consents and during the validity of the consent. The same consent ID (consentId) that was provided at the time of consent request must be entered.
In the case of PIS services, the issued tokens are one-off and it is not possible to use the refreshToken method.
The process of using the refreshToken is supported in order to exchange the consent to the payment order for the service used to retrieve the payment status (getPayment), the package (getBundle) and the standing order (getRecurring). The process has been implemented in accordance with the PolishApi 2.1.1 standard.

9. How are the address data returned in the getAccount service?

The returning address data in the getAccount service is as follow:
the first address line is the company name / name and surname of the account owner
the second line is street and number
the third line is the zip code, town
the fourth line is country 
Please remember that there may be situations in which a given line in the address will not be returned. The reason is the lack of data in the customer's file.

10. How does the AIS query counter work?

a. According to the guidelines, TPP has the option to download information on account operations up to 4 times within 24 hours without PSU's participation.
b. The counter for getAccount, getTransactionsDone, getTRasnactionDetail, getTRansactionsRejected and getHolds consents is assigned within a given TPP application (client_id) for each consent type within a given account separately. While the token is valid, the counter is not raised.
c. The counter for getAccounts consents is assigned within the given TPP application (client_id) and the consent identifier (consentId).
d. If the limit is exceeded, a response with the HTTP 429 code is returned along with a message informing which calls (requestId) caused the counter boost. After exceeding the counter, the next call can be made after 24 hours from the first call.

11. How is it possible to download the transaction history over 90 days ?

a. Yes, it's possible to download the history> 90 days during the validity of the consent.
b. Please note that the scope of the transaction history is defined in the authorize service in the maxAllowedHistoryLong parameter.
c. When asking for details of the transaction history, if the dates from which the transactions are to be returned are not entered, by default we will return the transactions according to the value entered in the maxAllowedHistoryLong parameter.

12. How is it possible to approve consent within the corporate segment client?

In the authorize service, the parameters should be completed:
isCompanyContext with the value true
              Additional completion of the following parameters will allow you to properly set the company context:
psuContextIdentifierType – according to our swagger, it can be NIP ("N") or Regon ("R"):
psuContextIdentifierValue - value corresponding to the previously indicated identifier (NIP or REGON)
After providing the above data, the redirecturl will be returned to corporate banking, where the PSU will have the option to approve the consent.