Give Someone a Subscription: Gift Cards and Redemption Codes for Vibe Projects

A friend wants to give your product as a gift, and all you can say is "just have them buy it themselves": a fictional lesson first

First, a fictional teaching example. A-Nan built an online illustration course platform called "Paint Box" on her own with AI — $48 a month, $480 a year. In the week before Christmas last year, a dozen emails suddenly arrived, all asking the same question: "I want to buy your course as a Christmas gift for my sister — how do I buy it?" A-Nan checked the admin panel: the purchase flow only knew "buy for yourself". There was no "buy for someone else" entry, no gift card, no redemption code, no scheduled delivery. She answered each email one by one: "Just buy an account yourself and send your sister the login details."

The result was predictable. Half of them just gave up. The other half did what she said — and then the support nightmare began: someone sent the login to the wrong person, someone discovered the sister already had an account and wanted a refund, someone realized on Christmas Day that the "gift" was just a username and password with zero ceremony, and came to complain "you don't even have a card". That Christmas, A-Nan lost at least twenty orders. Worse, she personally turned "giving a gift" — the most shareable scenario there is — into a series of miserable support experiences.

The point of this story: a gift card is not "one more SKU", it is "one more acquisition scenario". The person buying for themselves is your user; the person buying for someone else is your salesperson — spending their own money to put your product in the hands of someone you could never have reached. This guide explains how to build the gift card path properly: how a gift card differs from a coupon, how to choose among the three forms, the five steps of the purchase flow, how to design redemption codes that resist brute force, how to keep the balance ledger, how to prevent fraud, how to handle refunds and support, and finally a launch checklist. All names, product names, and numbers in the examples are fictional teaching examples, used only to make the ideas clear; the amounts, time periods, and ratios are engineering rules of thumb, not any official standard — verify them against your own pricing table, your payment provider's latest documentation, and local regulations before using them.

Setting the boundaries first: this guide only covers "buying for someone else" — not four other things

Before building anything, let's draw the boundaries. Several guides already published on this site cover neighboring territory, and this one is a new piece of the puzzle, not a repeat. The first is the coupon and discount code guide: "cheaper when buying for yourself" — threshold discounts, percentage discounts, time limits, stacking rules. That is the discount business. The second is the credits ledger and balance billing guide: how points and balances in a user's account are recorded and redeemed — the ledger for "your own money". The third is the pricing and paywall design guide: "what price to set, what to charge for" — pricing itself. The fourth is the subscription pause-and-resume and proration guides: the various changes mid-subscription — the subscription's own lifecycle.

This guide covers a fifth situation: A pays the money, B uses the product. Giver, recipient, and product are connected by one transaction for the first time. A gift card does not solve "cheaper" — it solves "giving": how to let A buy with dignity, let B receive it clearly, and let your system tell whose money this is, when it counts as revenue, and when it counts as a liability.

Three more things look similar but are not this guide's job. First, referral rewards: referral is "an existing user brings a new user and gets a reward afterward", while a gift card is "the giver pays first, the recipient redeems later" — the money flows in a different direction at a different time. Second, team seat purchases: a company buying seats in bulk is B2B procurement, with invoices, corporate payment, and admin assignment; a gift card is consumer gifting, about sentiment and ceremony. Third, free trials: a trial is "use first, pay later", a gift card is "pay first, use later" — on the books one is a cost and the other is a liability, handled completely differently. The boundary matters in practice: gift cards have their own ledger, their own fraud surface, and their own support problems. Mix them together and you cannot even write one field clearly in code.

1. A gift card is not a coupon: three forms — pick one before you build

The most common mistake is treating a gift card as "a coupon with a different name". A coupon is fundamentally a discount: the original price is $100, with the coupon it is $80, and the $20 difference is profit you give up. A gift card is fundamentally stored value: the giver pays $100 first, and the recipient later spends that $100 — not a cent less, just spent by a different person. One is "collect less money", the other is "collect money first". On the books one is a cost and the other is a liability; legally one is a promotion and the other may be regulated as a prepaid card. They were never the same thing from day one.

Gift cards come in three forms, and which one to pick depends on what your product is. The first is a stored-value card: fixed denominations or a custom amount, which the recipient spends like a balance on anything. It fits products that sell a bit of everything — asset stores, template libraries, credit-based AI tools. Suggested denominations: three tiers plus a custom amount box — $50, $100, and $200 are the most common. The second is a subscription gift card: what you give is not money but time — for example, "3 months of Pro". The recipient redeems it and gets 3 months of membership, then decides whether to renew. It fits subscription products — for A-Nan's "Paint Box", giving time is more gracious than giving money, and the recipient never has to pick a plan. The third is a specific-product card: the gift is one concrete thing, like "the Watercolor Basics course". The recipient redeems it and owns that course outright. It fits products where a single item has clear value — a course, a template pack, a premium feature bundle.

