QR Ordering in Singapore: What It Actually Costs (2026)

Search "QR ordering system Singapore cost" today and the best-ranked local answer is an article published in March 2022, quoting figures its own footnote dates to 2021 and a government grant rate of 80 per cent. That rate has not existed since April 2023, when the Productivity Solutions Grant was capped at 50 per cent of qualifying cost. Everything else on the first page is a global QR-menu vendor quoting US dollars for a market that is not this one.

So the honest starting point is that the question is badly served. This article answers it with numbers that were verified on 31 August 2026, each with a source, and it puts them in the order that actually matters — which is not the order vendors present them in.

Because here is the finding that reorders everything: for a typical outlet, the payment rail costs two to ten times more per month than the software subscription. Almost every comparison you will read is an argument about the small number.

What "QR ordering" actually means — three different products

The phrase covers three things with very different price tags, and vendors are not always careful about which one they are selling you.

• A static menu QR. A sticker that opens a PDF or a web page. The customer still calls a server to order. This is free to almost free, and it is not what anyone means by QR ordering any more.
• QR ordering without payment. The customer builds an order on their phone; it lands in the kitchen or on the POS; the customer pays at the counter or when the bill is brought over. You save the order-taking trip. You do not save the payment trip.
• QR ordering with payment. The customer orders and pays on their own phone, and the order reaches the kitchen only once the money is confirmed. This is the version that changes your floor staffing, and it is the version that introduces a payment fee on every single order.

The jump from the second to the third is where the cost model changes shape. Everything below assumes the third.

The five costs, largest first

1. Payment fees — the number that dominates

In-store card acceptance in Singapore generally runs 2.8% to 3.4% plus around S$0.50 per domestic transaction across mainstream gateways (SingSaver and Wise 2026 guides, both retrieved 31 Aug 2026). PayNow is far cheaper, commonly 0.65% to 1.3%.

For published, checkable numbers, Qashier lists its merchant discount rates openly on its Singapore MDR page: in-store PayNow from 0.4%, Visa/Mastercard from 1.8%, e-wallets from 1.25%, buy-now-pay-later from 5.5%. Online — which is the relevant column for a customer paying on their own phone — PayNow from 0.8% and cards from 2.4% plus S$0.20. All excluding GST, which is 9% in Singapore.

Now put a plausible outlet through that. Average order S$12, one hundred self-ordered tickets a day, so roughly S$36,000 a month through the QR channel:

• Paid by PayNow at 0.8%: about S$288 a month in fees.
• Paid by card at 2.4% + S$0.20: about S$1,464 a month in fees.

The same volume, the same software, a difference of nearly S$1,200 a month decided entirely by which rail your customers tap. Over a year that is the price of a small car. This is why the current shift matters: after a parliamentary reply from MAS on how card merchant service fees are constructed, Singapore retailers have been actively moving volume toward QR rails, and MAS and IMDA are extending SGQR into SGQR+ so merchants can accept more local and cross-border schemes through a single acquirer (Retail Insight Network, 9 April 2026).

The practical instruction: when you evaluate a QR ordering vendor, ask what the PayNow rate is and whether PayNow is presented to the customer _first_. A system that defaults to card on the payment screen will quietly cost you four figures a month.

2. Software subscription — smaller than you think, and now hard to compare

Verified 31 August 2026:

• Qashier (Singapore) has moved to a single price: S$5 a day, roughly S$152 a month excluding GST, with QR ordering, table ordering, KDS, delivery-platform integration and loyalty all included and no feature tiers. Capped at 3 devices, 10 staff accounts and 3 back-office logins per store. Terminal adds S$1/day; kiosk adds S$2/day (source).
• RestoSuite publishes package prices on sg.restosuite.ai: Lite $1,200, Essentials $2,980 (POS + QR ordering + Android POS hardware + training and installation), Professional $5,280, Suite $8,580. Note carefully: the page states neither the currency nor the billing period, so these cannot be compared to a monthly figure without asking.
• iCHEF lists US$100/month on its global pricing page, while its Singapore blog states S$99/month.
• StoreHub publishes US$39 / US$79 / US$149 tiers — in US dollars, for a Singapore buyer.
• Eats365 does not publish pricing.
• MakanCloud publishes S$59 / S$129 / S$199 / S$299 per month in Singapore dollars, with QR self-ordering included at every tier; the tiers differ by outlet and terminal count, not by features. Our pricing page shows the full table.

Two observations rather than a verdict. First, comparing these is genuinely hard: one is a daily rate, one is a package price with no stated period, two are in a foreign currency, one is unpublished. That difficulty is itself a cost — every hour you spend normalising vendor quotes is an hour you are not running the shop. Second, we are not the cheapest per outlet at every size and we do not claim to be; at one outlet the field is tightly bunched around S$60 to S$152 a month.

3. Hardware — one-off, and smaller than the brochure suggests

QR self-ordering runs on the customer's phone, so the hardware bill is about what happens _after_ the order.

