Payment Timing 8 min read

The clock for the timed stages starts when your Ozone Connect returns the 201 to the API Hub. That moment is T0 in the table below.

A payment booked on your LFI’s own ledger, where the debtor and creditor accounts are both held at your LFI, has no rail and no hand-off to report. Stages 2 and 3 collapse into one: see Intra-bank payments.

Within the window, your LFI works through four steps in order:

The AcceptedSettlementCompleted PATCH is mandatory on AANI and UAEFTS. It is how the API Hub, and through it the TPP, learns that the payment has cleared your LFI’s checks and been handed to the rail. It is not terminal: a second PATCH always follows in Stage 3.

Example PATCH bodies

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

{
  "paymentResponse.paymentRail": "FTS",
  "paymentResponse.status": "AcceptedSettlementCompleted",
  "paymentResponse.paymentTransactionId": "<UAEFTS end-to-end transaction identifier>"
}

{
  "paymentResponse.paymentRail": "LFI",
  "paymentResponse.status": "AcceptedCreditSettlementCompleted"
}

Intra-bank payments

Where the debtor and creditor accounts are both held at your LFI, the payment is booked on your own ledger and never reaches a rail. The same 3-second window applies. Within 3 seconds of returning the 201, your LFI MUST complete its screening, book the payment, and immediately PATCH AcceptedCreditSettlementCompleted with paymentRail: LFI. That status is terminal, so no second PATCH follows. paymentTransactionId is not sent on LFI.

Both PATCHes are sent as soon as the triggering event occurs: submission to the rail for the first, and receipt of the rail’s response for the second. In particular, your LFI MUST NOT:

• batch status updates across payments, or hold them for a scheduled job;
• defer a PATCH until the TPP polls GET/payments/{paymentId};
• skip the AcceptedSettlementCompleted PATCH because the rail has already responded — send it first, then the terminal status;
• send any further status once a terminal status has been PATCHed.

PATCH delivery is durable. Retry a transient failure (5xx, connection error, or timeout) with exponential backoff until it is accepted. Do not retry a 4xx; raise it for operational investigation. Your Ozone Connect GET/payments/{paymentId} MUST return the status most recently PATCHed, so the push and pull views of the payment stay consistent.