EveryoneBuilds
Prompt Kits

Build Gift Cards & Vouchers

A gift card is the only thing you sell to someone who will never use it — which is what makes it the easiest sale in the business and the one most often built badly. The buyer wants it in the next four minutes, usually for something happening tomorrow; the recipient wants a code that works without a conversation; and you want to know, at any moment, how much unredeemed service you are carrying. This kit builds all three: a purchase page that shows its terms before anyone pays, a code delivered properly, redemption that can happen exactly once, and a ledger of what you still owe. It treats the last two as the serious parts, because a code that redeems twice costs you real money and a liability you cannot see is how a good month quietly isn't one.

Project type: Gift cards & vouchers Difficulty: Intermediate Time: 1-2 days Works with: Base44 / Lovable / v0

What you'll have at the end

  • A gift card page with your amounts, your terms and your expiry rules, all visible before anyone pays
  • Payment handled on your provider's own secure page, with no card details ever touching your site
  • A unique code delivered to whoever should get it — including on a date you choose, for a birthday
  • A version that looks like a gift rather than a receipt, that the buyer can print or forward
  • Redemption that works once and only once, with partial balances if you allow them
  • A live figure for what you still owe in unredeemed cards, which is the number this kit exists to give you

Before you start

  • A payment provider account. Gift cards are money taken up front and there is no version of this that avoids proper payment handling.
  • Your amounts, or whether you allow any amount. Fixed values are easier for buyers to choose and easier for you to reconcile; open amounts sell better to people with a specific budget in mind.
  • What the card is for. A money value spendable on anything, or a specific service. A service card is simpler for the recipient and riskier for you if your prices rise before it is used — decide which you are selling.
  • Your terms, written out. Expiry if any, whether the balance can be used across several visits, whether it is refundable, whether it transfers to another person, and what happens if it is lost. These have to be visible before purchase, not after.
  • What the law where you operate says about gift cards. This is genuinely regulated in many places — minimum validity periods, outright bans on expiry, rules about unused balances. Look it up before you set an expiry date, because getting it wrong is a consumer-protection problem, not a design one.
  • Whether you already run a till or booking system that issues gift cards. If you do, it almost certainly should stay there — see the FAQ.

Which platform suits this

Base44 is the natural fit: card records, codes, balances, redemption history and the outstanding-liability view live in one managed app, and redemption at the counter is just another owner screen. Lovable builds the same through Lovable Cloud or an optional Supabase backend. v0 will build it on Vercel with server actions or API routes, but two things are yours to get right: the redemption must be safe against the same code being used twice at once, and the code generation must be genuinely unpredictable. On all three, the payment itself happens on your provider's hosted page — that part is identical everywhere and is not negotiable.

Start with the first prompt on a free plan. Extra usage and some connected services may cost more as you build out the project.

Build it on

Start free with Base44Read Review: Base44
Start free with LovableRead Review: Lovable
Start free with v0Read Review: v0 by Vercel

How we make money

The steps

1

Show the terms before anyone pays

When to use this

Start here, on your existing site.

A gift card page where every rule is visible before the buy button.

The prompt

Add a gift card page to this site for [YOUR BUSINESS].

Offer [YOUR AMOUNTS, e.g. fixed values of 25, 50 and 100, or any amount between a minimum and maximum I set]. [IF I SELL SERVICE CARDS INSTEAD: offer these specific services as gift cards: YOUR SERVICES.]

Let the buyer say who it is for, add a short personal message, and choose whether it goes to the recipient directly or back to the buyer to hand over themselves.

Show my terms on the page itself, above the buy button, not behind a link and not after payment: [YOUR TERMS — what it can be spent on, whether the balance can be used over several visits, expiry if any, transferability, refundability, what happens if it is lost]. Make the buyer confirm they have read them before paying.

Do not invent any term, expiry period or condition. Use exactly what I give you, and if something is missing, ask me rather than filling the gap.

Say plainly how and when the code arrives, because someone buying this at eleven at night for tomorrow needs to know before they pay.

Do not build payment, codes or redemption yet.

Check it worked

  • Your amounts or services appear exactly as you set them
  • The buyer can add a recipient and a message, and choose the delivery route
  • Every term is visible above the buy button and must be acknowledged
  • No term or expiry was invented
  • When the code arrives is stated before payment
  • Nothing takes money yet