• A payment terminal, if you also take physical cards: published Singapore prices start around S$299 for a full terminal and S$199 for a scan-to-pay soundbox (Qashier MDR page, 31 Aug 2026).
• A kitchen printer per station, or a screen if you run a kitchen display instead. If you already print dockets, you already have this.
• A screen for the kitchen display, if you want one. Any cheap tablet or an old monitor with a stick PC will do; this is the line item where people over-buy.

If you are already operating with a POS and a printer, adding QR ordering is frequently a zero-hardware change. Treat any quote that bundles mandatory hardware into a QR ordering package as a quote you should itemise.

4. Table decals and reprints — trivial money, recurring annoyance

Each table needs a code, printed and stuck down where a phone camera can reach it without moving the condiments. The printing cost is negligible. The recurring cost is that you reprint them whenever table numbering changes, whenever a decal gets scrubbed off during cleaning, and whenever an outlet reshuffles its floor. Budget for reprints as an ongoing chore rather than a one-time job, and make sure your system lets you regenerate a single table's code without regenerating all of them.

5. Setup labour — the cost nobody quotes

The largest one-off input is entering the menu: every item, price, modifier, station routing and photograph. This is not a hidden trick of any one vendor; RestoSuite's own team page has a project manager whose listed job description is "Keying in your menu at the moment..." — which is an unusually honest bit of website copy about where the first two weeks go.

A realistic first fortnight looks like this: menu entry and photographs, then a table map and one code per table, then a dry run at a handful of tables during a quiet service, then a decision about which payment rails appear on the customer's screen, then rollout to the rest of the floor. The dry run is not optional. It is where you discover that your Wi-Fi does not reach the corner tables.

Where QR ordering fails in practice

These are the failure modes that decide whether the thing survives its third month. Ask every vendor how their system handles each one, and be suspicious of a quick yes.

• Abandoned orders locking tables. A customer scans, browses, and leaves without paying. If the order occupies the table the moment it is created, your floor map fills up with ghosts by 8pm. The order should not hold the table until money is confirmed.
• Two people at one table, two bills. A pays, and then B — on their own phone, at the same table — sees A's order, or worse, cannot order at all. Splitting within a shared table session is the single most common thing that is demoed badly and breaks on day one.
• The customer paid and the floor does not know. With a static payment QR and an "I have paid" button, you are trusting the customer. Someone will tap it without paying. Either the payment is verified before the kitchen sees the order, or a staff member has to check every single one — which reintroduces the labour you were removing.
• The kitchen prints the same ticket twice. Two devices both listening for new orders, both printing. Deduplication has to be enforced on the server, at the moment of claiming the ticket. Doing it in the app is a race condition waiting for a lunch rush.
• Last night's orders still on this morning's table. If a table's session is never closed, the next customer scans and sees a stranger's food. The session must reset when the table is cleared, and there should be a time-based fallback for when nobody clears it.
• The customer's phone cannot reach your printer. Their phone is on mobile data, outside your shop network. Whatever prints in your kitchen must be triggered by a device inside the shop, not by the diner's handset. Systems that get this wrong appear to work in the demo and silently drop tickets in production.

Where MakanCloud fits

We build QR self-ordering into every tier, and the six failure modes above are not a hypothetical checklist — each one is something we hit in a live outlet and had to fix, which is why we can be specific about them.

Concretely: orders sit in a pending state and do not occupy the table until payment is confirmed; a shared table session tracks who ordered what so one diner can pay for their own items or for the whole table; kitchen ticket deduplication is enforced server-side with an atomic claim; table sessions reset on clearing with a time-based fallback; and printing is triggered from an in-shop screen rather than the customer's phone.

On payments, we will say only what has been proven in service: our YeahPay integration — QR and physical card terminal — has been running in a real paying outlet's daily trade, including settlement, refunds and end-of-day reconciliation. "Running in live service" is a weaker-sounding claim than "supports every payment method", and it is the one we can actually stand behind.

What we do not have, stated plainly: no loyalty or stored-value points programme, no GrabFood or foodpanda integration, no online reservations, and no floor-standing self-order kiosk hardware. If a delivery-platform integration is decisive for you, several competitors above have it and we do not. That is a real gap and you should weigh it.

The short version

• The subscription is the small number. At S$36,000 a month through the QR channel, the gap between paying by PayNow and paying by card is roughly S$1,200 a month — several times the entire software bill.
• Ask for the PayNow rate, and ask which rail appears first on the customer's payment screen.
• Singapore QR ordering software sits roughly between S$59 and S$152 a month per outlet where it is published at all; two of the six vendors here publish something you cannot directly compare, and one publishes nothing.
• Hardware is often zero if you already run a POS and a printer. Itemise any bundle that says otherwise.
• Budget the first two weeks for menu entry and a real dry run, and interrogate the six failure modes before you sign anything.

For the wider system comparison this sits inside, see Best Restaurant POS System in Singapore (2026). If you would rather read this in Chinese, the companion piece is 餐厅扫码点餐系统新加坡落地指南 — it covers the rollout sequence in more operational detail.