Business Overview

Roles

MyBank business cases presented below involve the following roles:

RoleDescription
Payer, Buyer, Authorising PartyThe subject responsible of authorising a MyBank transaction.
The term ‘Buyer’ is used noting that a Buyer can be a consumer, a small business, a medium-sized business or any other organisation that uses a human interface to authorise a purchase or a payment.
Payee, Seller, MerchantThe subject that, in the end, receives the funds of the MyBank transaction.
The term ‘Seller’ is used to refer to a ‘merchant’, however it also encompasses actors like charity organisations, public administrations, corporate entities that need to collect payments from Buyers.
Payer PSP, Buyer BankThe Bank or Payment Service Provider of the Payer that allows him to authenticate and authorise MyBank transactions and underlying payments.
Payee PSP, Seller Bank, Initiating PartyThe Bank or Payment Service Provider that, through his connection to the MyBank Gateway, provides Merchants or other PSPs with the MyBank solution.
API ClientThe subject technically connected to the MyBank Gateway. It might be the Payee PSP or a subject acting on behalf of the Payee PSP.
First BeneficiaryThe first subject that receives the funds.
As specified in MyBank Adherence Agreement for Payee PSP, the Payee PSP must be either (or both) the Account Holder or the Account Servicing PSP of the Beneficiary Account of MyBank payments.
Ultimate BeneficiaryThe last subject that receives the funds.
It almost always corresponds to the Merchant but in case the Merchant sells financial services (as for example pre-paid cards top-up) the Ultimate Beneficiary may be different.

Functional Flows

Aim of this section is listing and explaining the set of technical flows that a Payee PSP can implement with the MyBank Gateway APIs.

  • MyBank Standard Flow
  • MyBank QR Code Flow

Please note that each Payee PSP can decide which flow(s) to implement. The MyBank Standard Flow is typically considered the main one and is implemented by most Payee PSPs.

MyBank Standard Flow

The MyBank Standard Flow is used when the Payee and the Payer interacts to provide, at the same time, all the necessary data to initiate a MyBank Transaction.
In other words, all the MyBank transaction data items (including the Payer PSP as chosen by the Payer) are collected by the Payee PSP before initiating the MyBank transaction.

The classic scenario for this flow is the e-commerce use case, which could be described by the following steps:

(a) On the Merchant's checkout page the Payer selects MyBank as payment method
(b) The Payee PSP shows the list of the available Payer PSPs (using a cached response from the Payer PSPs List API)
(c) The Payer selects his Payer PSP from the list
(d) The Payee PSP initiates a MyBank Transaction, by invoking the Payment Initiation API
(e) The Payer is redirected to the Payer PSP's environment (i.e., typically his Internet/Mobile Banking or App)
(f) The Payer authenticates himself and authorises the MyBank Transaction
(g) The Payer is redirected back to the Merchant's environment
(h) The Payee PSP retrieves the result of the transaction, by invoking the Payment Result API
(i) The Merchant's website presents the business confirmation message to the Payer.

MyBank QR Code Flow

The MyBank QR Code Flow is composed by two phases.
In the first phase, the Merchant generates a MyBank Payment Request: to do this, the Merchant only needs information that he knows (in particular, the Payer PSP is NOT needed).
The Payment Request must then be presented to the Payer in the form of a proprietary MyBank QR Code (which only includes the identifier of the Payment Request).
In the second phase, the Payer chooses his Payer PSP and scans the MyBank QR Code to trigger the initiation of a MyBank transaction. This step involves the use of a Mobile App able to scan the MyBank QR Code (for example the MyBank App).

Suitable scenarios for this flow include payment-on-delivery and invoices, which could be described by the following steps:

First phase:
(a) The Payee asks for a new MyBank QR Code
(b) The Payee PSP creates a MyBank Payment Request, by invoking the Payment Request Create API
(c) The MyBank Gateway creates the Payment Request and returns the Payment Request's unique ID
(d) The unique ID is rendered under the form of a MyBank QR Code (by the Payee PSP or by the Payee) and sent or shown to the Payer
Second phase:
(e) The Payer chooses his Payer PSP and scans the MyBank QR Code using the MyBank App
(f) The Payer is redirected to the Payer PSP's environment (i.e., typically his Internet/Mobile Banking)
(g) The Payer authenticates himself and authorises the MyBank Transaction
(h) The Payer is redirected back to the MyBank App, which retrieves the result of the Transaction
(i) The MyBank App notifies the Payee PSP that the final result for the MyBank transaction is available
(j) The Payee PSP retrieves the result of the transaction by invoking the Transaction Details API
(k)The Payee PSP returns a Payee's customized confirmation page.

Please find below a couple of Sequence Diagrams that show an example of how the APIs can be used to implement the QR Code Flow:

|