Payments and POS for Restaurants

Why restaurant payments are different

Most retail payments are one finished transaction. A customer taps, the amount is final, the sale is done. A restaurant almost never works that way. The amount at the moment the card is read isn't the amount you'll actually be paid, because the tip has not been written yet. One table may pay on four cards. A bar tab may sit open for three hours. A delivery order arrives with no card and no cardholder in the building.

Every one of those is a normal night in a restaurant and an edge case to a payment system. That's why a setup that works fine for a gift shop can quietly cost a restaurant money, and why it's worth understanding the mechanics before you compare providers.

Tips and tip adjustment

When a server runs a card at the end of a meal, the card is authorized for the pre-tip amount. The customer then writes a tip on the slip, the server enters it, and the higher final amount is captured when the batch closes that night. This gap between the authorized amount and the captured amount is called tip adjustment, and it's the single biggest mechanical difference between restaurant processing and ordinary retail.

The card networks allow restaurants to capture more than they authorized, precisely because the tip is expected. What they don't do is allow it without limit. There's a tolerance above the authorized amount, and going beyond it can cause the transaction to be treated differently or, in the worst case, be disputed successfully by the cardholder.

Settle every day. Tip-adjusted transactions need to be batched promptly. A batch left open past the window your processor requires can cause transactions to be downgraded into a more expensive interchange category, which is a cost you never see coming because nothing about the sale looked wrong at the time. Closing out nightly isn't bookkeeping tidiness, it's money.

On-screen tipping changes the math. If the customer taps a tip on a screen before the card is read, the amount is final at authorization and there's no adjustment at all. That removes the tolerance question and the downgrade risk entirely. It's one reason quick-service and counter-service restaurants have an easier time of it than full-service, and one reason handheld terminals at the table are worth looking at.

Getting tips to staff. Card tips arrive in your deposit, not in your staff's pockets, so you need a decided answer for how they get paid out: cash at the end of the shift, added to payroll, or through a tip-management feature in the POS. Ask how a platform handles tip pooling and shared tips if you split between front and back of house, because this is handled quite differently from one system to the next.

Tableside and handheld payments

A handheld terminal that goes to the table, rather than a card that goes to a station, changes several things at once. The card never leaves the customer's hand, which people increasingly expect. The tip is entered on screen, which removes the adjustment problem above. And the table turns faster, because the walk to the terminal and back is gone.

Handhelds also cut down on walkouts and mis-keyed tips, and they let a server close a check while standing at the table instead of waiting at a station during a rush. Platforms like Clover and Square both make handheld devices built for this, and both will run the same check and the same menu as the stations on your counter, so you aren't maintaining two systems.

Check your floor before you buy. Handhelds live or die on connectivity. A stone-walled dining room, a patio at the far end of the building, or a basement bar can all leave a device without a usable signal. Ask how the device behaves when it drops off the network: some will store a transaction and forward it when the connection returns, others simply won't take the payment. If your building is difficult, this question matters more than any feature list.

Split checks

Splitting is where restaurant POS systems differ most, and where a demo that looks fine can fall apart in service. There are three quite different things people mean by it:

• Split evenly. One check divided by the number of payers. Easy, and every system does it.
• Split by seat. Each person pays for what they ordered. This only works well if your staff are assigning items to seats as they ring them in, so it's as much a training question as a software one.
• Split by item after the fact. Dragging items between checks once the meal is over, because the table decided at the end. This is the one that separates good systems from awkward ones, and the one to actually test in a demo.

Also worth testing: partial payments, where someone puts down a fixed amount on a card and the rest goes on another, and whether each split payment can carry its own tip. Ask to try these yourself on the real device rather than watching someone else do it.

Quick-service versus full-service

These are genuinely different problems and the right setup isn't the same.

• Quick service and counter service. Speed at the point of sale is everything, the transaction is final when it's taken, and tips are collected on screen. The priorities are a fast, obvious ordering screen, a kitchen display that keeps up, and as few taps as possible between order and paid.
• Full service. Checks stay open, tabs move between tables, courses are fired in order, and tips arrive after authorization. The priorities are table management, coursing, splitting, and tip handling. This is where the mechanics above actually bite.
• Bars. Open tabs with a card held on a pre-authorization, tabs transferring between bartenders at shift change, and a card left behind at close. Ask specifically how pre-authorized tabs are handled and what happens to one that's never closed out.
• Food trucks and markets. Everything above plus unreliable connectivity, so offline behavior and battery life matter more than table features.

