Selling Gift Cards Through Your App: Who Buys, Who Receives and What Remains?

A purchased gift card needs more than a discount-code field. Decide who pays for it, who receives it, when its value becomes usable and where the remaining balance can be spent. Keep those decisions separate from the design of the card itself.

This guide concerns prepaid gift value offered by a business, not promotional loyalty points or subscription discount codes. It proposes requirements for a development brief, not legal, tax or accounting advice. Have the actual programme terms and financial treatment reviewed before launch.

Separate the product from the issued card

A catalogue item called “Gift card” describes what someone can buy. The issued card is the particular redeemable value created for that purchase. A picture and a successful checkout page do not explain whether that value has actually been issued.

Odoo 19's gift-card documentation gives a concrete example: gift cards are products customers can purchase and then use as a payment method in an online shop or point of sale. Its setup distinguishes the gift-card product from the programme and generated cards. This is a product example, not proof that your custom checkout implements every later rule.

Ask for an understandable link between purchase, payment outcome and issued card. Agree which confirmed event makes it spendable. If a payment result is uncertain, reconcile it rather than issuing another card on every retry. Staff need to distinguish awaiting payment, awaiting issuance and available to use without assuming those states are identical.

Purchaser and recipient are different people

For a hypothetical pottery studio, someone buys a card for a friend's class. The purchaser needs their purchase confirmation; the friend needs the gift and instructions. Sending both documents to the same address by default could spoil the gift or expose information unnecessarily.

Specify separate fields and purposes. Is the recipient's email required, or may the purchaser deliver the card themselves? Is there an optional message? Can delivery be scheduled? If scheduled delivery is included, agree its time-zone rule and what happens when the sending attempt fails. Scheduling is a requirement to build and test, not a documented feature promised by the cited guide.

Odoo describes generating cards for anonymous or selected customers. That illustrates why account association is a deliberate choice. It does not settle whether your recipient must sign in, whether a card is transferable or who may recover a lost code. Put those rules in plain language before collecting recipient details.

Define the places and currency where it works

The documented Odoo programme includes currency, company, website and point-of-sale scope. Use that as a prompt to name your own boundaries: which storefronts, branches or checkout systems accept the card, and which do not?

Do not make “works online and in store” a vague promise. If those checkouts use different systems, have the developer demonstrate the connection that shares the usable balance. A printed card does not by itself create that integration.

State how the app responds to an unsupported currency or branch before the customer completes a purchase. Currency conversion, cash payout, expiry and excluded products require explicit reviewed policies; none follows automatically from a field labelled balance.

Delivery, replacement and remaining value

A card sent to the wrong address is not just an email typo. If possession of its code permits spending, a replacement must account for the old code's exposure. Limit who can see full codes and agree the verification process for support requests. Do not copy them into ordinary support logs merely for convenience.

Choose whether resending delivers the same still-valid card or invalidates it and creates a replacement. Staff should see what happened without creating two usable balances for one purchase. The specific invalidation and recovery process needs provider support and testing; the cited setup guide does not establish it.

Also specify part-payment. If the programme allows spending some value now and the rest later, show the amount used, the remaining amount and any other payment required. Test two concurrent attempts so the same available value cannot be spent twice. A refund needs a separate reviewed rule for restoring value or using another repayment method; do not silently choose one for every case.

A practical acceptance demonstration

Use fictional people and non-production cards. Buy one for a different recipient, complete and interrupt payment, and repeat the issuance request. Show the link from the purchase to exactly the intended issued value. Then demonstrate delayed or failed delivery, a wrong address and the authorised replacement process.

Where partial use is supported, redeem part, inspect the remainder and try competing checkouts. Try an excluded branch or currency and inspect the customer explanation. Walk through a refund using the agreed programme policy, not an improvised balance edit.

Bring the proposed gift journey and terms to a customer-app project discussion. The useful outcome is a traceable path from a paid gift to its permitted use, with support rules the team can actually follow. It is not a claim that a gift-card feature will increase sales.