QR Payments Confirmed by Customers but Missing From Merchant Records: Reconciliation Challenges for Singapore Businesses

A customer shows a “payment successful” screen on their phone. The merchant checks the dashboard or bank statement and sees nothing that matches. Is the customer wrong, is the system late, or has the money arrived under a different reference? In Singapore, where PayNow and SGQR are used everywhere, this scenario is common enough that it deserves a process of its own.

Why QR Payments Cause Reconciliation Problems

The payment itself is usually fine. The difficulty is matching it to the right order or invoice.

• The customer’s screen proves very little: The customer’s app shows that their bank sent the payment. It doesn’t prove how the merchant’s system recorded it.
• Confirmation is asynchronous: One integration guide notes that PayNow transactions are asynchronous: the customer scans and pays, but the confirmation event reaches the merchant’s server via webhook, not through a synchronous API response. If the webhook is delayed or fails, the order looks unpaid.
• Matching depends on references: Without a reliable link between payment and order, finance teams fall back on manual work. One provider describes how a finance team must manually open the bank statement, look at each incoming transfer, and try to match the amount and the customer-entered reference to a specific order before marking the invoice as paid.
• Volume multiplies the problem: A handful of unmatched payments per day is manageable. Hundreds is not.

Static vs Dynamic QR: The Biggest Single Factor

How the QR is generated largely determines how hard reconciliation will be.

• Static QR. It contains only your UEN, and the customer must manually enter the payment amount and reference. That means wrong amounts, missing references, and typos. It’s convenient for a shopfront, but it puts matching work on you.
• Dynamic QR. One processor explains that it generates a unique QR for each transaction tied to a specific amount, enabling automated reconciliation. Another notes that each payment is linked to a unique reference number, making it straightforward to match payments to orders in a database.
• Trade-off. Dynamic QR needs a system that generates it per order, either through a payment provider or a plugin. Static QR needs nothing but costs you time later.
• SGQR doesn’t change this. SGQR is a unified QR standard that consolidates multiple payment schemes, but one provider’s comparison notes that with a static label, reconciliation is manual per scheme, while dynamic QR via an app or terminal can be consolidated through a platform.

Common Reasons a Confirmed Payment Doesn’t Appear

1. The customer changed the reference

• Some systems rely on a reference embedded in the QR. Fazz’s support page explains that when the sender scans the QR code, their banking app should automatically populate the transaction reference in the remarks field, and the problem occurs when the sender changes it. In that case, the provider can’t link the payment, and the funds are automatically credited to your account using the Virtual Account method, so you must manually update the payment status.
• Another Fazz document says it doesn’t expect delays unless a customer changes the reference code embedded in the PayNow QR code, in which case the provider contacts you to resolve it.
• Fix: tell customers not to edit the remarks field, and put that instruction next to the QR.

2. The sender’s bank rejected or reversed it

• Fazz also notes that the sender’s bank may have declined the transaction before it reached the provider, and suggests asking the sender to check their app for reversal or cancellation notices.
• Some screens can look like success before the final status. Always check the app’s transaction history, not just the confirmation animation.

3. A webhook or callback failed

• Providers recommend that, for payment methods that require the customer’s action, you set up callbacks to be notified whether payment has succeeded or not.
• Common technical causes: endpoint downtime, signature validation errors, timeouts, or events processed out of order. Build a retry queue and a periodic reconciliation job that checks the provider’s records directly.

4. The QR expired or the payment was made to the wrong code

• Dynamic QR codes can expire or be cancelled. If a customer pays an old or wrong QR, the order may not match.
• Stripe notes that when a QR expires, the customer would need to initiate a new payment session where a new QR code is generated. Handle expiry and re-presentation without creating duplicate orders.

5. Wrong amount

• With static QR, customers can type the wrong amount, causing a partial or excess payment that doesn’t match an invoice.
• Dynamic QR reduces this, though it depends on how your provider handles amount edits.

6. Timing differences

• Funds may appear in the provider’s balance before they’re paid out to your bank. One Stripe answer, for example, explains that on a weekly (Monday) payout schedule, the funds are paid out on the coming Monday. A merchant looking at the bank statement may not see a payment that has already been confirmed in the provider’s dashboard.
• Bank statements may show batched or net amounts, not individual payments. Reconcile against the provider’s settlement report.

7. The “payment” never happened

• Fake screenshots are a real risk. Fazz warns that scammers have used fake PayNow payment confirmations to trick service providers, and advises that you should always double-check your account to confirm the payment has been received instead of relying on what the sender shows. Train staff, especially for high-value goods, never to release goods on a screenshot alone.

What Direct Bank PayNow Merchants Face

Merchants using PayNow Corporate directly through their bank, without a gateway, have fewer automation tools.

• Bank-side visibility. DBS describes incoming PayNow transactions as appearing in real time on DBS IDEAL with payer name and reference details for easy reconciliation, with optional email alerts. That’s one bank’s description of its own platform. Features differ by bank.
• SMS or email alerts as the notification. One WooCommerce plugin’s documentation says the flow is that your bank confirms the payment (most send an SMS), and you mark the order as paid. That’s a manual step prone to delay and error.
• Plugin-assisted reconciliation exists for small shops. The same plugin offers a reconciliation screen to confirm or flag PayNow orders as paid, with single and bulk actions.
• The risk: if matching depends on a person reading an SMS, payments get missed, double-confirmed, or confirmed for the wrong order.

A Practical Reconciliation Process

Prevent mismatches

• Use dynamic QR for online orders and invoices wherever possible, with a unique reference per payment.
• Pre-fill the amount and reference, and tell customers not to change the remarks field.
• Set clear expiry times and handle re-generation.
• Show a “payment pending” state instead of “failed” while you wait for confirmation.
• Avoid asking customers to type references unless there’s no alternative.

Detect mismatches quickly

• Use webhooks and callbacks, and monitor delivery failures.
• Run a scheduled job that checks the status of all pending orders directly with the provider.
• Compare three sources daily: your order system, the provider’s transaction report, and the bank statement.
• Flag unmatched incoming payments and unpaid orders for review, with an aging report.

Resolve mismatches

• Ask for the right evidence. A transaction reference or timestamp from the customer’s banking app history. Don’t accept a cropped screenshot alone.
• Search by amount and time window, not only by reference.
• Check the provider’s virtual account or unallocated funds area, where unmatched payments may land.
• Match and mark manually with an audit trail (who, when, why).
• Contact the provider with the transaction details if funds can’t be found.
• Set a service-level target for resolving unmatched payments, and tell customers what to expect.

Reduce fraud exposure

• Confirm receipt in your own account or dashboard before releasing goods or services.
• Train frontline staff on fake confirmation screens.
• Set stricter checks for high-value orders.

Questions to Ask Your Provider or Bank

• Is the reference embedded in the QR, and what happens if the customer edits it?
• Where do payments with missing or changed references go, and how do I see them?
• How quickly do webhooks arrive, and what is the retry policy?
• Can I query payment status by reference through an API?
• How are payouts timed relative to confirmation, and what does the settlement report show?
• What reconciliation reports can I export?
• How do I handle expired QR codes and duplicate payments?
• For direct bank PayNow: what notifications and statement detail does my bank provide, and can they be automated?

Final Thoughts

When a customer says they paid and your system disagrees, the cause is usually a reference problem, a notification gap, or a timing difference. Occasionally it’s fraud. Dynamic QR codes with unique references and reliable webhooks prevent most of it. For the rest, a daily three-way check and a standard process for chasing unmatched payments keep small gaps from turning into lost money or unhappy customers.