PR-1

Pay Request Start

TPPs MAY:

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

PR-2

Check User Onboarded

TPPs MAY:

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

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

• 2.2 If User is onboarded, go to step 4

PR-3

Get User Account Details

TPPs MAY:

3. Allow Users to provide their payment account details to be used for receiving the Pay Request funds when paid by the recipients. These may be one of the following options:

• 3.1 IBAN: In this case the information to acquire from the Users will be:

  • IBAN of the User’s payment account

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

• 3.2 Account Number (Domestic): In this case the information to acquire from the Users will be:

  • Account Number of the User’s payment account. This is the 12 or 14 digits domestic account number of the User with their LFI.

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

  • The User’s payment account holding entity (i.e. LFI). TPPs may enable Users to identify the holding entity using its trading name which is familiar to Users.

PR-4

Check User is Business

TPPs MAY:

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

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

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

PR-5

Request Confirmation of Payee (COP)

TPPs MAY:

5. Invoke the Confirmation of Payee service provided by Open Finance as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft5/pages/109413626/Single+Instant+Payment#3.3-Using-Confirmation-of-Payee-(COP) in order to validate the User’s Name against the payment account provided.

PR-6

Check COP Response

TPPs MAY:

6. Check if the Response from the COP Service:

• 6.1 If 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 Exact Match is No, TPPs should chose how to manage this error scenario.

PR-7

Apply Busines onboarding process (KYB)

TPPs MAY:

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/standardsv1rc1/pages/121375612/Common+Rules+and+Guidelines#9.3.1-Details-Verification-for-Merchants-onboarded-by-TPPs.

PR-8

Get Pay Request Recipient(s)

TPPs MAY:

8. Allow Users to select 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 MAY:

9. Allow Users to provide the Pay Request details or pre-popullate 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 (Payer) 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 (Payer) will expire and cannot be actioned.

PR-10

Generate Pay Request Info

TPPs MAY:

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

PR-11

Set Pay Request state to Pending

TPPs MAY:

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 method to send Pay Request

TPPs MAY:

12. Allow Users to select the method they want to use for sending the Pay Request message to the Recipient (Payer). This may include any standard methods available by Users devices for forwarding/sharing of information, including email, sms, messaging applications etc. Altenatively, if the Recipient (Payer) 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

Foward Pay Request

TPPs MAY:

13. Altenatively to step 12, if the Recipient (Payer) 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). Altenatively, Recipient (Payers) 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 (Payers) 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 Request Validity Period when no action

TPPs MAY:

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

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

• 16.2 If Recipient (Payer) 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 MAY:

17.1 Set the Pay Request state to Expired.

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

PR-18

Check Request Validity Period when Request Opened

TPPs MAY:

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

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

• 18.2 If Recipient (Payer) has 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 MAY:

19. Display the details of Pay Request to the Recipients (Payers). This information includes:

• Pay Request Amount

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

• Pay Request Reference

• Validity Period

PR-20

Get Accept/Reject of Pay Request

TPPs MAY:

20. Allow Recipients (Payers) to either Accept or Reject the Pay Request.

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

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

PR-21

Pay Request Rejected

TPPs MAY:

21.1 Set the Pay Request state to Rejected.

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

PR-22

Get LFI selection for Payment Initiation

Recipients (Payers) Accept the Pay Request

TPPs MAY:

22. Allow Users to selects the LFI they want to use for Payment Initiation.

PR-23

Check long-lived consent exists

TPPs MAY:

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

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

• 23.2 If Recipients (Payers) 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/standardsv1rc1/pages/121374011/Single+Instant+Payment#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

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

  • Payee account details (in IBAN or domestic account format & LFI Name)

  • Payee 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 a SIP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent, as the as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc1/pages/121374011/Single+Instant+Payment#3.1-Standard-Journey of the Open Finance Standard.

• 25.1 If Recipients (Payers) do not provide explicity consent, go to step 21

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

PR-26

Proceed with Payment Initiation Journey

TPPs MUST:

26. Proceed with the Single Instant Payment Initiation journey as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc1/pages/121374011/Single+Instant+Payment#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/standardsv1rc1/pages/121374011/Single+Instant+Payment#3.1-Standard-Journey of the Open Finance Standard.

PR-28

Check Single Payment Consent Authorized (Y/N)

TPPs MAY:

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

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

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

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

PR-30

Check Single Payment Authorized with TPP (Y/N)

TPPs MAY:

30. Request Recipient (Payer) to authorize the payment initiation with the TPP, as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc1/pages/121374398/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 Single Instant Payment Initiation journey as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1rc1/pages/121374398/Multi-Payments#5.-Payment-Initiation of the Open Finance Standard.

PR-32

Pay Request Accepted

TPPs MAY:

32.1 Set the Pay Request state to Accepted.

32.2 Send a notification to the Sender (Payee) that the Pay Request has been rejected by the Recipient (Payer) and that no payment will be received.

PR-33

Check Payment Status

TPPs MAY:

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

34.1 Set the Pay Request state to Paid.

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

PR-35

Pay Request Failed

TPPs MAY:

35.1 Set the Pay Request state to Failed.

35.2 Send a notification to the Sender (Payee) 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.