Singapore shoppers expect PayNow and GrabPay at checkout. When either option is missing, cart abandonment climbs and customers simply move to a competitor who offers it. Integrating both payment methods into your e-commerce checkout is less about a single technical trick and more about choosing the right architecture, completing the API setup correctly, and building a payment flow that feels instant on the customer’s side. This guide covers everything from understanding how each system works to writing the code that ties them into your checkout page, and it closes with a decision framework that helps you pick the right integration path for your store.

Why Singapore E-Commerce Stores Need PayNow and GrabPay

Singapore has one of the highest cashless adoption rates in Southeast Asia, driven by the national Smart Nation initiative and the aggressive rollout of PayNow through all major banks. PayNow is operated by the Association of Banks in Singapore and enables real-time fund transfers using a mobile number, NRIC, or Virtual Payment Address. GrabPay is the mobile wallet from Grab, Southeast Asia’s super-app, used for in-app and online purchases across the region. Together these two rails account for a very large share of online payment volume in Singapore, and any store that does not surface them at checkout is asking a significant portion of its audience to switch payment methods or leave entirely.

The case for including them is practical rather than theoretical. A customer browsing your store on their phone mid-commute already has the PayNow or GrabPay app open. Reducing the number of taps between decision and payment is the single most reliable way to lift conversion rate on mobile. Our work on The Roots Company, a US-based online destination for sourcing authentic Indian food products, showed how much a well-structured digital infrastructure matters for conversion. Their site was built around a unified design system with optimised user journeys and clear conversion pathways, the same structural thinking that makes a payment integration successful.

Understanding the PayNow Integration Architecture

PayNow has two distinct rails and you must pick the correct one before writing any code. The first is PayNow QR, which is designed for point-of-sale and in-person transactions. A merchant displays a static or dynamic QR code; the customer scans it with their banking app or the PayNow app and confirms the amount. This is not the right rail for e-commerce. The second is PayNow Server-to-Server, also called PayNow Online, and that is what an e-commerce checkout uses.

In a Server-to-Server PayNow flow, the customer selects PayNow at checkout. Your server constructs a PayNow transaction request and sends it to the PayNow server, which returns a redirect URL. You send the customer’s browser to that URL. The customer opens their banking app or PayNow app, confirms the amount and the recipient, which you pre-populate with your business details, and the PayNow server calls back to your server with a payment status notification. Your server updates the order status and confirms the purchase to the customer.

The prerequisite for this integration is a PayNow Corporate Account with a participating bank: DBS, OCBC, UOB, Standard Chartered, Citibank, HSBC, Maybank, and several others all offer the facility. You will need to work with your relationship manager to obtain the API credentials, including your entity ID, the PayNow endpoint URLs for the sandbox and production environments, and the callback URL that PayNow will POST status updates to. The credentials are bank-specific, and the sandbox environment is usually available within a few business days after your application is approved.

Setting Up GrabPay via the Developer API

GrabPay is a closed-loop mobile wallet, which means customers must have previously loaded value into it before spending. That closed loop makes the integration path different from PayNow. You do not connect to a bank directly; you connect through the GrabPay Merchant API, which requires a Grab Merchant account, business verification, and API key generation through the Grab Developer Portal.

The standard GrabPay checkout flow begins when the customer selects GrabPay. Your server creates an order and calls the GrabPay Create Order endpoint with the amount, currency, a unique order reference, and your redirect URLs. GrabPay returns an order ID and a redirect URL. You send the customer to that URL, which is either a web checkout page hosted by Grab or a deep link that opens the Grab app directly. The customer authenticates inside the Grab app or on the web page, reviews the amount, and confirms. GrabPay then redirects the customer back to your return URL with an order ID. Your server calls the GrabPay Check Status endpoint to confirm the payment, and the order proceeds.

One important consideration with GrabPay is wallet currency. If your store charges in Singapore Dollars, the wallet must be funded in SGD. GrabPay wallets are country-specific, so a GrabPay wallet funded in Malaysian Ringgit cannot complete an SGD transaction on your Singapore store. The API will reject it, so you should handle this error state explicitly and surface a clear message rather than a generic checkout failure.

Comparing Payment Integration Options for Singapore Checkouts

PayNow and GrabPay are not the only payment methods worth considering, and most Singapore merchants should offer a combination. The table below compares the four options that matter most for an SGD-denominated e-commerce store.

