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

An evidence-led guide to cards, local wallets, DuitNow and FPX for merchants evaluating Malaysia checkout, operations, settlement and account eligibility.

Updated Sep 9, 2026Intermediate31-min readby HongMing DongPayment Orchestration

Direct Answer

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.

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; confirm the current route status for each method with the provider in writing.

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:

Evidence layer

The question it answers

Evidence required

What it cannot prove by itself

Malaysia market evidence

Does the instrument, wallet or payment product exist in Malaysia?

Bank Negara Malaysia, PayNet or the method operator

That a gateway supports it, or that a merchant can enable it

Provider availability evidence

Does the provider have a current route for the method and currency?

Current product documentation, published market coverage and written provider confirmation

That the merchant passed underwriting or has the route enabled

Merchant operations evidence

Can this account run the complete payment lifecycle?

Contract, account configuration, test results, refund and dispute process, reports and settlement terms

That the same terms apply to another entity, sector or transaction profile

This guide fills the market layer with current official sources, and the provider layer with HaiPay’s published market coverage and current API documentation. Account-specific fields are left open rather than assumed: an evidence gap is not turned 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: market structure and published coverage are not proof of account approval.

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.

Malaysia payment ecosystem map separating cards, e-wallets, DuitNow QR, DuitNow Online Banking and Wallets, and FPX across regulated roles, provider integration and merchant approval

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.

Method family

Malaysia market evidence

Customer-side pattern

First merchant check

Cards

BNM describes payment cards as a distinct retail payment instrument and lists regulated network participants

Customer enters or presents card credentials; issuer and route determine authentication

Confirm schemes, card-not-present route, acquiring model, disputes, refunds and payout terms

E-money wallets

Official TNG, Boost, GrabPay, MCash and ShopeePay pages document active wallet products in Malaysia

App, redirect or QR experience can differ by provider and route

Confirm the exact wallet route, currency, device flow and refund path

DuitNow QR

PayNet defines a national standardised QR payment scheme

In merchant-presented mode, the customer scans a merchant QR in a participating bank or wallet app

Confirm QR mode, acquirer, merchant status source, refund route and account eligibility

DuitNow Online Banking/Wallets

PayNet documents a separate ecommerce checkout product

Customer chooses an issuer and is redirected to approve the payment

Do not substitute this workflow for DuitNow QR

FPX

BNM and PayNet describe an internet-banking payment platform for ecommerce

Customer chooses a participating bank, is redirected and authorises with that bank

Request the live bank list and verify refunds, reports and provider payout terms

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.

HaiPay’s published Malaysia market coverage on the pricing page lists Visa and Mastercard card acceptance alongside the local wallets and FPX. The Malaysia collection table in the API documentation itemises the local routes only, so use the pricing page for card coverage and the API documentation for route codes. Method availability by market is confirmed in your quote, so obtain written route and account confirmation for cards before 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: published market coverage does not replace account-specific route and contract confirmation.

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.

Wallet

Official market evidence

Documented Malaysia route status

What remains to be confirmed

Touch ’n Go eWallet

Official payments page and merchant guide

TNG shown as Available

Exact checkout journey, appId enablement, merchant eligibility, refunds, disputes, reports and payout terms

Boost

Official business terms identify the Boost wallet system; a separate page describes a Boost DuitNow QR product

BOOST shown as Available

Whether the planned checkout is the wallet route or a QR route, plus all account and lifecycle terms

GrabPay

Official Malaysia product page and current payment terms

GRAB shown as Available

Exact online route, account scope, customer authentication, refunds, reports and payout terms

MCash

Official MCash pages show a Malaysia wallet and payment features

MCash shown as Available

Direct online customer flow, account eligibility and the full merchant lifecycle

ShopeePay

Official product and merchant-help pages describe online and in-store wallet acceptance

SHOPEE shown as Available

Provider route, merchant approval, checkout experience, refunds, disputes, reports and payout terms

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.

