Selling digital products in PrestaShop: access and delivery

What we would do

We would start with the native virtual product for a straightforward file sale, and add a licensing or storage integration only for a requirement it cannot meet. The route depends on your existing shop setup, payment modules, theme and account pages, ERP or other integrations, purchase data, customer markets and the team who will support access.

Make the change on an isolated staging copy with representative previous purchases as well as new orders. Rehearse the checks below with test payments and captured test emails, keeping live billing and fulfilment connections disabled. Agree a planned switch, recoverable file and configuration backups, and a way to reconcile orders taken during the change.

If you want the delivery options tested against your shop, the PrestaShop Module Selection & Fit Assessment can assess native settings, existing tools and module candidates on a controlled copy.

Create a virtual product and define access

Under Catalog > Products, create or edit the product and choose the real Virtual product type. The exact editor layout differs between versions. A standard product with zero shipping cost is still a physical product.

A cart containing only virtual items does not need a carrier delivery step in the standard checkout. A mixed cart retains delivery for its physical items. Billing, tax and customer-information requirements can still apply, so do not promise an address-free purchase in every shop.

1. Decide whether the product includes a downloadable file or is a service without one.
2. Upload the file through the virtual-product controls. Give the customer-facing filename a recognisable product/version name.
3. Set the permitted download count. A value of zero means no count limit in the native controller.
4. Set a calendar expiry and/or an access period only when they match the offer you sell. Explain the deadline before purchase.
5. Test purchase, payment, delivery email, account access and re-download before publishing.

Choose limits from your access policy and support workload. For example, three to five attempts and a 30- to 90-day period are possible policies for a one-off file, not standard recommendations for every product. Interrupted transfers, device changes and long-term access promises need a clear support process.

Upload size is affected by PHP settings such as upload_max_filesize and post_max_size, application limits, proxy limits and hosting policy. Test with the real package size. A large video file may need a separate delivery integration rather than simply a higher upload limit.

Work through a mixed order before launch

A buyer orders a printed manual and a companion PDF, then chooses bank transfer. Model the parcel and download as separate products if that is how you sell them, and rehearse this sequence:

1. While payment is pending, confirm that the PDF is unavailable and the buyer knows when access will start.
2. After verified payment, apply the tested order state and check the download email and file access while the parcel still awaits dispatch.
3. Complete the physical fulfilment and check that the carrier, shipping charge and warehouse export still describe the parcel correctly.

If an ERP only applies the validated state at dispatch, the digital buyer may wait for a parcel workflow. Agree the payment and fulfilment mappings before changing status flags across the shop.

Understand emails, accounts and download checks

Native delivery uses a separate download_product email, rather than a guaranteed link inside the original order_conf confirmation. The normal order-history flow sends the download message when an order containing downloadable products moves from a non-validated state to a logable state.

Actual file authorisation uses a different check: the current order state must have its paid flag enabled. A custom state with mismatched paid and validated flags can therefore send a link that cannot yet be used, or allow access without the expected email. Design these flags together.

Registered customers can reach downloads through their order details in the account. For a registered-customer order, the download controller requires the owning customer's login. A logged-out guest can use the download token with the guest order's ID and secure key. Keep these access credentials private.

In PrestaShop 1.7.8 and 9, GetFileController checks the download/order credentials, paid state, relevant customer ownership, available file, refund/return information, deadlines and usage count before streaming the file. A customer who cannot download may be encountering any one of those checks.

A tokenised link is still copyable. Limits and expiry constrain access to the server, but neither makes the downloaded file unshareable. Core increments the usage counter before streaming, so an interrupted transfer can consume an attempt. Avoid putting complete download URLs in public screenshots, analytics events, support tickets visible to others or shared logs.

For manual payments, tell the buyer when access becomes available and verify the payment before using a paid state. Test pending, successful, cancelled, failed and refunded orders as well as guests and registered customers.

Trace a missing download without changing unrelated settings

1. Identify the order and payment reference, then inspect the current paid flag and the state transition that should have triggered the download email.
2. Reproduce the buyer's access route: the owning account for a registered order, or the guest credentials for a guest order. Do not test every case with an administrator account.
3. Check the order's usage count and deadline alongside the current product-download record and file. A correct product screen does not prove that an older purchase is still eligible.
4. If account access works but the email is missing, inspect the download-message send attempt, recipient address and mail delivery result before altering download rights.
5. Use the supported correction for the affected purchase, and confirm the customer can retry. Avoid opening access for unpaid orders or resetting limits across the catalogue to solve an individual case.

Keep product defaults and purchase records separate

The native product_download record contains file information, the displayed filename, count limit and product-level expiry. The order detail carries a download hash, usage counter and deadline. The access-period deadline is calculated when the order detail is created, rather than when a later payment clears. A bank-transfer order can therefore become paid after its download window has already ended. Rehearse that delay and define a supported way to honour the access you promised without extending every customer's deadline.

