Documentation
Start typing to search…

Requirements and Recommendations for Payee PSPs

Guidelines and requirements for Payee PSPs implementing MyBank APIs, including implementation guides, principles, and user experience recommendations.

Implementation Guide

Depending on the target use case(s) and the arrangements with the Payees, the Payee PSP will need to implement the Client for some of the APIs documented in the following sections, as well as specific UI functionalities. Payee PSPs are advised to carefully review the MyBank UX Guidelines documentation. The Solution Manager is available to provide assistance.

To implement the MyBank Standard Flow, Payee PSPs typically need to:

  • Add the MyBank Payment option (the MyBank "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. Note: The redirection must not occur within an iframe or an embedded WebView. Consider all possible scenarios carefully, especially on mobile devices, where the redirection will typically trigger the Payer PSP's App.
  • Handle the return redirection from the Payer PSP's environment and implement an appropriate mechanism to retrieve the status of transactions for which no return redirection occurs. Note: Pay attention to the note regarding the return URL in the documentation for the Payment Initiation API.
  • Integrate the Payment Result API.

To implement the MyBank QR Code Flow, Payee PSPs typically need to:

  • Integrate the Payment Request Create API and implement a mechanism to generate the QR Code and present it to the Payer.
  • Handle the return redirection and 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 that govern the services provided to a Seller. Every actor using the MyBank APIs, in relation to their role, *MUST guarantee that these key principles are fully respected.

1st Principle

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

2nd Principle

  • A Seller can be sure that they can benefit from the automatic reconciliation mechanisms included in the MyBank API. The First Beneficiary can be sure that an incoming MyBank authorized 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 authorized, they will not receive any associated payment.

4th Principle

  • A Seller can be sure that for each Transaction they initiate, they will receive a definitive decision, “Authorized” or “Not authorized,” within the time frame that the Seller requested.

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

User Experience and Style Guide

The MyBank User Experience presented to the final users must follow the rules and recommendations 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 consider 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 the Payee with all funds deriving from authorized MyBank transactions.
    • Assign and register internally an initiatingPartySubID for the Payee.
    • Ensure that the Payee understands both the need and the mechanism 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 endpoint.
    • 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 behavior is detected. The Payee PSP *MUST inform the Solution Manager immediately if any of the following applies:

    • Funds are not received after a MyBank Transaction has been authorized.
    • Funds are received after a MyBank Transaction has not been authorized.
    • Compromised behavior from another MyBank participant is 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 if 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 or an 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 specifying 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 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.
    Generally speaking, these functionalities must be in line with those provided for other payment methods (details will depend on the specific integration model between the Payee and the Payee PSP):

    • The Payee PSP must provide to the Payee a way to export the list of MyBank Transactions.
    • 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 send a request for 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 is recommended to obtain the refund’s Beneficiary Name and IBAN from the Payment Result response (buyerName and buyerIBAN, respectively). If the refund’s Beneficiary Name and IBAN need to be obtained from the received MyBank underlying payment, the Payee PSP is recommended to first try to get them from the ultimate debtor-related fields if present (CdtTrfTxInf/UltmtDbtr/Nm and CdtTrfTxInf/UltmtDbtr/Id/OrgId/Other/Id, respectively), or else from the debtor-related fields (CdtTrfTxInf/Dbtr/Nm and CdtTrfTxInf/DbtrAcct/Id/IBAN, respectively).
      Refunds must be executed in a timely manner. At any moment, the status of the refund must be clear and available to the Payee and, upon request, to PRETA.

  • 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 authorization of the transaction through non-compliance with the MyBank specifications and requirements, or
    • The Party prevents the Payee from being promptly informed that the transaction has been authorized. A Party's 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 authorized 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 on 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.

  • Additional requirements regarding "Third-Party Funding".
    The Payee PSP that initiates a MyBank Transaction where the final beneficiary of the funds is a natural person (examples: transaction aiming to top up gaming accounts or wallets) *MUST:

    • Ensure that the name of the final beneficiary is provided within the remittanceInformation data item in the "Payment Initiation" request, as specified in section Data Items.
      The name must reflect the actual name of the final beneficiary as it results from the KYC process (for example, the name of the client who opened the gaming account), and it must not derive from information that the Payer may enter as "free text" not subject to verification.
      The Payee PSP is responsible to make the necessary agreements with the Payee to ensure this goal.
    • Upon reception of status "AUTHORISED" for the MyBank Transaction, implement the following logic:
      • Compare the name of the final beneficiary (for example, the name of the owner of the gaming account) with the value returned by "Payment Result" in the buyerName data item (name of the owner of the payment account).
        The comparison aims to identify an actual "mismatch" between the two names, and should therefore take into account common variations (difference in case, different name/surname order, joint bank accounts, salutations, etc.). The guidelines provided by the EPC in the context of "Verification of Payee" may be used as a reference to implement the comparison logic.
      • "Third-Party Funding" is not allowed in MyBank (for example, a bank account owned by "John White" cannot be used to top up a gaming account owned by "John Brown").
        This means that, in case a mismatch between the two names is detected, the Payee PSP must:
        • refrain from crediting the Payee (or the final beneficiary, if handled by the Payee PSP itself)
        • upon reception of the payment related to this MyBank Transaction, instruct a full refund

      In case of failure to implement this requirement, the Payee PSP will be held responsible of any financial loss that may derive by fraud schemes relying on "Third-Party Funding".

  • Additional requirements regarding marketplaces.
    The Payee PSP that intends to initiate MyBank Transactions for a marketplace is recommended to discuss this with the Solution Manager. Dedicated IDs may be agreed to ensure the best follow-up on the transactions.

  • In case a chain of PSPs exists 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.

  • Obligations of Payee PSPs regarding Verification of Payee (VoP) within MyBank: Even though it is not expected that Payer PSPs will issue VoP requests in the context of MyBank transactions, Payee PSPs that follow the “Collecting Operating Model” (i.e., Payee PSPs that collect funds on one or more technical/bulk account(s) to the benefit of multiple payees) must take appropriate measures to ensure that any incoming VoP request is properly handled. In particular, in case the funds are collected on account(s) held at a Credit Institution other than the Payee PSP itself, appropriate arrangements must be put in place between the Payee PSP and the Credit Institution.

Updated 8 days ago

What’s Next