Every e-wallet, digital bank, super app, and fintech in Malaysia eventually faces the same set of questions. Should we build JomPAY bill payments ourselves, or license a bill payment API? Should we integrate the telcos one by one for mobile top-ups, or license a recharge API? And what about payouts, eSIM, digital content? The answer rarely comes down to engineering time. It comes down to compliance, partner relationships, and what the product roadmap looks like twelve months from now.
This is a unified comparison for product and engineering teams choosing between building the payments stack in-house and licensing it through a single platform.
What "building it yourself" actually means
Building any of these products in-house is rarely one project. It's a portfolio — and the portfolio compounds the more products you add.
Bill payments. JomPAY is the dominant rail, but PayNet's biller registration process is designed for banks acting as Collecting Banks — non-banks generally cannot participate directly. Even where it's possible, the validation, notification, and reconciliation modules require ongoing operational ownership. Beyond JomPAY, the long-tail billers — telcos like Maxis and CelcomDigi, government agencies like LHDN, utilities outside the JomPAY footprint, TV and streaming providers — are each their own contract, sandbox, and certification. Then there's bill presentment: a separate inquiry call to each biller, schema normalization, and real-time error handling.
Mobile recharge. Domestically that's Maxis, CelcomDigi, U Mobile, plus a handful of MVNOs. Cross-border is where the math breaks: APAC has more than 500 active mobile operators across Singapore, Thailand, Indonesia, the Philippines, Vietnam, and a dozen more markets, each carrier with its own request shapes, denomination structures, and delivery confirmation flows.
Payouts, eSIM, digital content, PTPTN. Each is its own set of partner integrations, sandboxes, and certification cycles — bank rails for payouts, MNO and eSIM provisioning agreements, content licensing for digital, and the PTPTN gateway for student loans.
A realistic in-house program for the bill payments slice alone is twelve to eighteen months to first launch, plus a permanent team to keep biller integrations alive. Add mobile recharge and the timeline doubles. Add payouts and the operational footprint doubles again.
The hidden operational layer
The headline cost of each product isn't the per-transaction wholesale margin. It's the operating infrastructure underneath that doesn't show up in the integration plan:
- Prepaid float, per partner. Most telcos and many billers require a prepaid balance before they'll deliver. Multiply by every partner you support and that capital sits idle, earning nothing.
- Multi-currency reconciliation. If your users pay in MYR but you fund partners in IDR, PHP, THB, VND, you're running an FX desk you didn't plan to — daily mark-to-market, hedging, and accounting all become real work.
- Failed delivery refunds. Top-ups fail; bills get rejected; payouts get returned. You need an automated refund path that closes the loop with the user inside seconds, not days.
- Compliance and dispute handling. AML screening for cross-border flows, JomPAY misroute investigations, telco-says-it-delivered disputes — operations cost scales with volume.
- Bill presentment infrastructure. Per-biller inquiry endpoints with different schemas, error envelopes, and uptime characteristics. The biller registry doesn't guarantee a stable contract.
What "buying it" means
A managed platform replaces the integration portfolio with a single endpoint set. IIMMPACT, for example, provides JomPAY plus 20,000+ direct billers, 500+ APAC telcos, payouts, eSIM, and digital content through one API key — with bill presentment, payment submission, real-time delivery status, automated refunds, and daily reconciliation built in. Settlement and FX are absorbed: you fund a single MYR balance and the platform handles the per-partner currency mechanics behind the scenes.
The trade-off is straightforward: you give up the option of bespoke per-partner behavior in exchange for a faster launch, predictable economics, and someone else owning the certification treadmill.
The compounding benefit. Once you've integrated one product through the platform, adding the next is a configuration change — a different product code, a small set of product-specific fields — not a new vendor contract or another sprint of plumbing. The same authentication, the same callback URL, and the same reconciliation feed work for every product. This is the part most build-vs-buy spreadsheets miss.
Decision factors that actually matter
Compliance posture. If you're a non-bank, the direct-JomPAY path is gated by PayNet's Collecting Bank rules; cross-border top-ups have AML implications that look like remittance; payouts inherit the AML program of the rail you choose. A managed platform handles screening; building in-house means owning each compliance program separately.
Time to revenue. Bill payments and top-ups are daily-use features — every utility bill or prepaid recharge is a reason to open your app. Every month of build delay is a month of users routing through someone else's app instead of yours.
Total cost of ownership. Direct integrations look cheap per-partner until you count the prepaid float, the FX desk, the refund engine, the bill presentment infrastructure, the AML program, and the operations headcount. A managed platform consolidates all of that into one vendor contract.
Optionality. This is where the platform model breaks away from per-product builds. If your roadmap includes any combination of bill payments, mobile recharge, payouts, eSIM, or digital content, picking a platform that already provides them avoids stacking five vendors over the next three years.
When building in-house is the right call
Building still makes sense in a few cases. First, if you're a Malaysian bank that already has a PayNet membership and a treasury operations team — your incremental cost to add JomPAY is low. Second, if you're a mobile operator offering top-ups to your own subscribers — the integration is internal and the float requirement disappears. Third, if your roadmap requires behavior that no managed platform will support: novel biller categories, deep custom pricing, or proprietary reconciliation flows tied to a specific partner deal.
Outside those cases, the math points to licensing — and the further across the product suite you plan to go, the harder the math tilts.
A practical next step
For most e-wallet, digital bank, super app, and fintech teams in Malaysia and APAC, the real question isn't "build or buy" for any single product. It's "how do we ship the payments stack we need, and how do we keep it alive as it grows?" A managed platform handles both.
For a product-level view of what the platform covers, see the bill payments product page and the mobile recharge product page. If you're ready to walk through your specific scenario, talk to the IIMMPACT team.