PSD2 service provider conecting issues (sandbox)

New-Pink-Lion-2906228819

Hello,
found several issues with the PSD2 service provider connecting.
The first one:

Performed installation call
Performed payment-service-provider-credential call
Tried to perform a device-server call using the script:
` #!/usr/bin/env bash
request='{
"description": "Token test app",
"secret": "here was an API KEY from the generated sandbox user's API KEYS"
}'

installationToken="here was an token value from the installation response"

signature=$(printf "$request" | openssl dgst -sha256 -sign ./qseal.key | openssl base64 -A)

curl -v -X POST "https://public-api.sandbox.bunq.com/v1/device-server" \
-H "User-Agent: curl" \
-H "Cache-Control: no-cache" \
-H "Content-Type: application/json" \
-H "X-Bunq-Client-Authentication: $installationToken" \
-H "X-Bunq-Client-Signature: $signature" \
-d "$request"`

but was an insufficient authentication exception:
{"Error":[{"error_description":"Insufficient authentication.","error_description_translated":"Insufficient authentication."}]}

I think the root case of the issue is the expiration of the token from the step 2 and if so there is no way to perform step 2 again or no way to refresh old token. And in the same time certificate was registered and I cannot revoke or delete registration.
So how can I proceed the connecting in this case?

The second issue.