For a Singapore-focused store, the right setup almost always combines PayNow as the primary domestic rail, GrabPay as the secondary mobile wallet option, and either Stripe or a local card acquirer for international customers. Offering all four without careful implementation, however, can clutter the checkout UI. Prioritise based on your customer data and gradually expand.

Choosing Between Direct API Integration and a Payment Gateway

You have two architectural choices when integrating PayNow and GrabPay: connect directly to each payment rail’s API, or route both through a payment gateway that handles the orchestration. Direct integration gives you full control over the checkout experience, the error states, and the visual flow, but it doubles the surface area of your integration work and means you must handle PayNow callbacks and GrabPay webhooks independently. A payment gateway such as Xendit, 2C2P, or Adyen aggregates both rails (and often cards and other wallets) behind a single API and a unified checkout interface. You call one endpoint, the gateway routes to the appropriate rail, and it returns a single result.

The gateway approach is the right choice for most merchants unless you have specific reasons to control each rail independently. The trade-off is slightly higher fees, gateways charge a margin on top of the underlying payment rail’s cost, and you become dependent on the gateway’s uptime and support quality. When evaluating a gateway, confirm that PayNow Server-to-Server and GrabPay are both in their supported methods list, that they offer an SGD settlement account, and that their documentation covers server-side callback handling in the language and framework you are using. For stores running on a custom stack, the team behind our website development service has built payment integrations across multiple platforms and can advise on the most maintainable approach for your particular setup.

The Step-by-Step PayNow Integration Process

Getting PayNow live involves moving through six stages in order. Skipping any of them creates problems that are harder to fix in production than in sandbox.

Stage 1: Bank Account and API Credential Setup

Contact your business bank’s corporate or cash management team and request PayNow Corporate API access. You will need your company’s UEN, your authorised signatories’ identification, and your existing corporate bank account details. Approval typically takes five to ten business days. Once approved, you receive API credentials, usually a merchant ID, a secret key, and endpoint URLs for the sandbox environment. Store the secret key in a secrets manager; never hardcode it into your application repository.

Stage 2: Configure Your Server Environment

PayNow requires a publicly reachable HTTPS endpoint that can receive POST requests from the PayNow server. This is your callback or notification URL. It must use a valid TLS certificate (HTTPS only, no self-signed certificates in production), respond with an HTTP 200 status quickly, and be idempotent, the PayNow server may retry delivery if your response is slow, so your endpoint must handle duplicate notifications gracefully. Create a dedicated route in your application, something like /webhooks/paynow, and verify that incoming requests carry a valid signature before processing the payload.

Stage 3: Build the Transaction Initiation Flow

When a customer reaches checkout and selects PayNow, your server must construct a PayNow transaction request. The minimum required fields are the merchant entity ID, the transaction amount, the currency (SGD), a unique order reference that you can map back to your internal order record, and your callback URL. Send this as a POST request to the PayNow initiation endpoint. A successful response contains a redirect URL. Store the PayNow transaction reference against your order before redirecting the customer, so that when the callback arrives you can match it to the right order.

Stage 4: Handle the Payment Callback

The PayNow server POSTs to your callback URL when the payment status changes, typically when the customer confirms the payment in their banking app. The payload contains the transaction reference, the status (success, failed, or pending), the amount, and a timestamp. Verify the signature in the payload header against your secret key. If the signature is invalid, log the request and do not act on it. If valid, look up your order using the transaction reference, check that the amount matches, and update the order status. Trigger your standard post-purchase flow: confirmation email, inventory deduction, and any downstream webhooks.

Stage 5: Build the Customer-Facing Return Page

After the customer confirms in their banking app, PayNow redirects them back to the return URL you provided. This page should show a clear payment status, confirmed, processing, or failed, and the next steps. Avoid showing a spinner indefinitely; poll your server for the latest order status and update the UI accordingly. A good return page also displays the transaction reference and amount so the customer can match it against their banking app’s notification, which reduces support tickets.

Stage 6: Test in Sandbox, Then Go Live

Use the PayNow sandbox environment to test every flow: a successful payment, a customer-initiated cancellation, an expired session, and a duplicate callback. Simulate each callback type by sending test payloads to your endpoint and verifying your application responds correctly. Only after your test suite passes should you swap the sandbox credentials for production credentials and place a small live transaction to confirm end-to-end flow before announcing the integration to customers.

