Functional Certification — Single Instant Payment 4 min read
Functional Certification proves that your Ozone Connect Single Instant Payment implementation executes a payment correctly end to end: it selects the right rail, reaches the correct terminal status for that rail, propagates status to the Consent Manager Payment Log, decrypts and validates the Creditor, consumes the Risk object, and honours the account, balance, and refund reads a payment consent can carry. This page explains what the evidence is and how to produce it; the portal then builds your submission for you.
Evidence that a single instant payment executes correctly
Single Instant Payment is the first of the seven UAE Open Finance payment types, and each type is certified separately. Your Ozone Connect POST /payments returns 201 with status Pending; your LFI then executes the payment on a rail and PATCHes the terminal status to the Consent Manager Payment Log. Because your LFI is the only party that sees the raw rail outcome, Functional Certification proves that each supported rail reaches the correct terminal status, that timing and rejection are handled, and that the encryption-model steps — decrypting the Creditor and consuming the Risk object — are performed. All evidence must come from the AlTareq Model Bank sandbox.
Gather this before you start
You choose the version and segments (Retail / SME / Corporate), declare the rails you support (AANI, Intra-bank, UAEFTS), and state your payment limit. Then have the following ready:
- Testing Tool output — one HTML report the Testing Tool produces for your Ozone Connect
POST /paymentsendpoint, plus a Postman screenshot of a successfulPOST /paymentsreturning201 Pending. - Terminal status per rail — for each rail you declare, a Postman screenshot evidencing the terminal status it reaches (AANI →
AcceptedWithoutPosting; Intra-bank and UAEFTS →AcceptedCreditSettlementCompleted). - AANI timing & a rejection — the
POST /payments, rail-submission, and terminal-PATCH timestamps (with screenshots), and one example of an AANI rejection mapped toRejectedwith anAANI.<code>reason. - Creditor & Risk — screenshots evidencing decryption of the payment PII, validation of the Creditor account, and that the Risk object is used in your screening.
- Account, balance & refund reads — Postman screenshots of
GET /accountsandGET /accounts/{AccountId}/balancesbefore a payment, andGET /payment-consents/{ConsentId}/refundafter one, on the same payment consent (https://rs1.LFICODE.apihub.openfinance.ae/open-finance/payment/v2.1), each with a screenshot of the authorisation page the customer authorised that consent on. - Authorisation-screen scenarios — screenshots of your authorisation page, each with its pre-production ConsentId: the debtor account when the TPP specified it in the consent, and each Confirmation of Payee
NameMatchIndicator—ConfirmationOfPayee.Yes,ConfirmationOfPayee.Partial, andConfirmationOfPayee.No— surfaced to the customer.
Your organisation and name are taken from your Sandbox Trust Framework sign-in — you do not type them in. Sign in when the portal prompts you so your submission is attributed to your LFI.
One ZIP to attach to your ticket
When you have filled in the form and attached your evidence, the portal generates a single ZIP containing a summary document, your Testing Tool report, and every screenshot, organised per evidence group. Attach that ZIP to a Service Desk certification-evidence ticket. Nothing is sent anywhere until you attach it — the submission is built entirely in your browser.