These are not wholly independent snapshots. When serving a download, core joins the current product-download record. Changing the file, product-level limit or expiry can affect existing purchasers. The order-detail usage count and deadline still apply.

Test the effect of replacing a file on a previous order before using replacement as an update policy. Keep a recoverable copy of the old release and document what customers are entitled to receive. Do not remove a purchased file without a migration or support plan. For example, replace a template on staging and re-download through an older paid order as well as a new purchase. Check the contents of the archive, not only its displayed filename, so you know which release each buyer actually receives.

Core does not provide a complete release catalogue, update-notification and licence-entitlement system. If you need versions, define which releases remain active, the update period, renewal rules, changelogs and how customers find eligible updates. Verify any notification workflow separately from release access.

Native pack membership does not automatically create individual download entitlements for all its virtual components. For a multi-file purchase, use one suitable archive or a bundle-fulfilment implementation that you have tested. A mixed physical-and-digital offer also needs deliberate modelling of its fulfilment and access rules.

Protect storage and choose a delivery model

Native virtual-product files are stored under the shop's download/ directory with internal filenames. The filename is not the access-control boundary. Test that direct HTTP access to a known test file is denied on the actual deployment.

Apache .htaccess protection depends on Apache reading the file and allowing its directives. Nginx does not process .htaccess; it needs equivalent server rules. Check any CDN or object-storage origin separately. Disable directory listing and avoid accidental public copies in backup or media folders.

There is no universal file-size boundary between these models. Native streaming attempts set_time_limit(0), so PHP execution time is not necessarily the fixed limit. Hosting restrictions, PHP worker availability and web-server or proxy timeouts can still interrupt transfers. Test concurrent downloads and slow connections.

Issue a signed URL only after checking entitlement, and keep its lifetime appropriate to download size and retry needs. A temporary URL remains shareable while valid. Storage delivery does not replace purchase authorisation.

Use a combination of access rules and suitable file protection. Native virtual products do not watermark files: document or image stamping needs a suitable extension or custom development, and software-package tracing is a separate implementation. Watermarking can help trace a copy but does not prove who redistributed it. A downloaded file can still be copied. If you commission personalisation, choose the least identifying marker that meets the purpose, such as an order reference, and test that stamping leaves the document readable and the package usable.

For software, decide whether activation, periodic checks or domain binding fits your licence terms and offline needs. Plan behaviour during a licence-server outage, domain migration or recovery. Evaluate DRM against compatibility, access and support costs rather than treating it as universally effective or universally unsuitable.

Design software licences and release entitlements

Native virtual products deliver files; they do not issue unique software licence keys. Choose a licensing model before advertising activation or update rights.

These are general models, not features of every digital-delivery extension. Verify how your chosen system handles pending payment, activation, refunds, chargebacks, expired rights and duplicate payment notifications.

For domain-bound software, define the permitted production domains, staging policy, reassignment confirmation and any waiting period. Check that the licence belongs to the customer before issuing a download, and enforce any domain restriction at the point where your licensing workflow binds the package.

Separate support expiry from historical release access. A policy might allow eligible releases published during coverage while requiring renewal for later releases. Check release activation, package validation and compatibility before publishing a new ZIP.

For Digital Revolution's generated licences, domain assignments, eligible releases and supported ZIP-package tracing, use the Digital Revolution help page; its confirmation email provides activation instructions and a licence-portal link rather than a guaranteed key and download token in the message.

Price the rights and ongoing delivery

Price against the value and rights offered, while accounting for payment fees, bandwidth, delivery infrastructure and support. Related assets can be sold together if the fulfilment model supports them. Recurring access needs a tested billing and entitlement integration. Avoid undefined promises such as lifetime access or lifetime updates without a clear policy for retirement and continuity. Creating another file copy may be cheap, but serving and supporting another customer still has costs.

Make a permission tier understandable before purchase

Suppose you sell the same design template for personal use and for commercial client work. Describe the permitted use on each offer, then check that the order, receipt and any licence record identify the tier purchased. A higher price alone does not tell the buyer what extra rights they receive.

If you bundle the template with related assets, check that the delivered archive contains everything advertised. Before discounting the bundle, compare its proceeds with payment, delivery and expected support costs, and consider whether existing buyers would simply switch from the individual offers.

Separate hosted demos from downloadable trials

A hosted demo is a separate test shop for trying a module's workflow. Compatibility with your own theme, modules, data and server needs testing in a suitable copy of your shop. If a downloadable trial is available, use it for that test.

Hosted demos need a provisioning service with compatible PrestaShop versions, capacity, expiry, isolation and cleanup. Installing a shop module alone does not supply that infrastructure. Keep credentials temporary and avoid real customer data or live payment credentials.