Generated test certificate with the key
Performed installation call
Tried to perform payment-service-provider-credential call with the script:
`#!/usr/bin/env bash

installationToken="35adfe9f5b8605e0b9b95853c68686a27e99276eb4292a844f12857e09085e05"

request="{
\"client_payment_service_provider_certificate\": \"-----BEGIN CERTIFICATE-----\nMIIDJjCCAg6gAwIBAgIJANoEqOYvzRgZMA0GCSqGSIb3DQEBCwUAMCgxGTAXBgNV\nBAMMEE15IEFwcCBQSVNQIEFJU1AxCzAJBgNVBAYTAk5MMB4XDTIxMDEwNjA5NDMx\nNFoXDTIyMDEwNjA5NDMxNFowKDEZMBcGA1UEAwwQTXkgQXBwIFBJU1AgQUlTUDEL\nMAkGA1UEBhMCTkwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxNm06\nEsQFGUSC+nRFjBiiXEv2lFxtOg6nRYHJj2pSLENg6LtyYO7qAW+3JSWGg9bZ6wqJ\n/E3Djm9fpJvqWP3DPj1fEWDS5YEtN9fF+s2+ZXCt7lEvUWuDtebpS3sLnbGvr2Ix\niwWv6oEDpd5m6QwiPWnQz/aZ56b8VDrfGLE61aaviufhLWkKxM+73kFBL8vHDK4q\nvBo9wGpIgUnQBYx7rMWJSvPZTWqghOYDCYhbWL9qJs6X+O1ggDyB6iuZMndqbTpY\nuku11zyIOrbDdKYX+0spbg1YUluQP2vf+MIgb+QFMhSW8UVt535bjGLsxelQm1zh\nJ3fxygh0VZwStyJtAgMBAAGjUzBRMB0GA1UdDgQWBBTgO3kwyGpLgIxhWf1g1kQx\npqR5JTAfBgNVHSMEGDAWgBTgO3kwyGpLgIxhWf1g1kQxpqR5JTAPBgNVHRMBAf8E\nBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQCfGjQp6i8cA5B2dSTApTJz6u5hbj8i\nHJWk27+ssr0D+Gaap04mHsJQHLszlUObBJEsMyCS6hE9DQ+cklJvaSJiAGlke5co\nCD04dCPQAZgr+iL0gYJsH6nekodbLMTva8fEzh199DkusAzF3xWXc6wdJ51KQ1p9\n6qz0Ey3Xxcmj2386UwNQE75Wx37aoXivHPG7G/tv49HNQ2BQ5sWybltNVtOceC2S\nn8KbSty/vRM5uRpKCL8hY/BM+wM5DligVQJ7CnX/Saong88VHsMPSjEh2BHhuDHf\nbX0Lo9toNwlCgmkXaw9+/+gJh8xB+d24GQ9CvFLFnDR6d3jqEtvumqv2\n-----END CERTIFICATE-----\",
\"client_payment_service_provider_certificate_chain\": \"-----BEGIN CERTIFICATE-----\nMIIDJjCCAg6gAwIBAgIJANoEqOYvzRgZMA0GCSqGSIb3DQEBCwUAMCgxGTAXBgNV\nBAMMEE15IEFwcCBQSVNQIEFJU1AxCzAJBgNVBAYTAk5MMB4XDTIxMDEwNjA5NDMx\nNFoXDTIyMDEwNjA5NDMxNFowKDEZMBcGA1UEAwwQTXkgQXBwIFBJU1AgQUlTUDEL\nMAkGA1UEBhMCTkwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxNm06\nEsQFGUSC+nRFjBiiXEv2lFxtOg6nRYHJj2pSLENg6LtyYO7qAW+3JSWGg9bZ6wqJ\n/E3Djm9fpJvqWP3DPj1fEWDS5YEtN9fF+s2+ZXCt7lEvUWuDtebpS3sLnbGvr2Ix\niwWv6oEDpd5m6QwiPWnQz/aZ56b8VDrfGLE61aaviufhLWkKxM+73kFBL8vHDK4q\nvBo9wGpIgUnQBYx7rMWJSvPZTWqghOYDCYhbWL9qJs6X+O1ggDyB6iuZMndqbTpY\nuku11zyIOrbDdKYX+0spbg1YUluQP2vf+MIgb+QFMhSW8UVt535bjGLsxelQm1zh\nJ3fxygh0VZwStyJtAgMBAAGjUzBRMB0GA1UdDgQWBBTgO3kwyGpLgIxhWf1g1kQx\npqR5JTAfBgNVHSMEGDAWgBTgO3kwyGpLgIxhWf1g1kQxpqR5JTAPBgNVHRMBAf8E\nBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQCfGjQp6i8cA5B2dSTApTJz6u5hbj8i\nHJWk27+ssr0D+Gaap04mHsJQHLszlUObBJEsMyCS6hE9DQ+cklJvaSJiAGlke5co\nCD04dCPQAZgr+iL0gYJsH6nekodbLMTva8fEzh199DkusAzF3xWXc6wdJ51KQ1p9\n6qz0Ey3Xxcmj2386UwNQE75Wx37aoXivHPG7G/tv49HNQ2BQ5sWybltNVtOceC2S\nn8KbSty/vRM5uRpKCL8hY/BM+wM5DligVQJ7CnX/Saong88VHsMPSjEh2BHhuDHf\nbX0Lo9toNwlCgmkXaw9+/+gJh8xB+d24GQ9CvFLFnDR6d3jqEtvumqv2\n-----END CERTIFICATE-----\",
\"client_public_key_signature\": \"hmghKNw5I8f5MM8/ZUn0HHwZmUj+hyEldYtn511RWevXBLR4N0taRHhS5XIzG0pEG9GkHHF4KKEwca8VUgiRDu+Zv0zjAAzCb11O2mHf4UojKrldaEtz9nHIYLb+ANSR2dXGPLeXo6/zjBEaun2BxVnydFu+wArqPx2WEw9SNZqpD1zGJcXZsfZa/F720vQ1se3R92UTVMieNeJR5bzFS4C7NN7RPO/yZqtOmbyaO58TqOOQx4YZ6tA/us47e98Nehd8tDkIzsoWDo5eyNUkONu01OezjAl00dnhExg+/yonsZR2LAVRc35KKf8pWeKyaaN+OIyEueF1M6BN5rhvLg==\"
}"

curl -v -X POST "https://public-api.sandbox.bunq.com/v1/payment-service-provider-credential" \
-H "User-Agent: curl" \
-H "Content-Type: application/json" \
-H "X-Bunq-Client-Authentication: $installationToken" \
-d "$request"
But was an unexpected for me exception:{"Error":[{"error_description":"You can have at most 5 active server credentials.","error_description_translated":"You can have at most 5 active server credentials."}]}`

What is server credentials and how it possible that I have 5 because I tried only 2 times?

Bastiaan

Deviprasad Hi!

Maybe you get this error about 5 active server credentials because you use a certificate with a "Common Name" (CN) that is already used in another test certificate.

Check my repository on GitHub, maybe this info can help you: https://github.com/basst85/bunq_psd2_example

New-Pink-Lion-2906228819

Bastiaan Thanks a lot!
It has sense, I've tried with the template from the portal "CN=My App PISP AISP/C=NL"

New-Pink-Lion-2906228819

