一个 Malaysia eCommerce Website 可以看起来已经完全做好。

Homepage 很漂亮，Product 全部 Upload 了，Cart 可以用，Checkout 里面也已经出现 FPX。

然后第一个真正的 Customer 下单。

他选择 Bank、离开 Website、在 Banking App Approve Payment，然后回到 Website。

结果 Order Status 还是：

Pending Payment.

也可能发生完全相反的情况。

Customer 看到 Error Page，以为没有付款成功，再按一次。

后来才发现自己有两个 Order。

这就是 eCommerce Website Development 很容易被低估的部分。

加上 Payment Gateway，不代表 Checkout 已经测试完成。

FPX 和 DuitNow：Customer 实际上在做什么？

Payment Flow Customer 会做什么 Website 需要处理什么
FPX 选择 Bank、离开 Checkout、通过 Online Banking Approve Redirect、Payment Confirmation、Success / Failure State 和 Return Flow
DuitNow Online Banking / Wallets 选择 Bank 或 eWallet，再到外部 Approve Payment Redirect、Transaction Status 和返回 Merchant Website
Cards / Wallets 输入或确认 Payment Detail Authentication、Decline Handling 和 Confirmation
Manual Transfer 另外转账，并可能需要上传 Proof Manual Verification 和 Reconciliation

FPX 是 PayNet 的 Online Payment Service，让 Customer 可以通过参与的 Bank Account 直接完成 Online Banking Payment。

DuitNow Online Banking / Wallets 也可以让 Customer 在 Online Checkout 选择 Bank 或 eWallet 完成付款。

对 Customer 来说，这些 Flow 看起来很简单。

但从 Website 的角度来看，Transaction 远远不只是显示一个 Payment Button。

1. Checkout 是一个 System，不只是一个 Page

很多 Business 在 Review eCommerce Project 时，只会看这些 Screen：

Home → Product → Cart → Checkout → Success

但真正的 Customer 不一定会完美地照着这五个 Screen 走完。

他们会 Refresh。

会按 Back。

会切去其他 App。

Bank 可能 Reject Transaction。

Mobile Internet 可能突然断掉。

Customer 可能不小心按两次 Pay。

Payment 甚至可能已经成功，但 Browser 根本没有回到 Success Page。

所以真正的 Checkout Flow 比较接近：

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

这些 Step 中间每一个 Connection，都有可能出问题。

FPX Flow 里面，Customer 一般会选择 FPX，再选择参与的 Bank，然后进入 Bank 的 Online Banking Environment，完成 Authorisation，最后再返回 Merchant Website。

真正应该测试的问题不是：

“FPX Page 开得到吗？”

而是：

“Customer 离开我们的 Website 以后，不管发生什么 Result，我们的 System 都知道应该怎样处理吗？”

应该测试：

  • Successful Transaction
  • Rejected Transaction
  • Customer Cancel
  • Timeout
  • Payment 以后 Order Status 是否正确

Payment Page 打得开，只是整个 Integration 最前面的一小部分。

3. “DuitNow” 不只是放一个 QR Code

Malaysia Business 很熟悉 DuitNow QR。

但 eCommerce Checkout 也可以使用 DuitNow Online Banking / Wallets。

Customer 可以在 Checkout 选择 DuitNow，再选择参与的 Bank 或 eWallet，到外部完成 Approval，然后回到 Merchant Website。

这跟单纯在 Checkout 放一个 Static QR Image，然后叫 Customer Transfer 后上传 Screenshot，是完全不同的 Flow。

一个 Proper Integrated Payment Flow，应该让 System 可以知道 Transaction Status，并把 Payment 正确连接到对应 Order。

正在开发 Malaysia eCommerce Website？

Payment Integration 应该跟 Checkout、Order Status、Inventory 和 Fulfilment 一起设计，而不是等 Website 做完以后，最后才加一个 Payment Button。

了解 Website Development → eCommerce · FPX · DuitNow · Checkout · Mobile

4. 不要把 Success Page 当成唯一的付款证明

这是整个 Checkout 里面最重要的 Technical Detail 之一。