A trial package may be prepared for a named domain or bind on first installation, depending on the implementation and release compatibility. Define its duration, download limits, renewal/purchase route and what happens at expiry. Test install, activation, uninstall and conversion to a paid licence.

For Digital Revolution's infrastructure-specific hosted demos and supported downloadable trial packages, use the Digital Revolution help page; hosted launches depend on its separate orchestrator, supported demo domains, service availability and capacity.

Before making a demo action public, test the launch page, any version choice, terms and privacy acceptance, progress and error states, access links, expiry and removal. Display a useful response when maintenance, limits or an unavailable release prevent a launch.

Configure tax for the actual digital supply

Classify what you sell before selecting rates. An automatically supplied download, a live instructor-led course and a physical item with a PDF are not interchangeable VAT cases. Product classification and customer type matter as well as country.

For EU B2C telecommunications, broadcasting and electronically supplied services, destination taxation is the general rule. An eligible supplier established only in one Member State can use the €10,000 threshold when combined qualifying cross-border TBE supplies and intra-EU distance sales, excluding VAT, stay within it in both the current and preceding calendar year. The supplier can elect destination treatment instead.

OSS is optional. If chosen, apply the relevant scheme to all supplies within its scope; it does not replace every domestic return or automatically cover every EU sale. Where OSS is not used, local registrations may be required. See the Commission's OSS and threshold guidance.

For customer location, statutory presumptions apply in defined cases. Otherwise the general rule uses two non-conflicting location records. For the relevant services supplied from an EU business or fixed establishment, a separate €100,000 simplification can allow one qualifying record supplied by another person involved in the service, rather than by you or the customer. The covered value excluding VAT must not exceed that threshold in either the current or preceding calendar year. It is not the €10,000 place-of-supply threshold. See Article 24b of Regulation 282/2011.

In PrestaShop, configure the appropriate tax-rules group under International > Taxes and attach it to the product. Test the address basis and rates for actual cases; the virtual-product type does not determine the tax classification or assemble a complete location-record trail for you.

B2B treatment requires the applicable place-of-supply and reverse-charge conditions, not simply a successful VAT-number lookup. Keep required validation and transaction records. For the validation integration, use the Automatic EU VAT Checker help page.

Check current rates, classifications and reporting with your tax adviser before launch, and reconcile exports with the appropriate returns. See the prices and VAT guide for shop configuration.

Keep useful delivery records and test failure paths

Keep proportionate records linking the purchase, accepted terms, release, authorisation and download attempt. A useful delivery log can include timestamp, order/customer identifier, release, result and necessary network/client information. Distinguish a requested or authorised download from a completed transfer.

Set retention and access controls, and avoid logging usable tokens or secrets. Preserve relevant records when responding to an incident or payment dispute. Delivery records can support a response, but cannot guarantee a card issuer's decision or prove that the customer personally used the file.

Check that the download email names the purchased product and tells registered buyers where to find it under My account > Order history in the order details, then test the email link and account access separately. Resending a status email or order confirmation is not automatically resending the native download message. For related payment, notification and correction behaviour, use the order workflows guide.

Rehearse the switch and give staff a recovery route

1. Record the current file versions, access settings, order-state mappings and published terms. Keep recoverable originals before replacing packages or changing entitlement tools.
2. Run the test table above and retain the results against the tested shop, module releases and configuration. Include previous purchases from before the change, rather than relying entirely on fresh test orders.
3. Agree who makes the switch and who reconciles new purchases, notifications and access records. Control catalogue and release edits during the switch so staff know which package is live.
4. Watch the first live delivery outcomes and support reports. If reversal is needed, restore the affected configuration or files while preserving new paid orders and their access rights; restoring an old database alone can lose those purchases.

What to ask your developer or agency

• Which existing theme, payment and ERP behaviours affect the delivery path, and where is the evidence that they were tested together?
• What still works when storage or licence validation is unavailable, and who handles an interrupted transfer or blocked activation?
• Which supported action resends the actual download message or repairs an entitlement, and which redacted records can staff use to diagnose it?
• If the delivery extension is removed later, how will you recover the files, ownership records and release rights needed to serve existing buyers?

Questions owners ask

Can I move previous buyers to a new delivery system?

Ask for a supported import and reconciliation plan that maps paid order lines to ownership, eligible releases and remaining rights. Resolve unmatched purchases before retiring the previous route.

What if someone asks to move a purchase to another account?

Verify ownership against the purchase record and use the supported customer-correction process. A request from an email address alone should not transfer a software entitlement.

Can support fix access without my customer's password?

Give staff a documented recovery procedure and access to the necessary order and entitlement records. They should not need the customer's password or a live download link pasted into a shared channel.

What happens if I stop selling the product?

Decide how entitled releases, licence validation and support will continue when new sales stop. Keep the promised access route available or arrange the transition before retiring its dependencies.