PayNow payment gateway integration that marks orders paid on its own

What does PayNow payment gateway integration mean for a website?

It means your site asks a payment provider to create a PayNow payment for a specific order, shows the customer the resulting QR code, and then receives a trustworthy signal when the money arrives, so the order moves to "paid" without a human looking at a bank statement.

PayNow itself is not a gateway. The Association of Banks in Singapore describes it as a funds-transfer service, launched on 10 July 2017, that moves Singapore dollars between bank and e-wallet accounts through FAST using a proxy such as a mobile number, NRIC/FIN or, for businesses through PayNow Corporate, the entity's UEN. Customers pay from their own banking or e-wallet app. Nothing about that flow, on its own, tells your website that order 1042 has been paid.

That gap is what integration fills. A payment gateway or collection service sits between your site and the PayNow network, generates a QR that encodes the amount and a reference, watches for the matching incoming payment and notifies your system. The site then updates stock, sends the confirmation email, and, if you connect accounting, records the receipt.

• Customer chooses PayNow at checkout
• Your server asks the provider for a payment tied to the order
• The provider returns a QR, and your page displays it with a countdown
• The customer scans and approves in their banking app
• The provider sends a signed webhook; your server verifies it and marks the order paid

Static UEN QR or dynamic PayNow QR: which should your checkout use?

Use a static UEN QR when orders are few and staff can check each transfer. Use a dynamic PayNow QR from a payment provider when orders are frequent, amounts vary, or you need confirmation within seconds.

A static QR is a fixed image linked to your UEN. Customers scan it, type the amount and ideally a reference. It costs nothing beyond your bank's business account terms and needs no code, which is why many home bakers, tutors and small shops start there. The problems appear with scale: customers mistype amounts, forget references, pay twice or pay for an order that has already been cancelled. Someone has to open the bank app, find each credit and match it by hand.

A dynamic QR is generated per order. It carries the exact amount and a unique reference, can be set to expire, and is watched by the provider. Customers cannot underpay by mistake, and the reference means matching is automatic. The trade-off is a per-transaction fee to the provider and a small development task to connect it properly.

How does a dynamic PayNow or SGQR code work at checkout?

A dynamic code is created for one payment only. The provider encodes your PayNow proxy, the amount and a reference into the QR payload, and marks whether the amount can be edited, so the customer's banking app shows the right figure and the right merchant name.

PayNow QR codes are integrated with SGQR, the national standard that the Monetary Authority of Singapore describes as the world's first unified payment QR code, co-owned by MAS and IMDA. For an online checkout that means the code your page shows is one that any participating bank or e-wallet app in Singapore can read.

Good checkout pages add a few touches around the QR. They show the amount and order number in text beside the code, a countdown to expiry, and a clear line saying what to do on a phone. That last part matters: most shoppers browse on the same phone they pay with, and you cannot scan a QR that is on your own screen. Common patterns are a "save QR image" button so the customer can open it from their gallery inside the banking app, or a provider-supported redirect where one exists.

While the customer is away paying, the page quietly checks the order status every few seconds and switches to a thank-you view the moment the webhook lands. If they close the tab, the confirmation email still arrives, because the server, not the browser, drives the status.

How do you choose a PayNow payment gateway in Singapore?

Choose on four things: whether the provider is licensed to operate in Singapore, how well its API and webhooks are documented, how and when it settles funds to your bank, and whether it covers the other methods your customers use, such as cards and wallets.

Providers that offer PayNow fall into rough groups. Global card processors have added PayNow alongside cards, which suits businesses already using them. Singapore-founded SME payment platforms focus on PayNow, QR and in-person payments with simple onboarding. Regional gateways cover several Southeast Asian countries, useful if you also sell in Malaysia or Thailand. Enterprise payment platforms suit high volumes and multiple markets. Some banks also offer business collection APIs. We are not affiliated with any provider and do not earn commission, so our advice is about fit.

Singapore regulates payment services under the Payment Services Act 2019, which MAS administers and which covers standard and major payment institutions. Before signing, check that the provider or its Singapore entity appears in MAS's Financial Institutions Directory, and read its merchant terms yourself.