HaiPay’s Malaysia API documentation currently labels the DuitNow QR route as Maintenance, while the published market coverage lists DuitNow QR for Malaysia. This guide therefore does not describe the route as live. Confirm the current status, exact QR mode and account eligibility with HaiPay in writing before planning a launch around it.

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.

HaiPay’s published Malaysia coverage and API documentation do not list DuitNow Online Banking/Wallets. It is included only to prevent the common mistake of applying its redirect workflow to DuitNow QR.

DuitNow check

DuitNow QR

DuitNow Online Banking/Wallets

Customer starts

Scans merchant-presented QR in a participating app

Selects issuer at ecommerce checkout

Customer continues

Reviews merchant and amount in the issuer app

Is redirected to the issuer to approve

Confirmation

Issuer and acquirer return payment status; exceptions may need enquiry

Status returns through issuer, network and acquirer flow

Refund

PayNet documents DuitNow Reversal; provider implementation must be confirmed

PayNet requires a refund integration; provider implementation must be confirmed

Dispute

Domestic QR process exists; scope is limited

No published end-user dispute workflow; confirm with the provider

Provider status in current Malaysia API document

Maintenance

Not listed

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.

  • PayNet publishes a grouped participant list that changes over time, so this guide refers to participating Malaysian banks and financial institutions rather than a fixed number. Treat the live bank list returned at checkout as the operating reference.
  • 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.

FPX lifecycle point

Evidence-led interpretation

Launch check

Initiation

Customer chooses FPX and a bank from a live list

Test the bank enquiry and unavailable-bank state

Authentication

Customer uses the selected bank’s login and approval controls

Do not promise one universal authentication factor

Confirmation

Customer and merchant receive a transaction result

Test redirects, callbacks, delayed results and transaction enquiry

Refund

PayNet states that merchants can process refunds, subject to merchant and provider policy

Confirm full or partial support, timing, fees and identifiers

Dispute

No published FPX-specific end-user dispute workflow was found

Obtain a written escalation and ownership process

Reconciliation

PayNet’s merchant guide documents transaction and settlement report fields

Map provider order, payment and provider payout identifiers before launch

Settlement

Payment confirmation, interbank processing and provider payout are separate layers

Obtain account-specific provider payout terms in writing

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.

Decision point

DuitNow QR

DuitNow Online Banking/Wallets

FPX

Product identity

Standardised QR payment product

Ecommerce issuer-selection and redirect product

Separate internet-banking ecommerce platform

Typical customer action

Scan merchant QR in bank or wallet app

Select issuer, redirect and approve

Select participating bank, redirect and approve

Interface dependency

Static or dynamic QR and acquirer status

Dynamic issuer list, redirect and status integration

Dynamic bank list, redirect and status integration

Refund evidence

DuitNow Reversal exists; provider implementation varies

Refund integration is part of product responsibilities

Merchant refund capability exists; provider policy varies

Dispute evidence

Domestic QR process is documented

No published end-user dispute workflow; confirm with the provider

No published end-user dispute workflow; confirm with the provider

Merchant reconciliation

Acquirer portal or statement; exact fields vary

Provider and participant reporting; merchant fields vary

Merchant reports can include transaction and settlement identifiers

Provider documentation status

Maintenance

Not listed

MYR route shown as Available

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.

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.

Quote field

What to request

Why it matters

Processing charge

Percentage and fixed component by method and currency

A blended headline can hide method differences

Setup, monthly and minimums

Every recurring, minimum or one-time charge

Small and seasonal merchants need the full fixed-cost view

Refund and dispute costs

Fee, original-fee treatment and operational charge by method

Customer support economics differ from sale economics

Foreign exchange

Reference source, spread or markup, conversion time and applicable currency pair

A public bank rate is not the merchant’s contracted rate

Tax treatment

Approved tax label, scope and whether the quoted amount includes it

Tax wording must match the applicable product and contract

Provider payout

Currency, calendar basis, cut-off, reserves, holds and bank-credit process

Customer confirmation does not answer cash availability

Cross-border or outbound charge

Exact market, route, trigger and quoted term

