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 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 MAY:

3. Allow Users to provide their the following 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:

.

• 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

PR-4

Check User is Business

TPPs MAY:

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

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

• 4.2 If the 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 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 chose choose how to manage this error scenario.

PR-7

Apply

business 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 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 MAY:

9. Allow Users to provide the Pay Request details or pre-popullate 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 (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 a method to send a 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, smsSMS, messaging applications etc. AltenativelyAlternatively, 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

Forward Pay Request

TPPs MAY:

13. Altenatively Alternatively 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). AltenativelyAlternatively, Recipient Recipients (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 the 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 the Recipient (Payer) has taken no action during the Validity Period AND the validity period has expired, then go to step 17

• 16.2 If the 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 the Recipient (Payer) has opened the Pay Request AND the validity period has expired, then go to step 17

• 18.2 If the 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 the 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 select the LFI they want to use for Payment Initiation.

PR-23

Check long-lived consent exists

TPPs MAY:

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

• 23.1 If Recipients (Payers) have not 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 an 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 explicit consent, go to step 21

• 25.2 If Recipients (Payers) 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/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 the 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 accepted by the Recipient (Payer) and that no payment will be receivedwas initiated.

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

Pending

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

Accepted

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

Paid

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

Rejected

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

Cancelled

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

Expired

The RTP request has expired due to no action from the RTP Payer during the validity period (i.e. the RTP Payer 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 (Payer’s) LFI or the RTP Payer’s receiving LFI. This is a terminal state.

PRCAN-1

Pay Request Cancellation

TPPs MAY:

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

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 MAY:

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 for to direct the Recipient (Payer). The Recipient (Payer) 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 (Payer). This may include any standard methods available by Users' devices for forwarding/sharing of information, including email, smsSMS, messaging applications etc.

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

2.3 AltenativelyAlternatively, if the Recipient (Payer) 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 (Payers).