Requirements and recommendations

Suggest Edits

Implementation Guide

Depending on the target use case(s) and on the arrangements in place with the Payees, the Payee PSP will need to implement the Client for some of the APIs documented in the next sections, as well as some specific UI functionalities.
Payee PSPs are recommended to check MyBank UX Guidelines documentation carefully. The Solution Manager will be happy to provide help.

In order to implement the Standard MyBank Flow, Payee PSPs will typically need to:

  • Add the MyBank Payment option (the MyBank's "payment button") to their Payees' websites.
  • Integrate the Payer PSPs List API, and implement the related caching mechanism.
  • Implement the Payer PSPs selection screen.
  • Integrate the Payment Initiation API, and implement the related redirection to the Payer PSP's environment.
    Reminder: the redirection must not occur within an iframe, nor within an embedded WebView, etc. Please consider all possible scenarios carefully, especially on the mobile environment, where the redirection will typically trigger the Payer PSP's App.
  • Handle the return redirection from the Payer PSP's environment, as well as implement an appropriate mechanism to retrieve the status of transactions for which no return redirection occurs.
    Please pay attention to the note regarding the return URL in the documentation for the Payment Initiation API.
  • Integrate the Payment Result API.

In order to implement the QR Code Flow, Payee PSPs will typically need to:

  • Integrate the Payment Request Create API, and implement some mechanism to generate the QR Code and present it to the Payer.
  • Handle the return redirection as well as implement an appropriate mechanism to retrieve the status of Payment Requests for which no return redirection occurs (this requires integrating the Payment Request Details API).
  • Integrate the Transaction Details API.
  • Optionally integrate the Payment Request Disable API (if the disable functionality is needed).

MyBank Four Principles

MyBank is built upon four key end-to-end Principles which govern the services provided to a Seller. Every actor that makes use of the MyBank APIs, in relation to his role, *MUST guarantee that these key principles are fully respected.

1st Principle

  • When a Seller is informed that a MyBank Transaction has been authorised, the Seller can be sure that the Buyer has made an irrevocable commitment to his Buyer Bank to execute the associated SCT within scheme and PSD timescales.

2nd Principle

  • A Seller can be sure that he can benefit of the automatic reconciliation mechanisms included in the MyBank API. The First Beneficiary can be sure that an incoming MyBank authorised payment will have the same identifiers/references provided when the associated Transaction was initiated. (See section "Data Items" for more details).

3rd Principle

  • A Seller can be sure that if a Transaction is not authorised then he will not receive any associated payment.

4th Principle

  • A Seller can be sure that for each Transaction that he initiates, he will receive a definitive decision, “Authorised” or “Not authorised”, within the time frame that the Seller himself requested.

The only exceptions to which these principles are subjects to are included in the legal documentation package.

User Experience and Style Guide

The MyBank User Experience presented to the final users must follow rules and recommendation included in the MyBank UX Guidelines and MyBank Graphics Guidelines documents. These can be downloaded from the website's reserved area.

Further requirements and recommendations for Payee PSPs

Besides implementing the flows described in the "Business Overview", by building the client-side of the API as explained in the "API Technical Overview", Payee PSPs must take into account several additional requirements and recommendations:

  • The Payee PSP is responsible for carrying out all necessary “Know Your Customer” checks on the Payee and *MUST:

    • Verify and register internally the merchantTradingName.
    • Assign and register the agreed mechanism for crediting to the Payee all funds deriving from authorised MyBank transactions.
    • Assign and register internally an initiatingPartySubID for the Payee.
    • Ensure that the Payee understands both the need and the mechanism to be used to provide the Ultimate Beneficiary's name when initiating transactions (see remittanceInformation in the "Reference Information" section for further information).

  • The Payee PSP MUST ensure that all exchanges of MyBank transactional messages with the Payee only take place through connections respecting the following requirements:

    • Strong authentication of each end-point.
    • Confidentiality of transferred data with state-of-the-art encryption algorithms.

  • The Payee PSP *MUST ensure the confidentiality and integrity of all MyBank related business data.

  • The Payee PSP *MUST promptly react if fraudulent or incorrect behaviour has been detected.
    The Payee PSP *MUST inform the Solution Manager immediately any of the following applies:

    • Funds are NOT received after a MyBank Transaction has been authorised.
    • Funds are received after a MyBank Transaction has NOT been authorised.
    • Compromised behaviour from another MyBank participant has been detected.
    • The Payee PSP itself has been compromised and is aware of it.

  • The Payee PSP MUST be capable of blocking all MyBank operations from a particular Payee, in case this Payee has been compromised or otherwise needs to be excluded from MyBank operations.

  • The Payee PSP MUST ensure that the party responsible for redirecting Payers to their Buyer Bank does not redirect within an iframe nor within embedded WebView.

  • The Payee PSP *MUST ensure that the Payee respects the user experience requirements given in the “MyBank UX Guidelines for Payee PSP”.

  • MyBank only allows to specify the amount of the payment in Euro.
    If the Payee has non-Euro pricing, then the currency conversion must be done by the Payee PSP. The currency conversion process lies outside the scope of the MyBank specifications; however, the Payee PSP MUST ensure that the Payee shows to the Payer the final price in both the original currency and in Euro.
    See orderDescription in the "Reference Information" section for further information.

  • The Payee PSP MUST provide a basic set of functionalities to the Payee (details will depend on the specific integration model between the Payee and the Payee PSP):

    • The Payee PSP MUST provide a technical mechanism allowing the Payee to request details of a previously initiated transaction.
    • The Payee PSP *MUST ensure that they identify and report all underlying payments in relation to MyBank Transactions to Payees. The Payee PSP *MUST ensure that Payees have access to all the data needed for automatic reconciliation of these incoming payments with their MyBank transactions.
    • The Payee PSP *MUST provide a technical mechanism allowing the Payee to automatically generate a full or partial refund in Euro in relation to any MyBank underlying payments, without the Payee having access to the Buyer’s IBAN. The refund MAY be larger than the original Euro amount (for a non-Euro Seller account, this could occur because of currency fluctuations).
      The refund Credit Transfer MUST contain the endToEndID of the original MyBank Transaction in the field CdtTrfTxInf/PmtId/EndToEndId.

  • The Payee PSP *MUST provide archiving of all messages exchanged with the MyBank Gateway for one year after transaction initiation so that within this period:

    • Payees can collect or verify all business data associated with a transaction (this includes the status).
    • Payee PSPs can demonstrate that the business data registered in their archive is exactly as exchanged with the MyBank Gateway (non-repudiation).

  • The Payee PSP MUST ensure that its system clocks are accurate to within 2 seconds.

  • A MyBank transaction is defined to have been blocked by a party if

    • The Party prevents the authorisation of the transaction through a non-compliance to the MyBank specifications and requirements, or
    • The Party prevents the Payee from being promptly informed that the transaction has been authorised.
      A Parties MyBank Service is defined to be unavailable during a given period (period of unavailability) if all transactions processed within that period are blocked by the Party. By definition, a period of unavailability must have at least two consecutive transactions blocked by the Participant.
      Examples of periods of unavailability:
    • A Payee PSP blocks a transaction at 09:15, another at 09:30 with no other transactions in between and no other blocked transactions that day. In this case the Payee PSP is unavailable for 15 minutes.
    • A Payee PSP blocks a transaction at 09:15, allows a transaction to be authorised at 09:20 and blocks a transaction at 09:30 with no other transactions blocked that day. In this case the Payee PSP has no periods of unavailability.
      The Payee PSP *MUST ensure that their respective MyBank Services are available for at least 99% of each calendar day (including weekends, holidays and non-Target days).
      The Payee PSP *MUST agree with the Solution Manager a period of planned unavailability with a notice of 5 working days - the SLA will not be applicable within such agreed periods. Parties MUST take into account their typical MyBank transaction usage profile when planning unavailability.

  • In case a chain of PSPs exist on the Payee-side, all above mentioned responsibilities must be covered along the chain.

  • When a single Participant plays the parts of both the Payer PSP and the Payee PSP for a MyBank Transaction (and so settlement can occur internally) the Payee PSP MUST use the MyBank Gateway for processing the transaction.

Updated 4 months ago