Buy the Till Card Reader Knowing Where Every Payment Lands

That split costs nothing on the day the reader arrives and something every month after it. Two payment accounts mean two sets of card fees to check, two statements to download and two runs of deposits landing in the bank on two timetables, each to be matched against the till roll and the online orders before the books close. A refund for a collection order paid online has to be found in one account, a refund for a meal paid at the counter in the other. On a busy weekend it is easy to search the wrong account for a payment and decide it never arrived, and a mismatch nobody can explain can sit in the books until someone asks about it.

For a limited company, the record-keeping duty is not optional, and it covers the till as well as the website. GOV.UK's guidance on company and accounting records says the company must keep records of

and the same page sets out what happens if those records are not kept:

That penalty is for failing to keep accounting records at all, not for running two payment accounts, and nobody should read it as a fine for a messy month. The page also says records must be kept for six years from the end of the last company financial year they relate to, and longer in some cases, such as when HMRC has started a compliance check or the company has bought equipment it expects to last more than six years. The point for an owner is practical. Every pound taken at the counter and every pound taken online has to end up in records that agree with each other and with the bank, for years. Each extra payment account is one more source those records have to be built from.

The work grows in three places when the till reader and the website settle separately:

None of this is dramatic. It comes to an hour here and a puzzled phone call there, every month, for as long as the restaurant trades. That is why the decision is worth making before the reader is ordered, not after.

A card reader carries two costs, and they behave differently. The hardware is paid once. The rate is paid on every charge for as long as the reader is in use. Stripe's UK pricing page, read on 1 October 2026, lists its reader hardware with prices excluding VAT: the BBPOS WisePad 3 at £49.00, the Stripe Reader S710 and S700 at £229.00 each, and the Stripe Reader T600 at £249.00, all excluding VAT. The same page lists an optional Mobile service, unlimited cellular data on enabled readers, at £7.00 per reader per month.

The rate line needs more care. For in-person payments, Stripe's page lists two rates:

and 2.9% + 10p per successful charge for non-EEA cards. Stripe's page does not say which of those two lines a UK-issued card takes at a reader, so an owner should confirm that with Stripe before putting a figure on the budget. For online payments the page is plainer. Its standard rate is 1.5% + 20p for standard UK cards, with 2.8% + 20p for premium UK cards, and the page heads its standard pricing with "No setup fees, monthly fees, or hidden fees."

A worked example shows the size of each line. These figures come from the page above and can be swapped for whatever the owner's own Stripe quote says:

The hardware line is easy to price and easy to forget once paid, and the rate line is the one that keeps arriving. Gift cards follow the same arithmetic, and the worked example of what a £50 gift card sale costs in card fees runs it through a bonus offer. The same page lists per-authorisation extras for Tap to Pay on a phone and for optional point-to-point encryption, so confirm whether either applies to the setup being priced. What the table cannot show is the time spent matching each of these fees across separate accounts, and that is the line an opening budget can leave out.

The principle that solves the month-end problem is simple. The reader at the till and every card payment on the website should settle into the same account, so there is one balance, one fee schedule and one report to reconcile against the bank.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and its payments are built on that principle. The restaurant connects its own Stripe account once, and the reader is registered against that same connection. The get-paid guide states it in the product's own words:

The /pricing table carries the till side as POS connections, described as "Stripe Terminal card readers for the till: charge an order or a walk-up amount on a reader, settled into your own Stripe account". POS connections start at Growth; the till reader, online orders and deposits on one Stripe balance are priced here on Full. Online ordering sits on Full, £69 a month excluding VAT, which includes everything in Growth, with 0% TableSpark commission on those orders; Stripe's standard card-processing fees apply to online payments. For a restaurant that wants the till reader and online orders on the same balance, that makes Full the plan to price. Paying for ten months and using twelve brings Full to £690 a year, excluding VAT.

The guide is equally direct about fees. However many places the money comes in, the chain carries one fee:

The reader joins the account in Settings, under Card readers, once payments are connected. The guide describes the device side in one line: "Power on the physical reader; it shows a short pairing code on its own screen." The owner types that code into the Pairing code field, gives the reader a name such as "Front till", and presses Register reader. A restaurant with more than one service point does not have to choose which one gets the reader:

The reader is not a separate till with its own list of sales. It works from the same orders the team already handles. On the Orders screen, an order set to pay at the restaurant carries its payment status, and the guide describes what happens once a reader is registered:

That ties together two things that otherwise sit apart: the order the kitchen cooked and the card payment that settled it. Deciding which orders pay online and which pay at the counter is its own set-up choice, covered in setting which orders pay by card online and which pay at the restaurant. Whichever way an order is paid, the money arrives in the same place. The pricing row also covers the other common case at a counter, a walk-up amount charged on the reader without an order behind it.

The opening problem was a month-end with two of everything. With the reader and the website on one connection, the three places where the work used to grow each come down to one.

Fees are one schedule, Stripe's standard card-processing rate, with 0% TableSpark commission on top of it. Checking that the charges are right means reading one statement.

Payouts come from one account. The guide's line about readers is "the identical bank payout": every reader and every online payment pays out from the same account. Matching one payout to one report is a shorter job than matching two payouts to two reports, and that is most of the saving.

Refunds go back the way the money came. The guide says so plainly:

A guest querying a charge from Saturday night can be traced in one account, whether they tapped a card at the bar, paid a deposit to hold a table or paid for collection on the website. Deposits and gift card sales take the same route. The guide describes a booking deposit as collected "through this exact same connected Stripe account", and gift card sales on the site as "paid straight to your bank". Every card a guest uses, at the counter or online, ends up in the same balance.

Two costs sit outside any website plan and belong on the owner's sheet. The first is the reader hardware itself, bought from Stripe at the prices its page lists, with Stripe publishing the reader models it supports. The second is card processing. Stripe's fees apply to every card payment, in person and online, and 0% TableSpark commission means TableSpark takes no share of a sale, not that card payments carry no fee at all.

Stripe sets its own rates and decides how each card is classed at a reader, so the in-person figure on the budget should come from Stripe's own quote. Whether a payout reaches the bank on a given day is likewise decided by Stripe and the bank, and no such promise is made here. What one connection does is put every card payment, every fee and every payout in one place, so that when a number looks wrong there is only one place to look.