This space is deprecated and no longer supported. Please use the latest available version here.
Pay Request enabled by Open Finance
- Chris Michael
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) | ||||
|---|---|---|---|---|---|
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.
3. Example 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:
|
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.
|
PR-4 | Check User is Business | TPPs COULD: 4. Check if the User is a business or not:
|
PR-5 | Request Confirmation of Payee (COP) | TPPs COULD:
|
PR-6 | Check COP Response | TPPs COULD: 6. Check if the Response from the COP Service:
|
PR-7 | Apply business onboarding process (KYB) | TPPs COULD:
|
PR-8 | Get Pay Request Recipient(s) | TPPs COULD:
|
PR-9 | Get Pay Request details | TPPs COULD:
|
PR-10 | Generate Pay Request Info | TPPs COULD:
|
PR-11 | Set Pay Request state to Pending | TPPs COULD:
|
PR-12 | Get a method to send a Pay Request | TPPs COULD:
|
PR-13 | Forward Pay Request | TPPs COULD:
|
PR-14 | Receive Pay Request link | Recipients (Users) MAY:
|
PR-15 | Open Pay Request (Y/N) | Recipients (Debtors) MAY:
|
PR-16 | Check the Request Validity Period when no action | TPPs COULD:
|
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:
|
PR-19 | Display Pay Request to Recipient | TPPs MUST:
|
PR-20 | Get Accept/Reject of Pay Request | TPPs MUST:
|
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:
|
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:
|
PR-24 | Single Instant Payment Consent | TPPs MUST:
|
PR-25 | Acquire User Consent for Single Instant Payment Initiation | TPPs MUST:
|
PR-26 | Proceed with the Payment Initiation Journey | TPPs MUST:
|
PR-27 | Authentication with LFI | TPPs MUST:
|
PR-28 | Check Single Payment Consent Authorized (Y/N) | TPPs COULD:
|
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:
|
PR-30 | Check Single Payment Authorized with TPP (Y/N) | TPPs COULD:
|
PR-31 | Proceed with Payment Initiation using Long-lived Consent
| TPPs MUST:
|
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:
|
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
| 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 |
|---|---|
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 |
|---|---|---|
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.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.
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
Please try out our Advanced Search function.