Gift cards for PrestaShop: adding digital vouchers to your store

A gift card is one of the few things you can sell that costs you nothing to make, ships in milliseconds, and can't be returned. The buyer pays today; you don't part with any stock until someone redeems the code. Which might be next week, might be in March, might be never. For a PrestaShop store heading into a gift-giving season, that's an unusually friendly bit of margin. And yet most PrestaShop stores don't sell them, usually because the owner assumes it needs a dedicated paid module and never gets round to checking what the platform already does.

Last updated: June 2026.

Here's the useful surprise: PrestaShop's cart rule system, the same engine behind every voucher and discount code in your store, is most of a gift card already. A gift card, stripped to its mechanics, is just a pre-paid voucher with a unique code, a fixed money value, and partial-use turned on. This guide walks the whole thing on PrestaShop specifically: what a gift card really is in back-office terms, how to build the basic version by hand, where that approach runs out, the decisions that bite you later (expiry, partial balance, fraud, VAT), and how to market the cards once they exist.

Why gift cards earn their place in the catalogue

Before any setup, it's worth being clear about why this is worth your afternoon. Three things make gift cards behave differently from normal products on the balance sheet, and all three favour the store:

• You get paid before you deliver anything. The cash lands when the card is bought; the cost of goods only hits when it's redeemed. That gap, often weeks, sometimes months, is interest-free working capital that sits in your account over exactly the period (post-holiday) when most stores are tightest.
• The buyer and the spender are usually two different people. Your existing customer buys the card; the recipient may never have visited your store. That makes a gift card a low-cost way to put your shop in front of someone new, with a pre-loaded reason to come in.
• They don't come back as returns. A gift card can't be sent back for a refund the way a sweater can. For categories with heavy return rates, that's a quiet relief on its own.

There's also the spending pattern worth knowing about: a recipient holding a, say, €50 card will quite often pick the €75 item and pay the €25 difference, because the card makes the out-of-pocket part feel smaller. Various retail surveys put gift-card recipients' average spend somewhere above the card's face value, the exact figure varies by study and by category, so treat it as a direction of travel rather than a number to bank on. The same goes for "breakage" (cards that go partly unredeemed): it's real, but consumer-protection rules in much of the EU now cap or ban expiry, so don't build a revenue plan around it. The honest, bankable benefits are the three above.

What a gift card actually is in PrestaShop

PrestaShop has no native "gift card" object, there's no toggle in the back office labelled as such. What it has is the cart rule, and a cart rule can do everything a single-use gift card needs:

• A unique code the recipient types at checkout.
• A discount of type "Amount" (a fixed money value, e.g. €50) rather than a percentage.
• Partial use allowed, so a €100 card spent on a €60 order leaves €40 live for next time.
• A validity window, a per-customer restriction, and tax handling, all already exposed in the cart-rule form.

So the question isn't "can PrestaShop do gift cards?", it's "how much of the plumbing between the customer buying a card and the cart rule existing am I willing to do by hand?" That's the real fork in the road, and it's worth seeing the manual version first so you understand what any module is actually saving you.

Building a basic gift card by hand

You can stand up a working single-card flow in PrestaShop with no module at all. It won't scale, but it's the clearest way to learn the mechanics, and it's genuinely fine for a store that sells a handful of cards a month.

Step 1: create the cart rule (the card itself)

Go to Catalog → Discounts → Cart rules (in PrestaShop 1.6 this lived under Price rules → Cart rules) and click Add new cart rule. The fields that matter for a gift card:

• Information tab, Code: type a unique code, or click Generate for a random one. This is what the recipient enters at checkout.
• Conditions tab. Valid from / to: set the validity window. Leave it generous (see the expiry section below), short windows create unhappy recipients and, in some EU countries, legal exposure.
• Conditions tab, Total available / Total available for each user: these only cap how many times the code can be redeemed in total and per customer; for a single-use card you'd cap "total available" at 1. They don't tie the code to one person, if a gift card must be usable only by a specific account, use the cart rule's customer restriction (the "Limit to a single customer" field on the Conditions tab) and keep the usage limits purely for redemption caps.
• Actions tab, Apply a discount: Amount. Enter the card value (e.g. 50), pick the currency, and decide tax included / excluded. This choice has VAT consequences covered later.
• Actions tab. "Apply a discount to" and partial use: set the discount to apply to the whole order, and crucially toggle partial use on so unspent balance survives to the next order.

