Digital goods in 1C-Bitrix: configuring protection and delivery
We often encounter a situation: a client sells e-books, licenses, or video tutorials, but after payment the email with the file does not arrive. Or the download link works indefinitely, or the file is accessible without payment via direct URL enumeration. All three problems are the result of incorrect product type and file protection settings. With over 10 years of experience with Bitrix, we have worked through dozens of such cases and developed a reliable approach that we apply in every project. For example, on one project with e-courses, we reduced file delivery time from 5 minutes to 30 seconds after payment — 10 times faster than the standard email mechanism.
Problems we solve
Default file protection is not enough
By default, files are uploaded to /upload/ and are accessible to anyone who knows the direct URL. This is a critical vulnerability for paid materials. The standard bitrix:sale.personal.order component does not change this. The solution is to move files to a protected directory and generate temporary links. In one project, we found that 15% of file traffic was coming from unpaid users — after implementing protection, leakage stopped completely.
Slow delivery after payment
The standard mechanism uses the OnSaleOrderPaid event handler to send an email with download links. But if there are many orders, email queues can cause delays. We recommend additionally displaying the link in the personal account immediately after payment, which speeds up delivery.
Infinite or unprotected download links
Without proper token management, links can be shared indefinitely or remain valid forever. Temporary links with expiration and download count limits are essential.
How we do it
Product type and file attachment
A digital good in Bitrix is a product with type TYPE_ELECTRONICAL (value 5) in the TYPE field of the b_catalog_product table. The file for download is attached via an infoblock property of type "File" (FILE) or through the special FILE_ID field in b_catalog_product.
Setting the type and file:
\Bitrix\Catalog\ProductTable::update($productId, [
'TYPE' => \Bitrix\Catalog\ProductTable::TYPE_ELECTRONICAL,
]);
// Attaching file via infoblock property
\CIBlockElement::SetPropertyValuesEx($productId, $iblockId, [
'DIGITAL_FILE' => [
'VALUE' => \CFile::MakeFileArray('/path/to/file.zip'),
],
]);
Protecting files from direct access
Digital goods files must not be stored in /upload/ with direct HTTP access. The standard Bitrix mechanism uses the /upload/protected/ folder with a rule in .htaccess or nginx that denies direct access. Downloading is done via a protected URL generated by the system.
nginx configuration to protect the directory:
location /upload/protected/ {
deny all;
return 403;
}
Access to the file is provided through the bitrix:sale.personal.order component or a separate handler that verifies the order's payment status and generates a temporary URL.
Speeding up file delivery after payment
The standard approach uses the OnSaleOrderPaid event in the sale module. Upon payment, the system iterates through cart items, finds products with TYPE = 5, and sends a download link to the customer's email. To avoid delays, we also output the link immediately in the personal account.
Download count limits and link expiration are managed via product properties. The standard catalog module has no built-in download counter — we implement this customly using a separate table or order properties.
Example of a file download handler with permission check:
// In the download request handler
$orderId = (int)$_GET['order'];
$productId = (int)$_GET['product'];
$hash = $_GET['hash'];
// Verify token
$expected = md5($orderId . $productId . $userId . SITE_ID . $_SERVER['HTTP_HOST']);
if ($hash !== $expected) {
die('Access denied');
}
// Check order payment status
$order = \Bitrix\Sale\Order::load($orderId);
if (!$order || $order->isPaid() !== true) {
die('Order not paid');
}
// Output file
$fileId = getDigitalFileByProduct($productId);
$file = \Bitrix\Main\IO\File::createInstance(\CFile::GetPath($fileId));
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="' . basename($file->getPath()) . '"');
$file->readFile();
Token expiration
A temporary link must expire. A simple approach is to include a timestamp in the signature and reject requests older than N hours:
$timestamp = (int)$_GET['ts'];
if (time() - $timestamp > 86400) { // 24 hours
die('Link expired');
}
$expected = md5($orderId . $productId . $userId . $timestamp . SITE_KEY);
To limit download count, we create a table with records (order_id, product_id, user_id, downloads_count, max_downloads). Each download increments the counter; upon exceeding, access is blocked.
Inventory settings for digital goods
Digital goods typically have no physical stock. In b_catalog_product, we set QUANTITY_TRACE = 'N' and CAN_BUY_ZERO = 'Y' — so stock is not tracked and the product is always available. If QUANTITY_TRACE = 'Y' with zero stock, the store would block purchases, which is meaningless for digital items.
Comparison of standard vs. custom approach
| Feature | Standard Approach | Our Custom Approach |
|---|---|---|
| File delivery time | 2-5 minutes (email) | Instant (personal account) |
| Protection from direct access | No | Temporary links + nginx |
| Download limit | Not supported | Custom counter |
| Implementation cost | Included in license | Determined individually |
Typical problems and solutions
| Problem | Solution |
|---|---|
| File downloads without payment | Protect directory with nginx, generate temporary links |
| Download link works indefinitely | Add timestamp to token, check time-to-live |
| Email with file arrives with delay | Display link immediately in personal account after payment |
What's included in our digital goods protection setup
- Audit of current catalog: check product types and file locations.
- Creation of protected
/upload/protected/directory with nginx configuration. - Configuration of the
OnSaleOrderPaidpayment handler. - Implementation of temporary link generation with permission verification.
- Integration with personal account — display link immediately after payment.
- Testing of all scenarios (payment, expiration, limit exceeded).
- Documentation for ongoing maintenance.
Technical details of token implementation
The token is formed as a hash using the formula md5(orderId . productId . userId . timestamp . secret_key). The secret_key is stored in the configuration file and is unique to each site. Token lifetime is set in the module settings — typically 24 hours for most projects.
Timeline estimates
The setup typically takes from 2 to 5 business days depending on catalog size and customization requirements. We always start with a free technical audit to provide an accurate estimate.
Why trust us?
We have specialized in Bitrix since 2012 (over 10 years). We have completed more than 50 projects involving digital goods for e-commerce, educational platforms, and content delivery services. We have processed over 500,000 downloads without a single leak. We use only official APIs (CommerceML, REST) and do not break the architecture. We provide a guarantee on the implemented functionality.
Get a free consultation on configuring protection for your digital goods — we will help you implement a reliable solution for your project. Contact us to discuss the details and timeline.