The Step-by-Step GrabPay Integration Process

GrabPay’s flow follows a similar pattern but with different endpoints, webhook formats, and authentication mechanisms.

Stage 1: Merchant Account Creation and KYC

Apply for a Grab Merchant account through the Grab for Business portal. You will need to submit your business registration documents, UEN, bank account information, and details of your business activity. Grab reviews applications within a few business days. Once approved, log in to the Grab Developer Portal, create an application, and generate your API key pair and partner transaction ID.

Stage 2: Configure Webhook and Security Settings

In the Developer Portal, register your webhook endpoint, the HTTPS URL that GrabPay will POST payment status notifications to. Like PayNow, this endpoint must respond with a 200 status quickly and must verify the payload signature. GrabPay sends webhooks for successful charges, failed charges, chargebacks, and refunds, so your handler must cover all four cases. Test the webhook delivery from the portal before proceeding; failed webhook delivery is the most common cause of order status mismatches in production.

Stage 3: Implement the Checkout Session Creation

When a customer selects GrabPay at checkout, your server calls the GrabPay Create Order endpoint. The request body includes your partner transaction ID, the amount in SGD, the currency, an order reference, and your success and cancel redirect URLs. GrabPay validates the request, creates the order, and returns an order ID plus a redirect URL. Store the order ID and the GrabPay order reference against your internal order record before redirecting the customer.

Stage 4: Handle Redirect, Return, and Status Verification

The customer is redirected to the GrabPay checkout page or deep link. After they confirm, GrabPay redirects them to your success or cancel URL. Do not trust the redirect alone as a payment confirmation, a customer can close their browser before the redirect fires, or network issues can prevent it. Always call the GrabPay Check Status endpoint server-side using the order ID to retrieve the definitive payment state before updating the order and proceeding with fulfilment.

Stage 5: Handle Refunds and Post-Purchase Events

GrabPay supports refunds through the Refund API. Build a refund action in your order management system that calls this endpoint with the original order ID and the refund amount. Verify the refund webhook to update your order status when GrabPay confirms the refund has been processed. Handling refunds correctly is especially important for GrabPay because customers often contact support when they do not see their wallet balance update promptly, and clear communication prevents escalation.

Security, Compliance, and Data Handling Requirements

Payment integrations in Singapore operate under the oversight of the Monetary Authority of Singapore (MAS) via the Payment Services Act. If your store processes more than S$1,000 in monthly payment volume through these rails, certain licensing and compliance obligations may apply depending on your business structure. Most e-commerce stores avoid direct licensing requirements by routing through licensed payment gateways, but you should still confirm your situation with a compliance professional.

On the technical side, follow these non-negotiable practices. Never log full card numbers, wallet tokens, or authentication codes. Store API keys and secret keys in a secrets manager such as HashiCorp Vault or your cloud provider’s key management service; environment variables are acceptable for development but not for production. Use HTTPS on every endpoint, including your callback and webhook URLs. Verify the signature on every incoming PayNow notification and GrabPay webhook before processing the payload. Implement idempotency keys on your order creation endpoint so that a double-submitted payment request does not create a duplicate order. Log every payment event, initiation, callback received, status confirmed, refund issued, with timestamps and request IDs so that disputes can be resolved quickly.

Display your refund policy, delivery timelines, and contact details prominently on the checkout page. MAS guidelines and the Consumer Protection (Fair Trading) Act both require transparent disclosure of key terms before a customer commits to a purchase. A customer who cannot find your refund policy is less likely to complete the transaction, and a customer who disputes a charge will hold you responsible for any lack of clarity.

Testing Your Integration Before Going Live

A payment integration that works in your development environment but fails in production is one of the most expensive mistakes an e-commerce store can make. Test every scenario before you route live traffic through the new checkout.

Start with happy-path testing: complete a full payment using each PayNow bank app and the GrabPay app, confirm that your callback and webhook handlers update the order correctly, and verify that the customer receives the confirmation email and that the order appears in your admin dashboard with the right status. Then test failure states: cancel the payment from the banking app before confirming, let the session expire, simulate a slow callback response, and interrupt the redirect. Each of these should result in a clean customer-facing message and a correctly abandoned order, not a stuck order in a pending state that requires manual intervention.

