Gift cards

Manage → Gift cards. Each card is a code and a balance. A shopper types the code at checkout, and the balance comes down order by order until it is gone.

A gift card is not a discount code

The two look alike — both are a string a shopper types into a box — but they do different things, and confusing them is a bookkeeping mistake rather than a cosmetic one.

A discount makes the goods cheaper. Revenue goes down, and the tax on that part goes down with it. Exactly right for "20% off".

A gift card pays for the goods. They still cost what they cost, the tax is still owed, and you were already paid — when somebody bought the card. It only reduces what is left to collect.

So on the order screen a gift card sits below the total, not beside the discount line, with a Still due row under it. The order total does not move. Folding it into the discount would leave your revenue short by the face value of every card ever redeemed, and you would still owe the tax on it.

The practical consequence, and the reason they are kept apart: one order can use both. A shopper with a 10% code and a 200k card uses both — the card pays into what is left after the discount and the tax.

Issuing a card

The amount is all you need. Everything else is optional.

Leave Code blank and one is made for you, like GC-4H9K-X2PM-7NTQ. Codes we make avoid the characters people misread — no 0, O, 1, I or L. That is not decoration: a gift card gets read off a piece of paper and typed in by somebody who did not choose it, so every pair a human confuses is a phone call for you.

You can also type your own — for a batch you had printed, or a code somebody already handed out. A code is unique within one store, and dashes and spaces do not count: GC-4H9K and gc 4h9k are the same card.

Leave Expires blank and the card never expires. Pick a date and it dies at the end of that day, not at the midnight that opens it.

Where the shopper types it

Not automatically. You have to add the field to your order form: form builder → Basic group → Gift card code. It arrives already wired to the order's gift-card column.

Beside it is Discount code — two separate boxes, because one order can carry both.

A bad code stops the order. The shopper sees the error on the box they just typed into and nothing is recorded, unlike every other form failure (those keep the customer's details and tell you afterwards). The reason: a shopper types a code precisely to pay less. If the order went through without it they would be charged in full while the thank-you page told them everything worked — and for a gift card that is worse than an overcharge, because the card may already have been debited by an earlier attempt.

They get exactly two answers: we don't know that code, or that code can't be used on this order. Whether it expired or was spent is your business, visible on the card's own screen — saying it out loud would turn that box into somewhere a stranger can probe for your store's live codes.

The history is the point, not the balance

Open a card and the history is what leads: issued, spent on which order, given back, adjusted. The balance is just the sum of those rows.

That is because "where did my 200k go?" has to be answerable. Every row carries a reason, and a spend row carries the order it paid for.

Cancel an order and the money goes back to the card, automatically. Deleting one does the same — and the money is returned before the order disappears, because afterwards there is no order left to trace it back to.

Cancelling and then reinstating an order does not charge the card again. The order goes back to unpaid, which is the truth: the card has been given back.

Adjusting, and why a reason is required

Adjust moves the balance up or down — goodwill, correcting a mis-issue, writing a card off. Use a negative amount to take value away.

The reason is required. An amount of money moving with nobody able to explain it is the one thing a ledger exists to prevent.

A balance never goes below zero. Type one digit too many and you are told, rather than quietly handed a negative liability.

There is no delete button, on purpose

Deleting a card does not take the code out of the shopper's hand — it only destroys the one record of what you owe them.

Void is what you get instead: the card stops being spendable while keeping who it was for, what it was worth, and what has already been redeemed against it. Changed your mind? Put back in circulation.

To write the value off, adjust it to zero — on the record, with your reason attached.

The list opens on what is still owed

The screen opens filtered to Still owed, not "all". That is the real question: how much of your customers' money are you holding. On a store that has been running a while, the full list is mostly spent cards nobody will use again.

"Still owed" is not a status but three conditions at once: not voided, not expired, and holding a balance. A card that is still active but spent to zero is not in it.

The line above the table adds up the balances on the page you are looking at, and says so.