Payments (Service Initiation) 2 min read
The Open Finance Payment Service Initiation capabilities enable TPPs to initiate payments on behalf of customers under explicit, consent-driven authorisation.
All payment initiations operate under explicit customer consent. The TPP requests the consent, the customer authorises it at their LFI, and the TPP may then submit payments within the bounds of what was authorised.
Bank Service Initiation Provider
Access to the Payment Service Initiation APIs requires the BSIP role. This role must be assigned to your application in the Trust Framework before making any payment requests. See Roles for the full list of scopes and grant types this role permits.
Note — within payments there is the ability to receive a small amount of data sharing permissions. If your consent includes ReadAccountsBasic, ReadAccountsDetail, or ReadBalances, in order to access this functionality you will also need the BDSP role.
Single Instant Payment
A one-time payment initiated immediately upon consent authorisation. The TPP specifies a fixed creditor account and amount at consent time; the customer authorises and the payment is submitted in a single flow. Suitable for checkout payments, bill settlement, and any scenario where a single, known amount is being paid to a known recipient.
Multi-Payment Consents
Multi-payment consents allow a TPP to initiate a series of payments over time under a single customer authorisation. The customer authorises the consent once; the TPP can then submit payments as needed within the rules defined at consent time. There are several variants, each suited to different use cases:
On Demand types let the TPP trigger payments at any time within the consent's period and limits, making them suitable for subscription billing, wallet top-ups, and discretionary recurring charges.
Periodic Schedule types enforce exactly one payment per calendar period (e.g. weekly, monthly), making them well suited to regular bills and standing payment arrangements.
Defined Schedule types lock payments to specific future dates set at consent time, which is ideal for instalment plans and known future obligations.
Delegated SCA
Delegated SCA is a variant of multi-payment consent where Strong Customer Authentication is performed by the TPP rather than the LFI. This enables a frictionless in-app payment experience — the customer authenticates once within the TPP's interface, and the LFI accepts that authentication for subsequent payments. Delegated SCA requires the TPP to hold an explicit delegation from the LFI and is subject to additional requirements. See Delegated SCA for details.
Which LFIs are live for Payment Initiation
LFIs currently accepting payment consents across UAE Open Finance.
Browse this section
The full set of pages for the Payments (Service Initiation) API.
Single Instant Payment
A one-time payment authorised and submitted in a single flow. Suited to checkout, bill settlement, and any one-known-amount payment to a known recipient.
Variable On Demand
Variable amounts within agreed limits, triggered on demand. Suited to subscription billing, wallet top-ups, and discretionary recurring charges.
Fixed On Demand
Fixed per-payment amount, triggered on demand within the consent period.
Variable Periodic Schedule
Exactly one payment per calendar period, variable amount per payment. Suited to regular bills.
Fixed Periodic Schedule
Exactly one payment per calendar period at a fixed amount. Suited to standing payment arrangements.
Variable Defined Schedule
Payments locked to specific future dates set at consent time, variable amount per payment.
Fixed Defined Schedule
Payments locked to specific future dates at fixed amounts. Suited to instalment plans and known future obligations.
Delegated SCA
Multi-payment flows where strong customer authentication is delegated to the TPP at consent time.
Refunds
Refund initiation against a previously-executed payment consent.
Personal Identifiable Information
How creditor and debtor PII is presented and validated across payment consents — encryption, payload structure, and per-LFI validation.
Multi-Authorization
Subsequent-authoriser flows for payments requiring approval from more than one customer.