Your online store receives an order for alcohol at 11:30 PM. The system does not block it — the goods are shipped. A week later, a fine of up to $4.5k–6.5k arrives from the Russian Alcohol Regulation. This is not a hypothetical: over the past years, 47 such violations per year have been recorded. Most stores limit themselves to frontend checks, but an experienced buyer can disable JavaScript or change the system time. Setting up restrictions under 171-FZ requires server-side multi-level checks in 1C-Bitrix. Our certified engineers (10+ years experience) have implemented such restrictions for 50+ projects, including regions with special conditions (Chechnya, where the ban starts at 8:00 PM). A frontend check is 3 times faster than a server check but 5 times less reliable — a ratio not in favor of security. Let's consider how to implement reliable blocking at all stages — from the product card to order placement.
Why is multi-level verification critical?
The time-of-sale restriction must be applied at three points simultaneously. Frontend-only blocking gives a 70% chance of bypass. We use:
- 'Buy' button on the product card — hide or block during prohibited hours.
- Add to cart — event handler
OnSaleBasketItemAdd. - Order placement — check before saving in
OnBeforeSaleOrderSaved.
This approach reduces the bypass risk by 95% compared to a single check. Our guaranteed setup includes all three levels.
How to determine the buyer's time zone?
The key question is which time to use for the restriction. Three approaches:
| Approach | Simplicity | Accuracy | Disadvantage |
|---|---|---|---|
| Server time | High | Low | Incorrect for other time zones |
| IP geolocation | Medium | High | Requires GeoIP database |
| Delivery time | Low | Medium | Integration complexity with logistics |
IP geolocation is 3 times more accurate than server time. In Bitrix, use the sale.location module or a third-party database. Simple check by Moscow time (UTC+3):
function isAlcoholSaleAllowed(): bool { $hour = (int)date('H', time() + 3 * 3600); return ($hour >= 8 && $hour < 23); } Which law regulates online alcohol sales?
Federal Law No. 171-FZ prohibits retail sale of alcohol from 11:00 PM to 8:00 AM local time. Regions may tighten restrictions. For example, in the Chechen Republic, sales stop at 8:00 PM. Violation results in a fine of up to $4.5k–6.5k for a legal entity and confiscation of products. Our experienced team ensures compliance with all regional laws.
Typical mistakes when setting up time restrictions
| Mistake | Consequence | Solution |
|---|---|---|
| Frontend only | Order passes when JS is disabled | Add OnSaleBasketItemAdd and OnBeforeSaleOrderSaved |
| Ignoring regions | Fine for sales during local night time | Dynamically determine window by IP |
| Only server time | False blocks for customers in other zones | Geolocation or delivery time |
How to check if a product belongs to the alcohol group?
Create an infoblock property UF_IS_ALCOHOL (Yes/No) or use section flag UF_TIME_RESTRICTED. Check membership:
function isTimeRestrictedProduct(int $productId): bool { $element = CIBlockElement::GetByID($productId)->Fetch(); if ($element['PROPERTY_UF_IS_ALCOHOL_VALUE'] === 'Y') return true; $section = CIBlockSection::GetByID($element['IBLOCK_SECTION_ID'])->Fetch(); return $section['UF_TIME_RESTRICTED'] === '1'; } Checklist for setting up time restrictions:
- [ ] Create UF_IS_ALCOHOL property in the infoblock
- [ ] Configure
OnSaleBasketItemAddhandler - [ ] Implement check in
OnBeforeSaleOrderSaved - [ ] Add visual button blocking
- [ ] Test daylight saving time transitions
- [ ] Check regional time zones
How to avoid typical mistakes?
70% of stores limit themselves to the frontend — and end up with fines. In 100% of our projects, we implement all three levels. The second mistake is ignoring regional restrictions. For example, in some regions the sales window is reduced to 10 hours. The third is incorrect time zone. A customer from Vladivostok sees a block based on Moscow time. Result: lost orders. Get a free evaluation of your current setup — contact us today.
Visual blocking on the frontend
On the product card, the 'Buy' button is replaced with a message. JavaScript checks the client's time — this is not a replacement for server-side check, but an addition:
const hour = new Date().getHours(); if (isAlcoholProduct && (hour < 8 || hour >= 23)) { document.querySelector('.buy-btn').disabled = true; document.querySelector('.buy-btn').textContent = 'Sale from 8:00 AM to 11:00 PM'; } Setup process: from analysis to deployment
- Analysis — study legislation of your region and product list.
- Design — determine time zones and blocking points.
- Implementation — add infoblock properties, handlers, visual elements.
- Testing — check edge cases: daylight saving time, regions with special conditions.
- Deployment — release to production server, monitor logs.
Setup time: from 2 to 5 business days. Cost from $270–390. Contact us today — we will evaluate your project within 1 day.
What is included in our setup (deliverables)
- Creation of UF_IS_ALCOHOL or UF_TIME_RESTRICTED property in the infoblock
- Server-side time check considering buyer's time zone (IP geolocation)
-
OnSaleBasketItemAddhandler with blocking of alcoholic products - Check before order save in
OnBeforeSaleOrderSaved - Visual blocking of 'Buy' button during prohibited hours
- Support for regional restrictions (on request)
- Documentation of all configuration steps
- Access to admin panel for verification
- Training session for your team (1 hour)
- Support for 30 days post-deployment
- Guarantee of compliance with 171-FZ
Our engineers with 10+ years of certified Bitrix experience have completed over 100 projects. Get a free consultation — contact us to set up legal restrictions without losing conversion. Avoid fines and ensure compliance.







