An OBP Consent allows the holder of the Consent to call one or more endpoints.
Consents must be created and authorisied using SCA (Strong Customer Authentication).
That is, Consents can be created by an authorised User via the OBP REST API but they must be confirmed via an out of band (OOB) mechanism such as a code sent to a mobile phone.
Each Consent has one of the following states: INITIATED, ACCEPTED, REJECTED, REVOKED, RECEIVED, VALID, REVOKEDBYPSU, EXPIRED, TERMINATEDBYTPP.
Each Consent is bound to a consumer i.e. you need to identify yourself over request header value Consumer-Key.
For example:
GET /obp/v4.0.0/users/current HTTP/1.1
Host: 127.0.0.1:8080
Consent-JWT: eyJhbGciOiJIUzI1NiJ9.eyJlbnRpdGxlbWVudHMiOlt7InJvbGVfbmFtZSI6IkNhbkdldEFueVVzZXIiLCJiYW5rX2lkIjoiIn
1dLCJjcmVhdGVkQnlVc2VySWQiOiJhYjY1MzlhOS1iMTA1LTQ0ODktYTg4My0wYWQ4ZDZjNjE2NTciLCJzdWIiOiIzNDc1MDEzZi03YmY5LTQyNj
EtOWUxYy0xZTdlNWZjZTJlN2UiLCJhdWQiOiI4MTVhMGVmMS00YjZhLTQyMDUtYjExMi1lNDVmZDZmNGQzYWQiLCJuYmYiOjE1ODA3NDE2NjcsIml
zcyI6Imh0dHA6XC9cLzEyNy4wLjAuMTo4MDgwIiwiZXhwIjoxNTgwNzQ1MjY3LCJpYXQiOjE1ODA3NDE2NjcsImp0aSI6ImJkYzVjZTk5LTE2ZTY
tNDM4Yi1hNjllLTU3MTAzN2RhMTg3OCIsInZpZXdzIjpbXX0.L3fEEEhdCVr3qnmyRKBBUaIQ7dk1VjiFaEBW8hUNjfg
Maximum time to live of the token is specified over props value consents.max_time_to_live. In case isn't defined default value is 3600 seconds.
Example of POST JSON:
{
"everything": false,
"views": [
{
"bank_id": "GENODEM1GLS",
"account_id": "8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0",
"view_id": "owner"
}
],
"entitlements": [
{
"bank_id": "GENODEM1GLS",
"role_name": "CanGetCustomer"
}
],
"consumer_id": "7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh",
"email": "eveline@example.com",
"valid_from": "2020-02-07T08:43:34Z",
"time_to_live": 3600
}
Please note that only optional fields are: consumer_id, valid_from and time_to_live.
In case you omit they the default values are used:
consumer_id = consumer of current user
valid_from = current time
time_to_live = consents.max_time_to_live
This endpoint is used to confirm a Consent previously created.
The User must supply a code that was sent out of band (OOB) for example via an SMS.
This endpoint starts the process of creating a Consent.
The Consent is created in an INITIATED state.
A One Time Password (OTP) (AKA security challenge) is sent Out of band (OOB) to the User via the transport defined in SCA_METHOD
SCA_METHOD is typically "SMS" or "EMAIL". "EMAIL" is used for testing purposes.
When the Consent is created, OBP (or a backend system) stores the challenge so it can be checked later against the value supplied by the User with the Answer Consent Challenge endpoint.
An OBP Consent allows the holder of the Consent to call one or more endpoints.
Consents must be created and authorisied using SCA (Strong Customer Authentication).
That is, Consents can be created by an authorised User via the OBP REST API but they must be confirmed via an out of band (OOB) mechanism such as a code sent to a mobile phone.
Each Consent has one of the following states: INITIATED, ACCEPTED, REJECTED, REVOKED, RECEIVED, VALID, REVOKEDBYPSU, EXPIRED, TERMINATEDBYTPP.
Each Consent is bound to a consumer i.e. you need to identify yourself over request header value Consumer-Key.
For example:
GET /obp/v4.0.0/users/current HTTP/1.1
Host: 127.0.0.1:8080
Consent-JWT: eyJhbGciOiJIUzI1NiJ9.eyJlbnRpdGxlbWVudHMiOlt7InJvbGVfbmFtZSI6IkNhbkdldEFueVVzZXIiLCJiYW5rX2lkIjoiIn
1dLCJjcmVhdGVkQnlVc2VySWQiOiJhYjY1MzlhOS1iMTA1LTQ0ODktYTg4My0wYWQ4ZDZjNjE2NTciLCJzdWIiOiIzNDc1MDEzZi03YmY5LTQyNj
EtOWUxYy0xZTdlNWZjZTJlN2UiLCJhdWQiOiI4MTVhMGVmMS00YjZhLTQyMDUtYjExMi1lNDVmZDZmNGQzYWQiLCJuYmYiOjE1ODA3NDE2NjcsIml
zcyI6Imh0dHA6XC9cLzEyNy4wLjAuMTo4MDgwIiwiZXhwIjoxNTgwNzQ1MjY3LCJpYXQiOjE1ODA3NDE2NjcsImp0aSI6ImJkYzVjZTk5LTE2ZTY
tNDM4Yi1hNjllLTU3MTAzN2RhMTg3OCIsInZpZXdzIjpbXX0.L3fEEEhdCVr3qnmyRKBBUaIQ7dk1VjiFaEBW8hUNjfg
Maximum time to live of the token is specified over props value consents.max_time_to_live. In case isn't defined default value is 3600 seconds.
Example of POST JSON:
{
"everything": false,
"views": [
{
"bank_id": "GENODEM1GLS",
"account_id": "8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0",
"view_id": "owner"
}
],
"entitlements": [
{
"bank_id": "GENODEM1GLS",
"role_name": "CanGetCustomer"
}
],
"consumer_id": "7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh",
"email": "eveline@example.com",
"valid_from": "2020-02-07T08:43:34Z",
"time_to_live": 3600
}
Please note that only optional fields are: consumer_id, valid_from and time_to_live.
In case you omit they the default values are used:
consumer_id = consumer of current user
valid_from = current time
time_to_live = consents.max_time_to_live
This endpoint starts the process of creating a Consent.
The Consent is created in an INITIATED state.
A One Time Password (OTP) (AKA security challenge) is sent Out of Band (OOB) to the User via the transport defined in SCA_METHOD
SCA_METHOD is typically "SMS" or "EMAIL". "EMAIL" is used for testing purposes.
When the Consent is created, OBP (or a backend system) stores the challenge so it can be checked later against the value supplied by the User with the Answer Consent Challenge endpoint.
An OBP Consent allows the holder of the Consent to call one or more endpoints.
Consents must be created and authorisied using SCA (Strong Customer Authentication).
That is, Consents can be created by an authorised User via the OBP REST API but they must be confirmed via an out of band (OOB) mechanism such as a code sent to a mobile phone.
Each Consent has one of the following states: INITIATED, ACCEPTED, REJECTED, REVOKED, RECEIVED, VALID, REVOKEDBYPSU, EXPIRED, TERMINATEDBYTPP.
Each Consent is bound to a consumer i.e. you need to identify yourself over request header value Consumer-Key.
For example:
GET /obp/v4.0.0/users/current HTTP/1.1
Host: 127.0.0.1:8080
Consent-JWT: eyJhbGciOiJIUzI1NiJ9.eyJlbnRpdGxlbWVudHMiOlt7InJvbGVfbmFtZSI6IkNhbkdldEFueVVzZXIiLCJiYW5rX2lkIjoiIn
1dLCJjcmVhdGVkQnlVc2VySWQiOiJhYjY1MzlhOS1iMTA1LTQ0ODktYTg4My0wYWQ4ZDZjNjE2NTciLCJzdWIiOiIzNDc1MDEzZi03YmY5LTQyNj
EtOWUxYy0xZTdlNWZjZTJlN2UiLCJhdWQiOiI4MTVhMGVmMS00YjZhLTQyMDUtYjExMi1lNDVmZDZmNGQzYWQiLCJuYmYiOjE1ODA3NDE2NjcsIml
zcyI6Imh0dHA6XC9cLzEyNy4wLjAuMTo4MDgwIiwiZXhwIjoxNTgwNzQ1MjY3LCJpYXQiOjE1ODA3NDE2NjcsImp0aSI6ImJkYzVjZTk5LTE2ZTY
tNDM4Yi1hNjllLTU3MTAzN2RhMTg3OCIsInZpZXdzIjpbXX0.L3fEEEhdCVr3qnmyRKBBUaIQ7dk1VjiFaEBW8hUNjfg
Maximum time to live of the token is specified over props value consents.max_time_to_live. In case isn't defined default value is 3600 seconds.
Example of POST JSON:
{
"everything": false,
"views": [
{
"bank_id": "GENODEM1GLS",
"account_id": "8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0",
"view_id": "owner"
}
],
"entitlements": [
{
"bank_id": "GENODEM1GLS",
"role_name": "CanGetCustomer"
}
],
"consumer_id": "7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh",
"email": "eveline@example.com",
"valid_from": "2020-02-07T08:43:34Z",
"time_to_live": 3600
}
Please note that only optional fields are: consumer_id, valid_from and time_to_live.
In case you omit they the default values are used:
consumer_id = consumer of current user
valid_from = current time
time_to_live = consents.max_time_to_live
Returns the minimal list of private accounts at BANK_ID that the user has access to.
For each account, the API returns the ID, routing addresses and the views available to the current user.
If you want to see more information on the Views, use the Account Detail call.
optional request parameters:
account_type_filter: one or many accountType value, split by comma
account_type_filter_operation: the filter type of account_type_filter, value must be INCLUDE or EXCLUDE
An OBP Consent allows the holder of the Consent to call one or more endpoints.
Consents must be created and authorisied using SCA (Strong Customer Authentication).
That is, Consents can be created by an authorised User via the OBP REST API but they must be confirmed via an out of band (OOB) mechanism such as a code sent to a mobile phone.
Each Consent has one of the following states: INITIATED, ACCEPTED, REJECTED, REVOKED, RECEIVED, VALID, REVOKEDBYPSU, EXPIRED, TERMINATEDBYTPP.
Each Consent is bound to a consumer i.e. you need to identify yourself over request header value Consumer-Key.
For example:
GET /obp/v4.0.0/users/current HTTP/1.1
Host: 127.0.0.1:8080
Consent-JWT: eyJhbGciOiJIUzI1NiJ9.eyJlbnRpdGxlbWVudHMiOlt7InJvbGVfbmFtZSI6IkNhbkdldEFueVVzZXIiLCJiYW5rX2lkIjoiIn
1dLCJjcmVhdGVkQnlVc2VySWQiOiJhYjY1MzlhOS1iMTA1LTQ0ODktYTg4My0wYWQ4ZDZjNjE2NTciLCJzdWIiOiIzNDc1MDEzZi03YmY5LTQyNj
EtOWUxYy0xZTdlNWZjZTJlN2UiLCJhdWQiOiI4MTVhMGVmMS00YjZhLTQyMDUtYjExMi1lNDVmZDZmNGQzYWQiLCJuYmYiOjE1ODA3NDE2NjcsIml
zcyI6Imh0dHA6XC9cLzEyNy4wLjAuMTo4MDgwIiwiZXhwIjoxNTgwNzQ1MjY3LCJpYXQiOjE1ODA3NDE2NjcsImp0aSI6ImJkYzVjZTk5LTE2ZTY
tNDM4Yi1hNjllLTU3MTAzN2RhMTg3OCIsInZpZXdzIjpbXX0.L3fEEEhdCVr3qnmyRKBBUaIQ7dk1VjiFaEBW8hUNjfg
Maximum time to live of the token is specified over props value consents.max_time_to_live. In case isn't defined default value is 3600 seconds.
Example of POST JSON:
{
"everything": false,
"views": [
{
"bank_id": "GENODEM1GLS",
"account_id": "8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0",
"view_id": "owner"
}
],
"entitlements": [
{
"bank_id": "GENODEM1GLS",
"role_name": "CanGetCustomer"
}
],
"consumer_id": "7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh",
"email": "eveline@example.com",
"valid_from": "2020-02-07T08:43:34Z",
"time_to_live": 3600
}
Please note that only optional fields are: consumer_id, valid_from and time_to_live.
In case you omit they the default values are used:
consumer_id = consumer of current user
valid_from = current time
time_to_live = consents.max_time_to_live
This endpoint gets the Consents that the current User created.
Get the server's public JSON Web Key (JWK) set and certificate chain.
It is required by client applications to validate ID tokens, self-contained access tokens and other issued objects.
Get Transaction Types for the bank specified by BANK_ID:
Lists the possible Transaction Types available at the bank (as opposed to Transaction Request Types which are the possible ways Transactions can be created by this API Server).
id : Unique transaction type id across the API instance. SHOULD be a UUID. MUST be unique.
bank_id : The bank that supports this TransactionType
short_code : A short code (SHOULD have no-spaces) which MUST be unique across the bank. May be stored with Transactions to link here
summary : A succinct summary
description : A longer description
charge : The charge to the customer for each one of these
An OBP Consent allows the holder of the Consent to call one or more endpoints.
Consents must be created and authorisied using SCA (Strong Customer Authentication).
That is, Consents can be created by an authorised User via the OBP REST API but they must be confirmed via an out of band (OOB) mechanism such as a code sent to a mobile phone.
Each Consent has one of the following states: INITIATED, ACCEPTED, REJECTED, REVOKED, RECEIVED, VALID, REVOKEDBYPSU, EXPIRED, TERMINATEDBYTPP.
Each Consent is bound to a consumer i.e. you need to identify yourself over request header value Consumer-Key.
For example:
GET /obp/v4.0.0/users/current HTTP/1.1
Host: 127.0.0.1:8080
Consent-JWT: eyJhbGciOiJIUzI1NiJ9.eyJlbnRpdGxlbWVudHMiOlt7InJvbGVfbmFtZSI6IkNhbkdldEFueVVzZXIiLCJiYW5rX2lkIjoiIn
1dLCJjcmVhdGVkQnlVc2VySWQiOiJhYjY1MzlhOS1iMTA1LTQ0ODktYTg4My0wYWQ4ZDZjNjE2NTciLCJzdWIiOiIzNDc1MDEzZi03YmY5LTQyNj
EtOWUxYy0xZTdlNWZjZTJlN2UiLCJhdWQiOiI4MTVhMGVmMS00YjZhLTQyMDUtYjExMi1lNDVmZDZmNGQzYWQiLCJuYmYiOjE1ODA3NDE2NjcsIml
zcyI6Imh0dHA6XC9cLzEyNy4wLjAuMTo4MDgwIiwiZXhwIjoxNTgwNzQ1MjY3LCJpYXQiOjE1ODA3NDE2NjcsImp0aSI6ImJkYzVjZTk5LTE2ZTY
tNDM4Yi1hNjllLTU3MTAzN2RhMTg3OCIsInZpZXdzIjpbXX0.L3fEEEhdCVr3qnmyRKBBUaIQ7dk1VjiFaEBW8hUNjfg
Maximum time to live of the token is specified over props value consents.max_time_to_live. In case isn't defined default value is 3600 seconds.
Example of POST JSON:
{
"everything": false,
"views": [
{
"bank_id": "GENODEM1GLS",
"account_id": "8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0",
"view_id": "owner"
}
],
"entitlements": [
{
"bank_id": "GENODEM1GLS",
"role_name": "CanGetCustomer"
}
],
"consumer_id": "7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh",
"email": "eveline@example.com",
"valid_from": "2020-02-07T08:43:34Z",
"time_to_live": 3600
}
Please note that only optional fields are: consumer_id, valid_from and time_to_live.
In case you omit they the default values are used:
consumer_id = consumer of current user
valid_from = current time
time_to_live = consents.max_time_to_live
Revoke Consent for current user specified by CONSENT_ID
In Sandbox mode, any string that can be converted to a positive integer will be accepted as an answer.
This endpoint totally depends on createTransactionRequest, it need get the following data from createTransactionRequest response body.
1)TRANSACTION_REQUEST_TYPE : is the same as createTransactionRequest request URL .
2)TRANSACTION_REQUEST_ID : is the id field in createTransactionRequest response body.
3) id : is challenge.id field in createTransactionRequest response body.
4) answer : must be 123 in case that Strong Customer Authentication method for OTP challenge is dummy.
For instance: SANDBOX_TAN_OTP_INSTRUCTION_TRANSPORT=dummy
Possible values are dummy,email and sms
In kafka mode, the answer can be got by phone message or other security ways.
In case 1 person needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => COMPLETED
In case n persons needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => NEXT_CHALLENGE_PENDING => ... => NEXT_CHALLENGE_PENDING => COMPLETED
The security challenge is bound to a user i.e. in case of right answer and the user is different than expected one the challenge will fail.
Rule for calculating number of security challenges:
If product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
In case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
When using ACCOUNT, the payee is set in the request body.
Money goes into the BANK_ID and ACCOUNT_ID specified in the request body.
Initiate a Payment via creating a Transaction Request.
In OBP, a transaction request may or may not result in a transaction. However, a transaction only has one possible state: completed.
A Transaction Request can have one of several states: INITIATED, NEXT_CHALLENGE_PENDING etc.
Transactions are modeled on items in a bank statement that represent the movement of money.
Transaction Requests are requests to move money which may or may not succeed and thus result in a Transaction.
A Transaction Request might create a security challenge that needs to be answered before the Transaction Request proceeds.
In case 1 person needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => COMPLETED
In case n persons needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => NEXT_CHALLENGE_PENDING => ... => NEXT_CHALLENGE_PENDING => COMPLETED
The security challenge is bound to a user i.e. in case of right answer and the user is different than expected one the challenge will fail.
Rule for calculating number of security challenges:
If product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
In case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
Transaction Requests contain charge information giving the client the opportunity to proceed or not (as long as the challenge level is appropriate).
Transaction Requests can have one of several Transaction Request Types which expect different bodies. The escaped body is returned in the details key of the GET response.
This provides some commonality and one URL for many different payment or transfer types with enough flexibility to validate them differently.
The payer is set in the URL. Money comes out of the BANK_ID and ACCOUNT_ID specified in the URL.
In sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
In sandbox mode, if the amount is less than 1000 EUR (any currency, unless it is set differently on this server), the transaction request will create a transaction without a challenge, else the Transaction Request will be set to INITIALISED and a challenge will need to be answered.
If a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
You can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
The following static FX rates are available in sandbox mode:
OBP-20001: User not logged in. Authentication is required!
OBP-30111: Invalid Bank Id. The BANK_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-30110: Invalid Account Id. The ACCOUNT_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-10001: Incorrect json format.
OBP-30001: Bank not found. Please specify a valid value for BANK_ID.
OBP-30003: Account not found. Please specify a valid value for ACCOUNT_ID.
OBP-30018: Bank Account not found. Please specify valid values for BANK_ID and ACCOUNT_ID.
OBP-40002: Insufficient authorisation to create TransactionRequest. The Transaction Request could not be created because you don't have access to the owner view of the from account or you don't have access to canCreateAnyTransactionRequest.
OBP-40001: Invalid value for TRANSACTION_REQUEST_TYPE
OBP-10001: Incorrect json format.
OBP-10002: Invalid Number. Could not convert value to a number.
OBP-40008: Can't send a payment with a value of 0 or less.
OBP-40003: Transaction Request Currency must be the same as From Account Currency.
OBP-00003: Transaction Requests is disabled in this API instance.
When using ACCOUNT, the payee is set in the request body.
Money goes into the BANK_ID and ACCOUNT_ID specified in the request body.
Initiate a Payment via creating a Transaction Request.
In OBP, a transaction request may or may not result in a transaction. However, a transaction only has one possible state: completed.
A Transaction Request can have one of several states: INITIATED, NEXT_CHALLENGE_PENDING etc.
Transactions are modeled on items in a bank statement that represent the movement of money.
Transaction Requests are requests to move money which may or may not succeed and thus result in a Transaction.
A Transaction Request might create a security challenge that needs to be answered before the Transaction Request proceeds.
In case 1 person needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => COMPLETED
In case n persons needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => NEXT_CHALLENGE_PENDING => ... => NEXT_CHALLENGE_PENDING => COMPLETED
The security challenge is bound to a user i.e. in case of right answer and the user is different than expected one the challenge will fail.
Rule for calculating number of security challenges:
If product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
In case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
Transaction Requests contain charge information giving the client the opportunity to proceed or not (as long as the challenge level is appropriate).
Transaction Requests can have one of several Transaction Request Types which expect different bodies. The escaped body is returned in the details key of the GET response.
This provides some commonality and one URL for many different payment or transfer types with enough flexibility to validate them differently.
The payer is set in the URL. Money comes out of the BANK_ID and ACCOUNT_ID specified in the URL.
In sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
In sandbox mode, if the amount is less than 1000 EUR (any currency, unless it is set differently on this server), the transaction request will create a transaction without a challenge, else the Transaction Request will be set to INITIALISED and a challenge will need to be answered.
If a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
You can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
The following static FX rates are available in sandbox mode:
OBP-20001: User not logged in. Authentication is required!
OBP-30111: Invalid Bank Id. The BANK_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-30110: Invalid Account Id. The ACCOUNT_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-10001: Incorrect json format.
OBP-30001: Bank not found. Please specify a valid value for BANK_ID.
OBP-30003: Account not found. Please specify a valid value for ACCOUNT_ID.
OBP-30018: Bank Account not found. Please specify valid values for BANK_ID and ACCOUNT_ID.
OBP-40002: Insufficient authorisation to create TransactionRequest. The Transaction Request could not be created because you don't have access to the owner view of the from account or you don't have access to canCreateAnyTransactionRequest.
OBP-40001: Invalid value for TRANSACTION_REQUEST_TYPE
OBP-10001: Incorrect json format.
OBP-10002: Invalid Number. Could not convert value to a number.
OBP-40008: Can't send a payment with a value of 0 or less.
OBP-40003: Transaction Request Currency must be the same as From Account Currency.
OBP-00003: Transaction Requests is disabled in this API instance.
When using a COUNTERPARTY to create a Transaction Request, specificy the counterparty_id in the body of the request.
The routing details of the counterparty will be forwarded for the transfer.
Initiate a Payment via creating a Transaction Request.
In OBP, a transaction request may or may not result in a transaction. However, a transaction only has one possible state: completed.
A Transaction Request can have one of several states: INITIATED, NEXT_CHALLENGE_PENDING etc.
Transactions are modeled on items in a bank statement that represent the movement of money.
Transaction Requests are requests to move money which may or may not succeed and thus result in a Transaction.
A Transaction Request might create a security challenge that needs to be answered before the Transaction Request proceeds.
In case 1 person needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => COMPLETED
In case n persons needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => NEXT_CHALLENGE_PENDING => ... => NEXT_CHALLENGE_PENDING => COMPLETED
The security challenge is bound to a user i.e. in case of right answer and the user is different than expected one the challenge will fail.
Rule for calculating number of security challenges:
If product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
In case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
Transaction Requests contain charge information giving the client the opportunity to proceed or not (as long as the challenge level is appropriate).
Transaction Requests can have one of several Transaction Request Types which expect different bodies. The escaped body is returned in the details key of the GET response.
This provides some commonality and one URL for many different payment or transfer types with enough flexibility to validate them differently.
The payer is set in the URL. Money comes out of the BANK_ID and ACCOUNT_ID specified in the URL.
In sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
In sandbox mode, if the amount is less than 1000 EUR (any currency, unless it is set differently on this server), the transaction request will create a transaction without a challenge, else the Transaction Request will be set to INITIALISED and a challenge will need to be answered.
If a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
You can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
The following static FX rates are available in sandbox mode:
OBP-20001: User not logged in. Authentication is required!
OBP-30111: Invalid Bank Id. The BANK_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-30110: Invalid Account Id. The ACCOUNT_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-10001: Incorrect json format.
OBP-30001: Bank not found. Please specify a valid value for BANK_ID.
OBP-30003: Account not found. Please specify a valid value for ACCOUNT_ID.
OBP-30018: Bank Account not found. Please specify valid values for BANK_ID and ACCOUNT_ID.
OBP-40002: Insufficient authorisation to create TransactionRequest. The Transaction Request could not be created because you don't have access to the owner view of the from account or you don't have access to canCreateAnyTransactionRequest.
OBP-40001: Invalid value for TRANSACTION_REQUEST_TYPE
OBP-10001: Incorrect json format.
OBP-10002: Invalid Number. Could not convert value to a number.
OBP-40008: Can't send a payment with a value of 0 or less.
OBP-40003: Transaction Request Currency must be the same as From Account Currency.
OBP-00003: Transaction Requests is disabled in this API instance.
Initiate a Payment via creating a Transaction Request.
In OBP, a transaction request may or may not result in a transaction. However, a transaction only has one possible state: completed.
A Transaction Request can have one of several states: INITIATED, NEXT_CHALLENGE_PENDING etc.
Transactions are modeled on items in a bank statement that represent the movement of money.
Transaction Requests are requests to move money which may or may not succeed and thus result in a Transaction.
A Transaction Request might create a security challenge that needs to be answered before the Transaction Request proceeds.
In case 1 person needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => COMPLETED
In case n persons needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => NEXT_CHALLENGE_PENDING => ... => NEXT_CHALLENGE_PENDING => COMPLETED
The security challenge is bound to a user i.e. in case of right answer and the user is different than expected one the challenge will fail.
Rule for calculating number of security challenges:
If product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
In case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
Transaction Requests contain charge information giving the client the opportunity to proceed or not (as long as the challenge level is appropriate).
Transaction Requests can have one of several Transaction Request Types which expect different bodies. The escaped body is returned in the details key of the GET response.
This provides some commonality and one URL for many different payment or transfer types with enough flexibility to validate them differently.
The payer is set in the URL. Money comes out of the BANK_ID and ACCOUNT_ID specified in the URL.
In sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
In sandbox mode, if the amount is less than 1000 EUR (any currency, unless it is set differently on this server), the transaction request will create a transaction without a challenge, else the Transaction Request will be set to INITIALISED and a challenge will need to be answered.
If a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
You can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
The following static FX rates are available in sandbox mode:
OBP-20001: User not logged in. Authentication is required!
OBP-30111: Invalid Bank Id. The BANK_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-30110: Invalid Account Id. The ACCOUNT_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-10001: Incorrect json format.
OBP-30001: Bank not found. Please specify a valid value for BANK_ID.
OBP-30003: Account not found. Please specify a valid value for ACCOUNT_ID.
OBP-30018: Bank Account not found. Please specify valid values for BANK_ID and ACCOUNT_ID.
OBP-40002: Insufficient authorisation to create TransactionRequest. The Transaction Request could not be created because you don't have access to the owner view of the from account or you don't have access to canCreateAnyTransactionRequest.
OBP-40001: Invalid value for TRANSACTION_REQUEST_TYPE
OBP-10001: Incorrect json format.
OBP-10002: Invalid Number. Could not convert value to a number.
OBP-40008: Can't send a payment with a value of 0 or less.
OBP-40003: Transaction Request Currency must be the same as From Account Currency.
OBP-00003: Transaction Requests is disabled in this API instance.
When using SANDBOX_TAN, the payee is set in the request body.
Money goes into the BANK_ID and ACCOUNT_ID specified in the request body.
Initiate a Payment via creating a Transaction Request.
In OBP, a transaction request may or may not result in a transaction. However, a transaction only has one possible state: completed.
A Transaction Request can have one of several states.
Transactions are modeled on items in a bank statement that represent the movement of money.
Transaction Requests are requests to move money which may or may not succeeed and thus result in a Transaction.
A Transaction Request might create a security challenge that needs to be answered before the Transaction Request proceeds.
Transaction Requests contain charge information giving the client the opportunity to proceed or not (as long as the challenge level is appropriate).
Transaction Requests can have one of several Transaction Request Types which expect different bodies. The escaped body is returned in the details key of the GET response.
This provides some commonality and one URL for many different payment or transfer types with enough flexibility to validate them differently.
The payer is set in the URL. Money comes out of the BANK_ID and ACCOUNT_ID specified in the URL.
In sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to SANDBOX_TAN. See getTransactionRequestTypesSupportedByBank for all supported types.
In sandbox mode, if the amount is less than 1000 EUR (any currency, unless it is set differently on this server), the transaction request will create a transaction without a challenge, else the Transaction Request will be set to INITIALISED and a challenge will need to be answered.
If a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
You can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
The following static FX rates are available in sandbox mode:
OBP-20001: User not logged in. Authentication is required!
OBP-20001: User not logged in. Authentication is required!
OBP-30111: Invalid Bank Id. The BANK_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-30110: Invalid Account Id. The ACCOUNT_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-10001: Incorrect json format.
OBP-30001: Bank not found. Please specify a valid value for BANK_ID.
OBP-30003: Account not found. Please specify a valid value for ACCOUNT_ID.
OBP-30005: View not found for Account. Please specify a valid value for VIEW_ID
OBP-40002: Insufficient authorisation to create TransactionRequest. The Transaction Request could not be created because you don't have access to the owner view of the from account or you don't have access to canCreateAnyTransactionRequest.
OBP-20017: Current user does not have access to the view. Please specify a valid value for VIEW_ID.
OBP-40001: Invalid value for TRANSACTION_REQUEST_TYPE
OBP-10001: Incorrect json format.
OBP-10002: Invalid Number. Could not convert value to a number.
OBP-40008: Can't send a payment with a value of 0 or less.
OBP-40003: Transaction Request Currency must be the same as From Account Currency.
OBP-00003: Transaction Requests is disabled in this API instance.
When using a SEPA Transaction Request, you specify the IBAN of a Counterparty in the body of the request.
The routing details (IBAN) of the counterparty will be forwarded to the core banking system for the transfer.
Initiate a Payment via creating a Transaction Request.
In OBP, a transaction request may or may not result in a transaction. However, a transaction only has one possible state: completed.
A Transaction Request can have one of several states: INITIATED, NEXT_CHALLENGE_PENDING etc.
Transactions are modeled on items in a bank statement that represent the movement of money.
Transaction Requests are requests to move money which may or may not succeed and thus result in a Transaction.
A Transaction Request might create a security challenge that needs to be answered before the Transaction Request proceeds.
In case 1 person needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => COMPLETED
In case n persons needs to answer security challenge we have next flow of state of an transaction request:
INITIATED => NEXT_CHALLENGE_PENDING => ... => NEXT_CHALLENGE_PENDING => COMPLETED
The security challenge is bound to a user i.e. in case of right answer and the user is different than expected one the challenge will fail.
Rule for calculating number of security challenges:
If product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
In case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
Transaction Requests contain charge information giving the client the opportunity to proceed or not (as long as the challenge level is appropriate).
Transaction Requests can have one of several Transaction Request Types which expect different bodies. The escaped body is returned in the details key of the GET response.
This provides some commonality and one URL for many different payment or transfer types with enough flexibility to validate them differently.
The payer is set in the URL. Money comes out of the BANK_ID and ACCOUNT_ID specified in the URL.
In sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
In sandbox mode, if the amount is less than 1000 EUR (any currency, unless it is set differently on this server), the transaction request will create a transaction without a challenge, else the Transaction Request will be set to INITIALISED and a challenge will need to be answered.
If a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
You can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
The following static FX rates are available in sandbox mode:
OBP-20001: User not logged in. Authentication is required!
OBP-30111: Invalid Bank Id. The BANK_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-30110: Invalid Account Id. The ACCOUNT_ID should only contain 0-9/a-z/A-Z/'-'/'.'/'_', the length should be smaller than 255.
OBP-10001: Incorrect json format.
OBP-30001: Bank not found. Please specify a valid value for BANK_ID.
OBP-30003: Account not found. Please specify a valid value for ACCOUNT_ID.
OBP-30018: Bank Account not found. Please specify valid values for BANK_ID and ACCOUNT_ID.
OBP-40002: Insufficient authorisation to create TransactionRequest. The Transaction Request could not be created because you don't have access to the owner view of the from account or you don't have access to canCreateAnyTransactionRequest.
OBP-40001: Invalid value for TRANSACTION_REQUEST_TYPE
OBP-10001: Incorrect json format.
OBP-10002: Invalid Number. Could not convert value to a number.
OBP-40008: Can't send a payment with a value of 0 or less.
OBP-40003: Transaction Request Currency must be the same as From Account Currency.
OBP-00003: Transaction Requests is disabled in this API instance.
Returns transaction request for transaction specified by TRANSACTION_REQUEST_ID and for account specified by ACCOUNT_ID at bank specified by BANK_ID.
The VIEW_ID specified must be 'owner' and the user must have access to this view.
Version 2.0.0 now returns charge information.
Transaction Requests serve to initiate transactions that may or may not proceed. They contain information including:
Transaction Request Id
Type
Status (INITIATED, COMPLETED)
Challenge (in order to confirm the request)
From Bank / Account
Details including Currency, Value, Description and other initiation information specific to each type. (Could potentialy include a list of future transactions.)
Related Transactions
PSD2 Context: PSD2 requires transparency of charges to the customer.
This endpoint provides the charge that would be applied if the Transaction Request proceeds - and a record of that charge there after.
The customer can proceed with the Transaction by answering the security challenge.
Returns the Transaction Request Types that the account specified by ACCOUNT_ID and view specified by VIEW_ID has access to.
These are the ways this API Server can create a Transaction via a Transaction Request
(as opposed to Transaction Types which include external types too e.g. for Transactions created by core banking etc.)
A Transaction Request Type internally determines:
the required Transaction Request 'body' i.e. fields that define the 'what' and 'to' of a Transaction Request,
the type of security challenge that may be be raised before the Transaction Request proceeds, and
the threshold of that challenge.
For instance in a 'SANDBOX_TAN' Transaction Request, for amounts over 1000 currency units, the user must supply a positive integer to complete the Transaction Request and create a Transaction.
This approach aims to provide only one endpoint for initiating transactions, and one that handles challenges, whilst still allowing flexibility with the payload and internal logic.
Returns transaction requests for account specified by ACCOUNT_ID at bank specified by BANK_ID.
The VIEW_ID specified must be 'owner' and the user must have access to this view.
Version 2.0.0 now returns charge information.
Transaction Requests serve to initiate transactions that may or may not proceed. They contain information including:
Transaction Request Id
Type
Status (INITIATED, COMPLETED)
Challenge (in order to confirm the request)
From Bank / Account
Details including Currency, Value, Description and other initiation information specific to each type. (Could potentialy include a list of future transactions.)
Related Transactions
PSD2 Context: PSD2 requires transparency of charges to the customer.
This endpoint provides the charge that would be applied if the Transaction Request proceeds - and a record of that charge there after.
The customer can proceed with the Transaction by answering the security challenge.