Gift cards · Money
A gift card is money, so it behaves like money.
Sold and redeemed at the counter, by barcode or by swipe, with a balance any till can check and a code no screen in the product can list.
What you get
Cards load up to a ceiling you set and sell like any other line.
The code is a bearer instrument: it is presented, never looked up. There is deliberately no “all our gift cards” screen anywhere in the product.
Checking a balance is a button, so “how much is on this?” does not require starting a sale.
Part-payment is ordinary — the card covers what it covers and the rest is paid however the customer likes.
Expiry follows your state's rules, and the settings screen will tell you what that state requires, including the states where expiry is not allowed at all.
How it runs
A card bought in December, spent in March.
- 1
A customer buys a $50 card at the counter; it is activated and the money is on the books the moment it is taken.
- 2
In March they present the card and the till reads the barcode or the swipe and shows the balance.
- 3
Part of it pays for the sale; the remainder stays on the card.
- 4
Nobody searched for the code. It was presented — which is the only way a bearer instrument should ever be read.
The questions people ask
- Barcode or magnetic stripe?
- Either, or both. It is a setting, because it is really a decision about the plastic you bought.
- Can staff look up a card and its balance?
- Only by reading the card in front of them. The code column is hidden from staff sessions and there is no listing call in the product to write a screen against.
- How much can go on one card?
- Up to a ceiling you set. It exists so a mistyped load is caught by the register rather than by an accountant.
Start with Gift cards switched on.
Every module is part of the same trial — turn on what you need, leave the rest off, and your data exports on any day of it.