A generic regional range cannot be assigned to Malaysia

HaiPay’s published list rates start at 2.5% + US$0.30 for eligible card transactions and from 0.8% for local payment methods, priced by market, with no setup or monthly fees. Settlement for Malaysia is typically T+2 (calendar days) on local payment methods and typically T+5 (calendar days) on international card payments. Tiers are counted in calendar days, and settlement falls on the first working day at or after the tier’s count date. Your actual rates, fees and timelines are confirmed in your quote. Confirm Malaysia-specific tax and FX treatment in your quote. Use the pricing page for discovery, then request a Malaysia quote and contract schedule.

Source: HaiPay, “Pricing” (published list rates and settlement tiers), accessed 25 August 2026. Applicability: quote planning only. Limitation: published list figures are not an account-specific quote.

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 HaiPay’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:

Test

Expected evidence

Method presentation

The correct methods appear only for approved currency, device and customer context

Payment creation

The currency-matched application identifier (appId), amount, currency, order reference and method code are validated

Redirect or QR

Customer returns to the correct order, and cancelled or expired attempts have defined states

Notification

Signature validation, idempotency and duplicate delivery are tested

Delayed result

Transaction enquiry can resolve a pending or missing callback without double fulfilment

Refund

Full and partial behavior, original-source return, fee and identifier are documented by method

Dispute

Owner, evidence, deadline, status and customer communication are documented by method

Reconciliation

Provider order ID, merchant order ID, gross amount, fee, net amount, status and provider payout reference can be matched

Finance handoff

Provider payout currency, cut-off, calendar treatment and exception owner match the contract

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:

Risk area

Evidence to request

Acceptance question

Unit economics

Written method-level quote, sample basket model and included/excluded cost list

Does the route still fit at the expected order value and refund rate?

Payment status

Success, failure, cancellation, expiry and delayed-result test cases

Can fulfilment wait for a provider-confirmed status without duplicate delivery?

Refund operations

Method-level full/partial policy, identifier and fee

Can support return the right amount to the original source and reconcile it?

Statement volume

Sample export or report with stable merchant-order and provider-payout identifiers

Can finance match a day of small orders without manual line-by-line recovery?

Integration load

Current docs, test account, callback retries, enquiry and idempotency cases

Can engineering recover from missing or repeated notifications safely?

Volume change

Account limit, review trigger and escalation owner in writing

Will a successful campaign create an avoidable account or operations interruption?

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: editorial synthesis of the Reddit signals cited above and the PayNet and HaiPay documentation used in this guide, prepared 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:

Comparison field

Acceptable evidence

Reject or hold for clarification

Method coverage

Current method-and-currency documentation plus account confirmation

Logo wall or undated list alone

Merchant eligibility

Entity, sector, country and underwriting terms for the applicant

“Available in Malaysia” without account scope

Cost

Comparable written quote with included and excluded items

Headline rate with missing FX, tax or operational fees

Customer flow

Screens, redirect or QR mode, authentication and status behavior

Generic “wallets supported” statement

Refund and dispute

Method-specific process, owner, timing, identifiers and fees

Card process copied onto bank or QR methods

Reconciliation

Sample report or API fields mapped to merchant orders and provider payouts

Dashboard screenshot without export or identifiers

Provider payout

Contracted currency, calendar basis, cut-off and exceptions

Payment-confirmation language used as cash-availability evidence

Integration

Current docs, test environment, callback design and failure cases

Feature list without test evidence

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

Nine-step Malaysia payment gateway selection flow from merchant eligibility and customer context to operations, settlement, integration testing and written confirmation

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, and the published market coverage adds Visa and Mastercard card acceptance; method availability by market is confirmed in your quote.

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.

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) and “Pricing” (published market coverage), accessed 25 August 2026. Limitation: product status and account eligibility may change after 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; accessed 25 August 2026.
  30. HaiPay — “Pricing” — supports published Malaysia market coverage and list rates; 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.

