Payment Gateway Malaysia: A Method-by-Method Selection Guide

Choose a payment gateway in Malaysia by checking who can use it, how customers pay, and how money and exceptions are handled.

As of 25 August 2026, cards, wallets, DuitNow and Financial Process Exchange (FPX) are different payment journeys, not interchangeable logos. For each method, verify the merchant entity—the company applying—customer steps, refunds, reconciliation (matching orders to payment records), and settlement (when payable funds reach the merchant). Market availability does not prove provider support or account eligibility. Confirm the result in writing before launch.

Source: Bank Negara Malaysia (BNM), “e-Duit” (Malaysia payment categories); PayNet, “DuitNow QR” and “FPX” (market workflows); HaiPay, “Malaysia” application programming interface (API) documentation (route status), accessed 25 August 2026. Applicability: Malaysia online checkout evaluation. Limitation: provider coverage, merchant eligibility and contract terms vary; the reviewed provider evidence has unresolved Cards and DuitNow gaps.

What a payment gateway in Malaysia must support

A payment gateway connects a customer-facing checkout to the payment route that handles the transaction. The practical decision is broader than whether a checkout displays a familiar logo. A merchant must be able to initiate a payment, receive a reliable status, handle exceptions and match the result to settlement records.

Evaluate three evidence layers separately:

This guide fills the market layer with current official sources. It uses the current publisher route document where available. It leaves account-specific and unsupported fields as Not verified. It does not turn an evidence gap into a zero or a negative product claim.

Source: Bank Negara Malaysia, “e-Duit” and “Financial Sector Participants Directory” (market instruments and regulated roles); PayNet, “Malaysia’s Digital Payment Backbone” (network context); HaiPay, “Malaysia” API documentation (route status), accessed 25 August 2026. Limitation: the public pricing matrix was not used as the controlling coverage source because it conflicts with current route documentation.

For the broader cross-border decision, use the international payment gateway guide. If acquiring structure is the main issue, compare local acquiring and cross-border acquiring separately.

Malaysia’s payment-method landscape

Malaysia’s online payment environment includes cards, e-money wallets and bank-funded payment products. These categories can overlap at the customer interface. A wallet may scan a DuitNow quick response (QR) code, while the wallet brand, QR product, issuer, operator and merchant acquirer remain different parts of the route. A payment service provider (PSP) may package several of those roles, but its commercial route still needs evidence.

The map prevents three common category errors:

1. A wallet brand is not automatically the underlying payment rail.
2. A network participant is not automatically the merchant’s gateway provider.
3. A provider’s route is not automatically approved for a particular merchant account.

Source: Bank Negara Malaysia, “Types of Payment Systems” and “e-Duit” (market categories); PayNet, “DuitNow QR”, “DuitNow Online Banking/Wallet” and “FPX” (product identities and customer flows), accessed 25 August 2026. Limitation: this is market structure, not proof of provider availability.

Cards for Malaysia-facing merchants

Cards can serve local and international customers, but “cards” is not one lifecycle. Scheme, issuer, acquirer, customer location, currency, authentication, merchant category and contract determine how a transaction behaves.

Before choosing a card route, ask the provider to document:

• accepted card schemes and card-not-present scope.
• local or cross-border acquiring route.
• customer authentication and failed-authentication handling.
• full and partial refund support.
• card dispute ownership, evidence windows and fees.
• reconciliation identifiers and provider payout terms.
• the merchant entities, sectors and currencies approved for the route.

Current publisher route documentation does not show a Cards collection row. A separate public pricing matrix displays Malaysia card labels, but that page is not controlling coverage evidence for this draft. Cards availability for Malaysia therefore remains Not verified and requires product-owner confirmation before publication or launch.

Source: Bank Negara Malaysia, “e-Duit” and “Financial Sector Participants Directory” (card-market structure); HaiPay, “Malaysia” API documentation and “Pricing” (document comparison), accessed 25 August 2026. Applicability: market existence and document comparison only. Limitation: no current controlling evidence confirms a Malaysia Cards route for the publisher.

Merchants evaluating cards can review the general credit card product page, but that page does not replace Malaysia-specific account confirmation.

