Food halls · Payments

One card key for ten kitchens is one bank account for ten businesses

Our first card-reader integration used a single platform-wide key, the way we hold a key for sending email. For money that is wrong: every venue would have charged into the same merchant account.


A platform holds keys. One for the mail service, one for the model that reads a menu photo, one for the maps. They sit in a vault and every venue uses them, because the platform is the one buying that service on everybody's behalf.

We added a card reader the same way. One key, in the same vault, beside the others.

That is fine for sending an email and wrong for taking money. A card key is not a key to a service the platform buys. It is a key to somebody's bank account. Ten kitchens on one key is ten businesses' takings landing in one account.

What that would actually mean

In a food hall, each kitchen is its own business with its own bank, its own VAT position, its own books. If their card payments settle into one merchant account, somebody has to divide the money up afterwards and pay it out — which means that somebody is holding other people's money.

In the UK that is regulated territory. It is also the reason every serious marketplace has a product for exactly this: the vendor holds their own account, the money lands there, and the platform's commission comes off at the moment of payment rather than being chased later.

We had already written that argument down for online payments. We then went and made the opposite mistake on the reader.

Now: one account per venue, and no quiet fallback

Each venue holds its own card account: which company, whose account it is, and its own key, encrypted. A venue that has not set one up cannot take a card on a reader — and that is a refusal that names the venue, not a silent fall back to whatever key happens to be in the vault. A payment charged into somebody else's account is not the kind of thing you want to discover at the first payout.

And pointing two venues at the same account is refused outright, with the count in the sentence: "this card company settles a payment to one merchant, and 2 venues are set to charge into the same account." Not a warning. A refusal, at the moment somebody tries to save it, rather than at a counter with a queue.

The question this does not answer

A payment taken on a card reader settles to that card company's merchant account. It does not pass through anybody else's. So if you are running a hall and you want one guest payment split across three kitchens automatically, a reader on a counter is not the thing that does it — that is the online path, and it is a different mechanism with different economics.

Worth knowing which of the two you are buying. And worth us saying plainly: card processing through HelchPOS is not switched on. The reader work is built and has never taken a payment; card at the till is taken on the venue's own terminal and recorded here, so the sale, the VAT and the reports still agree.


Try it on tonight’s service.

Nothing to install, no card. Not better by the weekend? Close the tab.