FAQ

  • There is no universal best gateway. Choose the provider that can document your required methods, merchant-entity eligibility, customer flow, total quote, refund and dispute process, reconciliation fields, provider payout terms and integration route. Test those claims before launch.

  • No. DuitNow is a family of products, including DuitNow QR and DuitNow Online Banking/Wallets. FPX is a separate internet-banking ecommerce platform. Their customer initiation, integration and exception handling should be specified separately.

    Source: PayNet, “DuitNow Online Banking/Wallet: Business Solutions” and “DuitNow QR: Business Solutions” (separate DuitNow products); PayNet Support, “What is FPX?” (FPX identity), accessed 25 August 2026.

  • Use the participating-bank list returned for the checkout session and the current PayNet source. A static number can become misleading because grouped institutions, channel codes and live availability are not the same count. This guide therefore refers to participating banks rather than a fixed number.

    Source: PayNet APIs, “FPX Browser Redirection” (buyer-bank enquiry and unavailable-bank handling); PayNet Support, “Which banks participate in FPX?” (current grouped participant list), accessed 25 August 2026. Limitation: a static count is not a substitute for the live bank list returned at checkout.

  • Yes. HaiPay’s published Malaysia market coverage lists Visa and Mastercard card acceptance alongside the local wallets and FPX, while the Malaysia collection table in the API documentation itemises local routes only. Method availability by market is confirmed in your quote, so request written route and account confirmation for cards before launch.

    Source: HaiPay, “Pricing” (published Malaysia market coverage) and “Malaysia” API documentation (route table), accessed 25 August 2026. Limitation: published coverage does not replace account-specific approval.

  • The current Malaysia route document labels its DuitNow QR route Maintenance. Do not plan a launch around it until the provider confirms the current status, exact QR mode and merchant-account eligibility in writing.

    Source: HaiPay, “Malaysia” API documentation (DuitNow QR route status), accessed 25 August 2026. Limitation: documentation status does not establish future availability or account eligibility.

  • Requirements can differ by method, acquirer, provider, merchant sector and contracting model. Official direct-onboarding pages provide market baselines, but they do not establish gateway eligibility for a cross-border entity. Ask for an account-specific underwriting answer.

    Source: PayNet, “DuitNow QR: Business Solutions”, PayNet Support, “How do merchants onboard to DuitNow QR?”, and PayNet, “FPX: Business Solutions” (direct onboarding baselines only), accessed 25 August 2026. Limitation: these sources do not establish provider-specific cross-border eligibility.

  • Compare written quotes with the same scope: method, percentage and fixed charge, setup or recurring costs, FX, tax treatment, refund and dispute costs, cross-border charges and provider payout terms. HaiPay’s published list rates start at 2.5% + US$0.30 for eligible card transactions and from 0.8% for local payment methods, priced by market. Your actual rates and fees are confirmed in your quote.

  • No. Cards, wallets, DuitNow products and FPX use different rules and parties. Confirm the process, owner, timing, fee, status and reconciliation identifiers for each enabled method.

    Source: Bank Negara Malaysia, “Types of Payment Systems” (structural distinctions); PayNet APIs, “DuitNow Reversal: Overview” and PayNet Support, “DuitNow Domestic Dispute Management” (product-specific exception scope), accessed 25 August 2026. Limitation: confirm provider implementation and account terms for every enabled method.

Related HaiPay surfaces

  • Guide

    International Payment Gateway

    Compare international gateway options by merchant eligibility, payment methods, currencies, settlement, integrations and operational fit.

  • Guide

    Local Acquiring vs Cross-Border Acquiring

    Compare local and cross-border acquiring by merchant entity, routing, settlement, acceptance and operating trade-offs.

  • Product

    Credit Card Acceptance

    Review HaiPay’s card product surface; confirm Malaysia route status, eligibility, operations and contract terms separately.

  • Product

    Local Payment Methods

    Explore HaiPay’s local-payment product surface; treat it as discovery, not proof of Malaysia method availability.

Need help mapping your payment stack?

Talk to HaiPay about acquiring, orchestration, local methods, and payout workflows.

Contact us