Food court system: cash card or QR ordering?

A food court system exists to do one thing well: record exactly what each stall sold, so the court can take its share and pay the stall the rest. Everything else, the cards, the terminals, the cashier counter, is plumbing for that one number. In Thailand the classic food court system is a top-up cash card, and it has lasted because it solves the money problem reliably. It also ties up a staffed counter, a float of cash, and a few hundred thousand baht of hardware. QR ordering now does the same job in a different way, and for a lot of courts it is the cheaper one.

This guide is for food court and food hall operators weighing the two: how the card system really works, what it costs a 12-stall court, why settlement matters more than payment, and where each approach is the honest right answer.

How a food court system works in Thailand today

Most Thai food courts still run on the same model. Stalls do not take cash. Guests buy coupons or load a card at a counter near the entrance, spend it at the stalls, and refund what is left at the same counter on the way out.

Modern versions use RFID cards instead of paper coupons. A guest hands over cash, the cashier loads it, and some courts hold back a small deposit so cards come home: one vendor's example is a ฿10 deposit, so ฿100 loaded gives ฿90 to spend with the ฿10 returned with the card. At the stall, the vendor keys in the price and the guest taps. The same vendor quotes under five seconds a sale.

The point of all this is not convenience for the guest. It is control for the court. Because every baht enters through one counter and leaves through a stall terminal, the court has a trustworthy record of each stall's gross sales, and it holds the cash. That is what lets it run on revenue share instead of rent.

What a food court card system costs

Pricing in this market is mostly on request, but at least one Thai vendor publishes a full list. ClipAcc lists its food court card software at ฿15,000 per shop, an RFID stall terminal with display at ฿15,800, and printed RFID cards at ฿30 each. The cashier station is a PC at ฿22,000, a thermal printer at ฿8,000, a cash drawer at ฿3,800, an RFID reader at ฿3,000 and a customer display at ฿4,000.

Run that for a modest 12-stall court:

• Stalls: 12 × (฿15,000 software + ฿15,800 terminal) = ฿369,600
• One cashier station: ฿40,800
• Cards: 2,000 × ฿30 = ฿60,000
• Total up front: about ฿470,400

That is before the running costs nobody puts on the quote. Someone has to staff the card counter every hour the court is open, and on a weekend lunch rush that is usually two people. There is a cash float to manage and reconcile, refunds to hand back at close, and cards that walk out of the door with guests. None of these are deal-breakers. They are simply the real price of the card model, and they are worth writing down before you compare it with anything else.

The card's real job is settlement

Food courts in Thailand mostly charge stalls GP, a share of sales, rather than fixed rent. It is negotiated court by court, but published examples sit around 20 to 30% of sales, and the stall waits for the court to settle. In that same example the stall was paid 15 days after the sales period closed.

Here is what that looks like for one stall. A noodle stall sells ฿120,000 in a month. At 25% GP the court keeps ฿30,000 and owes the stall ฿90,000. For that to work without arguments, three things have to be true:

1. The stall believes the ฿120,000. If the vendor suspects sales are missing, every settlement turns into a negotiation.
2. The court can produce it quickly. A per-stall report at close, not a spreadsheet rebuilt from paper on the 3rd of the month.
3. The stall records it properly. The same source notes that a stall should book the full ฿120,000 as sales and the ฿30,000 GP as an expense, not just the ฿90,000 it received, because VAT is calculated on gross sales.

This is why "which card system" is the wrong first question. The right one is which system gives you a per-stall gross figure that both sides trust, at close, with refunds and cancellations already reflected.

Where cash cards are still the right call

There are courts where the card model is simply correct, and saying so is more useful than pretending otherwise:

• Cash-heavy guests. If a large share of your guests pay in notes, a card counter takes their money and a phone payment does not.
• Staff canteens and hospitals. Many card systems let an employer load welfare credit onto staff cards in bulk, and the same ClipAcc page describes general cards that reset to zero daily while staff cards carry over. That is a payroll benefit as much as a payment method, and QR ordering does not replace it.
• Guests without a usable phone. Schools, some older demographics, some tourist sites. If scanning a code is a conversation every time, the code is not saving anyone time.