Local wallets: Touch ’n Go eWallet, Boost, GrabPay, MCash and ShopeePay

Each named wallet has official evidence of market presence in Malaysia. That evidence describes the wallet or a direct merchant product; it does not establish the route offered by a separate gateway.

The current Malaysia API page marks five Malaysian ringgit (MYR) wallet route codes as Available. This is documentation status, not a promise that every merchant can activate them.

In the documentation, appId is the application identifier tied to the configured currency. It must match the route being used.

The same document lists a general MYR collection range of MYR1–MYR3,000 for the Malaysia collection routes. Confirm whether that range applies unchanged to the selected method, merchant account and contract. Do not treat the document-wide range as an account approval.

Source: TNG Digital, “Payments”; Boost, “Terms & Condition (Business) — General”; Grab, “GrabPay”; MCash, “The Malaysia Wallet”; ShopeePay, “ShopeePay features” (wallet market presence); HaiPay, “Malaysia” API documentation (route status), accessed 25 August 2026. Limitation: market presence and documented route status do not prove merchant-account enablement or lifecycle support.

Use the local payment product page to understand the general product category. Use written account confirmation for the Malaysia methods you intend to launch.

DuitNow: confirm the exact product and workflow

“DuitNow” names a family of products. DuitNow QR and DuitNow Online Banking/Wallets are not interchangeable.

This guide uses OBW only as shorthand for DuitNow Online Banking/Wallets in the market-map visual.

DuitNow QR

For domestic merchant-presented QR, the merchant displays a static or dynamic QR. The customer scans it in a participating bank or wallet app, checks the merchant and amount, then approves using the issuer’s security method. The merchant should rely on its acquirer or provider status, not a customer screenshot alone.

PayNet also documents a DuitNow Reversal process for returning a completed payment to the original payment source. Refund policy, timing, fees and the merchant interface depend on the acquirer. PayNet publishes a domestic dispute process, but that process should not be applied to other DuitNow products or cross-border QR without evidence.

Current publisher documentation labels the QR / DuitNow QR route Maintenance. This guide therefore does not describe that route as currently available. The exact QR mode, account eligibility and reactivation status require product-owner confirmation.

DuitNow Online Banking/Wallets

DuitNow Online Banking/Wallets is an ecommerce checkout product. PayNet’s integration documentation describes an issuer list, customer redirect, issuer authentication and authorisation, and a status flow back through the merchant’s provider. Corporate approval can introduce a pending state.

No current Malaysia route evidence reviewed for this draft identifies this product. It is included only to prevent the common mistake of applying its redirect workflow to DuitNow QR.

Source: PayNet, “DuitNow QR — Personal Solutions”, “Merchant Presented Mode: Domestic QR”, “DuitNow Reversal — Overview”, “DuitNow Domestic Dispute Management”, “DuitNow Online Banking/Wallets — Overview” and “Initiate Payment Intent (One-Time Payment)” (separate product lifecycles, corporate approval and pending status); HaiPay, “Malaysia” API documentation (route status), accessed 25 August 2026. Limitation: PayNet infrastructure evidence does not prove gateway support.

FPX: bank selection, redirect and evidence

FPX is an internet-banking payment platform for ecommerce. At checkout, the customer selects FPX and chooses from the bank list returned for that session. The customer is redirected to the chosen bank, signs in and authorises the payment using the bank’s process. The merchant then receives a transaction result and should retain its own payment record.

PayNet instructs merchants to request the buyer-bank list when it is displayed. A bank may be shown as unavailable in that response. This makes the live list more useful than a static marketing count.

• Count status: The project work order contains a bank-count claim that conflicts with the current grouped PayNet participant list. This guide therefore uses participating Malaysian banks and financial institutions without publishing a number. Product-owner confirmation is required before any provider-specific count appears.
• Route status: The current Malaysia API page marks FPX_MYR as Available and also lists a separate United States dollar (USD) FPX route. Confirm the enabled appId, currency, customer flow, refund tooling, reconciliation fields, provider payout terms and merchant eligibility for the planned account.