The trade-offs are practical. Stored-value cards are the most flexible, but also the easiest to treat as "a discount in disguise" — the recipient spends $80 of a $100 card, and the remaining $20 sits on the books. Over time that becomes "dormant balance", which the ledger section below covers. Subscription gift cards are the simplest — neither the giver nor the recipient has to do any math — but you need to answer one question first: what if the recipient is already a paying user? Does the gift extend their membership by three months, or convert into balance? Specific-product cards have the strongest sense of ceremony — giving one feels like handing over a real object — but they are the most vulnerable to "the wrong gift": if the recipient already bought that course, the card is useless, so you need a way to swap it for another course.

My advice: when launching gift cards for the first time, build only one form. Subscription products start with subscription gift cards, single-product sellers start with specific-product cards, and sell-a-bit-of-everything products start with stored-value cards. Launching all three means three ledgers, three support scripts, and three fraud surfaces — more than a one-person team can carry. Once the first form runs smoothly and survives a Christmas, add the second.

2. The purchase flow: five steps for the giver, each one deciding whether they buy

The gift card purchase flow differs from an ordinary checkout in exactly one way: the buyer is not the user. That single difference adds a question to every step, and the flow has to answer them one by one.

Step one is choosing the gift: how much money, how many months, which course. Denominations need suggestions — do not leave users staring at an empty box. Hints like "$50 covers two lessons" or "$200 covers a full quarter" work better than bare numbers. A subscription gift card must state clearly "which tier, how many months, what happens when it expires"; a specific-product card should show the product image and a one-line description so the giver can confirm "yes, this is the one".

Step two is writing the message: a line for the recipient, a signature, and the option to stay anonymous. The message is not optional decoration — it is the biggest difference between a gift card and an ordinary order. A gift card without a message is just a voucher. Offer three sample messages to apply with one click, plus a custom box. Default the signature to the giver's account name, but allow a nickname or anonymous.

Step three is filling in the recipient: an email address is the minimum, plus an optional phone number. The key detail is "what if the recipient doesn't have an account yet" — the answer is: they don't need one first. The redemption code goes to the email; the recipient clicks the link, registers, and redeems in one smooth sequence. Never require the giver to confirm whether the recipient already has an account — that blocks your acquisition funnel at step one.

Step four is scheduled delivery: buy a week before Christmas, deliver on Christmas Day — the most common gifting need. Offer two options, "send now" and "send on a date", with scheduling precise to the day. On the delivery day, send the giver a confirmation too — "your gift has been delivered" — otherwise the giver will anxiously ask support on Christmas Day whether it actually went out.

Step five is payment and proof: right after paying, the giver should immediately receive three things — a forwardable gift card voucher (with the redemption code, amount, and message), a confirmation email, and a "not sent yet, change the address" entry. The voucher should look decent — it is the first thing the recipient sees, and the reason the giver would forward it to a group chat. Do not print the full redemption code on the voucher — print half of it and require a click on "view the full code" to expand it, so a forwarded screenshot cannot be redeemed by someone else.

One more easily missed detail across the whole flow: after buying, the giver's own account should show a "gifts I sent" list — who it went to, when it was sent, whether it has been redeemed. Redeemed, and they feel at ease; not redeemed, and a reminder before expiry — "they haven't redeemed it yet, want to send another nudge?" — turns "buy and forget" into a reason to come back.

3. Redemption code design: behind 16 characters sits a full anti-brute-force system

The redemption code is the most fragile part of a gift card, and the easiest to get wrong. It looks like just a string of characters, but it has to satisfy four requirements at the same time: unique, unguessable, revocable, and traceable.

First, the format. Use 16 characters in 4 groups of 4, separated by hyphens, like XXXX-XXXX-XXXX-XXXX. Remove easily confused characters from the set: 0 and O, 1 and I, and lowercase l all go. With about 30 usable characters, 16 positions give 30 to the power of 16 combinations — at that scale, the chance of randomly guessing a valid code is negligible. The hyphen grouping is not for looks; it lets people read the code aloud in one breath and copy it correctly, which matters most when support reads a code over the phone.

