The only thing you sell that you still owe afterwards.
The money arrives the day the card is bought. The jewelry leaves months later, in a different sale, often to somebody who has never been in your shop. So a gift card in Gem Logic is built like a ledger rather than a record: the balance is worked out from every redemption against it, the terms cannot be edited afterwards, and the card can never be deleted.
A gift card is money you have taken and not yet delivered.
That one sentence decides how the whole thing has to be built. Money that is owed needs a balance nobody can type, a history that cannot be quietly tidied, and a record that survives the person who issued it. What most systems give you instead is a code in a spreadsheet and a number somebody edits.
You have the money and you owe the goods. Until the card is spent, the amount on it is an obligation sitting in your bank balance looking exactly like takings.
Not stored, not adjusted. It is the amount it was issued for, less every successful redemption against it, recomputed on every save.
The code, the amount, the currency and the expiry are fixed at issue, and no card is ever deleted. A card you no longer honour is deactivated and stays visible.
Every card is a person who has a reason to come in, usually someone who has never been in your shop, usually spending past the amount on it.
It is bought and spent at the same counter as everything else, on the same order, as a line and then as a payment method. No second system, no separate login, no card provider taking a percentage of your own money.
Three ways a card comes into existence, and only one of them is a gift.
Somebody buys one at the counter in December. Somebody is handed one because a repair took three weeks longer than you promised. And somebody is owed money you would rather keep in the shop: an overpayment, a return, or the gold they sold you this morning. All three make the same object, and it behaves the same way afterwards.
Added to the order as a line item at zero tax, because the tax belongs to whatever the card eventually buys. The customer pays for it like anything else and the code is live the moment the sale is confirmed.
Issued on its own for a giveaway, a competition, a corporate order, or an apology worth more than a phone call. Same object, no sale behind it, and the record says who created it and when.
An overpaid order, a returned piece, or a buyback becomes a card for the difference instead of cash out of the drawer. Somebody who came in to sell a chain leaves with $2,280 to spend on the thing in the window, and offering a little more in credit than in cash makes both sides better off.
Nobody wants to be given a code read out over the counter. Every card prints as a proper voucher with the code, the amount, the expiry and your own branding on it, generated in the language the customer's contact record is in. Print it at the counter, or send it.
At the counter it is a payment method, not a puzzle.
This is where gift cards embarrass shops. Somebody arrives with a card, and finding out what is on it means a phone call, a folder, or a colleague who is not in today. Here the card is one of the payment methods on the order. Type the code, or press the customer's own card if they are already on the sale, and the amount comes off in front of them.
Ask a card for more than its balance and the amount is capped at what is left, with the rest going on another method. A card cannot go negative, cannot be spent twice, and cannot be used once it is deactivated or past its date.
Most jewelry costs more than the card that was bought for it, which is the whole point. A $150 card against $890 of earrings leaves $740 on a bank card, and both payments sit on the same order.
The wrong card pressed on the wrong sale is a Tuesday. Remove the payment and the card recomputes itself, because the balance was never a number somebody had to remember to correct.
The balance is not a field, and nobody can edit their way out of it.
This is the part that sounds like a restriction and is actually the product. A gift card is store money, and store money that anyone with a login can top up, alter or delete is not worth issuing. The code, the amount, the currency, the expiry and the customer are fixed when the card is created. What changes is the list of redemptions, and the balance follows it.
Code, amount, currency, expiry, customer and the sale it came from cannot be changed afterwards. Try it and the system says which field you are touching. The one way round it is deliberate and narrow: an administrator, or a setting your owner turns on knowingly.
A card that was issued in error, replaced, or reported lost is switched off and stays in the list with its history. Deleting it would remove the only evidence of money you took, which is the one thing an accountant will ask to see.
Issued, printed, redeemed, switched off and back on: all of it lands in the card's own activity with who and when. When a customer says the balance is wrong, the answer is on the card rather than in somebody's recollection of March.
Gift cards are not revenue until somebody spends them.
A December of gift-card sales looks like a very good December. Some of it is a very good January instead, and a little of it is never anything at all. The difference between the three is the outstanding balance, and it is one figure: everything issued, less everything redeemed. Knowing it is the difference between a shop that sells gift cards and a shop that has quietly borrowed money from its customers.
The money is real and it is in your account, but so is the obligation, and your accountant will want them separated. One number, on the list, at any date: what you have taken and not yet delivered. Give it to them monthly instead of reconstructing it in March.
Cards can carry an expiry date or none at all, per card, and where you set one the rules that apply to you are yours to follow. What the module does is make the dates visible in advance, so an expiring card is a reason to call somebody rather than an awkward conversation at the counter.
Whoever walks in holding the card has never bought from you. They arrive with a budget already spent, they usually go past it, and the redemption puts them on a contact record for the first time. That is what the card was really for.
Store money touches the till, the books and the buyback counter.
How much of last December is still sitting in somebody's wallet?
If the answer is a shoebox of numbered cards and a spreadsheet, book a demo. We will set your code format with you and run one card from the counter to the till and back.