Case study · Jabatan Akauntan Negara Malaysia

iPayment. The national payment platform of the Accountant General’s Department.

Maintenance, support, and infrastructure

— RM 8.2 million, 2025 to now

01 · Client and system

Client
Jabatan Akauntan Negara Malaysia
System
iPayment
Period
2025 – ongoing
Current status
In production. Under our maintenance now.

02 · The problem

A payment platform cannot be taken offline to be fixed.

iPayment moves federal payment instructions, so every hour it is degraded is an hour the Accountant General’s Department cannot settle. Its three external interfaces sit with parties the Department does not control, which means a fault can originate outside the platform and still present as its failure. Support therefore had to cover the platform, the servers beneath it, and the behaviour of every interface at once — under one accountable party rather than three.

03 · What we built

Five things we are accountable for.

  1. 01 Maintenance and support of the production platform, with defect resolution against an agreed response window.
  2. 02 Red Hat Enterprise Linux administration, with high-availability load balancing across the application tier.
  3. 03 Proactive monitoring and a defined escalation path, so a fault is raised by us and not by the Department.
  4. 04 Interface operation and daily reconciliation across PayNet, iGFMAS, and Merchant Bank RMA.
  5. 05 Technical and operational documentation kept current as the platform changes.

04 · Scale

The numbers this engagement is measured on.

RM 8.2m
Contract value

Approximate, rounded

3
External interfaces

PayNet · iGFMAS · Merchant Bank RMA

2025 –
In production since

Ongoing engagement

RHEL
Platform

High-availability load balancing

Transactions per day — to supply
Throughput
Uptime commitment — to supply
Availability

Two figures are held back until the Department confirms what may be published. An evaluator reads a blank field as honest; a made-up one costs the whole submission.

Architecture explorer

Six layers, in the order a payment instruction passes through them.

Scroll to move through the stack. Every layer and its detail is on the page whether the highlight runs or not.

Stack

  1. 01 Client
  2. 02 Gateway
  3. 03 Application
  4. 04 Queue
  5. 05 Database
  6. 06 Monitoring
  1. 01

    Client

    The officer raising or authorising a payment instruction, inside the Department.

    Session is bound to the officer, and an authorisation is only ever recorded against a named user — never against a role.

    • Web client
    • Single sign-on
  2. 02

    Gateway

    The entry point that authenticates the request and rate-limits it before anything downstream sees it.

    A malformed or unauthorised request is rejected here, so it never reaches the application tier or an external interface.

    • High-availability load balancing
    • RHEL
  3. 03

    Application

    Validation, authorisation rules, and the construction of the payment instruction itself.

    Every instruction is assigned an idempotency key at this layer, which is what makes a retry safe further down.

    • Application tier
    • RHEL
  4. 04

    Queue

    The buffer between the platform and the three systems it does not own.

    On a counterparty timeout the instruction is queued and replayed in order. It is never resubmitted blind, and never dropped silently.

    • Queued replay
    • Idempotency keys
  5. 05

    Database

    The record of truth for every instruction, its authorisation trail, and its settlement status.

    Status is only ever advanced from a counterparty acknowledgement, so a lost message leaves a reconcilable gap rather than a wrong balance.

    • Relational store
    • Daily reconciliation
  6. 06

    Monitoring

    Proactive monitoring across all five layers above, with a defined escalation path.

    The intent is that we raise the fault, not the Department. Alerts carry the layer and the interface so the first responder is not searching.

    • Proactive monitoring
    • Defined escalation

Interfaces

Three systems we do not own, each with a named failure path.

PayNet RESTful API Bidirectional

Payload — Payment instruction out, settlement acknowledgement back.

On failure — Retries carry an idempotency key. Unacknowledged instructions are held and reconciled against the daily settlement file, never resubmitted blind.

iGFMAS RESTful API Bidirectional

Payload — Payment voucher out, payment status back.

On failure — Requests are queued on timeout and replayed in order. Status mismatches are raised in the daily reconciliation report for a named officer to clear.

Merchant Bank RMA RESTful API Outbound

Payload — Signed remittance message set.

On failure — Rejected messages are parked for manual release. A financial instruction is never resubmitted automatically.

05 · Result

Three measured outcomes.

Outcome 1 — to supply

Availability achieved against the commitment, over a stated period.

Outcome 2 — to supply

Median and worst-case defect resolution time against the agreed response window.

Outcome 3 — to supply

Reconciliation exceptions cleared, as a proportion of instructions passed to the three interfaces.

This block is deliberately empty. It is the block an evaluation committee reads hardest, and it must carry numbers you can stand behind in a clarification meeting.

06 · Stack and standards

  • Red Hat Enterprise Linux
  • High-availability load balancing
  • Laravel
  • ReactJS
  • MySQL
  • RESTful API
  • Idempotency keys
  • Queued replay
  • Daily reconciliation
  • Proactive monitoring

Standards and compliance schedules applicable to this engagement are to be listed here — confirm which may be named publicly before this page is published.