Bastiaan Hi,
found a mistake in your repo.
For the payment-service-provider-credential call for the signing uses the wrong private key:
For the installation call uses public key that was generated from the client private key but signing performed with the psd2_key.pem.
And in this case we always receive {"Error":[{"error_description":"Invalid signature for public key.","error_description_translated":"Invalid signature for public key."}]}

New-Grey-Raccoon-3911247273

Hello @Bastiaan. Thanks for the GitHub repo example. Very helpful with the signing. We are trying to connect as a PSD2 service provider, however Bunq's documentation seems a bit confusing. After registering our software during the v1/payment-service-provider-credential, do we then need to perform the device-server and session-server calls or can we directly register our Oauth application? Many thanks for your time and help.

Jakob-Y

Joan It's explained here: https://beta.doc.bunq.com/psd2/connect-as-a-psd2-service-provider

What you get from /payment-service-provider-credential is your PSD2 bunq API user ID (it's not a user in the sense of a real person using bunq, but your application being the user), then you supply this to /payment-service-provider-credential/{itemId} in order to get your API key for that user. You then register that user with the usual /device-server and /session-server flow.

Now, when you have your PSD2 bunq API user all set up, you then need to initially register an OAuth application. It works by calling the end-points /user/{userID}/oauth-client, /user/{userID}/oauth-client/{oauth-clientID}/callback-url and /user/{userID}/oauth-client/{oauth-clientID} with the applicable data (like your redirect URL etc.) for your application.

After that is done, you can now start redirecting an actual user (like one that's made out of flesh) to https://oauth.bunq.com/auth with the correct parameters, they can then allow access via their bunq app to sub-accounts of their choice, and they will after that get redirected to your site and you get the OAuth code in the query. You can use this code to then exchange it for an access token at https://api.oauth.bunq.com/v1/token.

Now that access token belongs to the actual user (but bunq creates a special userApiKey instead of UserPerson / UserCompany that is normally returned with direct API access). You can use this to go through /installation + /device-server + /session-server flow and finally get a session token just for that user. Then call any API endpoint as usual (however, depending on what kind of PSD2 certification you have of course only certain endpoints will actually return any data).

New-Grey-Raccoon-3911247273

Jakob
Good morning Jakob. Thanks for that detailed explanation. I tried what you had suggested, using Bastiaan's method of creating the signature.
Installation token...no problem
I then make a POST request with the following details:

uri: https://public-api.sandbox.bunq.com/v1/payment-service-provider-credential

Request body: {"client_payment_service_provider_certificate":"-----BEGIN CERTIFICATE-----\nMIIE1jCCAr4CCQDdp5TgPW...YPl3iSw\nwWS1TNUu1qFndrSCkxSawiaDuEdOoMbaHq7A2hQjIvRJ5X9QqPtE2Lzs\n-----END CERTIFICATE-----\n","client_payment_service_provider_certificate_chain":"-----BEGIN CERTIFICATE-----\nMIIE1jCCAr4CCQDdp5TgPW...YPl3iSw\nwWS1TNUu1qFndrSCkxSawiaDuEdOoMbaHq7A2hQjIvRJ5X9QqPtE2Lzs\n-----END CERTIFICATE-----\n","client_public_key_signature":"fD4OP67uaNETBtOhaaY9sr4c5FP1fn+24dInSowLiNDmqiy/9..."}

Request headers: {Content-Type=[application/json], X-Bunq-Client-Authentication=[9729b907f34329ff1c5d844ba016...]}

...getting a 200 response from the bank with the following details:

{"Response":[{"CredentialPasswordIp":{"id":271175,"created":"2022-02-02 10:42:29.938045","updated":"2022-02-02 10:42:29.938045","status":"PENDING_FIRST_USE","expiry_time":"2022-02-02 11:42:29.937890","token_value":"af648f27f0a1451dae763211b393406d65...","permitted_device":null}}]}

According to Bunq's documentation (https://doc.bunq.com/#/), the response I should be getting at this stage is:

{"Id": {"id": 0}}

The one I got was supposed to be the proper response when I make a GET request to the https://public-api.sandbox.bunq.com/v1/payment-service-provider-credential/{itemId} endpoint.

So, could you please clarify what is going on? It looks like I doin't need to make a second request to get the api user credential id. How am I getting the api key then?

Our company has connected thousands of banks across Europe and none have been more challenging than registering Bunq. Looking forward to solving this riddle. Thanks so much for your time and kind assistance.