{"resource_docs":[{"operation_id":"OBPv2.1.0-createTransactionRequestSandboxTan","implemented_by":{"version":"OBPv2.1.0","function":"createTransactionRequestSandboxTan"},"request_verb":"POST","request_url":"/obp/v2.1.0/banks/BANK_ID/accounts/ACCOUNT_ID/VIEW_ID/transaction-request-types/SANDBOX_TAN/transaction-requests","summary":"Create Transaction Request (SANDBOX_TAN)","description":"
When using SANDBOX_TAN, the payee is set in the request body.
\nMoney goes into the BANK_ID and ACCOUNT_ID specified in the request body.
\nInitiate a Payment via creating a Transaction Request.
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to SANDBOX_TAN. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n{
\n"XAF":{
\n"HKD":0.0135503,
\n"AUD":0.00228226,
\n"KRW":1.87975,
\n"JOD":0.00127784,
\n"GBP":0.00131092,
\n"MXN":0.0396,
\n"AED":0.00601555,
\n"INR":0.110241,
\n"JPY":0.185328,
\n"USD":0.00163773,
\n"ILS":0.00641333,
\n"EUR":0.00152449
\n},
\n"HKD":{
\n"XAF":73.8049,
\n"AUD":0.178137,
\n"KRW":143.424,
\n"JOD":0.0903452,
\n"GBP":0.0985443,
\n"MXN":2.8067,
\n"AED":0.467977,
\n"INR":9.09325,
\n"JPY":14.0867,
\n"USD":0.127427,
\n"ILS":0.460862,
\n"EUR":0.112495
\n},
\n"AUD":{
\n"XAF":438.162,
\n"HKD":5.61346,
\n"KRW":895.304,
\n"JOD":0.556152,
\n"GBP":0.609788,
\n"MXN":16.0826,
\n"AED":2.88368,
\n"INR":50.4238,
\n"JPY":87.0936,
\n"USD":0.785256,
\n"ILS":2.83558,
\n"EUR":0.667969
\n},
\n"KRW":{
\n"XAF":0.531986,
\n"HKD":0.00697233,
\n"AUD":0.00111694,
\n"JOD":6.30634E-4,
\n"GBP":6.97389E-4,
\n"MXN":0.0183,
\n"AED":0.00320019,
\n"INR":0.0586469,
\n"JPY":0.0985917,
\n"USD":8.7125E-4,
\n"ILS":0.00316552,
\n"EUR":8.11008E-4
\n},
\n"JOD":{
\n"XAF":782.572,
\n"HKD":11.0687,
\n"AUD":1.63992,
\n"KRW":1585.68,
\n"GBP":1.06757,
\n"MXN":30.8336,
\n"AED":5.18231,
\n"INR":90.1236,
\n"JPY":156.304,
\n"USD":1.41112,
\n"ILS":5.02018,
\n"EUR":0.237707
\n},
\n"GBP":{
\n"XAF":762.826,
\n"HKD":10.1468,
\n"AUD":1.63992,
\n"KRW":1433.92,
\n"JOD":0.936707,
\n"MXN":29.242,
\n"AED":4.58882,
\n"INR":84.095,
\n"JPY":141.373,
\n"USD":1.2493,
\n"ILS":4.7002,
\n"EUR":1.16278
\n},
\n"MXN":{
\n"XAF":25.189,
\n"HKD":0.3562,
\n"AUD":0.0621,
\n"KRW":54.4512,
\n"JOD":0.0324,
\n"GBP":0.0341,
\n"AED":0.1688,
\n"INR":3.3513,
\n"JPY":4.8687,
\n"USD":0.0459,
\n"ILS":0.1541,
\n"EUR":0.0384
\n},
\n"AED":{
\n"XAF":166.236,
\n"HKD":2.13685,
\n"AUD":0.346779,
\n"KRW":312.482,
\n"GBP":0.217921,
\n"MXN":5.9217,
\n"AED":0.192964,
\n"INR":18.3255,
\n"JPY":30.8081,
\n"USD":0.27225,
\n"ILS":0.968033,
\n"EUR":0.253425
\n},
\n"INR":{
\n"XAF":9.07101,
\n"HKD":0.109972,
\n"AUD":0.0198319,
\n"KRW":17.0512,
\n"JOD":0.0110959,
\n"GBP":0.0118913,
\n"MXN":0.2983,
\n"AED":0.0545671,
\n"JPY":1.68111,
\n"USD":0.0148559,
\n"ILS":0.0556764,
\n"EUR":0.0138287
\n},
\n"JPY":{
\n"XAF":5.39585,
\n"HKD":0.0709891,
\n"AUD":0.0114819,
\n"KRW":10.1428,
\n"JOD":0.00639777,
\n"GBP":0.0070735,
\n"MXN":0.2053,
\n"AED":0.032459,
\n"INR":0.594846,
\n"USD":0.00883695,
\n"ILS":0.0320926,
\n"EUR":0.00822592
\n},
\n"USD":{
\n"XAF":610.601,
\n"HKD":7.84766,
\n"AUD":1.27347,
\n"KRW":1147.78,
\n"JOD":0.708659,
\n"GBP":0.800446,
\n"MXN":21.748,
\n"AED":3.6731,
\n"INR":67.3135,
\n"JPY":113.161,
\n"ILS":3.55495,
\n"EUR":0.930886
\n},
\n"ILS":{
\n"XAF":155.925,
\n"HKD":2.16985,
\n"AUD":0.352661,
\n"KRW":315.903,
\n"JOD":0.199196,
\n"GBP":0.212763,
\n"MXN":6.4871,
\n"AED":1.03302,
\n"INR":17.9609,
\n"JPY":31.1599,
\n"USD":0.281298,
\n"EUR":1.19318
\n},
\n"EUR":{
\n"XAF":655.957,
\n"HKD":8.88926,
\n"AUD":1.49707,
\n"KRW":1233.03,
\n"JOD":0.838098,
\n"GBP":0.860011,
\n"MXN":26.0359,
\n"AED":3.94594,
\n"INR":72.3136,
\n"JPY":121.567,
\n"USD":1.07428,
\n"ILS":4.20494
\n}
\n}
Transaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncurrency: EUR
\nvalue: 5987953
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nvalue: 5987953
\nWhen using ACCOUNT, the payee is set in the request body.
\nMoney goes into the BANK_ID and ACCOUNT_ID specified in the request body.
\nInitiate a Payment via creating a Transaction Request.
\nIn 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.
\nIn case 1 person needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n\nTransaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncurrency: EUR
\nvalue: 5987953
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\nchallenges: challenges
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nuser_id: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1
\nvalue: 5987953
\nGet Transaction Request Attribute Definition
\nAuthentication is Mandatory
\nURL Parameters:
\nJSON response body fields:
\nUpdate Transaction Request Attribute
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nTRANSACTION_REQUEST_ID: 8138a7e4-6d02-40e3-a129-0b2bf89de9f1
\nJSON response body fields:
\ntransaction_request_attribute_id: 7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh
\nvalue: 5987953
\nReturns transaction requests for account specified by ACCOUNT_ID at bank specified by BANK_ID.
\nThe VIEW_ID specified must be 'owner' and the user must have access to this view.
\nVersion 2.0.0 now returns charge information.
\nTransaction Requests serve to initiate transactions that may or may not proceed. They contain information including:
\nPSD2 Context: PSD2 requires transparency of charges to the customer.
\nThis endpoint provides the charge that would be applied if the Transaction Request proceeds - and a record of that charge there after.
\nThe customer can proceed with the Transaction by answering the security challenge.
Authentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nvalue: 5987953
\nInitiate a Payment via creating a Transaction Request.
\nIn 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.
\nIn case 1 person needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n\nTransaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\n\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\nchallenges: challenges
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nuser_id: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1
\nvalue: 5987953
\nGet Transaction Request Attribute By Id
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nTRANSACTION_REQUEST_ID: 8138a7e4-6d02-40e3-a129-0b2bf89de9f1
\nJSON response body fields:
\ntransaction_request_attribute_id: 7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh
\nvalue: 5987953
\nEither the from
or the to
field must be filled. Those fields refers to the information about the party that will be refunded.
In case the from
object is used, it means that the refund comes from the part that sent you a transaction.
\nIn the from
object, you have two choices :
\n- Use bank_id
and account_id
fields if the other account is registered on the OBP-API
\n- Use the counterparty_id
field in case the counterparty account is out of the OBP-API
In case the to
object is used, it means you send a request to a counterparty to ask for a refund on a previous transaction you sent.
\n(This case is not managed by the OBP-API and require an external adapter)
Initiate a Payment via creating a Transaction Request.
\nIn 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.
\nIn case 1 person needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n\nTransaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\nreason_code: reason_code
\ntransaction_id: 2fg8a7e4-6d02-40e3-a129-0b2bf89de8ub
\nvalue: 5987953
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\nchallenges: challenges
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nuser_id: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1
\nvalue: 5987953
\nImport the historical transactions.
\nThe fields bank_id, account_id, counterparty_id in the json body are all optional ones.
\nIt support transfer money from account to account, account to counterparty and counterparty to counterparty
\nBoth bank_id + account_id and counterparty_id can identify the account, so OBP only need one of them to make the payment.
\nSo:
\nWhen you need the account to account, just omit counterparty_id field.eg:
\n{
\n"from": {
\n"bank_id": "gh.29.uk",
\n"account_id": "1ca8a7e4-6d02-48e3-a029-0b2bf89de9f0",
\n},
\n"to": {
\n"bank_id": "gh.29.uk",
\n"account_id": "2ca8a7e4-6d02-48e3-a029-0b2bf89de9f0",
\n},
\n"value": {
\n"currency": "GBP",
\n"amount": "10"
\n},
\n"description": "this is for work",
\n"posted": "2017-09-19T02:31:05Z",
\n"completed": "2017-09-19T02:31:05Z",
\n"type": "SANDBOX_TAN",
\n"charge_policy": "SHARED"
\n}
When you need the counterparty to counterparty, need to omit bank_id and account_id field.eg:
\n{
\n"from": {
\n"counterparty_id": "f6392b7d-4218-45ea-b9a7-eaa71c0202f9"
\n},
\n"to": {
\n"counterparty_id": "26392b7d-4218-45ea-b9a7-eaa71c0202f9"
\n},
\n"value": {
\n"currency": "GBP",
\n"amount": "10"
\n},
\n"description": "this is for work",
\n"posted": "2017-09-19T02:31:05Z",
\n"completed": "2017-09-19T02:31:05Z",
\n"type": "SANDBOX_TAN",
\n"charge_policy": "SHARED"
\n}
or, you can counterparty to account
\n{
\n"from": {
\n"counterparty_id": "f6392b7d-4218-45ea-b9a7-eaa71c0202f9"
\n},
\n"to": {
\n"bank_id": "gh.29.uk",
\n"account_id": "8ca8a7e4-6d02-48e3-a029-0b2bf89de9f0",
\n},
\n"value": {
\n"currency": "GBP",
\n"amount": "10"
\n},
\n"description": "this is for work",
\n"posted": "2017-09-19T02:31:05Z",
\n"completed": "2017-09-19T02:31:05Z",
\n"type": "SANDBOX_TAN",
\n"charge_policy": "SHARED"
\n}
This call is experimental.
\nAuthentication is Mandatory
\nJSON request body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncompleted: 2020-01-27
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\nposted: 2020-01-27
\nvalue: 5987953
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncompleted: 2020-01-27
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\nposted: 2020-01-27
\ntransaction_id: 2fg8a7e4-6d02-40e3-a129-0b2bf89de8ub
\ntransaction_request_type: SEPA
\nvalue: 5987953
\nDelete Transaction Request Attribute Definition by ATTRIBUTE_DEFINITION_ID
\nAuthentication is Mandatory
\nURL Parameters:
\nJSON response body fields:
\nCreate or Update Transaction Request Attribute Definition
\nThe category field must be TransactionRequest
\nThe type field must be one of: DOUBLE, STRING, INTEGER and DATE_WITH_DAY
\nAuthentication is Mandatory
\nURL Parameters:
\nJSON response body fields:
\nReturns transaction request for transaction specified by TRANSACTION_REQUEST_ID and for account specified by ACCOUNT_ID at bank specified by BANK_ID.
\nThe VIEW_ID specified must be 'owner' and the user must have access to this view.
\nVersion 2.0.0 now returns charge information.
\nTransaction Requests serve to initiate transactions that may or may not proceed. They contain information including:
\nPSD2 Context: PSD2 requires transparency of charges to the customer.
\nThis endpoint provides the charge that would be applied if the Transaction Request proceeds - and a record of that charge there after.
\nThe customer can proceed with the Transaction by answering the security challenge.
Authentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nTRANSACTION_REQUEST_ID: 8138a7e4-6d02-40e3-a129-0b2bf89de9f1
\nVIEW_ID: owner
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nvalue: 5987953
\nWhen using ACCOUNT, the payee is set in the request body.
\nMoney goes into the BANK_ID and ACCOUNT_ID specified in the request body.
\nInitiate a Payment via creating a Transaction Request.
\nIn 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.
\nIn case 1 person needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n\nTransaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncurrency: EUR
\nvalue: 5987953
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\nchallenges: challenges
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nuser_id: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1
\nvalue: 5987953
\nCreate Transaction Request Attribute
\nThe type field must be one of "STRING", "INTEGER", "DOUBLE" or DATE_WITH_DAY"
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nTRANSACTION_REQUEST_ID: 8138a7e4-6d02-40e3-a129-0b2bf89de9f1
\nJSON request body fields:
\nJSON response body fields:
\ntransaction_request_attribute_id: 7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh
\nvalue: 5987953
\nReturns the Transaction Request Types that the account specified by ACCOUNT_ID and view specified by VIEW_ID has access to.
\nThese are the ways this API Server can create a Transaction via a Transaction Request
\n(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:
\nFor 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.
\nThis 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.
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON response body fields:
\n\n","description_markdown":"Returns the Transaction Request Types that the account specified by ACCOUNT_ID and view specified by VIEW_ID has access to.\n\nThese are the ways this API Server can create a Transaction via a Transaction Request\n(as opposed to Transaction Types which include external types too e.g. for Transactions created by core banking etc.)\n\n A Transaction Request Type internally determines:\n\n * the required Transaction Request 'body' i.e. fields that define the 'what' and 'to' of a Transaction Request,\n * the type of security challenge that may be be raised before the Transaction Request proceeds, and\n * the threshold of that challenge.\n\n 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.\n\n 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.\n \n \n\nAuthentication is Mandatory\n\n\n**URL Parameters:**\n\n* [ACCOUNT_ID](/glossary#Account.account_id): 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0\n\n\n\n* [BANK_ID](/glossary#Bank.bank_id): gh.29.uk\n\n\n\n* [VIEW_ID](/glossary#this_view_id): owner\n\n\n\n\n\n**JSON response body fields:**\n\n\n\n* [amount](/glossary#temporary_requested_current_amount): 10.12\n\n\n\n* [currency](/glossary#can_see_transaction_currency): EUR\n\n\n\n* [value](/glossary#Customer.customerAttributeValue): 5987953\n\n\n","example_request_body":{"jsonString":"{}"},"success_response_body":{"transaction_request_types":[{"value":"10","charge":{"summary":"The bank fixed charge","value":{"currency":"EUR","amount":"0"}}}]},"error_response_bodies":["OBP-20001: User not logged in. Authentication is required!","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.","Please specify a valid value for CURRENCY of your Bank Account. ","Current user does not have access to the view ","account not found at bank","user does not have access to owner view","OBP-40018: Sorry, Transaction Requests are not enabled in this API instance.","OBP-50000: Unknown Error."],"tags":["Transaction-Request","Payment Initiation Service (PIS)","PSD2","New-Style"],"typed_request_body":{"type":"object","properties":{"jsonString":{"type":"string"}}},"typed_success_response_body":{"type":"object","properties":{"transaction_request_types":{"type":"array","items":{"type":"object","properties":{"charge":{"type":"object","properties":{"value":{"type":"object","properties":{"currency":{"type":"string"},"amount":{"type":"string"}}},"summary":{"type":"string"}}},"value":{"type":"string"}}}}}},"is_featured":false,"special_instructions":"","specified_url":"/obp/v4.0.0/banks/BANK_ID/accounts/ACCOUNT_ID/VIEW_ID/transaction-request-types","connector_methods":["obp.getTransactionRequestTypes","obp.getTransactionRequestTypeCharges","obp.checkBankAccountExists","obp.getBank","obp.getBankAccountsForUser"]},{"operation_id":"OBPv4.0.0-answerTransactionRequestChallenge","implemented_by":{"version":"OBPv4.0.0","function":"answerTransactionRequestChallenge"},"request_verb":"POST","request_url":"/obp/v4.0.0/banks/BANK_ID/accounts/ACCOUNT_ID/VIEW_ID/transaction-request-types/TRANSACTION_REQUEST_TYPE/transaction-requests/TRANSACTION_REQUEST_ID/challenge","summary":"Answer Transaction Request Challenge","description":"In Sandbox mode, any string that can be converted to a positive integer will be accepted as an answer.
\nThis endpoint totally depends on createTransactionRequest, it need get the following data from createTransactionRequest response body.
\n1)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.
\nFor instance: SANDBOX_TAN_OTP_INSTRUCTION_TRANSPORT=dummy
\nPossible values are dummy,email and sms
\nIn 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
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn case REQUIRED_CHALLENGE_ANSWERS is not defined as an account attribute default value is 1.
Authentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nTRANSACTION_REQUEST_ID: 8138a7e4-6d02-40e3-a129-0b2bf89de9f1
\nTRANSACTION_REQUEST_TYPE: SEPA
\nVIEW_ID: owner
\nJSON request body fields:
\nadditional_information: additional_information
\nreason_code: reason_code
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nvalue: 5987953
\nGet the list of the Transaction Request Types supported by the bank.
\nAuthentication is Optional
\nURL Parameters:
\nJSON response body fields:
\nGet Transaction Request Attributes
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nTRANSACTION_REQUEST_ID: 8138a7e4-6d02-40e3-a129-0b2bf89de9f1
\nJSON response body fields:
\ntransaction_request_attribute_id: 7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ntransaction_request_attributes: transaction_request_attributes
\nvalue: 5987953
\nSpecial instructions for COUNTERPARTY:
\nWhen using a COUNTERPARTY to create a Transaction Request, specificy the counterparty_id in the body of the request.
\nThe routing details of the counterparty will be forwarded for the transfer.
Initiate a Payment via creating a Transaction Request.
\nIn 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.
\nIn case 1 person needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n\nTransaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\namount: 10.12
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\nvalue: 5987953
\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\nchallenges: challenges
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nuser_id: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1
\nvalue: 5987953
\nSpecial instructions for SEPA:
\nWhen using a SEPA Transaction Request, you specify the IBAN of a Counterparty in the body of the request.
\nThe 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.
\nIn 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.
\nIn case 1 person needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => COMPLETED
\nIn case n persons needs to answer security challenge we have next flow of state of an transaction request
:
\nINITIATED => 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.
\nRule for calculating number of security challenges:
\nIf product Account attribute REQUIRED_CHALLENGE_ANSWERS=N then create N challenges
\n(one for every user that has a View where permission "can_add_transaction_request_to_any_account"=true)
\nIn 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).
\nTransaction 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.
\nThis 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.
\nIn sandbox mode, TRANSACTION_REQUEST_TYPE is commonly set to ACCOUNT. See getTransactionRequestTypesSupportedByBank for all supported types.
\nIn 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.
\nIf a challenge is created you must answer it using Answer Transaction Request Challenge before the Transaction is created.
\nYou can transfer between different currency accounts. (new in 2.0.0). The currency in body must match the sending account.
\nThe following static FX rates are available in sandbox mode:
\n\nTransaction Requests satisfy PSD2 requirements thus:
\n1) A transaction can be initiated by a third party application.
\n2) The customer is informed of the charge that will incurred.
\n3) The call supports delegated authentication (OAuth)
\nSee this python code for a complete example of this flow.
\nThere is further documentation here
\nAuthentication is Mandatory
\nURL Parameters:
\nACCOUNT_ID: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\nBANK_ID: gh.29.uk
\nVIEW_ID: owner
\nJSON request body fields:
\n\nJSON response body fields:
\naccount_id: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0
\namount: 10.12
\nbank_id: gh.29.uk
\nchallenges: challenges
\ncounterparty_id: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh
\ncurrency: EUR
\ndate_of_birth: 2018-03-09
\niban: DE91 1000 0000 0123 4567 89
\nlegal_name: Eveline Tripman
\nstart_date: 2020-01-27
\nuser_id: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1
\nvalue: 5987953
\n