Digital Download Management: How to Protect and Deliver Your Files

Reviewed and updated June 2026 — native virtual-product delivery and download-protection behaviour verified on PrestaShop 1.7, 8 and 9.

Here is the uncomfortable truth about selling digital files: the sale is the easy part. The hard part starts the second after payment, when a customer expects their file now, expects it to still work when they switch laptops next month, and — if anything goes wrong — is one click away from a chargeback you can't prove you didn't earn. Physical goods leave a trail: a tracking number, a signature, a courier. A download leaves nothing unless you build the trail yourself. This guide is about exactly that: how PrestaShop actually delivers and protects a file under the hood, where the native system is solid, where it quietly leaves you exposed, and what to do about the gaps.

This is the delivery-and-protection half of digital commerce. The wider business model — how to price tiers, structure licences, handle EU VAT, and set up a virtual product in the first place — is its own topic, covered in selling digital products on PrestaShop. Here we stay narrow and go deep on one question: once someone has paid, how does the file get to them safely, and how do you stop it leaking everywhere else?

How PrestaShop actually serves a downloadable file

It helps to know what's happening, because every protection decision flows from it. When you mark a product as a virtual product and attach a file, PrestaShop does not drop that file into a public folder. It stores it in /download/ at the root of your install, renamed to a long SHA1 hash with no extension — something like /download/3f7a9c1e…. That folder ships with an .htaccess that denies direct web access, so a customer (or a bot) guessing URLs gets nothing.

The actual download is brokered by a controller, not a static link. On PrestaShop 1.7 through 8 the file is served through the get-file front controller, reached via a secure download link that carries an order/download token rather than a direct public path to the file — the exact URL shape and parameters vary by version and by the route the customer arrived from (account page, order, or email), so don't rely on one hard-coded format. Before it streams a single byte, access is gated by that download/security token, the order's validity and paid status, the expiration window, and how many downloads remain; depending on the route and context, account login may also apply. The metadata behind this lives in two places, and it's worth keeping them separate. The product's defaults live in the ps_product_download table — the columns that matter to you are nb_downloadable (how many times), date_expiration (until when), is_shareable, and display_filename (the friendly name the customer sees, separate from the hashed name on disk). Once an order is placed, the per-order download state — the order's own download hash, its remaining count, and its deadline — is recorded against the order detail, so each purchase tracks its own usage independently of the product defaults.

So what does this buy you? Out of the box, PrestaShop already gives you the two things most merchants think they have to bolt on: files that can't be reached by guessing a URL, and downloads that are gated on a real, paid, logged-in order. You are not starting from zero. You're starting from "secure but blunt," and the work is sharpening it.

Configuring the native virtual product correctly

The settings that decide your delivery behaviour sit in the product's Virtual Product tab (in 1.7+, set the product type to Virtual product first, which makes the tab appear). The fields look trivial; the wrong values cause most of the support tickets digital sellers get.

One trap worth calling out: a true virtual product should carry no weight and no shipping. If a digital item still drags the checkout through a delivery step, the product was set up as physical-with-a-file rather than virtual. Confirm the type is virtual so the carrier step is skipped and no delivery address is demanded for a download.

Three delivery models, and when each is right

"Delivery" for a file isn't one thing. There are three patterns, and the right one depends almost entirely on file size and how much you care about traceability.

The decision rule is simple. Under a few hundred megabytes, let PrestaShop's native controller do the work — it's already secure and tied to the order. Above that, don't push it through your web server; host the file on cloud storage and hand out a signed URL that expires. The native controller protects access; cloud storage protects your server's responsiveness while everyone downloads at once.

Protection that deters without punishing buyers

You cannot make a file uncopyable. Anyone who tells you otherwise is selling DRM. The honest goal is narrower and achievable: make the legitimate purchase the easiest path, and make casual re-sharing traceable enough that people hesitate. Three measures carry almost all the weight.

Per-customer watermarking

