Payment Status 8 min read

The Open Finance payment status enum is defined in the Ozone Connect Bank Service Initiation OpenAPI and aligns with ISO 20022 ExternalPaymentTransactionStatus1Code. Six values are in scope:

Pending is the initial status your Ozone Connect POST/payments response returns — your LFI does not PATCH a payment to Pending. On AANI and UAEFTS your LFI PATCHes twice: AcceptedSettlementCompleted immediately on submitting the payment to the rail, within 3 seconds of returning the 201, and then the terminal status — AcceptedWithoutPosting, AcceptedCreditSettlementCompleted, or Rejected — immediately on the rail’s response. Both PATCHes are mandatory. For an intra-bank payment there is no hand-off, and your LFI PATCHes the terminal status once. The sequence and timing are set out in Payment Timing.

Once a payment reaches a terminal status (AcceptedWithoutPosting, AcceptedCreditSettlementCompleted, or Rejected), your LFI MUST NOT transition it to a different value.

When the debtor account and creditor account are both held at your LFI, there is no interbank rail involved — the payment is executed by an internal debit-and-credit within your core banking system. Your LFI has full visibility of both legs, so the payment can reach the most specific Open Finance terminal status: AcceptedCreditSettlementCompleted.

The events that trigger a PATCH are:

Every PATCH for an intra-bank payment carries paymentRail: LFI. There is no hand-off to a rail, so AcceptedSettlementCompleted does not apply. Within 3 seconds of returning the 201, your LFI MUST complete its screening, book the payment, and immediately PATCH AcceptedCreditSettlementCompleted. Intra-bank payments have no paymentTransactionId, and the field is not accepted on LFI, so omit it.

UAEFTS is the UAE Funds Transfer System, the Central Bank of the UAE's domestic interbank funds transfer rail. UAEFTS carries payment messages using the ISO 20022 pacs.008 schema and returns the following acknowledgements:

• ACK — UAEFTS has accepted the message after technical validation
• NAK — UAEFTS has rejected the message with an FTS reason code
• CB900 — Debit Confirmation: settlement through the Central Bank has completed, the debtor account has been debited, and the corresponding credit to the receiving bank has been settled

Because UAEFTS settles through the Central Bank as a centralised interbank clearing, a CB900 implicitly confirms that the creditor side of the payment has been settled as well. The terminal successful status for a UAEFTS payment is therefore AcceptedCreditSettlementCompleted.

Immediately on submitting the payment to UAEFTS — within 3 seconds of returning the 201 — your LFI MUST PATCH AcceptedSettlementCompleted, carrying the payment’s UAEFTS transaction identifier as paymentTransactionId. ACK is technical acceptance only: it does not trigger a PATCH, and the payment remains at AcceptedSettlementCompleted until CB900 or NAK arrives. Your LFI MUST then PATCH the terminal status immediately. The events that trigger a PATCH are:

The initial Pending status is set by the 201 response your Ozone Connect POST/payments endpoint returns — no PATCH is required at that point.

What your LFI MUST PATCH

Every PATCH in this table is mandatory. Your LFI MUST NOT PATCH any status other than those listed for the rail, and MUST NOT PATCH anything after a terminal status. The full sequence, including what happens between the 201 and submission, is in Payment Timing.

How to PATCH

On each PATCH-triggering event, your LFI MUST immediately:

• Map the outcome to the new Open Finance status.
• Call PATCH/payment-log/{id} on the API Hub Consent Manager with paymentResponse.paymentRail, the new paymentResponse.status, paymentResponse.paymentTransactionId (on AANI and FTS), and, for Rejected only, paymentResponse.rejectReasonCode.
• Update the response your Ozone Connect GET/payments/{paymentId} endpoint returns so that push and pull views of the payment are consistent.

Your LFI MUST NOT batch status updates or defer them waiting for TPP polling. The Hub relays the new status to the TPP via webhook events as soon as it receives the PATCH.

Example PATCH bodies

{
  "paymentResponse.paymentRail": "AANI",
  "paymentResponse.status": "AcceptedSettlementCompleted",
  "paymentResponse.paymentTransactionId": "OFP7d2c1e9a4b6f4c0e8a1b"
}

{
  "paymentResponse.paymentRail": "AANI",
  "paymentResponse.status": "AcceptedWithoutPosting",
  "paymentResponse.paymentTransactionId": "OFP7d2c1e9a4b6f4c0e8a1b"
}

{
  "paymentResponse.paymentRail": "AANI",
  "paymentResponse.status": "Rejected",
  "paymentResponse.paymentTransactionId": "OFP7d2c1e9a4b6f4c0e8a1b",
  "paymentResponse.rejectReasonCode": [
    {
      "code": "AANI.AM04",
      "message": "Payment request cannot be executed as insufficient funds at debtor account."
    }
  ]
}