Source: Bank Negara Malaysia, “Types of Payment Systems” (FPX structure); PayNet, “What is FPX?”, “How FPX Works”, “Browser Redirection”, “Which banks participate in FPX?”, “Frequently Asked Questions (FAQs) — FPX” and “FPX Merchant Webview User Guideline (V3.0)” (workflow, current grouping, merchant refund capability and merchant report fields); HaiPay, “Malaysia” API documentation (route status), accessed 25 August 2026. Limitation: live bank availability and merchant terms can change.

DuitNow versus FPX

Use this comparison to choose the workflow to investigate. It is not evidence that either method is enabled for a specific gateway account.

Neither “DuitNow” nor “FPX” is a sufficient requirement on its own. The specification must name the product, customer flow, integration route, account entity and operational outcome.

Source: PayNet, “DuitNow QR: Business Solutions”, “DuitNow Online Banking/Wallets: Overview”, “DuitNow Reversal: Overview”, “Frequently Asked Questions (FAQs) — FPX” and “FPX Merchant Webview User Guideline (V3.0)” (product, refund and reconciliation comparison); HaiPay, “Malaysia” API documentation (route status), accessed 25 August 2026. Limitation: account eligibility, provider payout and contract terms remain merchant-specific.

Malaysia Payment-Method Lifecycle Matrix

The matrix is split into two selectable-text tables so each field remains readable. “Available” means only that the current Malaysia route document uses that status. It does not mean account approval.

Matrix A: market, availability and customer flow

Matrix B: post-payment operations, money movement and limitations

Source: Bank Negara Malaysia, “e-Duit” and “Types of Payment Systems” (market categories and structural definitions); PayNet, “FPX: Business Solutions”, “FPX Browser Redirection”, “Frequently Asked Questions (FAQs) — FPX”, “FPX Merchant Webview User Guideline (V3.0)”, “DuitNow QR: Business Solutions”, “Merchant Presented Mode: Domestic QR”, “DuitNow Reversal: Overview” and “DuitNow Domestic Dispute Management” (rail workflow, merchant reports and exception scope); HaiPay, “Malaysia” API documentation (route status), accessed 25 August 2026. Limitation: the controlling coverage matrix and factbase source files were unavailable; the matrix is not a launch approval.

Fees, tax, foreign exchange and settlement questions

Do not compare gateways on a headline transaction rate alone. A useful quote has to define the payment method, currency, merchant entity, volume, transaction profile and contract term. It should also explain foreign exchange (FX) when collection and provider payout currencies differ.

This draft does not publish Malaysia-specific fees, tax, FX reference or provider payout timing. The controlling pricing matrix and factbase files were unavailable, and public pages do not resolve the account-specific terms. Use the public pricing page for discovery, then request a Malaysia quote and contract schedule.

Source: HaiPay, “Pricing” (public discovery page); “HaiPay Content Work Order — Final” (project source hierarchy), reviewed 25 August 2026. Applicability: quote planning only. Limitation: no Malaysia-specific pricing, tax, FX or provider payout term is approved in this draft.

Merchant entity, underwriting and contract checks

Cross-border merchants should not assume that Malaysian customer access creates local merchant eligibility. Ask the provider to answer each question for the exact contracting entity.

1. Which legal entity signs the contract?
2. Is a Malaysian entity, local registration or local bank account required for each method?
3. Which merchant categories are restricted or need enhanced review?
4. Which currencies can the customer pay and the merchant receive?
5. Which methods will be enabled on the specific appId or account?
6. What transaction and rolling limits apply after approval?
7. Can reserves, holds or additional reviews apply, and under what contract terms?
8. Who owns customer-support escalation for a failed payment, refund or dispute?
9. What evidence is required before increasing volume?
10. Which facts will be written into the quote, order form or product schedule?

PayNet’s direct merchant-onboarding information provides useful market baselines for some products. It does not answer the publisher’s underwriting for a foreign or cross-border merchant. Those details remain account-specific.

Source: PayNet, “DuitNow QR — Business Solutions”, “How do merchants onboard to DuitNow QR?” and “FPX — Business Solutions” (direct onboarding baselines), accessed 25 August 2026. Limitation: direct PayNet/acquirer guidance is not gateway eligibility evidence.

Integration, refunds, disputes and reconciliation

