Sandbox testing for Accounts & Card Accounts (AISP)

Step-by-step guide to help you start testing our Account and Card Account Information APIs in our Sandbox using our static test data.

Sandbox Accounts & Card Accounts 



General Information

This guide will help you to start testing our PSD2 Account and Card Account Information APIs in our Sandbox environment.
For implementing the Accounts and Card Accounts APIs in our Live environment, please see this guide Accounts & Cards flow

The data in our sandbox is static, so within this guide you’ll find all the access tokens you need in order to perform the tests. We have tried to make it useful but also as simple as possible!



 



Sandbox access

In order to test our APIs in our Sandbox environment, you must complete the following steps.

1. Sign up to create an account on our Developer Portal. You can sign up here. (Don’t forget to activate it by following the instructions in the activation email).

2. After activating your account, log in and then click on your username (top right corner) and in the drop down list select “My apps”. This is where you'll see all of the test apps you've created (later on) and which APIs they are subscribed to.



Creating apps

3. On the Manage your apps page, click Create new app and complete the information. Once you’ve created the app, make a note of the Client ID (App-id) as you'll be using it in the requests later on.

Note: You'll only ever see your test apps in our Developer Portal, meaning you won't see your Live enironment apps (and subscriptions) here.







Subscribing to APIs

4. After creating an app, under “Subscriptions” you can browse the “Available APIs”. When you’ve found one you want, click on it and then under “Plans”, click “Subscribe”.

5. After subscribing to an API, if you want to subscribe to more, you can find the full list of available APIs on All API Products (found in the drop down list under "APIs" on the main menu). Click on an API and then scroll to the bottom to subscribe.



Testing the Accounts & Card Accounts API

Now let's get started with some testing!

We have tried to make this as simple as possible for you, which is why we provide Authorization tokens that you just have to copy and paste in. The test data that you receive back (regarding PSU Account & Card Account information) is static and basic, but it should give you an idea of the type of information you will receive in our Live Environment.

Unfortunately we do not have a full Accounts & Card Accounts flow in our Sandbox, so we are missing the Consent Authorisation step where the PSU authenticates themselves using the Redirect or Decoupled SCA method. Where this step is missing, we'll provide you with the documentation where you can read about how it will work in the Live environment.

Sandbox Gateway Host URL

When testing our APIs in our Sandbox environment, please ensure that the below base URL is used in the calls. 

Important: When using our APIs in the Live environment, the base URL changes to https://api.handelsbanken.com/openbanking

For the Sandbox testing, we'll keep the same steps as our guidelines for our Live environment Accounts & Cards flow



Step-by-step guide



Step 1: Request Client Credential Grant (CCG) token

The authorization process starts with requiring a Client Credentials Grant (CCG). The result of this call will be a CCG access token which is used to call the POST /consents endpoint of the Consents API (which is used to acquire AIS consents for the PSU).

The Client Credential Grant request and responses are identified using the scope object (e.g. AIS) and the CCG is identical for all countries and is PSU independent.

Request

curl -X POST https://sandbox.handelsbanken.com/bb/gls5/oauth2/token/1.0 \
--cert <Your public cert file> \
-H 'Accept: application/json' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=client_credentials&scope=AIS&client_id=f31b7318-8f21-4eaf-8817-6b5e4e02d6bc'

See below for the type of information that needs to be in your request for Sandbox testing.

Parameter Description Example
grant_type Type of token request - CCG in this case. Allowed value: “client_credentials”.
Mandatory
client_credentials
scope A static scope with one or several values. For the Account & Card Account APIs, "AIS" must be the scope.
Mandatory
AIS


client_id The client_id (app-id) for your test app which we said you should note down earlier.
Mandatory
f31b7318-8f21-4eaf-8817-6b5e4e02d6bc

Response

This is what the response looks like when the CCG token has been successfully created. 

HTTP/1.1 200 OK
{
    "access_token": "QVQ6OTMzZWYwNTctZDE5MC00MDhmLThjOTgtYjY3OGFiM2I1ZDZjx",
    "expires_in": 123456,
    "token_type": "Bearer"
}
Parameter Description Example
access_token The returned CCG token, associated with your registered application for the scope(s) you have requested. QVQ6OTMzZWYwNTctZDE5MC00MDhmLThjOTgtYjY3OGFiM2I1ZDZjx
expires_in