Online ordering and delivery

An online or phone order is a card-not-present transaction. No chip was read, and nobody checked the card against the person holding it. That carries more fraud risk, and card-not-present transactions generally cost more to process than the same sale taken in the dining room. This isn't your processor marking you up, it's how interchange is structured across the industry.

The practical question is whose ordering system you use. A first-party ordering page, of the kind platforms like Clover and Square provide, sends orders straight into the same POS and kitchen display as your dine-in tickets, and you keep the customer relationship. Third-party delivery marketplaces bring volume you wouldn't otherwise see, but they take a commission that's usually far larger than any card processing cost, and the customer belongs to the app rather than to you.

Most restaurants end up doing both. The thing worth avoiding is a third-party tablet sitting beside the till with orders being retyped into the POS by hand during a rush, which is how tickets get lost and how the same item ends up in the kitchen twice.

Chargebacks and disputes

A chargeback is a cardholder asking their bank to reverse a payment. Restaurants see a few characteristic kinds:

• Disputed tips. A customer says the tip was altered, or doesn't recognize the final amount because it's higher than the authorization they saw on their banking app. This is the most common restaurant dispute and the reason to keep the signed slip.
• Unrecognized charges. Your business name on a statement doesn't match the sign above the door, so a real customer reports a real charge as fraud. Making sure the descriptor on the statement is recognizable is a small fix that prevents a steady trickle of these.
• Card-not-present fraud. A stolen card used for a delivery order. This is the one category where the liability usually sits with you rather than the card issuer, which is why online orders deserve more care than dine-in.

What actually wins a dispute. Evidence, submitted inside the response window. For a dine-in tip dispute that means the itemized receipt and the signed slip showing the tip line in the customer's handwriting. For delivery it means the order record, the delivery confirmation and the address it went to. Restaurants that keep their signed slips filed by date win these. Restaurants that throw them out at close don't.

Chip transactions shift liability. When a chip card is dipped or tapped and the transaction is authorized, fraud liability generally sits with the card issuer rather than with you. Key a card in by hand and that protection is gone. Tell your staff this one plainly. Manually typing a card number because the chip is being slow moves the risk onto the restaurant.

Refunds and voids

These are two different operations and the difference is worth money.

• A void. Cancelling a transaction before the batch has settled. The sale effectively never happened. If you catch a mistake the same day, before close, void it rather than refund it.
• A refund. Returning money after settlement. This is a new transaction moving money the other way, and it takes days to appear on the customer's statement, which is why an unhappy customer often disputes the charge anyway before the refund lands.

Ask how refunds are treated on your account: whether you get back what it cost you to process the original sale, and whether there's a separate fee for issuing the refund itself. The answer differs between pricing models and it's a reasonable question to expect a straight answer to.

Comps are cheaper than refunds. If a meal goes wrong while the guest is still in the building, comping it before the card is run avoids the transaction, the refund, the fee and the dispute risk in one move. Getting staff to fix problems at the table rather than after the card is run is a payments decision as much as a hospitality one.

What to look for in a restaurant processor

Restaurant-specific questions, beyond the ones any business should ask:

1. Is tip adjustment handled properly, and what's the tolerance above the authorized amount?
2. What happens to a batch that isn't closed on time, and will you be warned before it costs you?
3. Can I split a check by item after the meal, on the actual device, not in a slide deck?
4. How do pre-authorized bar tabs work, and what happens to one left open at close?
5. What does a handheld do when it loses connectivity in the far corner of my dining room?
6. Does online ordering flow into the same tickets and kitchen display as dine-in?
7. How are tips reported and paid out, and does it handle tip pooling the way I actually split them?
8. Who do I call at 7pm on a Saturday when the terminal stops taking cards, and is it a person?
9. Is the hardware tied to this processor, or can I keep it if I move?
10. What's the contract length and what does it cost to leave?

Clover and Square for restaurants

We set businesses up on leading platforms like Clover and Square, tailored to each business. Both have restaurant-specific configurations, both make handheld devices for tableside payment, both run kitchen displays and first-party online ordering, and both handle coursing, tabs and splitting. Neither is simply better than the other.

Which one suits you comes down to specifics: how your floor is laid out, how many stations and handhelds you need, whether you're counter-service or full-service, what you already own, what your kitchen workflow looks like, and what you want to add in a year. That's a conversation about your restaurant, not a spec comparison, which is why we start by looking at how you actually run rather than leading with a product.