Save, and you have a functioning €50 gift card. Anyone who enters that code at checkout gets €50 off, with the remainder kept live. If this looks familiar, it should, it's the exact same mechanism behind every other discount you run, which is why the broader cart rules, specific prices and discount strategies guide is the natural companion read. It's worth understanding how cart rules differ from specific prices (catalogue-level price changes) before you lean on them heavily.

Step 2: sell the card as a product

Create a product called "Gift card" under Catalog → Products. Make it a virtual product (no shipping, no stock) and, if you want denominations, add a €25 / €50 / €100 set as combinations (the Combinations tab) each with its own price. Put this product somewhere visible, more on that in the mistakes section.

Step 3: connect the dots (the part that hurts)

This is where the hand-built version shows its seams. After someone buys the gift-card product, something has to generate a matching cart rule and email the code to the recipient. With no module, that "something" is you: watch for the order, create the cart rule manually (Step 1), and send the code by hand. Fine at a card a week; miserable at a card an hour in December. There's no recipient email field, no personal message, no balance lookup, and no delay before the code goes out. Everything in the next sections is about closing those gaps, and that's precisely the work a dedicated gift-card module exists to automate.

The decisions that bite you later

Whether you build by hand or buy a module, four design choices determine whether gift cards are a quiet win or a support headache. Decide them up front.

Fixed denominations vs custom amounts

Preset values (€25 / €50 / €100, mapped to product combinations) are simpler to build and faster for the buyer to choose. A free-entry "any amount" field is more flexible but needs validation, a minimum (say €10) and a maximum (say €500), and a way to price a product whose price the customer sets. A sensible middle path: offer four or five presets plus an "other amount" option. Start with presets only; add custom amounts when buyers actually ask.

Expiry dates

This is a legal question as much as a UX one. Several EU countries mandate a minimum validity (commonly in the two-to-five-year range), and some restrict expiry on single-brand cards more tightly still, France being the well-known strict case. Check your local rules before you set anything. From a pure business view, longer is better: an expired card is a bad experience and a potential complaint, and the cash-flow benefit of the card doesn't depend on it lapsing. Set the cart rule's "valid to" date generously (two to three years is a common, defensible choice) and state it clearly on the card and in the email.

Partial redemption

Make partial use the default, full stop. PrestaShop's cart rule already supports it via the partial use toggle on the Actions tab: a €100 card spent on a €60 order leaves €40 available. The mechanism PrestaShop uses is to issue a fresh cart rule for the leftover balance, which is worth knowing because it affects how you (or a module) show a customer their "remaining balance." Without partial use, a recipient who spends €60 of a €100 card loses the other €40. Which is the kind of thing that turns into a chargeback or a one-star review.

Single card vs scheduled / seasonal campaigns

A gift card is "always on." But the promotions around gift cards (bonus value, free-card-with-purchase) are time-boxed, and PrestaShop's cart rules let you schedule those with start and end dates. If you want a "buy €100, get €120" offer to switch itself on for the first two weeks of December and off again automatically, that's the territory of scheduled discounts that start and stop on their own. Set the dates once and walk away.

Digital or physical?

For most PrestaShop stores the answer is "digital, at least to start." A quick comparison:

Digital wins on cost, speed and inventory risk, which is why it suits online-only stores. The catch is fraud (covered below) and the slightly less special unboxing. Add physical cards later if demand justifies the operational overhead, not before.

The delivery email is the whole gift

