Adding bill payments to your app shouldn't feel like a quarterly project. With the IIMMPACT JomPAY API, the work is closer to a sprint — and the result is the daily-use feature that pulls customers back into your app, lifts deposit balances, and gives your team JomPAY parity without having to become a bank.

This is a plain-language walk through what's actually involved. If you're an engineer, the full technical reference lives at docs.iimmpact.com. If you're a product or business lead trying to scope the work — read on.

The whole integration, in four stages

Most teams ship their first end-to-end bill payment in a sprint. The work breaks into four stages, and each one delivers something tangible to your product.

Stage 1 — Get your keys

You sign up, your team gets a staging account, and your engineers generate a pair of credentials in the dashboard. Requests are authenticated and signed per call, so there's no separate login flow to build and no session tokens to manage. The whole step takes minutes, not days.

What you gain: a working staging environment your team can start building against on day one.

Stage 2 — Pick the billers you care about

IIMMPACT gives you the full Malaysian bill payment network — JomPAY plus 20,000+ direct billers — through one catalogue. Your engineers pull the list of products (JomPAY, mobile top-ups, PTPTN, and so on) and, for JomPAY, the list of billers your customers can pay. They cache it locally so search-as-you-type feels instant.

You don't negotiate with TNB, Maxis, or LHDN individually. You don't become a PayNet Collecting Bank. The biller relationships are already done.

What you gain: nationwide biller coverage from day one, without a single biller contract on your end.

Stage 3 — Show your customer the real bill

This is the step that makes bill payments actually convert. Before the customer pays, your app calls the biller through IIMMPACT and shows them what they actually owe — outstanding balance, due date, account holder name, and any biller-specific details. Not every biller returns every field, so your UI gracefully shows whatever's available.

It's the difference between a user who types a number into a blank box and hopes for the best, and a user who sees their exact RM 45.80 water bill and taps confirm. In our network the second experience converts dramatically better, and it eliminates the wrong-amount disputes that pile up on your ops team when presentment is off. More on this in our bill presentment guide.

What you gain: a confirmation screen that drives completion rates north of 99% — and effectively eliminates a category of customer support tickets.

Stage 4 — Take the payment and close the loop

Your app submits the payment with a reference ID you generate. The status comes back as one of a handful of values: still in flight (Accepted, Processing), terminal (Succesful, Failed), or auto-refunded if delivery failed (Refund) — a safety net your team doesn't need to build.

One thing to flag to your engineers: reuse the same reference ID on retries. The payment endpoint is idempotent on that ID, so the same call returns the same transaction instead of creating a duplicate. It's the single most important production detail.

For transactions still in flight, the final status arrives via a callback to a URL your team registers. Reconciliation is a balance-statement query your finance team can hit via API, or download from the dashboard — every deposit, transaction, refund, and commission, ready to drop into your ledger.

Here's the part that compounds: this same plumbing — the same payment endpoint, the same callback URL, the same reconciliation feed — works for every IIMMPACT product. Once JomPAY is live, adding mobile recharge, mobile data, PTPTN, eSIM, payouts, or digital content is a configuration change — a different product code, a small set of product-specific fields — not a fresh integration. New billers added to the network appear in your app without an app release.

What you gain: a payment flow with auto-refunds, async callbacks, and clean financial reconciliation — and every future product on the IIMMPACT roadmap drops into your app via a backend config change, not a fresh sprint.

From staging to production

Going live is a credential swap and a base URL change. The product catalogue, response shapes, and callback contract are identical between environments, so the code your team wrote against staging is the code that runs in production. Most teams do this on a Friday and watch their first real bill payment go through over the weekend.

Why teams pick this path

For e-wallets, bill payments turn sporadic users into daily users — every utility bill is a reason to open your app, and the balance you hold to fund those payments grows your float. For digital banks, you get JomPAY parity from day one without a PayNet membership or a treasury operations team. For super apps and fintechs, it's the financial layer that completes the ecosystem without a banking licence.

The full product story — what's included, how the network compares, and the use cases per business model — is on the bill payments product page. If your team is weighing the trade-offs against building biller relationships in-house, our build vs. buy guide walks the math across the whole payments stack.