Second, storage. Redemption codes must never be stored in plain text in the database. Do what passwords do: store only the hash, and verify by hashing what the user types and comparing. If the database is stolen, the codes do not leak with it. Every code also needs a state machine: unsent, sent, redeemed, expired, voided, refunded — six states, none optional. Without a "voided" state, a stolen code cannot be frozen in an emergency; without a "refunded" state, a refunded code could be redeemed a second time.

Third, brute-force protection. The redemption endpoint must be rate-limited: at most 20 attempts per hour from one IP, at most 10 attempts per day from one account, locked for a while once exceeded. Add a "honeypot" mechanism too: after 5 consecutive wrong guesses from one IP, every subsequent verification deliberately takes 2 extra seconds to return, collapsing the efficiency of automated scripts. Success and failure responses should take the same amount of time — do not let attackers tell from response timing that "this code exists, it was just already used".

Fourth, the redemption experience. The redemption page has to do three things. First, when a code is wrong, say clearly whether it is "this code does not exist", "this code was already used", or "this code has expired" — three situations, three messages, not one blanket "redemption failed". Second, after a successful redemption, immediately show "what you got, valid until when, and where to go next" — do not make users hunt for it themselves. Third, support both orders: "register first, then redeem" and "redeem first, then register" — the recipient may click the email link before realizing they have no account, or may remember the card only after registering.

4. The balance ledger: money received is a liability first, not revenue

A gift card's books are where many one-person teams first truly meet the concept of "liability". The moment the giver pays $100, your account has $100 more cash — but that $100 is not your revenue. It is $100 worth of product you owe the recipient. Only when the recipient actually redeems and spends it does it become revenue. In between, it sits on the books as "deferred revenue" or "prepaid balance" — a liability account. Spending that money as income on the day it arrives is the most common financial mistake with gift cards.

The ledger design can reuse the credits-ledger pattern directly: one gift card maps to one balance account, and every movement is a journal entry — issue (+100), redeem (-100 or partial), expire (balance cleared and moved to revenue), refund (-100). Stored-value cards must support partial redemption: a $100 card buys $60 of product, and the remaining $40 stays on the card for next time. Every partial redemption is journaled, and the balance is always "issued amount minus spent amount" — when the books do not reconcile, the journal entries are how you trace them one by one.

Expiry is where arguments start most easily. The recommendation: 12-month validity, a reminder 30 days and 7 days before expiry, and after expiry the balance is not zeroed out — instead, give a further 90-day grace period, and only then handle it under your policy. Many jurisdictions have explicit rules on prepaid card expiry — some require that balances never expire, others that expired balances remain redeemable — so the exact compliance wording depends on where you operate and is not expanded on here in legal detail. But one baseline never changes: the expiry rules must be written on the purchase page, visible before the user buys, so there is half as much arguing afterward.

There is one more entry called "breakage" — dormant balance: of the cards issued, some portion will never be redeemed, typically 10% to 20% in the industry. For a small team, dormant balance is not "free money" — it is "a sum that will have to be dealt with sooner or later". It sits on the books as a liability, and the longer it sits, the more auditors ask about it. The way to handle it: under your financial policy, after a card expires and a set period passes, move balances confirmed unredeemable into revenue, and keep records. Before moving anything, always complete the reminder flow first — reminders before expiry, reminders during the grace period — and only move what is still unclaimed after that.

5. Fraud prevention: gift cards are one of organized fraud's favorite money-laundering tools

A gift card has an unglamorous truth: it is one of the things organized fraud likes most. Buy gift cards with a stolen credit card, resell the cards, and the trail is far harder to follow than direct card fraud. So fraud protection has to ship on day one with gift cards — not patched in after something goes wrong.

The first line of defense is purchase limits: at most 5 cards per day from one account, at most 10 per day from one IP, and any single card over $500 goes through manual review or a second verification step. A brand-new account buying high-value gift cards on the day it registers deserves a close look — normal users do not register and immediately buy ten $200 cards for other people.

The second line is payment risk controls: gift card orders should carry their own risk tag, not be mixed in with ordinary orders. Billing address not matching the IP location, several cards failing in a row and then one suddenly succeeding, high-frequency orders late at night — any two of those three signals together should pause the order for a human to look at. Keep your payment provider's built-in risk rules switched on; do not turn them off for conversion's sake — one stolen-card refund and fine costs you the revenue of a hundred legitimate gift cards.