You'll know it worked when:

A gift card page you would be comfortable showing a consumer-protection regulator.

Watch out for

Terms shown after payment are not terms. This is the single most common complaint about gift cards and the easiest one to avoid — every rule that could disappoint someone belongs above the button, in plain words. And do not let the AI write an expiry period: in a number of countries a short expiry on a gift card is simply unlawful, and a plausible-sounding "valid for 12 months" is exactly the kind of thing it will produce unprompted.

2

Take the money properly

When to use this

Once the page and its terms are right.

A real purchase, handled by your payment provider, recorded on your side.

The prompt

Add payment to the gift card page.

Send the buyer to [YOUR PAYMENT PROVIDER]'s own secure hosted page to pay. Never collect, display or store card numbers on my site, in my database or in any email — not the full number, not a partial one.

When a payment succeeds, create a gift card record holding: the amount, the currency, the buyer's details, the recipient's details and message, the purchase date, and the terms exactly as they were shown at the time of purchase. Those stored terms must never change afterwards, even if I change my terms later.

Create the card only when the payment is actually confirmed by the provider, not when the buyer returns to my site. If a payment fails or is abandoned, no card exists.

Email the buyer a receipt with what they bought, for whom, and when the code will arrive.

Tell me exactly what I need to set up with the provider, and what to change when I go from test to live.

Do not generate the code or deliver anything yet.

Check it worked

  • Payment happens entirely on the provider's page
  • No card details exist anywhere in your site, database or emails
  • A card record is created only on confirmed payment
  • The record freezes the terms shown at purchase
  • An abandoned payment leaves no card behind
  • The buyer receives a receipt

You'll know it worked when:

A test purchase that created exactly one card record — and an abandoned test purchase that created none.

Watch out for

Create the card on the provider's confirmation, not on the buyer landing back on your thank-you page. Those are different events, and building on the second one means a closed browser tab produces a paid-for card that does not exist, or a refreshed page produces two. Test the abandoned case deliberately; it is the one nobody tries until a customer reports it.

3

Deliver a code that feels like a gift

When to use this

Once purchases are recorded reliably.

A unique code that reaches the right person, at the right time, looking like a present.

The prompt

Add code generation and delivery to my gift cards.

Generate a unique code for each card that cannot be guessed or worked out from another code — random, not sequential, and not derived from the date or the amount. Format it so a human can read it aloud over the phone without confusion: avoid characters that look alike.

Deliver it the way the buyer chose: straight to the recipient, or back to the buyer to pass on themselves.

Let the buyer choose a delivery date, so a card bought today can arrive on a birthday. Show clearly when it will be sent, and let me see and cancel anything scheduled.

The delivery should look like a gift and not an invoice: the amount or service, who it is from, their personal message, the code, my business name, and how to use it. Keep my terms and any expiry date on it too.

Give the recipient a version they can print or save, and let the same card be resent to either party if it is lost.

Send it through a proper email delivery service so it reliably arrives, and tell me what to set up.

Never put any payment information in the delivery.

Check it worked

  • Every code is unique and unpredictable, and readable aloud
  • It reaches whichever person the buyer chose
  • A scheduled card arrives on its date, and you can see the queue
  • The delivery reads as a gift and still carries the terms and expiry
  • It can be printed or saved, and resent if lost
  • No payment information appears anywhere in it

You'll know it worked when:

A test card that arrived on a scheduled date, looked like a present, and was readable enough to dictate over the phone.

Watch out for

Sequential or predictable codes are free money for anyone who buys one and guesses the next. Make them random and long enough that guessing is pointless. On the other side, remember the code gets read aloud at a counter and typed by someone who is not concentrating — dropping the characters that look alike costs you nothing and saves a surprising number of awkward moments.

4

Redeem exactly once

When to use this

Before the first real card is issued. This is the step that protects the money.

A code that works once, a balance that cannot go below zero, and a redemption you can trust.

The prompt

Add redemption to my gift cards.

Give me a private redemption screen where I enter or scan a code and immediately see: whether it is valid, its remaining balance, when it was bought, its terms, whether it has expired, and its full redemption history.

Redeeming reduces the balance. [IF I ALLOW PARTIAL USE: let a card be used across several visits until the balance reaches zero. OTHERWISE: a card is used once in full and closed.]