This is the single highest-value, lowest-friction protection for documents and media. Stamp every downloaded PDF, image or archive with the buyer's name, email or order ID. It does nothing to stop a determined pirate — and that's fine, because it's not aimed at them. It's aimed at the ordinary customer who'd casually forward a file to a colleague or a forum. The moment their own name is on every page, most don't. And when a file does leak, the watermark tells you whose account it came from. The native virtual-product feature doesn't watermark; this is the most common reason sellers reach for a module.

Licence keys (when the file alone isn't the product)

For software, the file is often worthless without a key. Ship a unique key per order, validate it on install or periodically against your server, and the leaked file becomes a leaked installer that won't activate. The deeper strategy — perpetual vs subscription keys, domain binding, tiered licences — sits in selling digital products on PrestaShop; here it's enough to note that key delivery is part of delivery: the key must arrive in the same breath as the download, in both the confirmation email and the account page, or you've created a support queue.

Download limits and expiry as a quiet backstop

The nb_downloadable and date_expiration values you set earlier aren't just housekeeping — they cap how far one purchase can spread before the link goes dead. Tuned right (a few downloads, a sane window, with re-download available from the account), they're invisible to honest buyers and a real ceiling on link-sharing.

What to skip: heavyweight DRM (Adobe DRM, Widevine, FairPlay). It adds friction for the people who paid you, breaks on devices you didn't anticipate, and is broken by the people you were worried about anyway. For a small or mid-size store it's a net loss. Watermark, key, and limit — then put your energy into experience.

Updates and re-downloads: the part that earns loyalty

Unlike a physical product, a digital one is expected to improve. A buyer who got a template, a plugin or an ebook last quarter assumes they can pull the fixed version this quarter — and resents paying again for it. The native virtual product replaces the file on disk when you upload a new one, but it has no concept of versions: no changelog, no "you're on v2, v3 is out" signal, no notification to past buyers. So the practical baseline you owe customers is:

• Re-download from the account — the minimum. Their order page must always serve the current file, within the download window you set.
• Update notification — even a plain email when a new version lands. It drives return visits and quietly justifies your price.
• A changelog — buyers need to know what changed before they bother re-downloading.
• A defined update period — "12 months of updates, optional renewal" is sustainable; "lifetime updates" is an open-ended liability you'll regret on a product you later retire.

Versioning, changelogs per release, and notifying existing buyers are exactly the gaps where a purpose-built tool earns its place — more on that below.

Building the chargeback trail nobody thinks about until it's too late

This is where digital sellers get hurt, and it deserves its own section because the native system logs almost nothing useful for a dispute. A customer claims they never received the file. With a parcel you'd produce a tracking number. With a download you have… whatever you logged. If that's nothing, you lose the dispute and eat the fee.

Build evidence deliberately:

• Log every download with timestamp, IP address, user agent, and the customer account / order it belonged to. This is your tracking number.
• Send a delivery email that explicitly describes what was purchased and links to the download — so "I never got anything" is contradicted in the customer's own inbox.
• Keep access records — login times, download history per order — so a pattern of repeated downloads undercuts a "never received" claim.
• Have terms of service the customer accepts before purchase, so the rules of what they bought are on record.
• Respond fast with that evidence; payment processors weigh disputes on whether the seller can show delivery, and a clean download log usually does.

If you only take one thing from this guide, take this: turn delivery into a logged event. A download that leaves a timestamped, IP-stamped record is the difference between winning and losing the disputes that quietly erode digital margins.

When the native system runs out of road

PrestaShop's native delivery is genuinely good at the basics — secure storage, order-gated access, download limits. It runs out of road at exactly the points above: it doesn't watermark, doesn't version, doesn't generate or bind licence keys, doesn't log downloads in dispute-ready detail, and doesn't notify past buyers of updates. Those aren't edge cases for a serious digital seller; they're the daily work.

That's the gap our Digital Revolution module is built to close, and it maps onto every problem this guide raised. So what does it actually change for you? Downloads arrive on time-limited, token-based links that resist sharing instead of relying on limits alone. Each download is personalised with watermark info, so a leaked file points back to the account it came from — piracy becomes traceable, not just forbidden. Files are delivered automatically the moment payment confirms, with the link and any licence key in the same email, killing the "where's my download?" ticket. Version management means existing customers get the updated file (and a changelog), so updates build loyalty instead of support load. And every download is logged with IP, user agent and watermark ID — the exact chargeback trail described above, kept for you rather than assembled in a panic mid-dispute. For sellers distributing software or modules, it adds licence types, domain binding so a key can't be installed everywhere at once, and customer-portal management of all of it. It installs and configures from the back office, not from a developer invoice.

Where delivery meets the rest of your operation

Protecting and delivering the file is one link in a chain. A few neighbouring jobs decide whether the whole experience holds together:

• The mechanics of delivery only matter once the order exists cleanly — handling, editing and progressing those orders is its own discipline. See order management workflows and, for the inevitable "I sent them the wrong tier" moment, order editing after a customer submits.
• A buyer who loses the delivery email needs you to resend it — a small feature digital customers lean on constantly. Covered in resending order confirmations.
• Automating the status flow so "payment accepted" reliably triggers delivery is its own setup: order status workflow customization and automation.
• Before you launch, the test purchases you made while wiring all this up have to go — delete test orders before going live.

Frequently asked questions

Where does PrestaShop store the files customers download?

In the /download/ folder at the root of your install, renamed to a long SHA1 hash with no extension — never in a public web folder. That folder ships with an .htaccess that denies direct access, so guessing a URL gets a bot nothing. The actual download is brokered by a front controller (the get-file route on 1.7–8) that checks a download token, the order's paid/valid status, the expiry window and the remaining download count before streaming a single byte.

How many downloads should I allow per purchase?

Not 1. A customer who changes laptops, suffers a dropped connection, or wipes a disk needs another go. Three to five absorbs honest re-downloads without inviting wholesale sharing. Setting it to 1 is the single most common cause of "I lost my file" support tickets. Pair a sane count with re-download available from the customer's account.

Can I stop people sharing the file once they've bought it?

You can't make a file uncopyable — anyone claiming otherwise is selling DRM. The achievable goal is to make casual re-sharing traceable and slightly inconvenient. The three measures that carry almost all the weight: per-customer watermarking (stamp the buyer's name/email on every download), licence keys for software, and sensible download limits plus expiry. Heavyweight DRM (Adobe DRM, Widevine, FairPlay) adds friction for honest buyers and is broken by the people you worried about anyway.

Does PrestaShop watermark downloads or log them for chargebacks?

No. The native virtual product is secure and order-gated, but it doesn't watermark files, doesn't version them, doesn't generate or bind licence keys, and logs almost nothing useful for a payment dispute. Those gaps are the daily work of a serious digital seller — per-customer watermarking, automatic keyed delivery, version management and a download log with IP/user-agent are exactly what Digital Revolution adds.

How do I win a "I never received my download" chargeback?

Turn delivery into a logged event. Record every download with timestamp, IP, user agent and the order it belonged to — that's your tracking number. Send a delivery email that explicitly names what was bought and links to it, so "I got nothing" is contradicted in the customer's own inbox. Payment processors weigh disputes on whether the seller can show delivery, and a clean download log usually does.

The bottom line

Selling files looks effortless from the outside — no warehouse, no courier, pure margin. The work just moves somewhere less visible: into making sure the right person gets the file, the wrong people can't, the file improves over time, and every delivery leaves a record you can stand behind when money is on the line. PrestaShop hands you a secure, order-gated foundation for free; the value you add on top is watermarking, versioning, automatic keyed delivery, and a download log that wins disputes. Get those right and the "frictionless digital product" finally behaves like one — for the customer and for you.