The third line is redemption controls: IPs that repeatedly guess codes get rate-limited (covered in the previous section); after a successful redemption, spending the balance should also have a rhythm — a freshly redeemed card can only be used for small purchases within the first 24 hours, and larger purchases wait until after 24 hours. That "cooling-off period" blocks a large share of "steal a code and drain it immediately" operations.

The fourth line is resale monitoring: if your gift card shows up on a second-hand marketplace at a discount, it is almost certainly organized fraud cashing out. Search your brand name plus "gift card" regularly; when you find one, freeze the corresponding card and route it through support. Keep evidence before freezing — purchase records, IP, redemption history — so you can explain yourself if a legitimate user is affected by mistake.

6. Refunds and support: the code is lost, the address was wrong, they want a refund — what now

Ninety percent of gift card support tickets cluster around three things: the code is lost, it was sent to the wrong address, or they want a refund. Each one needs a prepared answer before launch, not improvised when the user shows up.

Code lost: the recipient says the email is gone and the code is lost. The process: verify identity first — the recipient's email plus the purchase order number, both matching, before reissuing. Before reissuing, void the old code, then issue a new one; keep the reissue on record so nobody redeems both the old and the new code. Never reissue on the strength of one sentence — a wrong reissue is a direct financial loss.

Sent to the wrong address: the giver typed the wrong email, and the gift went to a stranger. The process: if the other person has not redeemed it yet, void the original code immediately and resend to the correct email. If they already redeemed it, it gets complicated — it depends on your policy, whether it is "no returns or exchanges after redemption" or "manual handling for special cases". Either way, the purchase page must state clearly who bears responsibility for a wrong email — writing it down beforehand is ten times better than arguing about it afterward.

Want a refund: the giver changed their mind after buying. The suggested rule: an unredeemed card can be fully refunded within 7 days of purchase; a redeemed card is refunded only for the unused portion, not the used portion; a subscription gift card that has already started counting down is refunded pro-rata for the remaining days. When refunding, return the money to the original payment method — do not refund it as balance. Refunding as balance forces the user to keep spending with you, and complaints arrive immediately.

One more principle for support scripts: gift card issues should be answered twice as fast as ordinary ones. Behind a gift card there is usually a specific date — a birthday, Christmas, an anniversary — and once it passes, it passes. Slow support by one day costs the user not just a card, but a chance to give a gift. Tag gift card tickets separately, prioritize them separately, and adding a "gift card hotline" for the two weeks before Christmas is not overkill at all.

7. Metrics and the launch checklist

After gift cards launch, four groups of metrics verify whether they work. The first is the gifting conversion rate: of the people who visit the gift card page, how many actually buy. Below 2% means the page has not explained "what to give and how to give it". The second is the redemption rate: of the cards sent, how many are redeemed within 30 days. Below 60% means reminders are not working or the redemption flow is too convoluted. The third is the new-customer share: of the people who redeem, how many are first-time registered users — the core value of gift cards as an acquisition channel. Below 50% means it is only circulating among existing users. The fourth is the fraud rate: stolen-card orders as a share of gift card orders. Above 1%, tighten risk controls immediately.

Finally, the pre-launch checklist — 14 items, do not launch with any missing. Form: pick only one of the three forms to start, denominations plus a custom amount, the "recipient is already a paying user" rule settled for subscription cards, and a "wrong gift, swap the course" path left open for specific-product cards. Purchase: the five-step flow works end to end, sample messages plus a custom box, scheduled delivery precise to the day, a good-looking voucher with the code half-masked, and a "gifts I sent" list for the giver. Redemption codes: 16-character grouped format with confusing characters removed, hashes only, a six-state state machine, rate limiting plus honeypot delays on the redemption endpoint, and three separate error messages. Ledger: issuance recorded as a liability, revenue only on redemption, complete journal entries for partial redemptions, 12-month validity plus a 90-day grace period, reminders at 30 days and 7 days before expiry, and a written policy for moving dormant balances to revenue. Risk controls: purchase limits, a separate risk tag on payment, a 24-hour cooling-off period on redemption, and someone responsible for resale monitoring. Support: written flows for reissue, wrong address, and refunds, with gift card tickets tagged separately. All 14 checked, gift cards are truly live; miss one, and someone will be asking you a question you never thought of in the week before Christmas.

In the end, a gift card does not sell a card — it sells a chance to "deliver your feelings for you". The person buying for themselves is your user; the person buying for someone else is your salesperson. Build this path properly, and next Christmas will not bring a dozen emails asking "how do I buy it" — it will bring a dozen people delivering your product to places you could never reach yourself.