Selling a Gift Card From Your Own Site, Not a Paper IOU

It's the second week of December, and a regular leans on the bar to ask whether the restaurant does gift vouchers. The owner says yes, pulls the voucher book out from under the till, writes "£50, valid for food and drink" on a slip, signs it, and rings the money through as an ordinary card sale. Nobody writes down who bought it, who it's for, or which slip number went out. The slip ends up inside a Christmas card. By February a stranger walks in holding it, and the only record that it was ever paid for is a £50 line on a December till report that looks exactly like every other £50 line from that week.

That one at least counts as the good version, since the buyer was standing in the room. The costlier failure happens where the restaurant can't see it. Someone living two hundred miles away wants to buy dinner for a sister around the corner from the restaurant. They may never have eaten there themselves. They search, find the website, and find nothing to buy. A phone number rings out during service, and an email address gets a reply on Monday. By the time the reply lands, the present may have been bought somewhere else. A paper voucher is a problem for the guest holding one, and a lost sale for the guest who never could buy one.

Both failures cost more at one point in the year than at any other. A gift card is money taken before the meal, and for a restaurant with a quiet January, the value of that money is partly about timing: cash arriving in December that carries the business through the quieter weeks after the new year. That means taking payment whenever the buyer is ready, often late in the evening, from a phone, far from the bar.

A handwritten slip promises food and drink worth a stated amount, at some point in the future, to whoever turns up holding the paper. Everything that should stand behind that promise lives in somebody's memory, or nowhere else.

The problems surface one at a time, usually at the busiest moment:

None of this needs fraud. Honest guests lose paper, and honest staff forget to log a sale. The paper alone creates the confusion.

There's an accounting wrinkle too: how a voucher is treated for VAT depends on the kind sold, which when VAT actually falls on a restaurant gift voucher covers. An owner who can't list what was sold has nothing to hand an accountant.

The paper problem at least surfaces on the premises. The bigger one stays invisible, because the buyer here is the one who never manages to pay.

A present for someone else is often bought by a person who isn't a regular. They may never have eaten at the restaurant. They know the recipient likes it, they have a budget in mind, and they want the job finished in one go. The moment they land on the website is the moment they're ready to buy. If the site offers only a phone number, an email address or a line saying "ask at the bar", the restaurant is asking a ready buyer to wait, and a buyer shopping for a present doesn't have to.

For a restaurant planning around a quiet January, the weeks before Christmas are probably the busiest stretch of the year for guests looking to buy a voucher. It's also when the floor is fullest and the owner has the least time to answer enquiries by hand.

Strip away the voucher book, and doing this properly comes down to a short list of requirements. Before picking any tool, an owner can test a setup against six questions.

A setup that fails the first two questions is still a voucher book with a web page bolted on the front.

The principle: make the restaurant's own website the shop, and give the bar a way to sell onto the same list. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and gift cards show why: the sale, the bar and the record sit on the restaurant's own site and in its own account. The published guide opens with a summary:

Turning the feature on comes first, and the guide describes that activation:

Once it's switched on, selling from the site becomes a Builder job. The owner opens Build, presses Add a module, and searches for "gift". Two modules come up: Gift cards, a call-to-action band with amount chips, and Gift card form, an in-page amount picker with the buyer's name, email and a personal message. The inspector sets the amounts, the heading and the button label, the same way every other block on the site gets set up.

The payment connection is what turns that form into a sale, and the guide says:

That answers the first three questions in one go. The buyer two hundred miles away can pay at eleven at night, the money lands in the restaurant's own Stripe account, and the recipient gets the card by email without anyone on the team having to send it. The how-it-works page states where the money lands:

On cost, the sale carries 0% TableSpark commission; Stripe's standard card-processing fees apply to online payments.

The website covers the buyer who's elsewhere. The regular at the bar still needs a way to buy on the spot, and that shouldn't mean going back to the voucher book.

In Service, a manager opens the guest's sheet (found by searching their name or tapping their booking) and scrolls to the gift cards section. The guide describes what happens next:

That answers the fourth question. The regular who wanted £50 for a friend walks away with a code and a PIN from the bar, plus a copy in their inbox. The card sits on the same list as every card sold through the website, so the owner has no desk book to reconcile against an online report come January. Anyone with service access can see a guest's cards, while issuing stays with managers, so a card is only ever written by someone with that authority.

The record covers the last two questions. The Gift cards page in the sidebar lists every issued card by its final six characters, along with its original value, issue date and status, and each card carries a dated, signed timeline behind it. Refunds, adjustments and voids each need a typed reason and a confirmation, and each stays on record as a permanent entry. What an owner can check on a card before honouring it, and how the total owed is read, is covered in gift card fraud and liability: what a restaurant can check.

Not every owner wants a card sold without a word exchanged. Some would rather speak to the buyer, suggest a set menu for a birthday, or check a date before a card goes out. The same form handles that, and the guide describes the second mode:

The request comes in with the buyer's details already written down, so nothing depends on somebody remembering a phone call. Both are published as first-class ways to sell, so the choice comes down to how the restaurant likes to work rather than what the form is capable of.

Whether adding an online sale raises the number of cards a particular restaurant sells was not located in this research, and no such promise is made here. What the setup changes is narrower and more certain: a buyer who reaches the site ready to pay finds somewhere to pay, and every card sold, online or at the desk, lands on one record.

A short check before the Christmas rush heads off a scramble in the thick of it.

The regular at the bar in December can still buy a card there. The difference is that the card now carries a code, a PIN, an email copy and a line on a list, and the stranger two hundred miles away can buy one at midnight without anyone picking up the phone.