A card must never be redeemable twice for the same value. Make sure two people redeeming the same code at the same moment cannot both succeed, and that the balance can never go below zero.

Show me clearly when a code is invalid, already fully used, or expired — and say which of those it is, because "invalid" tells the person in front of me nothing.

Let me reverse a redemption I made by mistake, and record that reversal in the history rather than erasing it.

Let the holder check their own balance from the card's link without being able to change anything.

Only I and [MY STAFF, IF ANY] can reach the redemption screen. Protect it properly rather than hiding the address.

Keep everything from the previous steps working exactly as it is.

Check it worked

  • Entering a code shows validity, balance, terms, expiry and history at once
  • Redeeming reduces the balance, and the balance never goes negative
  • The same code cannot be redeemed twice for the same value, even simultaneously
  • Invalid, spent and expired are distinguished
  • A mistaken redemption can be reversed, and the reversal is recorded
  • The holder can check a balance without changing it
  • The screen is genuinely protected

You'll know it worked when:

You tried to redeem the same code twice, in two browser windows at once, and only one succeeded.

Watch out for

Test the double redemption properly — two windows, same code, click at the same time. A naive build reads the balance, then writes the new one, and two people hitting it together both read the old figure and both get paid out. It is a bug nobody sees until the month someone notices. And distinguish "already used" from "invalid": a recipient told their gift is invalid assumes you are refusing them, and that conversation is much worse than "this was used on the fourteenth."

5

Know what you owe

When to use this

Once cards are selling.

The outstanding balance, visible, at any moment.

The prompt

Add a private gift card summary to my owner screen.

Show me the number that matters most: the total value of cards sold and not yet redeemed. That is money I have taken for service I have not yet given, and I want it visible rather than calculated once a year.

List every card with its code, amount, remaining balance, buyer, recipient, purchase date, expiry, and status — unsent, delivered, partly used, fully used, expired.

Let me filter and search by code, buyer or recipient, because someone will call having lost everything but a first name.

Show me by month: cards sold, value sold, value redeemed, and the outstanding total over time.

Flag cards approaching expiry so I can decide whether to remind the holder — which is usually both the decent thing and the thing that brings them in.

Let me issue a card manually without payment, for a complaint or a promotion, recording why.

Let me export everything, including redemption history.

Keep everything from the previous steps working exactly as it is.

Check it worked

  • The outstanding unredeemed total is the first thing you see
  • Every card is listed with its balance, status and both parties
  • You can find a card from a partial memory of a name
  • Monthly sold and redeemed figures are visible over time
  • Cards nearing expiry are flagged
  • You can issue a manual card with a recorded reason
  • Everything exports, redemption history included

You'll know it worked when:

You know, today, how much unredeemed service you are carrying — and it was a bigger number than you expected.

Watch out for

The outstanding total is a liability, not takings. Money from gift cards spends exactly like revenue and is not revenue until the service is delivered, which is how a business has a strong December and a difficult February. Keep the figure in front of you, and talk to your accountant about how gift cards should be treated where you are — the tax and accounting treatment differs by country and it is not the sort of thing to improvise.

Going live

  • Check what your country requires on gift card expiry and unused balances before you set any expiry
  • Confirm every term is visible above the buy button, on a phone, without expanding anything
  • Make a real purchase with live payment keys, then refund it
  • Abandon a payment halfway and confirm no card was created
  • Redeem the same code in two windows at once and confirm only one succeeds
  • Confirm no card details appear anywhere in your database or emails
  • Send a test card to an ordinary email account and confirm it lands in the inbox
  • Read the delivery email on a phone and check it reads as a gift, with the code legible
  • Open the redemption screen in a private window while signed out and confirm it is closed
  • Ask your accountant how to treat unredeemed balances before your first busy season
  • Add a privacy note covering what you store about buyers and recipients (see the legal pages prompt)

Spend fewer credits

Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.

  1. Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
  2. Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
  3. Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
  4. One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
  5. Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
  6. Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.

The prompts on this page are written to do most of this work for you — that's the point of them.

Read the full guide

Last reviewed: 2026-09-14

FAQ

We use cookies to analyze traffic and track affiliate clicks. By continuing, you agree to our Privacy Policy.