Transaction Requests

Simon Redfern edited this page Mar 10, 2017 · 9 revisions

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

SANDBOX_TAN

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.

COUNTERPARTY

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:

  1. A user who has can_add_counterparty on the Account/View creates a Counterparty with the correct routing information.
  2. 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.

SEPA

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:

  1. A user who has can_add_counterparty on the Account/View creates a Counterparty with the SEPA routing information.
  2. A user who is an account holder creates a Transaction Request specifying the IBAN.

An App could hide these separate steps from the User.

FREE_FORM

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.

The following are common to most Transaction Request Types:

charge_policy

An attribute of the Transaction Request that allows the User to specify who should pay the charges: SENDER, RECIEVER or SHARED

getChargeLevel

A call to the Connector / Adapter that determins the charge for this transaction_request_type, account_id etc.

getChallengeThreshold

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.

createChallenge

A call to the Connector / Adapter to create a security challenge and send it out of bounds. Returns a challenge_id

validateChallengeAnswer

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.

Try in API Explorer

See here

Transaction Request Sequence diagram

create transaction request v2 1 0 march 10th 2017

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.