Number of seconds the access_token is valid for.

e.g. 123456
token_type Always the value ”Bearer”. Bearer

Full definitions, descriptions and codes can be found here Client Credentials Grant (OAuth 2.0)



Step 2: Initiate consent (using CCG token)

With the CCG, an end user consent can be initiated. The returned ID would normally be used in the next step (Step 3 when the end user (PSU) signs the consent), however we are missing this step in our Sandbox environment. 

The test data in the Sandbox for Consent requests and responses is identified using the Authorization object. The responses are identified by the Authorization token.

Request

curl -X POST https://sandbox.handelsbanken.com/openbanking/psd2/v1/consents \
-H 'X-IBM-Client-Id: f31b7318-8f21-4eaf-8817-6b5e4e02d6bc' \
-H 'Authorization: Bearer QVQ6OTMzZWYwNTctZDE5MC00MDhmLThjOTgtYjY3OGFiM2I1ZDZjx' \
-H 'Accept: application/json'\
-H 'Content-Type: application/json' \
-H 'Country: <ISO 3166-1 country code>' \
-H 'TPP-Request-ID: <Unique identifier for the request>' \
-H 'TPP-Transaction-ID: <Unique identifier for the transaction>' \
-d '{"access":"ALL_ACCOUNTS"}'

See below for the type of information that needs to be in your request for Sandbox testing.

Important: In the Live environment, if the PSU is a Corporate customer, then the parameters "PSU Corporate ID" and "PSU Corporate ID" Type must be included in the header with the relevant values. More information about this can be found in the guidelines for the Live environment Accounts and Cards flow

Parameter Description Example
X-IBM-Client-Id Your test app's client-id (app-id) that we asked you to note down earlier.
Mandatory.
f31b7318-8f21-4eaf-8817-6b5e4e02d6bc
Authorization

The CCG access token.

Use the example on the right in your request. We have included a negative scenario as well for testing purposes.
Mandatory.

Bearer QVQ6OTMzZWYwNTctZDE5MC00MDhmLThjOTgtYjY3OGFiM2I1ZDZjx

 

Access token expired (negative scenario):

Bearer QVQ6MmQ3NGIwNTYtZTYwNy00M2FkLTkzZTEtYTQ3ZTc0NmQ4ODJm

Country ISO 3166-1 country code. 
Mandatory.
SE, GB, FI, NL, LU (one country per request)
TPP-Request-ID Unique identifier for the request. For Sandbox testing, you can make this up.
Mandatory.
c8271b81-4229-5a1f-bf9c-758f11c1f5b1
TPP-Transaction-ID Unique identifier for the transaction. For Sandbox testing, you can make this up.
Mandatory.
6b24ce42-237f-4303-a917-cf778e5013d6
access Supported value is 'ALL_ACCOUNTS'.
Mandatory.
ALL_ACCOUNTS

Response

This is what the response looks like when the consent initiation for Account / Card Account Information has been done. A successful response will include a consent ID as well as links to endpoints for continuing the authorization process with the signing of the consent by the end user (PSU).

HTTP/1.1 200 OK
{
  "consentId": "22aa3559-577d-441c-b9e6-664ac3311a3e",
  "consentStatus": "RECEIVED",
  "scaMethods": [{
      "_links": {
        "authorization": [{
            "href": "https://api.handelsbanken.com/bb/gls5/decoupled/mbid/initAuthorization/1.0",
            "name": "decpld_mbid_1.0",
            "type": "application/json"
          }
        ]
      },
      "scaMethodType": "DECOUPLED"
    },
    {
      "_links": {
        "authorization": [{
          "href": "https://secure.handelsbanken.com/bb/gls5/oauth2/authorize/1.0",
          "name": "authorize_1.0",
          "type": "application/x-www-form-urlencoded"
        }]
      },
      "scaMethodType": "REDIRECT"
    }
  ]
}
Parameter Description Example
consentId The consent ID that has been created to be used later on when the PSU signs it. 22aa3559-577d-441c-b9e6-664ac3311a3e
scaMethods.[]._links.authorization.[].href Link to authorization endpoint for starting the PSU authorization process.
Decoupled:
https://api.handelsbanken.com/bb/gls5/decoupled/mbid/initAuthorization/1.0
Redirect:
https://secure.handelsbanken.com/bb/gls5/oauth2/authorize/1.0
scaMethods.[].scaMethodType The type of PSU authorization method. DECOUPLED
REDIRECT