Load test your callback and webhook endpoints. PayNow and GrabPay will retry failed callbacks, and a spike in traffic, for example, during a sale or a promotional campaign, can produce a burst of simultaneous webhook calls. Confirm your endpoint handles concurrency correctly without creating duplicate order updates or exhausting your database connection pool. If you are building the integration as part of a broader platform build, this kind of robustness is where web design and development expertise makes a measurable difference, because the payment layer sits at the intersection of frontend UX, backend reliability, and compliance.

Optimising the Checkout Experience After Integration

Adding PayNow and GrabPay buttons to the checkout page is the technical milestone, but the work is not done when the integration goes live. The placement of payment options, the clarity of the labels, the number of form fields required before payment, and the error messages displayed when something goes wrong all determine whether customers actually use the new options.

Put PayNow and GrabPay at the top of the payment method list, above card options, for domestic Singapore customers. Use the official PayNow and GrabPay brand marks, these are recognised instantly and signal that the checkout is legitimate. Keep the checkout to a single page or a short two-step flow; every additional field between the customer and the PayNow or GrabPay button adds friction. Pre-fill the customer’s name and email from their account or from the first step of checkout so that the only fields remaining at the payment step are the shipping address and the payment selection.

Monitor the split between PayNow, GrabPay, and your other payment methods after launch. If PayNow consistently accounts for a majority of completed orders, consider making it the default selected option for returning Singapore customers. If GrabPay usage is low, review whether your GrabPay onboarding messaging is clear enough, many customers do not use GrabPay simply because they have not funded their wallet, and a brief explanation of how to top up can unlock that segment.

For businesses that need to go beyond a standard checkout into custom functionality, course purchases with tiered access, membership signups with recurring billing, or multi-vendor marketplaces, the integration becomes significantly more complex. A practical example is the work we did for KV School of Psychology, a psychology school in Chennai that needed a custom e-learning marketplace with student registration, login, course purchase, a learning management system with lecture view restrictions and interactive quizzes, and automated certificate generation. That project required stitching together payment processing, user authentication, content delivery controls, and progress tracking, the kind of layered system where the payment integration is one of several interlocking pieces.

Frequently Asked Questions

How long does it take to integrate PayNow and GrabPay into an existing e-commerce store?

The timeline depends on whether you are connecting directly to each rail’s API or routing through a payment gateway. A direct PayNow integration, from bank application to live callback handling, typically takes three to four weeks, the bank approval step alone accounts for most of that time. GrabPay merchant onboarding runs in parallel and usually completes within one to two weeks. If you route both through a payment gateway like Xendit or 2C2P, the onboarding time drops to one to two weeks because the gateway already has the bank and Grab relationships in place and exposes a single API. The remaining implementation time for either approach is roughly five to ten working days of development, depending on your store’s complexity and how cleanly your checkout code is structured.

Do I need a separate bank account for PayNow and GrabPay transactions?

No. PayNow settles directly into the corporate bank account that you registered the PayNow Corporate Account against. GrabPay settlements are made to the bank account you designate in your Grab Merchant account settings. You can, and usually should, use the same corporate bank account for both. The key thing to confirm is that your bank is a PayNow participant and that GrabPay supports settlement into your chosen bank. All major Singapore banks are PayNow participants, and GrabPay settlement covers all major local banks, so this is rarely a constraint.

Can I offer PayNow and GrabPay on a Shopify or WooCommerce store?

Yes. Shopify supports PayNow through its Shopify Payments configuration in certain regions and through third-party payment apps that bridge PayNow into the Shopify checkout. WooCommerce has PayNow plugins available that handle the server-side callback and order status updates. GrabPay is supported on both platforms through official or community plugins and through payment gateway integrations. Before installing any plugin, verify that it supports the PayNow Server-to-Server rail specifically, some plugins only support PayNow QR, which is designed for point-of-sale and will not work in an online checkout context. Review the plugin’s update history and support responsiveness, because payment plugins that are not maintained can break during API version updates.

What happens if a PayNow or GrabPay payment fails after the customer confirms?

