/
Pay Request enabled by Open Finance

This space is deprecated and no longer supported. Please use the latest available version here.

Pay Request enabled by Open Finance

Owned by Chris Michael
Last updated: 18 Oct 2024 by Alexandros Dimitrakoudis
12 min read

1. Description

The Bank Service Initiation functionality of the Open Finance Standard can become an enabler for additional functionality to be implemented by TPPs. One example of functionality is the implementation of Pay Request (PR). This functionality enables TPPs to initiate payment requests from a Sender (Creditor) to a Recipient (Debtor) business or a person. The Pay Request includes all the information about the payment including the Creditor’s payment account which will be used to receive the funds, if the Pay Request is accepted by the Recipient (Debtor). The Pay Request is then fulfilled using the existing Bank Service Initiation functionality defined in the Open Finance Standard.

The PR scope can be initially targeted to domestic creditor accounts (i.e. creditor accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.

Note: Pay Request (PR) can be initiated by all UAE account-holding users (Creditors) and sent to all UAE account-holding owners (Debtors) without any requirement for enrollment with the UAEIPP Overlay Service directory service, provided that users have a valid email address and/or a valid mobile phone number to receive the Pay Requests.

1.1 Debtor and Creditor Segments

The scope of the Pay Request functionality related to the segments of debtors and creditors is shown below:

PR Sender (Creditor)

PR Recipient (Debtor)

PR Sender (Creditor)

PR Recipient (Debtor)

Consumer

SME

Corporate

Consumer

SME

Corporate

There are no restrictions on who can send PRs to whom. All possible combinations are available including individual to individual, individual to business, business to individual and business to business.

1.2 Pay Request (PR) - Example User Story

User Story

As a User (Consumer, Business or Corporate),

I want to have the ability to send a payment request with all the payment details to a debtor (debtor),

so that I can get paid directly to my payment account when the debtor accepts the request and initiates a payment using Open Finance.

Note: It is in the competitive space of TPPs to innovate further supporting services, in addition to these guidelines. For example:

  • Sending multiple Payment Requests to multiple Users who should split a certain payment (e.g. friends dinner) using various splitting methods (e.g. percentage or custom split)

  • Creating predefined groups of Users who frequently split & share certain payments (e.g. weekly, monthly or yearly)

  • Schedule Payment Requests to be triggered at a specific date & time in the future.

2. Example Process Flow

The below diagram depicts the process flow from initiating a Pay Request to fulfilment with a payment via an Open Finance Standard Payment Initiation.

CBUAE Payment Request New.jpeg
Pay Request Example Process Flow

3. Example Rules & Guidelines

#

Step

Rules & Guidelines

#

Step

Rules & Guidelines

PR-1

Pay Request Start

TPPs COULD:

1. Allow Users, after starting the TPP application, to select the option to send a Pay Request.

PR-2

Check User Onboarded

TPPs COULD:

2. Check if the User is already onboarded or not:

  • 2.1 If the User is NOT onboarded, go to step 3

  • 2.2 If the User is onboarded, go to step 4

PR-3

Get User Account Details

TPPs COULD:

3. Allow Users to provide the following payment account details to be used for receiving the Pay Request funds when paid by the recipients.

  • IBAN of the User’s payment account

  • Name of the User (First/Last Name or Business Name)

PR-4

Check User is Business

TPPs COULD:

4. Check if the User is a business or not:

  • 4.1 If the User is NOT a business, go to Step 5

  • 4.2 If the User is a business, go to step 7

PR-5

Request Confirmation of Payee (COP)

TPPs COULD:

  1. Invoke the Confirmation of Payee service provided by Open Finance as defined in Confirmation of Payee to validate the User’s Name against the payment account provided.

PR-6

Check COP Response

TPPs COULD:

6. Check if the Response from the COP Service:

  • 6.1 If the Exact Match is Yes, go to step 8. TPPs should only allow Users to continue with the Pay Request if they have verified the User Name and the payment account.

  • 6.2 If the Exact Match is No, TPPs should choose how to manage this error scenario.

PR-7

Apply business onboarding process (KYB)

TPPs COULD:

  1. Apply the KYB processes for onboarding businesses. As part of this, TPPs should validate the business name and the payment account as defined in Common Rules and Guidelines | 9.3.1 Details Verification for Merchants onboarded by TPPs.

PR-8

Get Pay Request Recipient(s)

TPPs COULD:

  1. Allow Users to select the Recipient(s) of the Pay Request by providing email, mobile phone number or any other user identification to be used for sending the Pay Request message to them.

PR-9

Get Pay Request details

TPPs COULD:

  1. Allow Users to provide the Pay Request details or pre-populate the details depending on the use case. The details required are:

  • Pay Request Amount: This will be in local currency (AED).

  • Pay Request Reference: This is a text reference describing the Pay Request. This may include any information the User wants to provide to the Recipient (Debtor) and can be used in identifying and reconciling the payment.

  • Validity Period: This is the period the Pay Request will be valid for. Any Pay Request that has not received a response from the Recipient (Debtor) will expire and cannot be actioned.

PR-10

Generate Pay Request Info

TPPs COULD:

  1. Generate an actionable link that will be used to direct the Recipient (Debtor) to the information about the Pay Request.

PR-11

Set Pay Request state to Pending

TPPs COULD:

  1. Keep track of the state of each Pay Request Message throughout its lifecycle. When the Pay Request message is initiated, TPPs should set its state to Pending.

PR-12

Get a method to send a Pay Request

TPPs COULD:

  1. Allow Users to select the method they want to use for sending the Pay Request message to the Recipient (Debtor). This may include any standard methods available by Users devices for forwarding/sharing of information, including email, SMS, messaging applications etc. Alternatively, if the Recipient (Debtor) is also a user of the TPP application, TPPs may use their backend systems to forward the Pay Request message information to Recipients (Users).

PR-13

Forward Pay Request

TPPs COULD:

  1. Alternatively to step 12, if the Recipient (Debtor) is also a user of the TPP application, TPPs may use their backend systems to forward the Pay Request message information to Recipients (Users).

PR-14

Receive Pay Request link

Recipients (Users) MAY:

  1. Receive the Pay Request message including the actionable link using the forwarding/sharing method selected by the Sender (User). Alternatively, Recipients (Debtors) may receive a notification of a pending Pay Request message from the TPP directly, if they are also onboarded users of the TPP application.

PR-15

Open Pay Request (Y/N)

Recipients (Debtors) MAY:

  1. Decide to do the following:

  • 15.1 Either click to follow the actionable link/open the TPP notification. In this case, go to step 18

  • 15.2 Or not to take any action. In this case, go to step 16

PR-16

Check the Request Validity Period when no action

TPPs COULD:

  1. Monitor the elapsed time from when the Pay Request message was sent to the Recipient (Debtors) against the Validity Period.

  • 16.1 If the Recipient (Debtor) has taken no action during the Validity Period AND the validity period has expired, then go to step 17

  • 16.2 If the Recipient (Debtor) has taken no action during the Validity Period AND the Pay Request is still within the validity period, then go to step 14

PR-17

Pay Request Expired

TPPs COULD:

17.1 Set the Pay Request state to Expired.

17.2 Send a notification to the Sender (Creditor) that the Pay Request has expired and can no longer be actioned.

PR-18

Check Request Validity Period when Request Opened

TPPs COULD:

  1. Monitor the elapsed time from when the Pay Request message was sent to the Recipient (Debtors) against the Validity Period.

  • 18.1 If the Recipient (Debtor) has opened the Pay Request AND the validity period has expired, then go to step 17

  • 18.2 If the Recipient (Debtor) has opened the Pay Request AND the Pay Request is still within the validity period, then go to step 19

PR-19

Display Pay Request to Recipient

TPPs MUST:

  1. Display the details of the Pay Request to the Recipients (Debtors). This information includes:

  • Pay Request Amount

  • Sender Information (Creditor): This includes the payment account details to receive the funds and the Creditor Name (First/Last Name or Business Name)

  • Pay Request Reference

  • Validity Period

PR-20

Get Accept/Reject of Pay Request

TPPs MUST:

  1. Allow Recipients (Debtors) to either Accept or Reject the Pay Request.

  • 20.1 If Recipients (Debtors) Reject the Pay Request, go to step 21

  • 20.2 If Recipients (Debtors) Accept the Pay Request, go to step 22

PR-21

Pay Request Rejected

TPPs COULD:

21.1 Set the Pay Request state to Rejected.

21.2 Send a notification to the Sender (Creditor) that the Pay Request has been rejected by the Recipient (Debtor) and that no payment will be received.

PR-22

Get LFI selection for Payment Initiation

Recipients (Debtors) Accept the Pay Request

TPPs COULD:

  1. Allow Users to select the LFI they want to use for Payment Initiation.

PR-23

Check long-lived consent exists

TPPs COULD:

23. Check if the Recipient (Debtor) has provided long-lived consent to the TPP for the selected LFI or not:

  • 23.1 If Recipients (Debtors) have not provided long-lived consent, go to step 24

  • 23.2 If Recipients (Debtors) have provided long-lived consent, go to step 29

PR-24

Single Instant Payment Consent

TPPs MUST:

  1. Allow Users to Initiate a Single Instant Payment as per the Single Instant Payments | 3.1 Standard Journey of the Open Finance Standard, pre-populating the following information:

  • Payment Amount: This should be pre-populated with the Pay Request Amount

  • Creditor Identification: This will be pre-populated with the Pay Request Sender Information, including:

    • Creditor account details ( IBAN & LFI Name)

    • Creditor Name (First/Last Name or Business Name)

  • Creditor Reference: This should be pre-populated with the Pay Request Reference

PR-25

Acquire User Consent for Single Instant Payment Initiation

TPPs MUST:

  1. Enable Users to provide explicit consent for the initiation of an SIP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent, as per the Single Instant Payments | 3.1 Standard Journey of the Open Finance Standard.

  • 25.1 If Recipients (Debtors) do not provide explicit consent, go to step 21

  • 25.2 If Recipients (Debtors) provide explicit consent, go to step 26

PR-26

Proceed with the Payment Initiation Journey

TPPs MUST:

  1. Proceed with the Single Instant Payment Initiation journey as per the Single Instant Payments | 3.1 Standard Journey of the Open Finance Standard.

PR-27

Authentication with LFI

TPPs MUST:

  1. Enable Users to perform authentication with their LFIs as per the Single Instant Payments | 3.1 Standard Journey of the Open Finance Standard.

PR-28

Check Single Payment Consent Authorized (Y/N)

TPPs COULD:

  1. Check the status of the Single Instant Payment consent, as per the Consent Setup | 4. Consent States of the Open Finance Standard.

  • 28.1 If the payment consent is Authorized, go to step 32.

  • 28.2 If the payment consent is Rejected, go to step 21.

PR-29

Check long-lived consent selected

TPPs COULD:

29. Check if the Recipient (Debtor) has selected to use the existing long-lived consent provided to the TPP for the selected LFI or not:

  • 29.1 If Recipients (Debtors) selected not to use the existing long-lived consent, go to step 24

  • 29.2 If Recipients (Debtors) selected to use the existing long-lived consent, go to step 30

PR-30

Check Single Payment Authorized with TPP (Y/N)

TPPs COULD:

  1. Request Recipient (Debtor) to authorize the payment initiation with the TPP, as per the Multi-Payments | 1.6 Multi Payments to Variable Beneficiaries of the Open Finance Standard.

  • 30.1 If the payment initiation is Authorized, go to step 32.

  • 30.2 If the payment initiation is Rejected, go to step 21.

PR-31

Proceed with Payment Initiation using Long-lived Consent

 

TPPs MUST:

  1. Proceed with the Payment Initiation journey as per the Multi-Payments | 5. Payment Initiation of the Open Finance Standard.

PR-32

Pay Request Accepted

TPPs COULD:

32.1 Set the Pay Request state to Accepted.

32.2 Send a notification to the Sender (Creditor) that the Pay Request has been accepted by the Recipient (Debtor) and that payment was initiated.

PR-33

Check Payment Status

TPPs COULD:

  1. Check the status of the Single Instant Payment Initiation, as per the Common Rules and Guidelines | 15. Payment Status Update of the Open Finance Standard.

  • 33.1 If the payment status indicates that the payment has been received successfully, go to step 34.

  • 33.2 If the payment status indicates that the payment has failed, go to step 29.

PR-34

Pay Request Paid

TPPs COULD:

34.1 Set the Pay Request state to Paid.

34.2 Send a notification to the Sender (Creditor) that the Pay Request has been paid to the Recipient’s payment account.

PR-35

Pay Request Failed

TPPs COULD:

35.1 Set the Pay Request state to Failed.

35.2 Send a notification to the Sender (Creditor) that the Pay Request has Failed and the payment will not be received at the Recipient’s payment account, even if the User has Accepted the Pay Request.

4. Example Customer Experience

4.1 Initial Journey (Pay Request Sent)

1

01.png

 

2

 

3

 

4

 

5

 

6

 

7

 

4.2 User has same TPP APP (A)

8.A

 

9.A

 

10.A

 

11.A

 

12.A

 

13.A

 

14.A

 

15.A

 

4.3 User accesses link via SMS, and flow will be in “Browser” (B)

8.B

 

9.B

 

10.B

 

11.B

 

12.B

 

13.B

 

14.B

 

15.B

 

16.B

 

5. Pay Request Status

For each Pay Request, there are multiple statuses as described below:

RTP Status

Description

RTP Status

Description

Pending

The RTP request is pending. The RTP has been sent successfully by the Creditor LFI and it is sitting in a temporal state waiting to be processed by the Recipient (Debtor). Further checks and status updates will be performed.

Accepted

The RTP request has been accepted by the RTP Debtor. Further checks and status updates will be performed.

Paid

The RTP Debtor has fulfilled and paid the RTP request. This is a terminal state.

Rejected

The RTP Debtor has rejected (i.e. “refused to accept”) the RTP request. This is a terminal state.

Cancelled

The Creditor has cancelled (i.e. “annulled”) the RTP request before being accepted or rejected by the RTP Debtor. This is a terminal state.

Expired

The RTP request has expired due to no action from the RTP Debtor during the validity period (i.e. the RTP Debtor has not accepted, paid or rejected it within the validity period). This is a terminal state.

Failed

The RTP request has failed due to an error either on the Sender’s (Debtor’s) LFI or the RTP Debtor’s receiving LFI. This is a terminal state.

6. Example Pay Request Cancelation Process

#

Step

Rules

#

Step

Rules

PRCAN-1

Pay Request Cancellation

TPPs COULD:

1.1 Enable Users to cancel an active Pay Request before it is actioned (accepted or rejected) by the Recipient (Debtor).

1.2 Request Users to authenticate within their application using Multi Factor-Authentication (MFA) before allowing them to cancel an active Pay Request.

PRCAN-2

Pay Request Cancelled

TPPs COULD:

2.1 Set the Pay Request state to Cancelled.

  • 2.1.1 Invalidate the information of the Pay Request in the actionable link that was used to direct the Recipient (Debtor). The Recipient (Debtor) should not be allowed to action the Pay Request and an appropriate message should be displayed that the Pay Request has been cancelled.

2.2 Enable Users to send a cancellation message for the Pay Request to the Recipient (Debtor). This may include any standard methods available by Users' devices for forwarding/sharing of information, including email, SMS, messaging applications etc.

  • TPPs should advise Users to send the cancellation message using the same method used to forward the Pay Request to the Recipients (Debtors).

2.3 Alternatively, if the Recipient (Debtor) is also a user of the TPP application, TPPs may use their backend systems to forward the cancellation message of the Pay Request to Recipients (Users).

2.4 Confirm the User that the Pay Request has been cancelled and can no longer be actioned by the Recipients (Debtors).

© CBUAE 2024
Open License and Contribution Agreement | Attribution Notice