Digital Gift Sender - Send Virtual Products and Download Links to a Friend as a Gift

The gift use case your digital catalogue is already missing

Someone wants to buy your e-book, your sample pack, your course or your licence key for a friend. Today they either buy it, download it themselves and forward the file by hand, or they simply do not buy it. This module closes that gap with one checkbox on the cart page and no extra checkout step.

One option, in exactly the right place

When every item in the cart is virtual or downloadable, a Send this order as a gift to a friend option appears in the cart. Ticking it reveals an e-mail field; the preference saves instantly in the background, with no page reload. The customer then checks out exactly as they always do — nothing is added to your checkout flow, and a short read-only reminder during checkout confirms who the gift is going to, with an Edit link back to the cart.

Mixed carts do not show the option at all. That is deliberate: a physical item cannot be gifted by e-mail, and half-gifting an order would only confuse everyone.

The friend gets the file, not the receipt

When the order first reaches a paid or processing status, the module e-mails the download link or links to the friend's address using its own gift_download_ready template. What the friend receives is the download and nothing else — no invoice, no price, no order reference, no address. The buyer keeps their own order confirmation as usual.

You can see whether it worked

The order page in the back office gains a Gift request panel: who the recipient is, whether the e-mail was sent, and a Resend gift e-mail button for the times it was not. Bounced addresses and SMTP hiccups happen; recovering from one should not mean digging through mail logs. The configuration page also lists the 20 most recent gift requests — order, date, recipient, sent or pending — so you can see the feature working at a glance.

Built on hooks, not overrides

Version 1.x shipped five full-class core overrides — Cart, Order, OrderHistory, PaymentModule and CheckoutAddressesStep — just to add two columns and splice a few lines into the order flow. Every PrestaShop update was a chance of silently breaking checkout for every shop running it.

Version 2.0 removes all five. Gift requests live in their own table, keyed by cart and then by order, and the module hooks into documented extension points instead: actionValidateOrder when the order is placed, actionOrderStatusUpdate when it becomes payable. Nothing in the core is touched, so nothing in the core can break.

Security and privacy taken seriously

The field that decides where a paid file gets forwarded is exactly the kind of thing that must not be forgeable. In 1.x it had no CSRF protection — a forged cross-site request could have redirected a customer's own download to an attacker's address. The save endpoint now requires a per-cart signed token that only the module's own page can produce.

The friend's address is personal data about someone who is not your customer, so GDPR customer erasure is wired in: deleting a customer through PrestaShop's own privacy tools removes their gift requests with them.

A widget that keeps up with the cart

The cart page changes without reloading, and the gift option has to follow it. This one re-checks eligibility when the theme fires a cart-update event, listens for the several event names different themes use, and falls back to a periodic recheck for themes that fire none — never interrupting a customer who is mid-typing. Eligibility is decided by a direct uncached read of the cart's contents, so an emptied cart never keeps showing the option and a cart that has just become all-digital shows it immediately.

The module's own AJAX responses send Cache-Control: no-store, and its CSS and JavaScript are inlined in the template rather than registered through the asset pipeline — because that registration silently does nothing when the block is re-fetched over AJAX. Nothing is left that can fail to load.

Compatibility

PrestaShop 1.7, 8 and 9, in eight languages: Dutch, English, French, German, Italian, Polish, Spanish and Turkish. No core overrides, one small database table, three hooks and no theme changes required. Multistore aware — the Allow gifting switch is per shop. Upgrading from 1.x removes the five overrides and cleans up the Configuration rows 1.x created per cart and never deleted.

Frequently asked questions

When does the friend get the e-mail?

The first time the order reaches a paid or processing status. An order sitting in "Awaiting payment" never triggers it, which is the point — nobody gets a file that has not been paid for.

Does the friend see the price or the invoice?

No. The gift e-mail contains the download link or links and nothing else. No price, no invoice, no order details.

What about a cart with both a physical and a digital product?

The option does not appear. Only all-digital carts can be gifted, since a physical item cannot be delivered by e-mail.

The e-mail never arrived — what do I check?

That gifting was enabled when the order was placed, that the cart was all-digital, that the order reached a paid status, that the product actually has a file attached in its Virtual product tab, and that the address is not spam-filtering your shop. Then use Resend gift e-mail on the order.

Can the customer change the address after checkout?

Not from the storefront, by design — it would mean reaching into a paid order. You can edit it on the order page and resend.

Does it override any core files?

No. Version 2.0 removed all five overrides that 1.x shipped and replaced them with hooks and its own table.

The option is not showing on the cart page. Check the setting and that the cart is entirely digital. If both are right, it is almost always caching — clear the shop cache after updating, and make sure any CDN or reverse proxy in front of your shop excludes cart, checkout and account pages.