Gift cards

Sell your own gift cards at every checkout: the buyer picks a value, adds a personal message, and chooses the day it lands in the recipient’s inbox — with a designed card to download. The value comes back to you as ticket sales, on any of your events.

Selling gift cards

Turn them on once, in Settings → Gift cards. From then on every event’s checkout offers a “gift card” ask alongside the tickets — and your public organiser page sells them too, so someone holding your link can buy a gift card on its own, without picking an event first. You choose the one-tap amounts buyers see — up to four — and the smallest and largest value a card can carry.

The card itself is created the moment the order is paid, with a code the buyer or their recipient later types at checkout. Codes avoid look-alike characters, and a code read out over the phone works however it is typed back — lower case, no dashes, an O for a zero.

A gift card’s sale carries no VAT: tax falls due when the card pays for something, not when the value is loaded. Invoices and receipts for orders that include a card say so on the document.

Delivery & the designed card

When a buyer picks an amount, the recipient fields open with it: a name, a message (it travels in the email, word for word), and a delivery date. The answers stay on the basket — shown against the card line, editable right up to payment. The email goes out at purchase — or at 9am on the chosen day, in your timezone — with the code, the message and a link to the designed card as a PDF they can print or forward. A card bought without a recipient is delivered back to the buyer, who also always sees it on their order page.

The card’s look comes from the badge designer: a separate “gift card” design kind with its own fields — the value, the code, the message, your name — and deliberately no scannable code, because a gift card is typed, never scanned. Until you design your own, the platform’s design is used.

Typo in the recipient’s address? Open the card in the console, correct the recipient and re-send — the value never moves, only the delivery.

How buyers redeem

Redeeming is typing the code at checkout, on any of your events. The card pays as much of the order as it can: if it covers everything, there is no card payment at all; if not, the buyer pays only the remainder as normal. The order total never changes — the card changes how it is paid.

Whatever is left on the card stays on it for next time. Cards never expire unless you set a term in settings, and a term is never under 12 months.

If you add the booking fee to your buyers’ total, one thing does change: the fee is charged only on the part a card doesn’t cover. A card that covers the whole order means no booking fee to pay, because your buyer already paid it when they bought the card — charging it again would be charging twice for the same money. A £20 card against a £50 ticket leaves £30 uncovered, so the fee is worked out on that £30. If you absorb the fee yourself instead, nothing about this is visible to your buyer.

One thing a card cannot do: fund a Gift Aid claim. HMRC only allows claims on donations made from the donor's own money, so a donation on an order a gift card helped pay — even partly — is left off your Gift Aid schedule. The donation itself still goes through.

The ledger & your liability

The console’s Gift cards area lists every card with a full movement history — issued, redeemed, credited back, voided — and totals your outstanding balance: the value sold but not yet spent, which is the figure your accountant will ask for. Staff can look a card up by typing its code, exactly as a buyer would read it out.

Your event’s sales report shows both halves of the same story: what you sold in cards, and how much of your takings was paid with one. That matters because a card counts as a sale twice over its life — once when you sell it, and again inside the order it eventually pays for. Both are real sales, so neither is hidden; the report simply names them, and subtracting what was paid by card from your gross gives the money that actually came in.

Refunds & voiding

Refunding an order that was paid with a gift card puts the money back on the card first, before anything goes back to a bank card — and restored value gets a fresh expiry runway, never less than a new card would. Buyer self-service cancellation doesn’t cover card-paid orders; refund those from the console.

Refunding the sale of a card itself is different: while the card has been spent, the refund is blocked — that value has already gone to someone else. Void the card first (knowingly writing off what remains) or refund a smaller amount. Refunding a card’s sale in full voids the card with it, so a refunded card can’t keep circulating.

Cancelling the sale of a card does the same thing. Cancelling never moves money — that is what a refund is for — but it does retire what the order sold, and on a gift-card sale that is the card. If it has already been part spent, whatever is left on it is written off and the card stops working. This is what makes cancelling useful against a card bought with a stolen bank card: it stops the value being spent while you sort the payment out.

When an order was part paid by card and part paid by bank card, a refund handles one payment at a time, starting with the gift card, so no money leaves your bank before the stored value is back where it came from. The order page lists both, with what is left to refund on each; ask for more than one of them holds and the console tells you which it is and how much remains.

Recipients & privacy

A gift recipient never becomes one of your contacts: their name, email and the buyer’s message exist only on the card, for delivery, and never join your marketing audience. An erasure request reaches them there — the personal details are removed while the card’s value and history remain as your financial record.