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:

5. 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:

7. Apply the KYB processes for onboarding businesses. As part of this, TPPs should validate the business name and the payment account as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210800446266375125/Common+Rules+and+Guidelines#9.3.1-Details-Verification-for-Merchants-onboarded-by-TPPs.

PR-8

Get Pay Request Recipient(s)

TPPs COULD:

8. 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:

9. 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:

10. 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:

11. 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:

12. 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:

13. 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:

14. 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:

15. 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:

16. 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:

18. 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:

19. 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:

20. 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:

22. 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:

24. Allow Users to Initiate a Single Instant Payment as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210798067266372709/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:

25. 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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210798067266372709/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:

26. Proceed with the Single Instant Payment Initiation journey as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210798067266372709/Single+Instant+Payments#3.1-Standard-Journey of the Open Finance Standard.

PR-27

Authentication with LFI

TPPs MUST:

27. Enable Users to perform authentication with their LFIs as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210798067266372709/Single+Instant+Payments#3.1-Standard-Journey of the Open Finance Standard.

PR-28

Check Single Payment Consent Authorized (Y/N)

TPPs COULD:

28. Check the status of the Single Instant Payment consent, as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210796838266371380/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:

30. Request Recipient (Debtor) to authorize the payment initiation with the TPP, as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210798542266373190/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:

31. Proceed with the Payment Initiation journey as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210798542266373190/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:

33. Check the status of the Single Instant Payment Initiation, as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1finalstandardsv1dot2draft1/pages/210800446266375125/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.