Selling downloadable products

A PDF book, a font pack, a video course, a template. You upload the file to a variant and that variant is sold as a download: no shipping, a link of its own for each buyer, and only once the payment has been captured.

It is done on the product page, on each variant: Digital download.

Uploading the file

Pick the variant and upload the file. From then on:

• It is not shipped. The variant stops asking for a shipping rate and a delivery address. If you remove the last file, it becomes a physical product again.
• It goes per variant, not per product. That way you can sell the same course as "video only" and "video + materials" with different files, or a paper book and a PDF inside the same product.
• A variant can carry several files. The buyer gets all of them.

The limit per file is 100 MB. Change it with PCC_TOPE_DIGITAL_MB in the backend's .env. For something bigger, a whole course for instance, split the content into several files.

Files are stored in privado/digital, outside anything served publicly. Nobody reaches them with a URL: only with the signed link from their order. Under Docker they live in the privado volume, so they survive an upgrade.

What cannot be uploaded

exe, msi, bat, cmd, com, scr, ps1, vbs, js, jar, sh, app, dmg and apk are refused.

It is not that you cannot sell software: an executable downloaded loose from your domain is exactly what the customer's browser and antivirus treat as suspicious, and whoever gets that warning stops trusting your shop. Pack it in a ZIP and upload that.

The file name is cleaned on upload: letters, digits, spaces, dots, hyphens and brackets stay, up to 120 characters. It is the name the file downloads with.

How many times, and for how long

Two settings per variant, and both can be left empty:

• Downloads per purchase. Empty means no limit. With a number, each download takes one off and, when it reaches zero, the link stops working.
• Days of access. Empty means no expiry. With a number, the buyer can download it during those days, counted from when they place the order, not from when it is paid.

A limit stops a link shared on a forum from serving a thousand downloads. But set it too low and what you get is an email from the customer whose connection dropped halfway. Three to five is usually enough.

Links expire after 15 minutes

The buyer does not get a link to the file. They get an email that sends them to their order page — carrying the proof that the order is theirs — and that is where the download link is generated, signed and valid for 15 minutes.

So a link that gets copied, forwarded or left in the browser history stops working almost at once. If it expires, they go back to the order and get a new one. The download allowance and the days of access keep counting the same: the link is only the door, not the permission.

The signature uses PCC_CLAVE_CIFRADO or, if it is not set, JWT_SECRET. If you change that key, any links that were open stop working. Since they last 15 minutes, that is fine: going back to the order is enough.

Every download is logged with its date and the IP it came from.

Nothing downloads before it is paid

Access is created when the order is placed, but locked. It opens when the payment is marked as captured, and that is when the email goes out (its subject, for now, in Spanish: «Tus descargas del pedido»).

A bank-transfer order arrives before the money does. If downloads opened on ordering, anyone could order, download the file and never pay. With a physical product you still have the parcel; with a digital one, once it is downloaded there is nothing left to hold back.

If you refund the whole order, access is withdrawn. With a partial refund it stays.

Consent before delivery, in the EU

In the European Union (and in the European Economic Area, the UK and Turkey), someone buying at a distance has 14 days to withdraw. Digital content has an exception: the right is lost if the customer expressly asked for it to be delivered straight away and accepted that doing so meant losing it.

That is why, in those countries, checkout shows a checkbox and will not let the order go through without it ticked. The default text comes in English and in Spanish, in the customer's language; any other language gets the English one. In English:

I ask for the digital content to be supplied now, before the withdrawal period ends, and I understand that as soon as the download starts I lose my right of withdrawal for that part of the purchase.

In Spanish:

Pido que el contenido digital se me entregue ya, antes de que termine el plazo de desistimiento, y sé que en cuanto empiece la descarga pierdo el derecho a desistir de esa parte de la compra.

The acceptance is stored on the order, with the date, the text that was accepted and its version. And as soon as the first download starts, that order line no longer allows withdrawal: the withdrawal form leaves it out and says why.

Without the checkbox, the customer could download the file and withdraw afterwards. And you would have to refund them with no way of getting back what they took.

The confirmation travels in the order email

Ticking the box is not the end of it. The same rules that take the withdrawal right away also require the buyer to be given confirmation of that consent on a durable medium. Here that medium is the order confirmation email, the one that goes out the moment the order is placed.

When an order carries the consent, that email includes a Digital content section with:

• the exact text that was accepted, printed as it was stored and never translated. It is the record of what the person read, so translating it would make it a different text. What is around it — the heading, the sentence introducing it, the date — does follow the order's language, so an order placed in English shows an English heading over a Spanish text if that is what the customer read.
• the date the box was ticked.
• the version of the text.

It goes in both the HTML and the plain-text version of the email, because some mail clients only show the second one.

An order without digital consent gets no such section: no empty block, no heading on its own.

The order in which things happen is kept by the event queue: the confirmation email hangs off order placed, while downloads, game keys and licences are opened by payment captured, which is always queued afterwards. The written confirmation therefore leaves before the content is supplied.

Under Settings → Billing → Returns and digital content you decide two things:

• Ask for consent before delivering a download. It follows the shop's country: on in the EU, off where the law does not ask for it. You can turn it on in any country.
• Checkbox text, if you want other words. Your text replaces both default ones and is shown as written, in every language. Keep it saying both things: that it is delivered straight away and that withdrawal is lost. If one is missing, the checkbox is worth nothing.

Uploading a new version

If you upload a file with the same name as one the variant already has, it is not added: it is a new version that replaces the old one.

• Everyone who already bought it now downloads the new one, from the same order. There is nobody to notify by hand and nothing to resend.
• Their allowance is renewed: they get the variant's full number of downloads again, and the days of access count again from today. Someone who had used up their downloads, or let their access expire, has to be able to get the fix you have just published.
• The first time each buyer downloaded is kept. The new version does not touch it, because it is what shows the content was already delivered and withdrawal does not apply.
• Anyone whose access was withdrawn, after a refund for example, does not get it back.

With a different name, the file is added as one more, and existing buyers do not get it. If you want the update to reach them, keep the name: guide.pdf, not guide-v2.pdf.

Removing a file

A file that some buyer still has access to cannot be deleted. The panel tells you how many there are and suggests uploading a new version instead.

Deleting it would leave those people with a paid order and nothing to download. If what you wanted was to fix it, a new version does that without leaving anyone out.

What you need

• Email set up (SMTP_*). Without it, downloads still open on payment, but the notice waits in the queue until there is a way to send it.
• STOREFRONT_URL, so the email carries the link to the order page. Without it, the email only gives the order number.
• A theme that shows downloads on the order page. It asks for them at GET /tienda/pedidos/:id/descargas, and that route answers 403 without the proof that the order belongs to whoever is asking. The proof arrives in the email link (?acceso=), with checkout.complete, or by the buyer writing the email they bought with; the theme then sends it in the x-pcc-pedido header. The four factory themes do all of that, and so does the commerce contract (getDownloads(orderId, access) and requestOrderAccess). A theme that ignores it gets an empty list and the buyer sees no downloads.

PCC_DIAS_FICHEROS has nothing to do with this, even if it sounds like it: it is how many days the files that customers upload when personalising a product are kept (90 by default). It does not affect what you sell as a download.