Please also refer to the API documentation for definitions, descriptions and codes Consents API documentation



Step 3: Consent Authorisation Grant using ACG or DG

This is the step where the end user (PSU) signs the consent and this one is not testable in our Sandbox environment.

However, for the authorization process in the Live environment, the end user (PSU) should be able to choose among the type of authorization flows that are applicable to the specific country and customer type (Individual or Corporate customer). The applicable types of authorization flows are returned, including the URL to initiate the process, in the response of the consent initiation (in the previous step). On the successful completion of these processes, you will receive an access token which will be an Authorization Code Grant (ACG) for the Redirect Authorization flow or Decoupled Grant (DG) for the Decoupled Authorization flow. With this access token, you will be able to call the endpoints of the Account and Card Account APIs in the next step.

In the below links you can find more detailed technical help and the next steps required for the Live environment.

SCA Redirect

SCA Decoupled

Important: not all countries support both SCA methods. See here for which methods are applicable per country SCA Methods

But as we aren't able to test this in our Sandbox, please continue to the next step!



Step 4: Call the Account / Card Account Information APIs

As the authorization process (the previous step) cannot be tested in our Sandbox (and therefore you will not obtain ACG or DG access tokens), so you can call the endpoints of our Account & Card Account APIs, we have provided you with access tokens below. 

