Transaction Requests
Transaction Requests are records of transaction / payment requests coming to the API. They may or may not result in Transactions (following authentication, authorisation, security challenges and sufficient funds etc.)
A successful Transaction Request results in a Transaction.
There are currently four different Transaction Request Types which allow different details to be submitted whilst sharing much of the same logic.
- SANDBOX_TAN
- COUNTERPARTY
- SEPA
- FREE_FORM
With a SANDBOX_TAN Transaction Request, we send money to a known bank_id and account_id. i.e. the "to" bank_id and the account_id must be known to the OBP backend connector / adapter. This was the first type to exist and is typically used in sandbox mode i.e. where OBP uses its own transaction store. However there's no reason why this type can't be used in core banking connected mode.
With a COUNTERPARTY Transaction Request, we send money by specifying a single counterparty_id of an existing Counterparty on the account which has is_beneficiary to True. The specified Counterparty contains the routing information which could be SEPA or some other scheme.
Thus the creation of a COUNTERPARTY Transaction Request has two step:
- A user who has can_add_counterparty on the Account/View creates a Counterparty with the correct routing information.
- A user who is an account holder creates a Transaction Request specifying the counterparty_id
Of course an App could hide these separate steps from the User.
With a SEPA Transaction Request, we send money by specifying the IBAN of a known Counterparty on the account which has is_beneficiary to True. The specified Counterparty contains the SEPA routing information i.e. the IBAN.
Thus the creation of a SEPA Transaction Request has two step:
- A user who has can_add_counterparty on the Account/View creates a Counterparty with the SEPA routing information.
- A user who is an account holder creates a Transaction Request specifying the IBAN.
An App could hide these separate steps from the User.
With a FREE_FORM Transaction Request, the application developer / bank is free to specify any details in the "body" of the Transaction Request which could include multiple payments and additional metadata. This puts more responsibility on the backend Adapter to validate the request.
An attribute of the Transaction Request that allows the User to specify who should pay the charges: SENDER, RECIEVER or SHARED
A call to the Connector / Adapter that determins the charge for this transaction_request_type, account_id etc.
A call to the Connector / Adapter that determins the minimum value that will trigger a security challenge. Parameters include bank_id, account_id, view_id, transaction_request_type and user_id, currency and amount.
A call to the Connector / Adapter to create a security challenge and send it out of bounds. Returns a challenge_id
A call to the Connector/Adapter to validate the answer given to a security challenge specified by challenge_id. This is called during the answerTransactionRequestChallenge call.
See here
