Tutorial
How the Payment Initiation (PSD2) API works
- Register a payment.
- Request single payment consent from the ABN AMRO account holder through the consent application.
- Execute the payment.
For information on how to get authorization and use this API, see Single payments tutorial.
The consent application
The consent application is used to obtain consent from an ABN AMRO account holder, and grant you with third-party access to execute a registered payment, or to access account information on behalf of the account holder by using, for example, an E.dentifier. This is a so-called redirect. In the consent application, the ABN AMRO client can review the payment details that were registered by you and authorize the payment.
The account holder consent process consists of three steps:
- Authenticate.
- Check the requested access to an account.
- Confirm and redirect back to 3rd party.
All payment initiation consents provide one time access to execute a payment and perform one available balance check. For status calls the token is valid for 30 days. Consent is given using the consent application via browser or Mobile Banking app.
The ABN AMRO client can either authorize or cancel the requested authorization.
Notes:
- For details on how to access the consent application through the OAuth server, see Step 3 of the Single payments tutorial.
- If an account owner is not authorized on the account number in the registered payment, they can select a different account number for which they are authorized.
- The ABN AMRO client can select Dutch or English in the consent application.
- The consent application uses Strong Customer Authentication (SCA). By clicking the "Finish" button the authorization is done. This completes the consent. The process now continues with the technical redirect.
- When the debit account is prefilled in the pre-registered payment the user cannot change this later.
- Consent for Batch payments and Cross Border payments is not available via the mobile app / QR code. The user can use the eDentifier to provide consent.
Authorization Code
The consent application is visible to the account owner only. It provides you with an access code for the requested authorization using an OAUTH 2.0 authorization code process. This is described in Step 3 of the Single payments tutorial.
Authorization is a grant on an account for one or multiple scopes. For more information, see Authorization Code.
Scopes in the authorization code process
A scope defines the type of access. For payments there are write, read, and delete scopes. Here are some rules on how scopes can be combined in the authorization code:
- Write scopes can be combined with read scopes.
- Scopes for different products cannot be combined.
- Write scopes cannot be combined with write scopes.
- Delete scopes cannot be combined with other scopes.
For more information on required scopes, see the POST payments operation.
Error messages
The following table describes consent application error scenarios. The error message is returned as parameter in the URL.
| Error message | Explanation |
|---|---|
| error=access_denied# | No current accounts are available to authorize or user declined authorization. |
An account holder may report an incident where they see the following error message in their browser, or application: "The page you are trying to access is no longer available". In this scenario, no redirect is occurring, this error message is visible to the user only, and occurs when consent flow is restarted manually. For example, by using the refresh button.
Generic information
- There is no duplicate check on any of the payment methods.
- A response is always sent. Ensure that your application does not time-out.
- If a 5xx or time-out occurs, it cannot be assumed the payment failed:
- If a POST operation fails, the payment can be safely posted again.
- If a PUT operation fails, check the status of the payment using GET. If the status is still 'PDNG', try the GET endpoint again later. If the status changed to one of the 'Accepted' statuses the operation has succeeded. A 'CANC' or 'RJCT' status occurs when a user cancels the payment or the payment cannot be executed.
- If a PUT operation fails, and the status cannot be checked, contact the bank.
- If a GET operation fails, retry later.
- If reposting, avoid using short retry periods to keep out of rate limiting scenarios.
Character set
The following character set can be used for SEPA single, batch payments, and cross-border payments.
| Character set |
|---|
| space |
| ! & ' ( ) + - . / 0 1 2 3 4 5 6 7 8 9 : ? _ ` , |
| aAbBcCdDeEfFgGhHiljJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ |
| àÀáÁâÂãÃäÄåÅæÆçÇèÈéÉêÊëËìÌíÍîÎïÏðÐñÑòÒóÓôÔõÕöÖ×øØùÙúÚûÛüÜýÝþÞßÞÿ |
Note: For cross-border payments, characters may be converted; for example, the ":" and "‘"; and lines can be truncated because of differences in standards between local payment and the clearing system.
Requirements
To use this API in a production environment, you must have the following:
PSD2 access:
- A PSD2 license for payment initiation.
- An EIDAS certificate.
- Your QWAC certificate MUST include Client Authentication (1.3.6.1.5.5.7.3.2) value for the certificate usage which can be found in the "Enhance Key Usage" tag of your certificate.
- Note: for certificates requested or renewed after the 1st of October 2025 Client Authentication might not by default be added in your certificate by your CA. Please specifically request this to your CA.
Open Banking UK access:
- A FCA licence for payment initiation.
- An OBWAC certificate with the appropriate licence details.
License
To use this API in a production environment, or if you require TPP access to ABN AMRO accounts, you must have a PSD2 license from a local competent authority. In the Netherlands, this is De Nederlandsche Bank (DNB). For access to UK accounts, a FCA license is required.
Licensing requirements
| API | AISP License | PISP License | Banking License | Payment Instrument Issuing License |
|---|---|---|---|---|
| Payment Initiation (PSD2) | N | Y | Y | N |
EIDAS certificate
ABN AMRO only accepts Qualified Website Authentication Certificates (QWAC) from Qualified Trusted Service Providers (QSTPs) that are on the trusted list with CEF Digital. This certificate is used for identification, and is also required for OAUTH authorization when accessing APIs.
Note: Inline with the PSD2 technical standard, wildcards are not permitted in certificates.
Note: Ensure the certificate usage includes " Client Authentication (1.3.6.1.5.5.7.3.2) "
Sandbox access
The sandbox and production API are in function the same with the distinction that the Sandbox contains static data. This static data means that you can perform all operations without making any transactions on an account. Transactions posted in the sandbox are cleaned every day.
Important: It is prohibited to use transactions that contain sensitive or private information in the sandbox. Account information in the sandbox is production like and fictive.
To use the Payment Initiation (PSD2) API in a sandbox environment, complete the following steps:
- Register and create an account:
- Go to ABN AMRO Developer Portal.
- Click Sign up.
- Enter your details, and click Create new account.
- Developer Support will send you an activation link by email.
- Click the activation link.
- Create and register application:
- Log in to your account.
- In the left-side navigation, click Apps.
- Click Add app.
- In the App name field, enter a name for your application.
- In the APIs field, select Payment Initiation (PSD2) API, and click Add app.
- Complete the Single payments tutorial.
Sandbox access details
The following account types are available for testing:
| Account type | International Bank Account Number (IBAN) |
|---|---|
| Positive scenario | NL12ABNA9999876523 NL91ABNA9999428707 NL62ABNA9999841479 |
| Negative scenario | NL58ABNA9999142181 |
Sandbox URL: https://api-sandbox.abnamro.com
Sandbox token URL: https://auth-mtls-sandbox.abnamro.com
Sandbox authorization URL: https://auth-sandbox.abnamro.com
Use the following credentials for the sandbox:
| Attribute | Value for Sandbox |
|---|---|
| client_id | TPP_test |
| API-Key | The API Key for your app from the Developer Portal |
| redirect_uri | https://localhost/auth |
Note: Redirect URL's in sandbox cannot be modified. For production environment desired URL's can be specified in the setup process.
| Certificate files: |
|---|
| Download public certificate: Download |
| Download private key: Download |
Notes: The sandbox handles functional error scenarios only.
Production access
Important: To use this API in a production environment, you must have a license. For more information, see Requirements.
To get access to production:
- Log in to your account.
- In the left-side navigation bar, click Apps.
- Click Request Production Access.
- Select the API category that you want to request production access on.
Note: It is not possible to request production access for multiple API categories in one request.
- Fill in the form, and click Submit.
- You receive a confirmation email and ticket-ID.
- ABN AMRO Developer Support validates the form, and if necessary contacts you.
- When the setup is complete, ABN AMRO Developer Support contacts you and supplies you with a client_id.
- A new app is added in Apps. This new app contains your API key.
Note: It is not possible for account holders to get API access on their own accounts.
Production access details
- Production URL for access to the API: https://api.abnamro.com
- SCA Production authorization URL: https://www.abnamro.nl/consent/v2/authorize?
- Production Token URL: https://auth-mtls.abnamro.com/as/token.oauth2
Note: The authorization URL supports accounts in all countries which the user can access through Internet Banking, Access Online or Dutch Mobile app. For other access see the related brands section on the developer portal.
Use the following credentials for production:
| Attribute | Value for Production |
|---|---|
| client_id | As supplied to you by ABN AMRO |
| API-Key | The API Key for your production app from the Developer Portal |
| redirect_uri | The URLs that you specified in your request access form |
| Certificate files: |
| --- | | Certificate file : Your QWAC EIDAS certificate | | Private key : Your private key |
How to use this API
Single payments tutorial
This tutorial describes how to connect an application to the Payment Initiation API (PSD2) in the sandbox environment, and execute a single payment. For Standing Orders or Bulk payments, please see version 1 of the PSD2 PIS API.
Note: Before you start this tutorial, you must complete the steps described in Sandbox access.
Note: In the production environment, the PSD2 compliant EIDAS QWAC certificate or OBWAC certificate for UK access, production redirect-uri, and production API-Key are used.
Step 1 - Request an access token for payment registration
This step uses OAUTH2.0 client credentials as an authorization method. When requesting a client credentials access token, you must authenticate yourself as a client using an SSL certificate. In the response, an access token is returned. This token is used to register a payment. For security reasons, the validity of this token is temporary.
Request attributes
You must specify the scope for the operation that is to be authorized. The possible scopes are described in the table below.
| Operation | Request for scope |
|---|---|
| Post (structured) SEPA payment | psd2:payment:sepa:write |
| Post Cross Border payment | psd2:payment:xborder:write |
Attributes
| Attribute | Value for Sandbox |
|---|---|
| client_id | TPP_test |
Certificates
| Certificate files |
|---|
| Download public certificate: Download |
| Download private key: Download |
Sandbox URL: https://api-sandbox.abnamro.com
Request examples
Request a client credentials access token to register a payment, using one of the following sample requests:
SEPA payment request
curl -X POST https://auth-mtls-sandbox.abnamro.com/as/token.oauth2 \
-v \
--cert TPPCertificate.crt \
--key TPPprivateKey.key \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=client_credentials&client_id=TPP_test&scope=psd2:payment:sepa:write'
Cross-border payment request
curl -X POST https://auth-mtls-sandbox.abnamro.com/as/token.oauth2 \
-v \
--cert TPPCertificate.crt \
--key TPPprivateKey.key \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=client_credentials&client_id=TPP_test&scope=psd2:payment:xborder:write'
Sample response
{
"token_type": "Bearer",
"access_token": "X1PTWZre0fnW72l263yrhAWB2FDwx3tg",
"expires_in": 7199
}
Step 2 - Register a payment
Use the access_token that you created in Step 1 of this tutorial to register a payment. This payment must be authorized by the account holder using the consent process described in Step 3 of this tutorial.
Sample requests
Register a payment using one of the following sample POST requests:
Standard SEPA payment request
This is a EUR payment inside the euro zone.
curl -X POST https://api-sandbox.abnamro.com/payment/v2/sepa-credit-transfers \
-v \
-H 'Accept: application/json' \
-H 'Authorization: Bearer X1PTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'content-type: application/json' \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-d '{
"debtorAccount": {
"iban": "NL62ABNA9999841479"
},
"creditorName": "John Doe",
"creditorAccount": {
"iban": "NL12ABNA9999876523"
},
"instructedAmount": {
"currency": "EUR",
"amount": "100.01"
},
"requestedExecutionDate": "2025-01-01",
"remittanceInformationUnstructured": "Ref Number 12345/0123."
}'
For more information, see the POST payments operation.
Structured SEPA payment request
This is a domestic SEPA payment with structured remittance information such as acceptgiro.
curl -X POST https://api-sandbox.abnamro.com/payment/v2/sepa-credit-transfers \
-v \
-H 'Accept: application/json' \
-H 'Authorization: Bearer UTUZnSKhYEYhX9qWl03epLVC3jyD' \
-H 'content-type: application/json' \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-d '{
"debtorAccount": {
"iban": "NL62ABNA9999841479"
},
"creditorName": "John Doe",
"creditorAccount": {
"iban": "NL12ABNA9999876523"
},
"instructedAmount": {
"currency": "EUR",
"amount": "100.01"
},
"requestedExecutionDate": "2025-01-01",
"remittanceInformationStructured": {
"issuer": "CUR",
"reference": "12345"
}
}'
For more information, see the POST payments operation.
Cross-border payment request
This is a non EUR payment or EUR payment outside the euro zone.
curl -X POST https://api-sandbox.abnamro.com/payment/v2/cross-border-credit-transfers \
-v \
-H 'Accept: application/json' \
-H 'Authorization: Bearer X1PTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'content-type: application/json' \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-d '{
"debtorAccount": {
"iban": "NL62ABNA9999841479"
},
"creditorAccount": {
"bban": "13141513158835300",
"currency": "USD"
},
"creditorAgent": "USBKUS44"
"creditorName": "John Doe",
"creditorAddress": {
"streetName": "Main Street",
"buildingNumber": "123",
"postCode": "10001",
"townName": "New York",
"countrySubDivision": "NY",
"country": "US"
},
"instructedAmount": {
"amount": 100.51,
"currency": "USD",
},
"chargeBearer": "SHAR",
"requestedExecutionDate": "2026-01-19",
"remittanceInformationUnstructured": "Invoice payment 2026-001"
}'
For more information, see the POST Cross Border operation.
Sample response
{
"debtorAccount": {
"iban": "NL12ABNA9999876523"
},
"paymentId": "8325P3346070108S0PD",
"paymentStatus": "RCVD"
}'
Note: You must store the
paymentId. It is used to check the account holder authorization and to execute the authorized payment.
Step 3 - Obtain consent
In this step, the OAuth 2.0 authorization code flow is used to obtain consent from an ABN AMRO account holder, and grant you with third-party access to execute a registered payment. This grant is given using the Consent application.
Request attributes
The table below defines the usage of attributes in a request.
| Parameter | Description |
|---|---|
| scope | Indicates for which scope consent is requested. This can be more than one scope. You can find the available scopes in the operation table below. |
| transactionId | Unique ID that is generated during the registration of a payment. This is the paymentId from Step 2. |
| redirect_uri | In sandbox, you must use https://<span></span>localhost/auth. In production, this URI must be identical to the URL configured on your request. |
| state | Value returned in the response that is used for session management. This parameter can, for example, be used to link the access code in the response to the paymentId of the payment. Note: this can be approx. max. 150 characters long depending on the length of the other parameters in the URL. |
| Operation | Request for scope |
| --- | --- |
| Execute SEPA payment | psd2:payment:sepa:write |
| Cancel SEPA payment | psd2:payment:sepa:write |
| Check SEPA payment status | psd2:payment:sepa:read |
| Execute Cross Border payment | psd2:payment:xborder:write |
| Cancel Cross Border payment | psd2:payment:xborder:write |
| Check Cross Border payment status | psd2:payment:xborder:read |
Notes:
- In the sandbox, a simplified version of the consent application is used to select the client account. This application does not use authentication such as e-Dentifier or Mobile App, or is it limiting the account choice when an account is pre-supplied, in favor of easier and quicker development.
- For more information, see Consent application
- Optionally, a one time call to the Confirmation Availability Funds (CAF) API can be performed, using the same token you retrieve in the PIS flow in Step 4.
- When using the attributes please assure the total length of the URL will not exceed 256 characters.
- When registering an redirect URL please note app deeplinking requires a browser to be launched on the device. For optimal user experience use a internet URL or a universal links.
Sample requests
All of the following examples will start the consent application. In the consent application, the ABN AMRO client reviews the payment details and authorizes the payment. Then you will receive an access code, which is used to execute the registered payment.
To request consent, direct the account holder to one of the following sample URLs:
SEPA payment consent request
https://auth-sandbox.abnamro.com/as/authorization.oauth2?scope=psd2:payment:sepa:write+psd2:payment:sepa:read&client_id=TPP_test&transactionId=123&response_type=code&flow=code&redirect_uri=https://localhost/auth&state=Paymentreference123
Cross-border payment consent request
https://auth-sandbox.abnamro.com/as/authorization.oauth2?scope=psd2:payment:xborder:write&client_id=TPP_test&transactionId=123&response_type=code&flow=code&redirect_uri=https://localhost/auth&state=Paymentreference123
Note: The transactionId in the URL is the paymentId from the response in step 2.
Sample response
In the response, you will receive an authorization code, which must be exchanged within 60 seconds for an access_token and a refresh_token. This is described in the next step.
https://localhost/auth?code=9C6UrsGZ0Z3XJymRAOAgl7hKPLlWKUo9GBfMQQEs&state=Paymentreference123
Note: For more information, see Consent application.
Step 4 - Exchange access code token
The authorization code you received in Step 3 must be exchanged within 60 seconds for an access_token and a refresh_token. The access_token is used to access the API and is valid for 2 hours. When the access_token has expired, the refresh_token can be exchanged for a new access_token and refresh_token. For more information, see the Additional operations section of this tutorial.
Request attributes
| Attribute | Description |
|---|---|
| grant_type | Indicates which type of authorization is used. It must contain 'Authorization_code'. |
| code | Authorization code from Step 3. |
| redirect_uri | Field is mandatory when redirect_uri is used in Step 3. |
Sample request
curl -X POST https://auth-mtls-sandbox.abnamro.com/as/token.oauth2 \
-v \
--cert TPPCertificate.crt \
--key TPPprivateKey.key \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=authorization_code&client_id=TPP_test&code=9C6UrsGZ0Z3XJymRAOAgl7hKPLlWKUo9GBfMQQEs&redirect_uri=https://localhost/auth'
Sample response
{
"access_token": "GPgYglX4sO1WhzfChx4tmjr4y7Qg",
"refresh_token": "UHjIAzBZfLGh4dLm8cvEcH6d8BrOmCZXumOpznQBP1",
"token_type": "Bearer",
"expires_in": 7193
}
Step 5 - Check authorization using consent information
Note: A
paymentIdis needed to execute a payment. This is obtained in this step. If you used thestateparameter to link to thepaymentIdin Step 3, proceed to Step 6 to execute the payment.
To execute an authorized payment, you must have an access_token, which was obtained Step 4, and the paymentId of the payment. By requesting consent information, the paymentId associated with the access_token, received in the previous step, can be retrieved. The scopes and initiating account number are also returned in the response.
Request attributes
| Attribute | Description |
|---|---|
| authorization | Use the access_token received in Step 4 and send this as a bearer token. |
Sample request
curl -X GET https://api-sandbox.abnamro.com/v1/consentinfo \
-v \
-H 'Accept: application/json' \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Authorization: Bearer GPgYglX4sO1WhzfChx4tmjr4y7Qg'
For more information, see the GET Consentinfo operation.
Sample response
{
"scopes": "payment:sepa:write payment:sepa:read",
"iban": "NL62ABNA9999841479",
"transactionId": "8325P3346070108S0PD",
"valid": "1554379039",
"consentStatus": "FULLY_SIGNED",
"consentExpiresIn": "26 days, 23 hours, 57 minutes, and 5 seconds"
}
To execute the payment in the next step and to check status, store the transactionId. The 'transactionId' will be used as the 'paymentId' in the next step.
Step 6 - Execute the payment
The registered payment must be executed using the transactionId and access_token retrieved in previous steps. The 'transactionId' will have to be used as the 'paymentId' in this step.
Sample request
Using one of the following sample requests, execute the registered payment using the PUT method:
SEPA or structured SEPA payment request
curl -X PUT https://api-sandbox.abnamro.com/payment/v2/sepa-credit-transfers/{paymentId} \
-v \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer GPgYglX4sO1WhzfChx4tmjr4y7Qg' \
-H 'Content-Length= 0'
For more information, see the PUT payment operation.
Cross border payment request
curl -X PUT https://api-sandbox.abnamro.com/payment/v2/cross-border-credit-transfers/{paymentId} \
-v \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer GPgYglX4sO1WhzfChx4tmjr4y7Qg'
-H 'Content-Length= 0'
For more information, see the PUT Cross Border operation.
Sample response
{
"debtorAccount": {
"iban": "NL12ABNA9999876523"
},
"paymentId": "8325P3346070108S0PD",
"paymentStatus": "PDNG",
"debtorName": "John Doe"
}'
Notes: In some scenarios the account holder can change the initiating account number during consent. For more information, see Consent Application. The initiating account number is located in the
debtorAccountfield of the sample response.
Additional operations
Check payment status
Retrieve the status of the transaction with the following request.
Note: Only the payment status of paymentIds which have a POST or PUT operation in the V2 version of this API can be retrieved with this V2 status endpoint.
SEPA payment request
curl -X GET https://api-sandbox.abnamro.com/payment/v2/sepa-credit-transfers/{paymentId}/status \
-v \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer {your_access_token}'
For more information, see the GET payments operation.
Sample SEPA response
{
"debtorAccount": {
"iban": "NL12ABNA9999876523"
},
"debtorName": "John Doe",
"paymentId": "KCPXBJU7WK1754485254512",
"paymentStatus": "ACCC",
"statusDetails": {
"withRecipient": "2025-08-06T15:01"
}
}
Cross Border payment request
curl -X GET https://api-sandbox.abnamro.com/payment/v2/cross-border-credit-transfers/{paymentId}/status \
-v \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer {your_access_token}'
For more information, see the GET payments operation.
Sample response
{
"debtorAccount": {
"iban": "NL12ABNA9999876523"
},
"debtorName": "John Doe",
"paymentId": "KCPXBJU7WK1754485254512",
"paymentStatus": "RJCT",
"statusDetails": {
"statusISORsn": "FF02"
}
}
- The status of a successful payment is "ACCC" or "ACSC". For a rejected payment, the status is "RJCT". In exceptional cases, it may take several seconds for the initial intermediate status "PDNG" to be updated. For more information, see the GET payments operation.
Cancel payments
A future-dated payment can be cancelled using the transactionId and access_token.
To cancel a released payment that has a future execution date, use one of the following samples:
Sample SEPA payment request
curl -X DELETE https://api-sandbox.abnamro.com/payment/v2/sepa-credit-transfers/{paymentId} \
-v \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer {your_access_token}'
For more information, see the DELETE SEPA payment operation.
Sample Cross Border payment request
curl -X DELETE https://api-sandbox.abnamro.com/payment/v2/cross-border-credit-transfers/{paymentId} \
-v \
-H 'API-Key: X1QTWZre0fnW72l263yrhAWB2FDwx3tg' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer {your_access_token}'
For more information, see the DELETE Cross Border payment operation.
Payments can be also cancelled by the account holder using Internet Banking or Access Online.
Refresh an access token
When the short-lived access_token, received in Step 4, expires, the long-lived refresh_token can be used to get a new access_token and a new refresh_token. This renders the used refresh token as invalid.
Sample request
curl -X POST https://auth-mtls-sandbox.abnamro.com/as/token.oauth2 \
-v \
--cert TPPCertificate.crt \
--key TPPprivateKey.key \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=refresh_token&client_id=TPP_test&refresh_token=UHjIAzBZfLGh4dLm8cvEcH6d8BrOmCZXumOpznQBP1&scope=psd2:payment:sepa:write+psd2:payment:sepa:read'
Sample response
{
"access_token": "{mkwAngBIJtlL9TxxNhECHV4LaBBt}",
"refresh_token": "{nLlBcohGqcAvs2iyQ4SAdenC5moqRh9y3NifBR3j04}",
"token_type": "Bearer",
"expires_in": 7193
}
Store the access_token to access the payment API, and the refresh_token to request a new access_token when it expires.
Need help?