想象 Customer 已经在 Bank 成功付款。

然后 Mobile Internet 突然断掉。

Browser 根本没有回到你的 Success Page。

如果 Website 只有在 Customer 打开：

/payment-success

以后才 Create Order，那就会出现一个很危险的 Situation：

Customer 已经付款，但 Website 不知道接下来应该做什么。

Reliable Payment Integration 通常需要 Server-side Confirmation，例如 Gateway 提供的 Callback、Webhook 或其他 Transaction Confirmation Mechanism。

Browser Redirect 可以负责显示 Confirmation Screen。

但不应该成为判断是否收到钱的唯一依据。

5. Payment Technology 救不了一个很差的 Checkout

就算所有 Malaysia Payment Method 都 Integration 正确，Customer 还是可能在真正付款之前离开。

常见原因包括：

  • 最后才突然出现 Extra Cost
  • 强制 Create Account
  • Checkout 太长或太复杂
  • Technical Error
  • 找不到想用的 Payment Method

所以 Checkout Design 应该尽早回答这些 Basic Question：

  • Total Price 是多少？
  • Shipping 多少钱？
  • 几时可以收到？
  • 可以 Guest Checkout 吗？
  • 支持什么 Payment Method？

不要等 Customer 已经来到最后一页，才突然显示会改变 Buying Decision 的 Information。

这也是为什么一个 eCommerce Project 不能只看 Homepage 漂不漂亮。

如果想看 Customer Journey 前面的 Conversion，可以参考我们的 Homepage Design That Converts。

6. 一定要用 Customer 真正在用的 Phone 测试 Checkout

Developer Desktop 上面完美运行，不代表 Project 已经 Ready。

Malaysia Payment Flow 很常需要 Customer 在 Browser 和 Banking App 之间切换。

所以 Mobile Testing 至少应该包括：

  • iPhone Safari
  • Android Chrome
  • Browser 切去 Banking App
  • Approve 后返回 Browser
  • Slow Mobile Connection
  • Refresh Page
  • Payment 后直接关闭 Browser

如果大多数 Customer 本来就是用 Phone Shopping，Mobile Checkout 就不是 Desktop Experience 的缩小版。

它才是真正的 Main Checkout。

7. 最容易没人认真测试的 Checkout Situation

一个实际的 eCommerce Checkout Test Matrix

Test 正确情况下应该发生什么 你在避免什么 Problem
Successful Payment 只 Create 一个 Paid Order Missing Order
Failed Payment Order 保持 Unpaid，而且 Customer 可以安全 Retry 错误 Paid Status
Customer 在 Bank Cancel Checkout 回来以后清楚显示 Unpaid 一堆不知道状态的 Pending Order
Customer 已付款但没有回来 Server 还是可以收到 Payment Confirmation Customer 已付款但没有 Fulfilment
Double-click Pay 只有一个 Valid Order / Payment Flow Duplicate Order
Slow Confirmation Order 保持 Safe Pending State，等真正 Confirmation 错误显示 Success / Failure
Checkout 期间 Stock Change Inventory Rule 阻止 Invalid Fulfilment 卖出已经没 Stock 的 Product
Mobile Banking App Return Customer 回到正确 Order State Broken Mobile Checkout

这些 Testing 没有挑 Website Colour 那么有趣。

但这里才是真正开始有 Money Flow 的地方。

8. Malaysia Shipping Logic 也一定要一起测试

Payment 并不是 Malaysia eCommerce Checkout 唯一有 Local Requirement 的部分。

Shipping 也可能产生很多 Rule：

  • Peninsular Malaysia vs Sabah / Sarawak
  • Postcode Restriction
  • 不同 Courier Rate
  • Free Shipping Threshold
  • Self-pickup
  • Bulky Product
  • Courier 不 Support 的 Area

Customer 应该在最后按 Pay 之前，就已经知道自己需要付多少 Shipping。

如果到了最后一个 Screen 才突然多 RM18 Shipping Fee，Checkout Fail 的原因就不是 FPX。

9. 一定要定义清楚每一个 Order Status 代表什么

eCommerce Backend 不应该所有 Order 都只有一个很模糊的：