• Sandbox with PayNow simulation, so testing does not need real money
• Signed webhooks with documented retry behaviour
• API endpoints to fetch a payment's status and to issue refunds
• Settlement schedule and minimum payout amount in writing
• A plug-in for your platform, if you run WooCommerce or similar
• Reports you can export or pull through the API for reconciliation

How do webhooks confirm a PayNow payment and update the order?

The provider sends an HTTPS request to your server when the payment succeeds, fails or expires. Your server verifies the signature, checks the payment against the provider's API, and then changes the order status exactly once.

Each of those steps protects against a real failure. Signature verification stops someone faking a "paid" message to your endpoint. The API check confirms the amount and currency match the order, so a partial or altered payment is not accepted. Processing exactly once matters because providers retry webhooks when they do not receive a quick success response, which means the same event can arrive two or three times. We record every event ID and ignore repeats.

Timing matters too. The webhook handler should respond fast and do slow work, such as sending emails or updating stock across channels, in a background job. Otherwise the provider may time out and retry, causing the duplicates you were trying to avoid.

We also run a safety net: a scheduled job that asks the provider about any order still "awaiting payment" after its QR has expired. If a webhook was lost during a server restart, that job catches it, and the customer still gets their confirmation. The same job marks expired orders as cancelled and returns reserved stock, which is vital for limited drops and ticketed events.

PayNow payment gateway integration for WooCommerce, Shopify and custom sites

On WooCommerce and most open-source platforms, the provider's plug-in is the starting point, and our work is configuring it correctly, fixing theme conflicts, and adding the order-status rules and safety checks it lacks. On Shopify, PayNow comes through a payment provider or app that Shopify supports in Singapore, so options are narrower and set by Shopify's rules.

Custom sites and headless stores need a direct API integration. We write the server-side code that creates the payment, the page that shows the QR, the webhook handler and the reconciliation job. This is the most flexible route and the one we recommend when your checkout has anything unusual: deposits, split payments across bookings, or orders confirmed only after stock is checked in a warehouse system.

Whichever platform you use, three rules apply. The amount must come from your server, never from the browser. The order reference must be generated by your system and carried through the provider into your bank statement where possible. And the order status must change only after verification.

If your store itself needs work, our Shopify developer service for Singapore and ecommerce website cost guide are good next reads.

Can you add PayNow payments to a mobile app?

Yes. The app asks your server to create the payment, displays the QR with the amount, and listens for status changes, while your server does the verification. The app itself never holds provider secret keys.

The awkward part in apps is the same-phone problem. A customer cannot scan a code shown on the phone they are holding. We usually offer a clear "Save QR to photos" action with instructions to open their banking app and choose the scan-from-gallery option, and we use any app-to-app flow the provider documents. On tablets and kiosks, where the customer scans from a separate phone, the QR works as normal.

Status updates reach the app through push notifications or short polling of your server, and the order screen changes the moment payment is confirmed. For subscriptions or in-app digital goods, note that Apple and Google have their own rules on when in-app purchases must use their billing systems, which can rule out PayNow for certain products; physical goods and real-world services are generally treated differently. Check the store guidelines for your case.

Our mobile app development service for Singapore covers the wider build, with Android and iOS apps starting from US$600.

How do PayNow refunds work after an online payment?

With a payment gateway, you refund through the provider's API or dashboard and the money returns to the customer's account according to the provider's process. With a static QR, you refund by making a new PayNow or bank transfer yourself, since PayNow payments cannot be reversed by the merchant.

We connect gateway refunds to your admin screen, so staff issue a full or partial refund from the order itself. The integration sends the refund request with the original payment reference, records the provider's refund ID, updates the order and stock, and emails the customer. If the provider processes the refund asynchronously, a webhook tells us when it completes, and the order shows "refund pending" until then.

Some points to settle in advance, with your provider and your own policy:

• Whether the provider supports partial refunds on PayNow payments
• Whether refunds are deducted from your next payout or need a balance
• Whether fees on the original payment are returned, which depends on the provider
• Who in your team may issue refunds, and up to what amount
• How refunds appear in your accounting, usually as a credit note

Your refund policy itself, including consumer rights, is your decision with your own adviser. We make whatever policy you choose work cleanly in the system; our own terms for your project are in the written quote and on our refund policy page.

What are PayNow gateway fees and settlement times?