The current Malaysia document uses currency-specific collection routes and requires route identifiers that match the selected currency. Treat that as the start of implementation discovery, not the complete launch specification.

Build a method-level acceptance test before production:

For small, frequent transactions, reconciliation is not an afterthought. A method that converts well but produces manual statement work or unclear refund matching can increase operating cost. Test exports with finance and support, not only with engineering.

Source: HaiPay, “Malaysia” API documentation (route prerequisites); PayNet APIs, “FPX Browser Redirection” (bank enquiry, redirect and unavailable-bank handling), “DuitNow Online Banking/Wallets: Overview” (participant responsibilities and redirect workflow) and “Merchant Presented Mode: Domestic QR” (QR workflow and exception states), accessed 25 August 2026. Limitation: this is a recommended test plan; it does not claim that every listed field exists in a particular provider report.

Review the general Checkout and API Integration pages when choosing an integration style. Confirm the exact Malaysia route and test environment with the implementation owner.

Low-value, high-frequency merchant checks

For digital goods, games, content, subscriptions and smaller ecommerce baskets, unit economics and operating effort must be tested together. A payment method can suit customer demand yet create avoidable work if status handling, refunds or statement matching remain unclear.

Merchant research signals

Two individual Malaysia community comments captured the type of friction a payment lead should investigate:

“Many of these payment gateway fees, integration and APIs are a huge PITA.”

“We have had statements that went to 50+ pages, which is cumbersome to handle.”

Source: Reddit, “RHB just dropped Malaysia’s first bank-owned unified payment gateway (RHB Pay). Are third-party payment gateways finished?” (individual developer comment about gateway integration; published 6 August 2026); Reddit, “E-wallet + credit card + QR Pay feels broken lately” (individual merchant-side comment about statement workload; published 1 January 2026), accessed 25 August 2026. Applicability: question framing only. Limitation: two anecdotes do not establish prevalence, product performance or a market benchmark.

Acceptance test

Convert those concerns into a pre-launch test:

This table is a testing framework, not evidence of one provider’s cost or performance. Use your own order distribution, refund rate, staffing model and account quote.

Source: HongMing Dong, “Low-Value, High-Frequency Merchant Checks” (editorial synthesis of sourced Malaysia pain signals and the technical evidence in this guide), created 25 August 2026. Limitation: merchant-specific modelling is required.

A limited provider-comparison method

Malaysia’s broad gateway results mix local provider pages, regional provider comparisons and official network or regulatory pages. That search engine results page (SERP) pattern supports a bounded comparison module, but not an unsupported ranking.

Inclusion scope: brands repeatedly visible across the seven live Google Malaysia query snapshots, including Fiuu, Paydibs, Billplz, senangPay, HitPay, Xendit and Airwallex, plus HaiPay as the publisher of this guide. Cost scope: no third-party fee is reproduced. Ordering method: none; this guide compares evidence requirements, not performance. Data date: 25 August 2026. Source method: first-page observation followed by official-source verification for any fact used. Conflict disclosure: HaiPay publishes this guide and has a commercial interest in the reader’s decision.

Trust disclosure: No provider was performance-tested, scored or ranked for this guide, and search visibility is not an endorsement. Source and product evidence was checked on 25 August 2026. This operational guide is not legal, tax, investment or financial advice.

Evidence request for every candidate

Compare every candidate with the same evidence request:

The snapshot used these exact queries:

• payment gateway malaysia
• payment gateway in malaysia
• best payment gateway malaysia
• online payment gateway malaysia
• payment gateway for small business malaysia
• FPX payment gateway malaysia
• DuitNow payment gateway malaysia

Source: Google, “Malaysia / English search results” (seven-query desktop SERP snapshot), captured 25 August 2026 with Malaysia country setting gl=my, English language setting hl=en, requested result count num=10 and personalisation disabled through pws=0. Limitation: the browser was signed in and the exact IP-derived location was not independently verified; search presence is not product-quality evidence.

Malaysia payment gateway selection process

Use the flow in order:

1. Establish entity eligibility. Confirm contracting entity, sector, know-your-business (KYB) review and bank-account requirements.
2. Define the customer context. Record buyer location, device, currency, average order value and purchase frequency.
3. Choose method families. Separate cards, named wallets and account-based methods.
4. Prove customer demand. Use your own checkout analytics, support requests and controlled tests. Do not infer demand from a logo list.
5. Specify the rail workflow. Name DuitNow QR, DuitNow Online Banking/Wallets or FPX precisely.
6. Validate operations. Test status, refunds, disputes, reconciliation and customer escalation.
7. Document money movement. Obtain the provider payout currency, FX basis, cut-off and account terms.
8. Test the integration. Verify route, appId, callbacks, enquiry and failure recovery.
9. Obtain written confirmation. Attach the approved methods, limits, price, tax, FX and operational schedule to the launch decision.

If any evidence gate remains open, keep that method out of production scope until it is resolved.

Where HaiPay may fit

The provider may be worth evaluating when a cross-border merchant wants one discussion covering Malaysia local routes, checkout and API integration. The current Malaysia API document provides route codes for the five named MYR wallets and FPX, plus currency-specific collection setup.

The next step is not to assume those routes are enabled. Send the payments team the merchant entity, sector, customer countries, required methods, currencies, transaction profile, refund needs, reconciliation requirements and proposed integration. Ask for a written account-specific response.

• Verify Malaysia payment-method and merchant-entity applicability. Request the market quote only after the required methods and lifecycle are confirmed.

Source: HaiPay, “Malaysia” API documentation, “Local Payment”, “Checkout” and “API Integration” (route and product discovery), accessed 25 August 2026. Limitation: general product pages do not approve a method for an account.

Where HaiPay may not fit yet

Keep the provider out of the final shortlist, or keep the affected method out of scope, if your launch depends on evidence that is still missing. Current examples include:

• Malaysia Cards acceptance without written route and account confirmation.
• DuitNow QR at launch while the current route document shows Maintenance.
• a fixed FPX participant count in marketing or contractual scope.
• a Malaysia-specific tax, FX or provider payout term that has not been supplied in the quote.
• a method-level refund, dispute or reconciliation workflow that cannot be demonstrated.
• a merchant entity, sector or currency combination that has not passed underwriting.

This is not a conclusion that the capability will remain unavailable. It is a rule against approving launch before the evidence exists.

Source: HaiPay, “Malaysia” API documentation (current route status); HongMing Dong, “Payment Gateway Malaysia Evidence Log” (evidence-gap review), verified 25 August 2026. Limitation: product status and account eligibility may change after product-owner and underwriting review.

Sources

All sources below were accessed on 25 August 2026 unless another date is stated.