Processing

Team 应该知道这些 Status 之间有什么差别：

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

实际 Naming 可以根据 Business 改。

重点是 Finance、Customer Service 和 Fulfilment Team 看到同一个 Status 时，理解的是同一件事。

Payment Status 和 Fulfilment Status 也不应该混在一起。

Customer 已经付款成功，不代表 Parcel 已经 Pack 好。

10. 不要只看 Logo 数量选择 Payment Gateway

比较 Payment Gateway 或 Acquiring Partner 时，不要只问：

“Support FPX 吗？”

还应该检查：

  • FPX 和 DuitNow Availability
  • Card 和 Wallet Support
  • Transaction Fee
  • Settlement Timing
  • Refund Support
  • Recurring Payment Requirement
  • Dashboard 和 Reconciliation
  • Technical Documentation
  • Integration Support

例如 FPX 本身是 Customer-authenticated Bank Payment，并不是拿来做 Recurring Payment 的 Method。

如果 Business 卖 Subscription，就可能需要另外一种 Payment Architecture 来 Handle Recurring Charge。

Payment Gateway 应该根据 Business Model 选。

不是看 Sales Page 上面有多少个 Logo。

11. 什么情况下 eCommerce 需要 Custom Development？

很多 Malaysia Business 用 Standard eCommerce Platform 就已经足够。

如果卖的是普通 Product，而且 Inventory、Shipping 和 Checkout Rule 都很 Standard，根本没有必要全部从零 Build。

Custom Development 比较值得考虑，通常是 Business 开始需要：

  • 特别 Pricing Rule
  • Dealer 或 B2B Account
  • ERP / Inventory Integration
  • 特殊 Approval Workflow
  • Multiple Warehouse
  • Custom Fulfilment Logic
  • Standard Plugin 很难 Handle 的 Checkout Rule

到了这个 Level，问题已经不只是 Website Design。

而是 System Integration。

如果你的 Workflow 已经超过 Standard Website，可以看我们的 Malaysia Software Company Selection Guide，了解 Custom Development 之前应该检查什么。

eCommerce Website Budget 到底应该 Cover 什么？

eCommerce Quotation 不应该只 Cover Customer 看得到的 Page。

根据 Scope，可能还应该包括：

  • Product Catalogue Setup
  • Cart 和 Checkout UX
  • Payment Gateway Integration
  • Shipping Logic
  • Order Management
  • Email Notification
  • Mobile Testing
  • Payment UAT
  • Analytics
  • SEO Foundation
  • Training
  • Post-launch Support

所以两份 Quotation 就算都写：

Online Store

Price 也可能差非常多。

如果想先了解比较整体的 Malaysia Website Budget，可以看我们的 Website Design in Malaysia：RM3k vs RM10k vs RM30k。

总结

对 Malaysia eCommerce 来说，FPX 和 DuitNow 当然很重要。

但 Checkout 上面出现这些 Option，并不代表 Project 已经完成。

真正的 Testing，是 Customer 开始做一些不完美的事情以后：

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

Reliable eCommerce Website 应该知道这些 Situation 出现时，要怎样处理。

所以 Launch 前不要只测试：

“我可以成功买到这个 Product 吗？”

还要测试：

“如果 Transaction 没有完美进行，System 会发生什么？”

通常就是在这些 Exception 里面，才会真正看出一个 Online Shop 是单纯 “可以用”，还是已经 Ready 给 Real Customer 和 Real Money 使用。

正在为 Malaysia Customer 开发 eCommerce Website？

Optimum Technology 会把 Local Payment、Checkout、Mobile Experience 和 Business Workflow 当成一个完整 System 一起设计，而不是最后才把几个 Plugin 加进去。

了解 Website Design → Malaysia eCommerce · FPX · DuitNow · Mobile Checkout · Integrations

Payment Method Availability、Fee 和 Technical Requirement 会根据选择的 Gateway 或 Acquiring Partner 而不同。正式决定 Payment Architecture 之前，应该确认最新的 FPX、DuitNow、Card、Wallet、Settlement 和 Recurring Payment Support。