## What Is FPX?
FPX (Financial Process Exchange) is Malaysia’s online banking [payment gateway](/glossary/#gateway-token), operated by Payments Network Malaysia Sdn Bhd (PayNet). It lets customers pay directly from their bank account at checkout instead of using a card, redirecting them to their own bank’s internet banking portal to authorize the transaction. PayNet is jointly owned by Bank Negara Malaysia, the country’s central bank, and 11 Malaysian financial institutions.
FPX launched in 2004 and has since become the largest single online payment method in the country. It accounts for roughly 45% of Malaysian ecommerce transactions (Antom, citing PayNet data) and reaches 96% of Malaysian bank account holders. For any business selling into Malaysia, FPX isn’t an optional local add-on. It’s closer to what Visa and Mastercard are to US ecommerce: the default rail most customers expect at checkout.
## How FPX Payments Work
An FPX transaction runs through five steps from the customer’s side:
1. The customer selects FPX at checkout and picks their bank from a list of participants.
2. FPX redirects them to that bank’s internet banking login page.
3. The customer logs in with their normal banking credentials.
4. The bank displays the payment amount and payee for review.
5. The customer confirms, usually with a second authentication factor such as an OTP or a bank-specific security step.
Funds move in real time, and the merchant never sees or stores banking credentials, since authentication happens entirely inside the bank’s own portal. Message integrity between merchant, gateway, and PayNet is enforced with RSA-SHA1 signing, and every transaction carries a unique ID for reconciliation and dispute handling.
Some banks layer on their own requirements on top of the base FPX flow. CIMB, for example, requires SecureTAC authentication for any FPX transaction over MYR 100. A merchant’s integration needs to accommodate these bank-level variations, not just the generic PayNet spec.
[Settlement](/glossary/#settlement) to the merchant’s account is typically next-business-day through a standard acquirer relationship, though some providers offer same-day settlement at a higher tier. This is slower than the instant fund movement between customer and gateway, since the acquirer batch-settles merchant payouts separately from the real-time authorization step.
## FPX Service Models: B2C, B2B1, and B2B2
FPX isn’t one flow. PayNet defines three service models, and which one a merchant needs depends on who’s paying:
– B2C covers individual consumer payments at a standard ecommerce checkout. This is the model most online stores use.
– B2B1 adds dual [authorization](/glossary/#authorization) for corporate accounts, so a payment requires sign-off from more than one authorized user on the paying company’s account.
– B2B2 supports batch payment requests, aimed at higher-volume corporate use cases like paying multiple invoices in one session.
Most Malaysian ecommerce integrations only need B2C. But any platform serving business customers in Malaysia, such as a B2B SaaS product invoicing Malaysian companies, will run into B2B1 or B2B2 requirements, which carry their own authorization logic that a basic FPX integration doesn’t handle.
## Why FPX Matters for Ecommerce in Malaysia
Malaysian shoppers didn’t skip from cash to cards the way many Western markets did. Bank transfer through FPX became the default digital payment method first, and card penetration in ecommerce never caught up to the same degree. That history is why FPX still leads: PayNet’s broader transaction network processed 4.4 billion transactions in 2023 and was targeting 6 billion in 2024, about 35% year-over-year growth (The Star, December 2024).
The regulatory backdrop reinforces this. Bank Negara Malaysia treats FPX as core national payment infrastructure, not a third-party add-on, which is part of why bank participation is near-universal. 28 [acquiring banks](/glossary/#acquirer) and 14 third-party acquirers connect to FPX as of mid-2026 (PayNet). A merchant that doesn’t support FPX in Malaysia is opting out of the payment method the majority of the addressable market already trusts.
> Account-to-account payments are forecast to reach 40% of Malaysian ecommerce value by 2030 (Global Payments Report 2026).
This isn’t a rail in decline waiting to be replaced by wallets or cards; it’s the rail wallets and cards are still catching up to. FPX is Malaysia’s primary form of A2A payment.
## FPX vs. Cards, E-Wallets, and DuitNow
Each Malaysian payment method solves a different part of the checkout problem:
| Method | How it works | Where it fits |
|---|---|---|
| FPX | Redirect to bank portal, authenticate, confirm | Ecommerce checkout, bank-authenticated, no chargebacks |
| Cards | Standard card capture and authorization | Lower adoption in Malaysia vs. Western markets |
| E-wallets (Touch ‘n Go, Boost, GrabPay) | App-based balance or linked account | Strong at point-of-sale, growing in ecommerce |
| DuitNow | QR-based transfers and P2P | In-store and peer-to-peer, not primarily an ecommerce checkout method |
The practical distinction that matters for integration: FPX and DuitNow are both operated by PayNet, but they aren’t interchangeable. FPX is built for online checkout redirects; DuitNow is built around QR codes for in-person and peer-to-peer transfers. A merchant asking “should I support FPX or DuitNow” is usually asking the wrong question. They solve different transaction contexts, and most Malaysian ecommerce merchants need FPX specifically for online checkout.
Because FPX authenticates the customer through their own bank, merchants also avoid card-style chargebacks entirely. That’s a real advantage in fraud-sensitive categories, though it comes with a trade-off: refunds route back through the bank relationship rather than a card network, and timelines run three to five working days rather than instantly.
## Integrating FPX: Technical Requirements and Payment Flow
A direct FPX integration is a multi-step process, not a single API call. The standard path through an acquirer or gateway looks like this:
1. Select an acquiring bank or third-party acquirer (TPA) that holds a direct PayNet connection.
2. Complete PayNet’s Merchant Registration Form (MRF) through that acquirer.
3. Receive sandbox credentials once the MRF is approved.
4. Complete System Integration Testing (SIT) and User Acceptance Testing (UAT) with PayNet before going live.
5. Get production credentials and a Seller ID.
6. Integrate the redirect flow, callback handling, and RSA-SHA1 message signing into your checkout.
7. Handle bank-specific variations (like CIMB’s SecureTAC threshold) in your transaction logic.
This is where FPX diverges sharply from a card integration. There’s no single, static API you call the same way every time. The redirect-and-callback pattern means your backend has to handle the case where the customer returns to your site before the bank’s asynchronous confirmation arrives, and your idempotency handling has to account for that gap. None of this is exotic, but it’s also not something you get for free by reusing your existing card payment code.
## Integration Challenges Developers Hit in Practice
The gap between “FPX works” and “FPX works reliably in production” shows up in a few recurring places:
– Asynchronous callback timing: The bank’s confirmation callback and the customer’s browser redirect back to your site aren’t guaranteed to arrive in order. Code that assumes a synchronous request/response cycle, like a standard card auth, will show incorrect payment status to customers who return before the callback lands.
– Bank-specific authentication variance: CIMB’s SecureTAC threshold is one example; other banks impose their own step-up authentication rules above certain amounts. Testing against one bank’s sandbox doesn’t validate behavior across the full participant list.
– MRF and certification lead time: SIT and UAT with PayNet aren’t instant. Teams that plan an FPX launch on the same timeline as adding a new card processor typically underestimate this by weeks.
– No native recurring payments: FPX authorizes a single transaction per bank session. Subscription billing needs a separate mechanism, such as stored card details or a different local method, layered on top.
– Sandbox coverage gaps: Not every participating bank exposes a full sandbox environment with the same fidelity as production. Some integration bugs, particularly around bank-specific step-up authentication, only surface once real customers with real bank accounts start transacting.
None of these are reasons to skip FPX. They’re reasons a standalone FPX build takes longer than most teams initially budget for, especially when FPX is the fourth or fifth payment method a team has integrated directly rather than the first.
## Accepting FPX Through a Payment Orchestration Platform
Most of the FPX integration burden above isn’t specific to FPX. It’s the same pattern every regional payment method creates: a separate MRF-equivalent process, separate authentication quirks, separate callback handling, and a separate set of edge cases to test. A team supporting FPX, iDEAL, and PIX directly is maintaining three separate versions of that same problem.
Orchestra connects to FPX and 90+ other providers and payment methods through a single JavaScript library, so a platform expanding into Malaysia doesn’t need a dedicated FPX integration project alongside its existing card and wallet code. The redirect flow, callback handling, and bank-specific variance get handled inside Orchestra’s connection to the relevant acquirer, and your team keeps the integration surface it already has. For platforms serving multiple markets, this is the difference between “add Malaysia” being a multi-week integration project versus a configuration change against a rail you’ve already connected once.
This also matters for teams with existing Stripe, Adyen, or direct-acquirer code already in production. Adding Orchestra for FPX and other new markets doesn’t require ripping out what’s already working; it sits alongside existing integrations and takes on the new payment methods your product needs next, whether that’s FPX for Malaysia or another region’s dominant local method. See our [global payment acceptance](https://orchestrasolutions.com/global-payment-acceptance/) overview for how this applies across markets, or read about the [infrastructure cost of expanding into new markets](/payment-infrastructure-global-expansion/) when every region has its own preferred payment method.
## Frequently Asked Questions
### What does FPX stand for?
FPX stands for Financial Process Exchange, an online banking payment method operated by PayNet, Malaysia’s national payments network. It was established under Bank Negara Malaysia’s direction in 2004.
### Which banks support FPX in Malaysia?
28 acquiring banks participate in FPX as of mid-2026, including Maybank, CIMB, Public Bank, RHB, Hong Leong, HSBC, Citibank, OCBC, and Bank Islam. Coverage extends to 96% of Malaysian bank account holders.
### Is FPX only available in Malaysia?
Yes. FPX processes Malaysian ringgit transactions for customers with a Malaysian bank account and doesn’t support cross-border or multi-currency use cases. See our [cross-border payments FAQ](/faqs-cross-border-payments/) for how merchants handle settlement when accepting local methods like FPX alongside international card payments.
### What are the FPX transaction limits?
Personal (B2C) accounts run from MYR 1 to MYR 30,000 per transaction. Corporate accounts run from MYR 2 to MYR 1,000,000. Individual banks can set lower limits than PayNet’s maximums, so actual limits vary by the customer’s bank.
### How does FPX differ from a card payment?
FPX redirects the customer to their own bank’s login page for authentication rather than capturing card details at checkout. Because the bank handles authentication directly, FPX transactions don’t carry the chargeback risk that card payments do, though refunds take three to five working days to process back through the bank relationship.
### What is the difference between FPX and DuitNow?
Both are operated by PayNet, but they serve different transaction contexts. FPX is built for online checkout redirects; DuitNow is built around QR codes for in-store and peer-to-peer transfers. Most ecommerce merchants need FPX specifically for online checkout, not DuitNow.
### How do I add FPX to an existing checkout without a standalone integration?
FPX is available through a payment service provider or orchestration platform that already holds the PayNet connection, which avoids running your own Merchant Registration Form, System Integration Testing, and User Acceptance Testing process directly against PayNet.
