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.
The map prevents three common category errors:
- A wallet brand is not automatically the underlying payment rail.
- A network participant is not automatically the merchant’s gateway provider.
- 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.
- Which legal entity signs the contract?
- Is a Malaysian entity, local registration or local bank account required for each method?
- Which merchant categories are restricted or need enhanced review?
- Which currencies can the customer pay and the merchant receive?
- Which methods will be enabled on the specific appId or account?
- What transaction and rolling limits apply after approval?
- Can reserves, holds or additional reviews apply, and under what contract terms?
- Who owns customer-support escalation for a failed payment, refund or dispute?
- What evidence is required before increasing volume?
- 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
Use the flow in order:
- Establish entity eligibility. Confirm contracting entity, sector, know-your-business (KYB) review and bank-account requirements.
- Define the customer context. Record buyer location, device, currency, average order value and purchase frequency.
- Choose method families. Separate cards, named wallets and account-based methods.
- Prove customer demand. Use your own checkout analytics, support requests and controlled tests. Do not infer demand from a logo list.
- Specify the rail workflow. Name DuitNow QR, DuitNow Online Banking/Wallets or FPX precisely.
- Validate operations. Test status, refunds, disputes, reconciliation and customer escalation.
- Document money movement. Obtain the provider payout currency, FX basis, cut-off and account terms.
- Test the integration. Verify route, appId, callbacks, enquiry and failure recovery.
- 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.
- 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) 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.
- Bank Negara Malaysia — “e-Duit” — supports Malaysia payment categories and customer payment modes; accessed 25 August 2026.
- Bank Negara Malaysia — “Financial Sector Participants Directory” — supports regulated-role and entity listings, not interoperability; accessed 25 August 2026.
- Bank Negara Malaysia — “Types of Payment Systems” — supports stable structural definitions for cards, e-money and FPX; accessed 25 August 2026.
- 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.
- 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.
- PayNet — “FPX: Business Solutions” — supports FPX merchant context and onboarding baseline; accessed 25 August 2026.
- PayNet Support — “What is FPX?” — supports the FPX definition; accessed 25 August 2026.
- PayNet Support — “How FPX Works” — supports bank selection, redirect, authentication and confirmation; accessed 25 August 2026.
- PayNet APIs — “FPX Browser Redirection” — supports dynamic buyer-bank enquiry and unavailable-bank handling; accessed 25 August 2026.
- PayNet Support — “Which banks participate in FPX?” — supports the current grouped participant list and its update caveat; accessed 25 August 2026.
- PayNet — “DuitNow QR: Personal Solutions” — supports the basic customer QR journey; accessed 25 August 2026.
- PayNet APIs — “Merchant Presented Mode: Domestic QR” — supports the domestic merchant-presented QR lifecycle and exception states; accessed 25 August 2026.
- PayNet APIs — “DuitNow Reversal: Overview” — supports the reversal/refund mechanism and its limits; accessed 25 August 2026.
- PayNet Support — “DuitNow Domestic Dispute Management” — supports the domestic QR dispute scope; accessed 25 August 2026.
- PayNet — “DuitNow QR: Business Solutions” — supports merchant notifications, statements and direct-acquirer context; accessed 25 August 2026.
- PayNet Support — “How do merchants onboard to DuitNow QR?” — supports direct onboarding baselines, not gateway eligibility; accessed 25 August 2026.
- PayNet — “DuitNow Online Banking/Wallet: Business Solutions” — supports the identity of OBW as a separate ecommerce product; accessed 25 August 2026.
- PayNet APIs — “DuitNow Online Banking/Wallets: Overview” — supports issuer selection, redirect and participant responsibilities; accessed 25 August 2026.
- Touch ’n Go eWallet — “Payments” — supports wallet market presence and customer payment contexts; accessed 25 August 2026.
- Touch ’n Go — “Merchant’s Guidebook” — supports direct merchant-operation context, not gateway availability; accessed 25 August 2026.
- Boost — “Terms & Condition (Business): General” — supports the Boost wallet operator and direct merchant context; accessed 25 August 2026.
- Boost — “DuitNow QR” — supports a distinct Boost-provided QR acceptance context; accessed 25 August 2026.
- Grab — “GrabPay” — supports GrabPay market presence and consumer payment contexts; accessed 25 August 2026.
- Grab — “Terms of Service: Payment and Rewards” — supports issuer identity and product scope; last modified 25 May 2026, accessed 25 August 2026.
- MCash — “The Malaysia Wallet” — supports MCash market presence; accessed 25 August 2026.
- MCash — “E-Wallet Features” — supports scan-and-pay and in-app payment categories; accessed 25 August 2026.
- ShopeePay — “ShopeePay features” — supports wallet market presence and online/in-store use; accessed 25 August 2026.
- Shopee Help — “What is a ShopeePay Merchant?” — supports direct merchant acceptance context, not gateway availability; accessed 25 August 2026.
- HaiPay — “Malaysia” API Documentation — supports route codes, document status, route-level limits and integration prerequisites; accessed 25 August 2026.
- HaiPay — “Pricing” — supports published Malaysia market coverage and list rates; accessed 25 August 2026.
- HaiPay — “Local Payment” — supports general product discovery, not Malaysia account availability; accessed 25 August 2026.
- HaiPay — “Credit Card” — supports general card-product discovery, not Malaysia route status; accessed 25 August 2026.
- HaiPay — “Checkout” — supports general checkout discovery, not method enablement; accessed 25 August 2026.
- HaiPay — “API Integration” — supports general integration discovery, not method-level lifecycle proof; accessed 25 August 2026.
- HaiPay — “Contact” — commercial endpoint for eligibility and quote confirmation; accessed 25 August 2026.
- 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.
- 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.
- PayNet APIs — “Initiate Payment Intent (One-Time Payment)” — supports the OBW corporate-approval flow and pending-authorisation state; accessed 25 August 2026.
- PayNet Support — “Frequently Asked Questions (FAQs) — FPX” — supports merchant FPX refund capability subject to merchant policy; accessed 25 August 2026.
- 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
Explore the payment stack
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