They depend entirely on the provider and your agreement with it. Most charge a per-transaction fee for PayNow, often lower than for cards, and settle to your bank on a schedule, which may be daily, a few days after the payment, or on request above a minimum balance.

We do not quote other companies' prices because they change and vary by merchant. What we do is put the right questions in front of you before you sign. How is the PayNow fee calculated: a percentage, a fixed amount, or both? Is there a monthly minimum or setup fee? How long after a payment do funds reach your bank, and does that change for new merchants during an initial review period? Are refunds free, and are original fees returned? Can you pull settlement reports through the API?

One Singapore rule matters for your pricing. The Association of Banks in Singapore states that businesses using PayNow Corporate are prohibited from imposing surcharges on consumers for PayNow transactions. So if a provider charges you for PayNow payments, build that cost into your prices rather than adding a PayNow fee line at checkout.

Direct PayNow to your UEN, the static route, lands in your bank account almost immediately and typically has no scheme fee for you, but you give up automation. For many businesses the answer is both: static QR for occasional B2B invoices and a gateway for web checkout.

How do you reconcile PayNow gateway payments with your bank and accounts?

Match at two levels: each customer payment to its order, and each provider payout to the batch of payments it contains. The first is handled by the gateway reference; the second needs the provider's settlement report or API.

Gateways usually pay out batches net of fees and refunds. Your bank shows one credit, perhaps for dozens of orders. Without an automated match, a bookkeeper rebuilds each payout from a spreadsheet export. With one, the integration pulls the settlement data, confirms the payout total, records the fees as an expense and marks the batch reconciled.

If you use Xero, this fits a clearing-account pattern: receipts go into clearing when each payment succeeds, and the payout moves the net amount to the bank while fees go to their own account. The detail is in our guide to Xero API integration in Singapore. Businesses with other accounting systems get a daily CSV or dashboard showing orders, payments, refunds and payouts side by side, which any accountant can work with.

The payoff is quiet months. Instead of discovering at quarter end that twelve orders were never paid, or were paid twice, you see exceptions the day they happen.

Security and fraud checks every PayNow integration needs

Treat the browser as untrusted, verify every webhook, and keep provider keys on the server. Those three rules prevent most payment problems we see on small sites.

Common failures on hastily built PayNow checkouts include a "thank you" page that marks orders paid when visited directly, a webhook endpoint that accepts any request without checking its signature, and amounts taken from a hidden form field that a customer can edit. Each lets someone receive goods without paying the right amount. Fixing them is not complicated, but it has to be done deliberately.

• Amounts calculated on the server from the cart, never trusted from the page
• Webhook signatures verified with the provider's secret, and events de-duplicated
• Payment status re-checked through the provider's API before fulfilment
• Secret keys kept in environment settings, rotated at handover
• Admin refund actions logged with who did what and when
• Only the data the checkout needs collected and stored, in line with the PDPA
• Card data never touching your server, by using the provider's hosted fields

If you also take cards, hosted payment fields keep your PCI DSS scope as small as possible. Compliance with Singapore's Personal Data Protection Act and card-industry rules remains your responsibility, confirmed by your own advisers; our PDPA-focused website page explains how we build forms and consent around it.

How much does PayNow payment gateway integration cost?

From us, adding PayNow with automatic confirmation to an existing site or app starts from US$600. A new online store with PayNow built in starts from US$750, and larger platforms with payments inside are quoted from US$900. The provider's transaction fees are separate and paid by you directly to them.

What moves the figure? The platform matters most: configuring a well-maintained plug-in is lighter work than a direct API integration on a custom stack. Then come the extras: refunds from your admin, partial payments or deposits, several providers side by side, accounting sync, mobile app support and reporting. Quotes from other developers vary widely for the same reasons, and a suspiciously low one often leaves out webhook verification, expiry handling and refunds, which are exactly the parts that cause trouble later.

Our quote lists each part separately, with the provider you have chosen and the events we will handle, so you can compare it properly and drop anything you do not need.

For the wider picture of store budgets, see what an ecommerce website costs in Singapore, or compare our plans on the pricing page.

How long does it take to integrate PayNow into a website?

Two to four weeks is typical for adding PayNow to an existing site, and the slowest step is often not ours: provider onboarding, where the gateway verifies your business before live payments are enabled, can take days or longer.

