eCommerce Website Development in Malaysia: FPX, DuitNow and the Checkout Nobody Tests

A Malaysian eCommerce website can look completely finished.

The homepage is polished. The products are uploaded. The cart works. FPX appears under Payment Methods.

Then the first real customer buys something.

They choose their bank, leave the website, approve the payment, return from the banking app — and somehow the order still says:

Pending Payment.

Or the opposite happens.

The customer sees an error page, tries again and later discovers two orders.

This is the part of eCommerce website development that is easy to underestimate.

Adding a payment gateway is not the same as testing a checkout.

FPX is operated by PayNet and allows customers to pay directly from participating bank accounts through online banking.

DuitNow's online checkout model can also allow customers to pay using participating banks or eWallets.

Both can feel simple to the customer.

But from the website side, the transaction involves more than displaying a payment button.

1. Checkout Is a System, Not a Page

Businesses often review an eCommerce project by looking at screens:

Home → Product → Cart → Checkout → Success

Real customers do not always move through those five screens perfectly.

They refresh.

They press Back.

They change apps.

The bank rejects a transaction.

The mobile connection disappears.

They accidentally tap Pay twice.

The payment succeeds, but the browser never reaches the Success Page.

So a real checkout flow is closer to:

Cart → Customer Details → Shipping → Payment → External Payment Flow → Confirmation → Order Creation → Inventory → Email → Fulfilment

Every connection between those steps is something that can fail.

2. FPX Is More Than a Logo at Checkout

With FPX, a customer normally selects FPX, chooses a participating bank, moves into the bank's online banking environment, authorises the transaction and then returns to the merchant.

PayNet itself requires testing and UAT for direct FPX merchant integrations before production go-live.

That makes sense because the important question is not:

“Can the FPX page open?”

It is:

“Can our system correctly understand every possible outcome after the customer leaves our website?”

You need to test successful transactions, rejected transactions, customer cancellation, timeout behaviour and what the order looks like afterwards.

3. “DuitNow” Can Mean More Than Showing a QR Code

Malaysia businesses are familiar with DuitNow QR, but an eCommerce checkout can also use DuitNow Online Banking / Wallets.

In that flow, the customer chooses DuitNow at checkout, selects a participating bank or eWallet, approves the transaction and returns to the merchant website.

PayNet currently describes the service as supporting more than 40 participating banks and eWallet providers.

This is different from simply placing a static QR image on a checkout page and asking customers to upload a screenshot afterwards.

A proper integrated payment flow should allow the system to understand the transaction status and connect the payment to the correct order.

4. Never Treat the Success Page as Proof That You Got Paid

This is one of the most important technical details in the entire checkout.

Imagine the payment succeeds at the bank.

Then the customer's mobile internet drops before the browser returns to your Success Page.

If your website creates the order only when the customer reaches:

/payment-success

you now have a customer who paid successfully — but your website may not know what to do.

Modern payment integrations normally need a reliable server-side confirmation mechanism, such as a payment callback or webhook, depending on the gateway.

The customer's browser redirect can show the confirmation screen.

It should not be the only thing deciding whether money was received.

5. Payment Technology Cannot Fix a Bad Checkout

You can integrate every Malaysian payment method correctly and still lose the sale before the customer reaches them.

Current checkout research continues to find avoidable abandonment caused by issues such as:

• unexpected costs appearing too late,
• forced account creation,
• a checkout that feels too long or complicated,
• technical errors,
• and customers not finding a payment method they want.

That is why checkout design should answer basic questions early:

• What is the total price?
• How much is shipping?
• When will the order arrive?
• Can I check out as a guest?
• Which payment methods are available?

Do not wait until the final payment screen to reveal information that changes the buying decision.

This is also why an eCommerce project should not be judged only by how attractive the homepage looks. Our homepage conversion guide covers the earlier part of that customer journey.

6. Test the Checkout on the Phone Customers Actually Use

A checkout that works perfectly on the developer's desktop is not enough.

Malaysia payment flows often move the customer between browser and banking app.

So mobile testing should include:

• Safari on iPhone
• Chrome on Android
• switching from browser to a banking app
• returning to the browser after approval
• slow mobile connections
• refreshing the page
• closing the browser after payment

If most customers shop through their phones, mobile checkout is not the smaller version of the desktop experience.

It is the main checkout.

7. The Checkout Test Cases Nobody Likes Testing

This testing is less exciting than choosing website colours.

It is also much closer to the point where real money changes hands.

8. Malaysia Shipping Logic Needs Testing Too

Payments are not the only Malaysia-specific part of an eCommerce checkout.

Shipping can create another set of rules:

• Peninsular Malaysia vs Sabah and Sarawak
• postcode restrictions
• different courier rates
• free-shipping thresholds
• self-pickup
• bulky products
• areas a courier does not serve

The customer should understand the cost before reaching the final Pay button.

If RM18 shipping suddenly appears on the last screen, the payment gateway is not the reason the checkout failed.

9. Decide What Each Order Status Actually Means

An eCommerce backend should not have one vague status called:

Processing

for everything.

The team should understand the difference between states such as:

Pending Payment → Paid → Processing → Shipped → Completed → Cancelled → Refunded

The exact terminology can vary.

The important part is that Finance, Customer Service and Fulfilment understand the same thing when they see a status.

Payment status and fulfilment status should also not be confused.

A customer paying successfully does not mean the parcel has been packed.

10. Do Not Choose a Payment Gateway From the Logo List Alone

When comparing gateways or acquiring partners, ask more than:

“Do you support FPX?”

Check:

• FPX and DuitNow availability
• card and wallet support
• transaction fees
• settlement timing
• refund support
• recurring payment requirements
• dashboard and reconciliation
• technical documentation
• integration support

For example, FPX primarily supports one-time payments. Recurring payments or instalments may require additional arrangements with the bank or payment service provider. If your business sells subscriptions, confirm the recurring-payment setup before choosing the final payment architecture. If your business sells subscriptions, the payment architecture may need another method for recurring charges.

Choose the gateway around the business model, not around how many logos appear on the sales page.

11. When Does eCommerce Need Custom Development?

A standard eCommerce platform is enough for many Malaysian businesses.

If you sell ordinary products with standard inventory, shipping and checkout rules, there may be no reason to build everything from zero.

Custom development starts becoming more relevant when the business needs:

• special pricing rules,
• dealer or B2B accounts,
• ERP or inventory integration,
• unusual approval workflows,
• multiple warehouses,
• custom fulfilment logic,
• or a checkout that standard plugins cannot handle reliably.

At that point, the question becomes bigger than website design.

It becomes a system integration problem.

If your workflow is already moving beyond a standard website, our guide to choosing a software company in Malaysia explains what to check before commissioning custom development.

What Should an eCommerce Website Budget Actually Cover?

An eCommerce quotation should not only cover the pages customers see.

Depending on Scope, it may need to include:

• product catalogue setup,
• cart and checkout UX,
• payment gateway integration,
• shipping logic,
• order management,
• email notifications,
• mobile testing,
• payment UAT,
• analytics,
• SEO foundations,
• training,
• and post-launch support.

This is one reason two eCommerce quotations can look very different even when both say “online store”.

For a broader look at Malaysia website budgets, see our Website Design in Malaysia: RM3k vs RM10k vs RM30k.

The Bottom Line

For Malaysian eCommerce, FPX and DuitNow matter.

But simply displaying those options does not mean the checkout is finished.

The real test begins when customers do something unexpected:

Cancel → Fail → Refresh → Switch App → Lose Connection → Pay Twice → Pay Successfully and Never Return

A reliable eCommerce website needs to know what to do in all of those situations.

So before launch, do not only test:

“Can I buy this product?”

Test:

“What happens when the transaction does not go perfectly?”

That is usually where the difference between a working online shop and a production-ready eCommerce system becomes visible.

Payment-method availability, fees and technical requirements depend on the selected gateway or acquiring partner. Confirm current FPX, DuitNow, card, wallet, settlement and recurring-payment support before choosing the final payment architecture.