Payment integration guide
How do I add FPX and DuitNow payments to my website or app?
By Pali (Wan Muhamad Fadzli), product builder, Penang.
Last updated
To add FPX and DuitNow payments, connect your Malaysian website or app to a payment gateway that supports those methods, then build checkout, server-side confirmation and payment records around it. Pali's published payment integration rate is RM 450. Gateway fees, refunds, settlement needs, subscriptions and changes to your existing system are priced or paid separately.
How does an FPX and DuitNow payment integration work?
The integration sits between your checkout, a payment gateway and the system that stores the order or invoice. The gateway handles the payment method. Your website or app creates the payment request, sends the customer through the approved flow and waits for a validated result before recording payment.
| Integration part | What it does | Decision to make |
|---|---|---|
| Checkout | Collects the order, invoice and customer details needed for payment | Which fields and payment methods the customer sees |
| Payment gateway | Provides FPX, DuitNow QR or other enabled methods | Which provider fits your account and operating needs |
| Payment reference | Links the gateway transaction to your order or invoice | Which internal record is the source of truth |
| Server confirmation | Reports and validates the payment result | Which statuses can update the order or invoice |
| Staff record | Shows successful, pending, failed and refunded payments | Which team reviews exceptions and settlements |
The customer may return to a success or failure page after paying. Separately, the gateway sends a payment update to your server. The system validates that update, matches it to the correct record and changes the status only when the confirmation is valid.
Which payment flow should I add first?
Choose one flow with a clear amount, reference and owner. Practical first flows include:
- paying a fixed order total at checkout;
- paying an invoice from a unique payment link;
- collecting a booking deposit or full payment;
- marking an order paid after gateway confirmation;
- sending a receipt or staff notification after payment;
- showing staff when a payment remains pending or fails.
Start with one-time payments if they meet the business need. Saved payment methods, recurring charges, split payments and marketplace settlements add different account, data and exception requirements.
What should be decided before connecting a payment gateway?
Map the complete payment journey before development:
- Choose the gateway account your business will own.
- Confirm that the account offers FPX, DuitNow QR and any other required methods.
- Define the order or invoice record that owns each payment reference.
- List the statuses the gateway can send and what each status changes.
- Decide how pending, failed, duplicate and refunded payments appear to staff.
- Define the customer message, receipt and next step for every result.
- Set up test and live credentials outside the code repository.
If payment belongs to an online store, compare the e-commerce website cost guide. For a broader system build, read the app development cost guide.
What affects the scope of payment gateway integration?
- Existing platform. A supported plugin, hosted checkout, custom website and mobile app need different work.
- Payment flow. Orders, invoice links, deposits, full payments and recurring charges use different rules.
- Business records. The integration must match each gateway transaction to the correct order, booking or invoice.
- Payment states. Pending, successful, failed, expired, duplicate and refunded results need clear handling.
- Connected systems. Receipts, accounting, e-invoice, inventory and staff notifications add workflows.
- Testing. Test accounts, live credentials, return pages and server confirmations must be checked before launch.
- Operations. Staff need a clear process for exceptions, refunds, transaction searches and settlement review.
The technical payment gateway connection uses RM 450. Gateway fees and other third-party charges stay on accounts you own and are paid by you at cost where possible. Extra checkout rules, migrations, dashboards and connected systems are priced by scope.
How should payment status and account ownership work?
Your internal order or invoice should keep the business record, while the gateway keeps the payment transaction. Store the references needed to match them without treating the browser return page as final confirmation. Staff should be able to see the current status, the gateway reference and any exception that needs review.
Keep the gateway account, settlement details and live credentials under your business. Limit access by role, separate test and live settings, and remove access when responsibilities change. Credentials should stay in protected environment settings, not in source code or public pages.
How do I plan a payment gateway integration?
- Describe the first payment journey in the project calculator, including the checkout, payment methods, record, confirmation and staff owner.
- Use the Discovery Sprint to check the provider account, API documentation, payment states, security, test flow and exceptions before agreeing a fixed scope.
- Test successful, pending, failed and duplicate attempts before launch, then monitor the first live transactions and staff handoff.
See how fixed-scope app development works before connecting FPX and DuitNow payments to your website or app.