From open-the-form to tap-and-go in five quiet stages.

The recharge form on abudhabibuscard.com

The form is one screen, with four required fields. The mobile number takes the nine digits that follow the +971 prefix — no spaces are required, the form pads them automatically. The Hafilat card type is picked from a short drop-down with three options: Standard, Personalised and Premium.

The 13-digit Hafilat ID is the most important field — it is the public identifier of the card on the ITC backend. The number is printed on the back of every Hafilat card in a single block, grouped 4-4-5. The form formats the number as it is typed and rejects entries shorter than 13 digits. There is no check digit on the card itself; the ITC backend is the source of truth and an order to a non-existing ID returns a quiet failure on the next sync.

The amount is picked from four preset values (AED 50, 100, 150, 200) or typed manually between AED 5 and AED 1,000. The submit button stays disabled until every field passes the local checks.

The redirect to the card desk

When the form passes the checks, the page generates an order ID in the shape HBC-1234-5678, builds a short query string and sends the rider to checkout.abudhabibuscard.com — a different subdomain, on a different store. The rest of the site is left behind so that the card data never shares a window with a marketing pixel.

The card desk is a slim white screen. It re-prints the order summary at the top — order ID, Hafilat ID, the chosen amount — and asks for the cardholder name, the 16-digit card number, the expiry month and year and the three-digit security code. The order ID stays valid for fifteen minutes; opening the card desk in another tab does not invalidate the order.

The 3-D Secure prompt

After the card desk validates the number, the expiry and the security code, the request is forwarded to the issuing bank. The bank then opens a small 3-D Secure window with its own prompt — usually a one-time code by SMS or a confirmation tap inside the bank's mobile app.

The bank decides whether to authorise the payment. If the answer is yes, the card desk receives a confirmation token and writes the order as paid. If the answer is no, the card desk shows a clean error page that links back to the recharge form with the original parameters preserved.

The ITC sync

The Integrated Transport Centre backend pulls new credit orders on a fixed schedule — minutes, not hours. Until the next sync window, the new credit lives as a queued line in the desk's order register; it does not appear on the bus reader.

When the sync runs, the ITC backend writes the new amount to the central balance for the Hafilat ID. From that moment, the new total is the source of truth — all readers, kiosks and the Hafilat mobile app pick it up at their next refresh. The desk's role ends here.

The first tap on a real reader

Hafilat readers are offline-tolerant — the chip on the card carries a copy of the balance for fast reads. On the first tap after the ITC sync, the reader updates the chip with the new total. The next tap shows it directly; no further action is needed from the rider.

A confirmation SMS is sent to the mobile number from Stage 01 with the order ID, the amount and a short reminder that the credit posts on the next sync.