With both PayNow and GrabPay, a payment that the customer confirmed in their app should not fail at the merchant level unless there is a genuine technical issue, insufficient wallet balance for GrabPay, for example, will be caught before confirmation and the customer will see an error in their app. If the callback or webhook is delayed and your server does not receive the status update promptly, do not treat the order as failed. Build a polling mechanism that checks the payment status with PayNow or GrabPay if the callback has not arrived within a configurable timeout window, such as two minutes. Display a processing state to the customer during this window with a clear message that you are confirming their payment. Only mark the order as failed if the status check explicitly returns a failure state.

Are there fees I should budget for beyond the transaction charges?

The main cost components are the PayNow Corporate Account fees, which are typically bundled into your existing corporate banking package and may be zero for the PayNow rail specifically, and GrabPay’s per-transaction fee, which varies by merchant volume tier but generally falls in the range of one to two percent of the transaction value. If you route through a payment gateway, add the gateway’s margin, which is usually expressed as an additional percentage on top of the underlying rail. There are no setup fees from PayNow or GrabPay themselves, but your bank may charge a fee for the corporate API account application. Budget for potential development costs if you are building a custom integration, and factor in ongoing maintenance when the APIs are updated, which happens periodically.

How do I handle refunds when the original payment was made via PayNow or GrabPay?

PayNow refunds are initiated through your bank’s corporate banking portal or API. You will need the original PayNow transaction reference and the customer’s registered mobile number or NRIC to process the refund. GrabPay refunds are handled through the GrabPay Refund API, which requires the original order ID and the refund amount. In both cases, the refund reaches the customer’s bank account or GrabPay wallet within one to three business days. Build a refund action into your order management interface that captures the necessary identifiers, initiates the refund through the appropriate channel, and logs the refund transaction for your records. Notify the customer by email with the refund reference number and an estimated arrival time, this reduces the volume of incoming support queries during the refund processing window.

Can I run PayNow and GrabPay alongside my existing payment methods without rebuilding my checkout?

Yes, and this is the most common integration pattern. You do not need to replace your existing payment infrastructure. Add PayNow and GrabPay as new payment method options in your checkout alongside whatever you already offer. The integration code for each method is isolated, PayNow has its own initiation and callback flow, GrabPay has its own, and they do not interfere with each other or with your existing card processing. The main architectural consideration is your order status management system, which must be able to handle payment confirmation events from multiple sources and update the order state correctly regardless of which rail the customer used.

What happens if PayNow or GrabPay update their API and my integration breaks?

API version changes by PayNow and GrabPay are announced in advance through developer portals and email notifications to registered merchants. The key to managing this risk is keeping your integration code modular, separate the API client code (which makes the actual HTTP requests) from your business logic (which processes the result and updates orders), so that when an API change is announced, you can update the client code in one place without touching your order management logic. Subscribe to the developer mailing lists for both PayNow and GrabPay. Assign someone on your team to review change notifications quarterly and schedule integration tests against the sandbox when an update is announced. A payment integration that is not actively maintained will eventually break, and the failure will happen during peak traffic unless you are proactive.

Planning Your Next Steps

Integrating PayNow and GrabPay into your e-commerce checkout is a project with distinct phases: bank and merchant account onboarding, API credential setup, implementation of the initiation and callback flows, sandbox testing, and production launch with monitoring in place. Each phase has its own timeline and dependencies, and the bank onboarding step for PayNow is almost always the longest pole in the tent, so start that process first even if your development work is not ready.

The quality of the implementation matters as much as the fact of having it. A PayNow integration that redirects correctly but handles callbacks poorly, missing an order update, sending a duplicate confirmation email, or failing silently, creates more support work than it saves. The same is true for the checkout experience surrounding the payment buttons. If the page feels slow, the labels are unclear, or the error states are confusing, customers will abandon the payment even though the underlying integration is technically sound.

If you are planning a new e-commerce store or a checkout redesign that includes PayNow, GrabPay, and other payment rails, reaching out early lets your team account for the payment integration requirements in the site architecture from the start rather than bolting it on as an afterthought. Getting the structure right during the design and build phase is always faster and cheaper than retrofitting it later.

Monk Creatives is a full-service creative agency specialising in web design and development, branding, social media, photo and video production, and print. Based in Chennai, we work with brands internationally and have offices planned across multiple markets. If you are building or redesigning an e-commerce store and need support integrating PayNow, GrabPay, and other payment methods, reach out at our contact page or email info@monkcreatives.com, we would be glad to discuss your project.