We start in the provider's sandbox as soon as you have a test account, so development runs alongside their review. A plug-in setup on WooCommerce with our additional checks may take a week of effort. A direct API integration with refunds, expiry handling and reconciliation takes longer. A new store with PayNow follows the store timeline of four to eight weeks, with payments built in the middle phase.

What PayNow cannot do, and what to offer alongside it

PayNow moves Singapore dollars between Singapore bank and e-wallet accounts, so it does not serve tourists without a local account, overseas buyers, or anyone paying in another currency. Keep cards and wallets at checkout for them.

It is also a push payment: the customer initiates it, so there is no built-in way to charge a saved PayNow account automatically each month. Subscription businesses usually take the first payment by PayNow if they wish but use cards for recurring billing, or send a fresh PayNow request each cycle with a reminder. Instalment plans and buy-now-pay-later work differently again and are provided by their own schemes.

And PayNow, like any bank transfer, relies on the customer being able to open their banking app. During a bank's maintenance window or an app outage, a PayNow-only checkout loses sales. A second method protects you.

For most Singapore online stores we suggest PayNow first in the list, because many local shoppers prefer it, followed by cards and one or two wallets. The order matters less than making every option reliable.

Working with a freelance team in India on a payments project from Singapore

Our day overlaps almost all of yours: Singapore is two and a half hours ahead of India, so a 10 am SGT call is 7:30 am for us and your late afternoon is our early afternoon. Payment incidents rarely wait for office hours, which is why WhatsApp replies continue seven days a week.

On payments projects, we are careful about access. You create the provider account in your business name and invite us as developers with the narrowest role that works. Live secret keys go into your hosting settings, entered by you or by us on a screen share, and they are rotated when the project ends. Funds settle to your bank account; at no point do customer payments pass through us.

The first two weeks look like this. Day one or two: a call to walk through your checkout and decide between static QR, plug-in and direct integration. Within about two working days: an itemised quote in USD. After your written approval: provider application, sandbox setup and a shared test page where you can pay simulated orders by the end of week one. Week two brings refunds and admin views for you to try. Payments to us go by Wise or bank wire against the milestones in your quote, with invoices from India.

We do not visit premises, install card terminals or give legal advice. Anything more formal, such as confidentiality terms, is agreed in writing with your quote; our general terms are published.

Worked example: a hypothetical Katong bakery moving from static QR to automatic PayNow

Suppose a two-outlet bakery in Katong takes festive preorders on its website. Today the checkout shows a static UEN QR and asks customers to upload a screenshot. During busy weeks, two staff spend evenings matching screenshots to bank credits, and a few orders each season are baked but never paid, or paid twice.

A sensible PayNow payment gateway integration for them keeps the existing site but replaces the screenshot step. At checkout, the server asks their chosen provider for a payment with the exact amount and the preorder number. The page shows the QR, a 15-minute countdown and a "save QR" button for phone shoppers. When the webhook arrives, the server verifies it, confirms the amount, marks the order paid, reserves the collection slot and emails a receipt. Unpaid orders expire and release the slot automatically.

Staff get a simple admin view: today's paid orders by collection time, a refund button for cancellations, and a weekly payout report the bakery's bookkeeper uses to reconcile. Cards stay available for customers who prefer them.

This fits our add-on range starting from US$600. If the bakery also wanted a new site with a proper product catalogue, it would be quoted as a store from US$750. The scenario is illustrative only, not a description of a real client.

Go-live checklist for a PayNow payment gateway integration

Before real customers pay, run through every path in the sandbox and then with one small live payment. The list below is the one we work through with clients.

• Provider account approved in your business name, with PayNow enabled
• Correct merchant name appears when the QR is scanned
• Amount and order reference match on the QR, the order and the provider dashboard
• Webhook signature check rejects a tampered test request
• Duplicate webhooks do not send two confirmation emails
• Expired QR releases stock and cancels the order
• Full and partial refunds work from your admin and appear on the order
• Phone shoppers can save the QR and pay from their banking app
• Payout report reconciles with a real bank credit
• Alerts reach a named person if webhooks stop arriving

Once all ten pass, switch on live mode and keep an eye on the first day's orders together with us. Questions before you start? Send them through our contact page.