The information you can retrieve can vary due to which country the customer holds accounts in and also the customer type. Whilst we always try to keep our Sandbox test data up to date, the attribute documents reflect exactly what is retrievable in our Live APIs. So before integrating with our Live APIs, please check our Country specific pages for the countries you want to integrate with, particularly the Attribute documents (found on every Country's page).

Country specific Account rules

Country specific Card Account rules

In the below links, you can find our API documentation (definitions, descriptions and codes) which is not country specific:

Account Information API documentation

Card Account Information API documentation

Below we have provided some examples of the requests for the Accounts API. To test the Card Accounts API, use the endpoints:
GET /card-accounts and GET /card-accounts/{accountId}/transactions and the Card Account access tokens instead.

 

GET /accounts (Sandbox) Request example

Here is an example of how a request would look like when peforming tests in our Sandbox:

curl -X POST https://sandbox.handelsbanken.com/openbanking/psd2/v2/accounts \
-H 'X-IBM-Client-Id: f31b7318-8f21-4eaf-8817-6b5e4e02d6bc' \
-H 'Authorization: Bearer U0VfRsOWUkVUQUdfUFJPRklMX18x' \
-H 'Accept: application/json'\
-H 'Content-Type: application/json' \
-H 'TPP-Request-ID: <Unique identifier for the request>' \
-H 'TPP-Transaction-ID: <Unique identifier for the transaction>' \

See below for the type of information that needs to be in your request for Sandbox testing.

Parameter Description Example
X-IBM-Client-Id

Your test app's client-id (app-id) that we asked you to note down earlier.
Mandatory.

f31b7318-8f21-4eaf-8817-6b5e4e02d6bc
Authorization

The CCG access token.

Mandatory.

Use the access tokens found under Accounts test data

 

TPP-Request-ID Unique identifier for the request. For Sandbox testing, you can make this up.
Mandatory.
c8271b81-4229-5a1f-bf9c-758f11c1f5b1
TPP-Transaction-ID Unique identifier for the transaction. For Sandbox testing, you can make this up.
Mandatory.
6b24ce42-237f-4303-a917-cf778e5013d6

Response

You'll receive all the available accounts for the test customer. 

 

GET  /accounts/{accountId} (Sandbox) Request example

An accountId is obtained from the GET/accounts step which you just did, so make sure you add this in to the url ("REPLACE_ACCOUNTID").

curl -X POST https://sandbox.handelsbanken.com/openbanking/psd2/v2/accounts/REPLACE_ACCOUNTID \
-H 'X-IBM-Client-Id: f31b7318-8f21-4eaf-8817-6b5e4e02d6bc' \
-H 'Authorization: Bearer U0VfRsOWUkVUQUdfUFJPRklMX18x' \
-H 'Accept: application/json'\
-H 'Content-Type: application/json' \
-H 'TPP-Request-ID: <Unique identifier for the request>' \
-H 'TPP-Transaction-ID: <Unique identifier for the transaction>' \

See below for the type of information that needs to be in your request for Sandbox testing.

Parameter Description Example
X-IBM-Client-Id Your test app's client-id (app-id) that we asked you to note down earlier.
Mandatory.
f31b7318-8f21-4eaf-8817-6b5e4e02d6bc
Authorization

The CCG access token.

Mandatory.

Make sure to use the same access token as you did in the previous step. Use the access tokens found under Accounts test data

 

TPP-Request-ID Unique identifier for the request. For Sandbox testing, you can make this up.
Mandatory.
c8271b81-4229-5a1f-bf9c-758f11c1f5b1
TPP-Transaction-ID Unique identifier for the transaction. For Sandbox testing, you can make this up.
Mandatory.
6b24ce42-237f-4303-a917-cf778e5013d6

Response

You'll receive all information available, excluding the balance, for a particular account.

 

GET /accounts/{accountId} with balance (Sandbox) Request example

If you would like to get a balance with the account too, please do the request with the accountId (that you previously received) and include the withBalance query parameter.

curl -X POST https://sandbox.handelsbanken.com/openbanking/psd2/v2/accounts/REPLACE_ACCOUNTID/withBalance=true \
-H 'X-IBM-Client-Id: f31b7318-8f21-4eaf-8817-6b5e4e02d6bc' \
-H 'Authorization: Bearer U0VfRsOWUkVUQUdfUFJPRklMX18x' \
-H 'Accept: application/json'\
-H 'Content-Type: application/json' \
-H 'TPP-Request-ID: <Unique identifier for the request>' \
-H 'TPP-Transaction-ID: <Unique identifier for the transaction>' \

See below for the type of information that needs to be in your request for Sandbox testing.

Parameter Description Example
X-IBM-Client-Id Your test app's client-id (app-id) that we asked you to note down earlier.
Mandatory.
f31b7318-8f21-4eaf-8817-6b5e4e02d6bc
Authorization

The CCG access token.

Mandatory.

Make sure to use the same access token as you did in the previous step. Use the access tokens found under Accounts test data

 

TPP-Request-ID Unique identifier for the request. For Sandbox testing, you can make this up.
Mandatory.
c8271b81-4229-5a1f-bf9c-758f11c1f5b1
TPP-Transaction-ID Unique identifier for the transaction. For Sandbox testing, you can make this up.
Mandatory.
6b24ce42-237f-4303-a917-cf778e5013d6

Response

You'll receive all information available, including the balance, for a particular account.

 

GET /accounts/{accountId}/transactions (Sandbox) Request example

Please note: The date query parameter (dateFrom and dateTo) should not be used in our Sandbox environment due to (old) static transaction dates (between the years 2017-2019). If you do use it, you may not retrieve any transactions... so we recommend that you don't use it!

curl -X POST https://sandbox.handelsbanken.com/openbanking/psd2/v2/accounts/REPLACE_ACCOUNTID/transactions \
-H 'X-IBM-Client-Id: f31b7318-8f21-4eaf-8817-6b5e4e02d6bc' \
-H 'Authorization: Bearer U0VfRsOWUkVUQUdfUFJPRklMX18x' \
-H 'Accept: application/json'\
-H 'Content-Type: application/json' \
-H 'TPP-Request-ID: <Unique identifier for the request>' \
-H 'TPP-Transaction-ID: <Unique identifier for the transaction>' \

See below for the type of information that needs to be in your request for Sandbox testing.

Parameter Description Example
X-IBM-Client-Id Your test app's client-id (app-id) that we asked you to note down earlier.
Mandatory.
f31b7318-8f21-4eaf-8817-6b5e4e02d6bc
Authorization

The CCG access token.

Mandatory.

Make sure to use the same access token as you did in the previous step. Use the access tokens found under Accounts test data

 

TPP-Request-ID Unique identifier for the request. For Sandbox testing, you can make this up.
Mandatory.
c8271b81-4229-5a1f-bf9c-758f11c1f5b1
TPP-Transaction-ID Unique identifier for the transaction. For Sandbox testing, you can make this up.
Mandatory.
6b24ce42-237f-4303-a917-cf778e5013d6

Response

You'll receive all transactions available for a particular account.



Accounts Test Data

Use the accesst tokens below when doing the requests. The static data you receive reflects the type of info you'll receive from our Live environment Account API.

Sweden

Customer type Profile Access token
Individual 1 Bearer MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI1
Individual 2 Bearer MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI2
Individual 3 Bearer MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3
Corporate 1 Bearer U0VfRsOWUkVUQUdfUFJPRklMX18x
Corporate 2 Bearer U0VfRsOWUkVUQUdfUFJPRklMX18y
Corporate 3 Bearer U0VfRsOWUkVUQUdfUFJPRklMX18z

 

Great Britain

Customer type Profile Access token
Individual 1 Bearer VUtfUFJJVkFURV9QUk9GSUxFX18x
Individual 2 Bearer VUtfUFJJVkFURV9QUk9GSUxFX18y
Individual 3 Bearer VUtfUFJJVkFURV9QUk9GSUxFX18z
Corporate 1 Bearer VVtfQ9SQVRFU19QUk9GSUxFC31x
Corporate 2 Bearer VVtfQ9SQVRFU19QUk9GSUxFC31y
Corporate 3 Bearer VVtfQ9SQVRFU19QUk9GSUxFC31z

 

Finland

Customer type Profile Access token
Individual 1 Bearer MV9QUk9GSUxFLUZJX1BSSVZBVEUx
Individual 2 Bearer MV9QUk9GSUxFLUZJX1BSSVZBVEUy
Individual 3 Bearer MV9QUk9GSUxFLUZJX1BSSVZBVEUz
Corporate 1 Bearer MS9QUk9GSUwtRklDT1JQT1JBVEUx
Corporate 2 Bearer MS9QUk9GSUwtRklDT1JQT1JBVEUy
Corporate 3 Bearer MS9QUk9GSUwtRklDT1JQT1JBVEUz

 

The Netherlands

Customer type Profile Access token
Individual 1 Bearer MVBST0ZJTEVfTkxfUFJJVkFURV8x
Individual 2 Bearer MVBST0ZJTEVfTkxfUFJJVkFURV8y
Individual 3 Bearer MVBST0ZJTEVfTkxfUFJJVkFURV8z
Corporate 1 Bearer UFJPRklMRTFfTkxfQ09SUE9SQVRFU18x
Corporate 2 Bearer UFJPRklMRTFfTkxfQ09SUE9SQVRFU18y
Corporate 3 Bearer UFJPRklMRTFfTkxfQ09SUE9SQVRFU18z

 

Luxembourg

Customer type Profile Access token
Individual 1 Bearer QVQ6ZGViMzMwNTktMWIwMy00MjJkLTk4MzYtNjJjZjBhOTg1MmQ5


Card Accounts Test Data

As mentioned in Step 4: Call the Account / Card Account Information APIs to test the Card Accounts API, use the endpoints:
GET /card-accounts and GET /card-accounts/{accountId}/transactions and the Card Account access tokens below instead.

 

Customer type Profile Access token
Individual 1 Bearer QVQ6NmQ4OTQwYWUtZjRmZi00NGMwLWJkYWQtZWU3ZTM0MTgxOTdmCg==
Individual 2 Bearer QVQ6OTU2Y2E5YWQtOWE0Zi00ZmM2LTg4ZTUtMGJmMWY4ZmJmZjU2Cg==
Individual 3 Bearer QVQ6M2U0ZTMzZjgtMmE3Yi00YjAwLTk3NGMtN2E2YzNiNTg0ZDc3Cg==
Individual 4 Bearer QVQ6ZWMwZmE5NmQtZTdhMi00NTlhLTljYTItNjgyYzYwY2FiNDU3Cg==