1. Bank Negara Malaysia — “e-Duit” — supports Malaysia payment categories and customer payment modes; accessed 25 August 2026.
2. Bank Negara Malaysia — “Financial Sector Participants Directory” — supports regulated-role and entity listings, not interoperability; accessed 25 August 2026.
3. Bank Negara Malaysia — “Types of Payment Systems” — supports stable structural definitions for cards, e-money and FPX; accessed 25 August 2026.
4. Bank Negara Malaysia — “Financial Services Act 2013 and Islamic Financial Services Act 2013” — supports the distinction among operators, acquirers and issuers; accessed 25 August 2026.
5. Bank Negara Malaysia — “Promoting Safe and Efficient Payment and Remittance Services,” Annual Report 2025 — supports current infrastructure context and distinguishes FPX, DuitNow QR and DuitNow Online Banking/Wallets; accessed 25 August 2026.
6. PayNet — “FPX: Business Solutions” — supports FPX merchant context and onboarding baseline; accessed 25 August 2026.
7. PayNet Support — “What is FPX?” — supports the FPX definition; accessed 25 August 2026.
8. PayNet Support — “How FPX Works” — supports bank selection, redirect, authentication and confirmation; accessed 25 August 2026.
9. PayNet APIs — “FPX Browser Redirection” — supports dynamic buyer-bank enquiry and unavailable-bank handling; accessed 25 August 2026.
10. PayNet Support — “Which banks participate in FPX?” — supports the current grouped participant list and its update caveat; accessed 25 August 2026.
11. PayNet — “DuitNow QR: Personal Solutions” — supports the basic customer QR journey; accessed 25 August 2026.
12. PayNet APIs — “Merchant Presented Mode: Domestic QR” — supports the domestic merchant-presented QR lifecycle and exception states; accessed 25 August 2026.
13. PayNet APIs — “DuitNow Reversal: Overview” — supports the reversal/refund mechanism and its limits; accessed 25 August 2026.
14. PayNet Support — “DuitNow Domestic Dispute Management” — supports the domestic QR dispute scope; accessed 25 August 2026.
15. PayNet — “DuitNow QR: Business Solutions” — supports merchant notifications, statements and direct-acquirer context; accessed 25 August 2026.
16. PayNet Support — “How do merchants onboard to DuitNow QR?” — supports direct onboarding baselines, not gateway eligibility; accessed 25 August 2026.
17. PayNet — “DuitNow Online Banking/Wallet: Business Solutions” — supports the identity of OBW as a separate ecommerce product; accessed 25 August 2026.
18. PayNet APIs — “DuitNow Online Banking/Wallets: Overview” — supports issuer selection, redirect and participant responsibilities; accessed 25 August 2026.
19. Touch ’n Go eWallet — “Payments” — supports wallet market presence and customer payment contexts; accessed 25 August 2026.
20. Touch ’n Go — “Merchant’s Guidebook” — supports direct merchant-operation context, not gateway availability; accessed 25 August 2026.
21. Boost — “Terms & Condition (Business): General” — supports the Boost wallet operator and direct merchant context; accessed 25 August 2026.
22. Boost — “DuitNow QR” — supports a distinct Boost-provided QR acceptance context; accessed 25 August 2026.
23. Grab — “GrabPay” — supports GrabPay market presence and consumer payment contexts; accessed 25 August 2026.
24. Grab — “Terms of Service: Payment and Rewards” — supports issuer identity and product scope; last modified 25 May 2026, accessed 25 August 2026.
25. MCash — “The Malaysia Wallet” — supports MCash market presence; accessed 25 August 2026.
26. MCash — “E-Wallet Features” — supports scan-and-pay and in-app payment categories; accessed 25 August 2026.
27. ShopeePay — “ShopeePay features” — supports wallet market presence and online/in-store use; accessed 25 August 2026.
28. Shopee Help — “What is a ShopeePay Merchant?” — supports direct merchant acceptance context, not gateway availability; accessed 25 August 2026.
29. HaiPay — “Malaysia” API Documentation — supports route codes, document status, route-level limits and integration prerequisites; last modified 17 July 2026, accessed 25 August 2026.
30. HaiPay — “Pricing” — used only as public discovery and conflict evidence; accessed 25 August 2026.
31. HaiPay — “Local Payment” — supports general product discovery, not Malaysia account availability; accessed 25 August 2026.
32. HaiPay — “Credit Card” — supports general card-product discovery, not Malaysia route status; accessed 25 August 2026.
33. HaiPay — “Checkout” — supports general checkout discovery, not method enablement; accessed 25 August 2026.
34. HaiPay — “API Integration” — supports general integration discovery, not method-level lifecycle proof; accessed 25 August 2026.
35. HaiPay — “Contact” — commercial endpoint for eligibility and quote confirmation; accessed 25 August 2026.
36. Reddit r/malaysia — “RHB just dropped Malaysia’s first bank-owned unified payment gateway (RHB Pay). Are third-party payment gateways finished?” — supports an individual developer’s integration-friction signal, not prevalence or product capability; published 6 August 2026, accessed 25 August 2026.
37. Reddit r/MalaysianPF — “E-wallet + credit card + QR Pay feels broken lately” — supports an individual merchant-side statement-workload signal, not a market benchmark; published 1 January 2026, accessed 25 August 2026.
38. PayNet APIs — “Initiate Payment Intent (One-Time Payment)” — supports the OBW corporate-approval flow and pending-authorisation state; accessed 25 August 2026.
39. PayNet Support — “Frequently Asked Questions (FAQs) — FPX” — supports merchant FPX refund capability subject to merchant policy; accessed 25 August 2026.
40. PayNet — “FPX Merchant Webview User Guideline (V3.0)” — supports merchant transaction and settlement report fields; effective 17 November 2025, accessed 25 August 2026.