For a digital card, the email is the present. There's nothing else to hold. PrestaShop's email templates live under Design → Email theme (and the raw templates in your theme's mails/ folder), so you have the hooks to make it look like a gift rather than an order confirmation. Whatever you build, include:

• The code, big and copy-pasteable. Most recipients open this on a phone; the code needs to be large, high-contrast, and easy to select.
• The amount and, if relevant, the expiry date, stated plainly.
• The buyer's personal message, displayed prominently. This is the single thing that makes it read as a gift and not marketing.
• Clear redemption steps: "Visit [store], add items to your cart, and enter code XXXX-XXXX at checkout."
• A direct CTA ("Start shopping") linking to the store, with a tap target comfortable on mobile.

Marketing the cards once they exist

Gift card sales cluster hard around a few dates, so this slots straight into your wider promotional calendar, if you haven't mapped one, the seasonal sales calendar lays out the whole year. The peaks that matter most for cards:

• Christmas / holidays, by far the biggest window. Start promoting in early November and run hard through to the 24th. Pair this with your broader Christmas gift-guide and last-minute marketing push.
• Valentine's Day, position the card as the low-risk choice when someone doesn't know a partner's size or taste. Quick campaigns that convert are covered in the Valentine's Day playbook.
• Mother's / Father's Day. Start two to three weeks out.
• Back to school, relevant for some categories; see back to school beyond fashion for whether it fits yours.
• The last 48 hours before any major holiday. The moment digital cards earn their keep. "Still searching for a gift? Send an e-gift card in seconds." Nobody else can deliver in that window.

Promotional structures that work

Three structures earn their keep. A native cart rule can discount eligible products or an order and be scheduled like any other PrestaShop discount, but note that issuing a new gift-card value as a reward ("get €120 to spend," "get a free €20 card") isn't something a plain cart rule does on its own: it can't automatically generate a fresh gift-card voucher after a purchase. Those offers need either a gift-card module that handles the issuance, or a manual step where you create and send the bonus card yourself:

• Bonus value: "Buy a €100 card, get €120 to spend." The extra €20 only costs you the margin on what gets bought against it, and it brings the recipient in at all. The buyer pays €100 but the redeemable card has to carry €120 of value, so this means issuing a higher-value voucher than was paid for, a module or a manual create-the-card step, not a one-line cart rule.
• Free card with purchase: "Spend €150, get a free €20 card." This lifts the current order and guarantees a return visit when the card is redeemed, but again, generating that €20 card after the qualifying order is module/manual territory, since a native cart rule discounts the current cart rather than handing out a new voucher.
• Bulk / corporate pricing: a 10–15% discount on orders of ten or more cards. Companies buy these for staff rewards and client gifts, often in volume. This one is a straightforward native cart rule, a percentage discount conditioned on quantity.

These are urgency plays as much as gift plays, and if you want the urgency to be honest rather than the fake-countdown kind, the principles in flash sales without being manipulative apply directly to a "last 48 hours" gift-card push. One important boundary: gift cards themselves should generally be excluded from your sitewide discount codes (you don't want a 20%-off coupon to apply to a €100 card and hand someone €100 of value for €80). That's a specific case of the broader principle in why some products should never go on sale. Set the exclusion in the cart rule's product restrictions.

Fraud: the one thing not to skip

Digital gift cards are a favourite target precisely because they're instant and liquid, buy with a stolen card, redeem the code before the chargeback lands. A few low-effort guards cut most of this:

• Delay the delivery email. Don't fire the code the instant payment clears. A short hold (an hour or a few) gives your payment processor's fraud checks time to flag a bad transaction before the value walks out the door.
• Cap purchases. Limit gift-card buys per customer per day and set a maximum card value (e.g. €500). Note that PrestaShop doesn't enforce a per-customer-per-day purchase cap out of the box, cart-rule limits govern voucher redemption, not how many gift-card products someone can buy, and product quantity settings don't track daily per-customer totals. In practice you get there through order monitoring, your payment processor's fraud tools, customer-group or order rules, or a small custom validation / module that counts recent gift-card orders per account.
• Require an account for gift-card orders. An account creates an identity trail that guest checkout doesn't. This is one of the rare cases where you'd deliberately turn off the otherwise-helpful guest checkout.
• Watch for clusters. Several card purchases from one IP, email domain, or card number in a short window is the classic pattern.

VAT and accounting, talk to your accountant

Two things commonly trip up store owners, and both are worth a five-minute conversation with whoever does your books:

• A gift card sale usually isn't revenue yet. In most jurisdictions it's a liability, you've taken money but not delivered goods. Revenue is recognised on redemption, not sale. So December card sales shouldn't inflate December's revenue line; they sit as a liability until spent.
• VAT timing depends on the card type. In the EU, a single-purpose voucher (redeemable for one product type at a known VAT rate) is taxed at sale; a multi-purpose voucher (a normal store-wide gift card, usable across products at different rates) is taxed at redemption. The tax-included/excluded choice you made on the cart rule needs to line up with this. Get it confirmed for your jurisdiction rather than guessing.

The mistakes that quietly cost you

• Burying the card in a subcategory. During gift-giving season a gift card is a headline product, not a footnote. Put it in the main menu or header, if a buyer has to search for it, they won't.
• Never testing redemption on mobile. If your checkout's voucher field is hidden or fiddly on a phone, recipients literally cannot spend their cards. Test the full redeem flow on a real device.
• No balance lookup. Partial-use cards mean customers will have leftover balances and will want to check them. With the hand-built approach there's no native way to surface this, which is one of the strongest arguments for a proper module.
• No reminders. Recipients forget. A gentle nudge at 30, 60 and 90 days recovers redemptions (and sales) that would otherwise just sit there.

When to stop hand-building and reach for a module

The manual cart-rule method is genuinely good for learning the mechanics and for low volume. You should move to a dedicated gift-card module the moment any of these become true: you're generating codes by hand more than once or twice a week; you need recipient email + personal message captured at purchase; you need scheduled (delayed) delivery for fraud control; or customers start asking "how much is left on my card?" Those are exactly the gaps the hand-built flow can't close, and they're the whole reason gift-card modules exist, to wire the purchase, code generation, branded email, delay, and balance lookup together so you're not the integration.

If you're already running automated promotions in your store, this fits the same toolkit you use for everything else, see how we approach automating discounts at scale in Black Friday prep: automating discounts and promotions, and the broader Sales Revolution approach to deal automation. The same back-office discipline that runs your seasonal sales runs your gift-card campaigns.

Frequently asked questions

Does PrestaShop have a built-in gift card feature?

Not as a labelled object, there's no "gift card" toggle. What it has is the cart rule, and a cart rule with a unique code, a fixed "Amount" discount, and partial use turned on is functionally a single-use gift card. You build it under Catalog → Discounts → Cart rules, then sell access to it as a virtual product. The missing pieces are the plumbing, code generation, recipient email, delay, balance lookup. Which is what a dedicated module automates.

How do I make a leftover gift-card balance survive to the next order?

Turn on partial use on the cart rule's Actions tab. With it on, a €100 card spent on a €60 order leaves €40 live. PrestaShop handles this by issuing a fresh cart rule for the remaining balance, worth knowing because it's why you (or a module) need a way to show customers their remaining balance. Without partial use, the recipient simply loses the unspent €40, which invites chargebacks and one-star reviews.

Can a native cart rule give a "buy €100, get €120" bonus automatically?

No. A plain cart rule discounts the current cart; it can't generate a fresh higher-value gift-card voucher after a purchase. "Buy €100, get €120" and "free €20 card with purchase" both mean issuing a new voucher worth more than was paid, that's a gift-card module's job, or a manual create-and-send step. Bulk/corporate pricing (a percentage off ten or more cards) is a straightforward native cart rule, because it's just a quantity-conditioned discount.

When does VAT apply to a gift card sale?

It depends on the voucher type and you should confirm it for your jurisdiction. In the EU, a single-purpose voucher (redeemable for one product type at a known VAT rate) is taxed at sale, while a multi-purpose voucher (a normal store-wide card usable across different rates) is taxed at redemption. The tax-included/excluded choice on the cart rule needs to line up with that. Separately, a gift-card sale usually isn't revenue yet, in most jurisdictions it's a liability until the card is redeemed.

How do I stop fraudsters buying gift cards with stolen payment details?

Digital cards are instant and liquid, so a few low-effort guards matter: delay the delivery email by an hour or a few so your processor's fraud checks can flag a bad transaction first; cap card value (e.g. €500); require an account for gift-card orders so there's an identity trail; and watch for clusters from one IP, email domain or card number. Note PrestaShop doesn't enforce a per-customer-per-day purchase cap natively. That comes from order monitoring, your processor's tools, or a small custom validation.

Should gift cards be excluded from my sitewide discount codes?

Yes. Otherwise a 20%-off coupon could apply to a €100 card and hand someone €100 of value for €80. Set the exclusion in the cart rule's product restrictions so the card itself is never eligible for store-wide discounts.

The short version

A gift card in PrestaShop is a cart rule with a fixed amount, a unique code, partial use on, and a generous expiry, wrapped in a virtual product and a good-looking email. You can build that by hand today and it will work. The honest payoff is real and doesn't depend on hopeful statistics: cash before you ship, a new customer for each card, and no returns. Decide expiry and fraud handling up front, exclude the cards from your sitewide coupons, line up the VAT treatment with your accountant, put the product where people can see it, and when generating codes by hand starts eating your week, that's your signal to let a module take over the plumbing.