Straight disclosure, since this is our blog: Papaya does not sell a prepaid food court card or a stored-value top-up system. If the list above describes your court, a card vendor is the right supplier.

What QR ordering changes in a food court

If your guests sit down with a phone in hand, the picture shifts. With Papaya Order, the court puts its QR code on the tables. A guest scans it with no app to download, sees the list of stalls, opens each stall's menu, and builds one basket across several of them: noodles from one, som tam from another, drinks from a third. They pay once, by PromptPay, card or whichever methods the court has switched on through Papaya Pay.

After payment, each stall gets an order containing only its own items, printed on that stall's own printer, so the cook never has to read past someone else's dishes. If a stall sells out of something, it greys out on the guest's menu instead of being ordered and refunded.

The practical differences from a card counter:

• No card counter in the critical path. No float, no top-up queue, no refund line at close, no cards lost.
• Bigger baskets are easier. A group no longer splits up to queue at four counters. They order from their seat.
• Each stall's share is recorded as the guest pays. On a combined payment, Papaya records a payment against each stall's own order for exactly what that stall's items cost. That is the per-stall number settlement depends on, produced at the moment of sale.

And the honest limits. A phone payment will not take a ฿1,000 note. The guest browses one stall's menu at a time rather than one merged menu of the whole court. Guests still collect from the stalls the way your court already runs pickup. And each vendor needs to be set up on Papaya with its own menu, which takes some onboarding, though a stall can work from printed tickets rather than a screen.

Two ways to handle the money with QR ordering

This is the part to get right before launch, because it decides how settlement works.

Option 1: the court collects, then settles. The guest pays one combined bill into the court's payment account. Papaya splits that payment on paper, recording each stall's share against its own order, and the court gets a payouts report to work from. The court then deducts its GP and transfers each stall's balance on whatever schedule it already uses. To be plain about it: Papaya does not move money to the vendors for you. It gives you the numbers. The transfer is still yours.

Option 2: each stall is paid directly. With single-outlet checkout switched on, a guest's basket is limited to one stall, and the order is charged to that stall's own payment account. The money lands with the vendor, and the court invoices its GP afterwards. You give up the multi-stall basket, but the court never holds vendor money at all, which some operators prefer.

Neither is wrong. Option 1 is closer to how card courts already work. Option 2 suits a food hall where vendors are established businesses that want their own takings.

Running both while you switch

You do not have to choose on day one. Plenty of courts run the card counter for cash guests and staff, and put the QR code on the tables for everyone else. What matters is that the two do not create two versions of each stall's sales. Before you start, agree how a stall's card sales and QR sales combine into the one figure its GP is calculated on, and who produces that figure each month.

Six questions to ask any food court system vendor

1. Show me the per-stall report. Gross sales, refunds, cancellations, by stall, for yesterday. If it takes a spreadsheet to produce, keep looking.
2. How does a refund flow through it? Card balance, a cancelled QR order, a stall that closed early.
3. Who holds the money, and how long does a stall wait? Fifteen days is common. Your vendors will ask.
4. What does it cost per stall, all in? Software, terminal, cards, and the staff the model needs.
5. What happens with cash? If you still need a cashier for cash guests, price that in either way.
6. Can I get my data out? Per-stall sales should export cleanly, because your accountant and your vendors' accountants both need them.

Most Thai food court operators who run through this list find their answer quickly. If cash and staff credit dominate, cards are still the right tool. If your guests sit down, pay by phone, and your vendors mostly want a figure they trust at close, QR ordering removes the counter and keeps the number. Either way, settle the report question first, and the rest of the decision gets much shorter.

Frequently asked questions

Buy the settlement, not the card

Food court operators tend to shop for a payment gadget: a card, a terminal, a kiosk. The thing they are actually buying is a number. Every month each stall needs a gross sales figure it believes, the court needs its GP out of that figure, and both need it fast enough that nobody is chasing money between counters. Cards produce that number by forcing every baht through one counter. QR ordering produces it by recording each stall's share as the guest pays. So start your evaluation at the end of the month, not at the till. Ask any vendor, us included, to show you the per-stall report, how a refund flows through it, and how long a stall waits to be paid. If the answer is clean, the hardware question mostly answers itself.