A duty-free pre-order platform is more than an eCommerce website with a pickup option.
The platform needs to understand the traveller, journey, location, stock availability, product eligibility, payment flow, pickup process and the retailer’s existing technology environment.
For a duty-free retailer, the real challenge is usually not building the product catalogue. It is connecting the digital storefront with existing systems such as SAP, Microsoft Dynamics, Dynamics NAV/Navision, Zoho, POS, inventory, warehouse or custom retail software.
A modern pre-order platform can sit on top of these existing systems and synchronise products, SKUs, stock, prices, offers, orders, cancellations, refunds and fulfilment status.
This model can support duty-free retail across:
At iDigitalize, we have experience working on digital commerce solutions associated with Le Marché, Ospree Duty Free, Colombo Duty Free, Mumbai Duty Free and Go Duty Free.
This guide explains how duty-free operators can plan a modern pre-order platform without unnecessarily replacing the retail systems they already use.
| Project Type | Typical Budget | Typical Timeline |
| Discovery & architecture | €5,000–€10,000 | 3–5 weeks |
| Focused pre-order website | €20,000–€35,000 | 4–6 months |
| Shopify/WooCommerce + integrations | €25,000–€45,000 | 4–7 months |
| POS/ERP-integrated platform | €40,000–€70,000 | 6–9 months |
| Multi-location travel retail platform | €60,000–€100,000+ | 7–12+ months |
These are planning ranges rather than fixed quotations. Integration complexity, journey rules, store count and compliance requirements can significantly affect the final scope.
A duty-free pre-order platform allows eligible travellers to browse products before travelling, reserve or purchase them online and collect their order at an approved location.
A typical journey might look like:
Choose location → enter travel details → browse eligible products → add to basket → verify traveller → pay or reserve → receive pickup instructions → collect order
Behind this customer journey, the platform may need to connect with:
The customer sees one smooth experience. The technology behind it may involve several systems working together.
A normal online shop mainly needs to understand the customer, product and delivery address.
A duty-free platform also needs to understand the travel journey.
Depending on the location and operating model, the system may need to consider:
A traveller may be eligible to purchase one product on one route but not on another.
That means journey logic becomes part of the commerce platform.
| Business | Common Use Case |
| Airport duty-free retailer | Pre-order before departure or arrival |
| Ferry operator | Reserve before boarding or collect onboard |
| Seaport retailer | Passenger pre-order |
| Cruise terminal retailer | Journey-linked shopping |
| Eurotunnel retailer | Pre-order before crossing |
| Border retail | Journey-based click & collect |
| Multi-location retailer | One platform across several locations |
| Travel retail group | Centralised commerce and inventory visibility |
The business case is strongest where physical stores already have good passenger traffic but digital pre-order remains limited.
Do not start by asking which commerce platform should be used.
Start with the traveller journey.
For example:
Select location → choose departure or arrival → enter travel details → browse permitted products → add to basket → check limits → pay or reserve → collect
This process helps clarify:
The technology decision becomes much easier once the journey is understood.
The platform may need to identify:
For retailers operating across several locations, availability and pricing may differ by location.
Useful travel data may include
Some of the information can be auto-validated where travel APIs can be trusted.
Depending on local requirements, the platform may ask for traveller details such as:
Collect only the data necessary for the transaction.
Sensitive data should be encrypted, access-controlled and retained only as required.
A duty-free catalogue may include:
The same product may not be available at every location.
The platform therefore needs to support location-based catalogue and stock rules.
Product information should not need to be manually maintained in several systems.
A better setup is to define which system owns each type of information and synchronise it with the pre-order platform.
| Data | Typical Source |
| SKU | ERP / PIM |
| Product name | ERP / PIM |
| Price | ERP / POS |
| Stock | ERP / POS / WMS |
| Promotion | ERP / POS / Promotion engine |
| Online order | Website |
| Customer record | Website / CRM |
| Refund status | ERP / Payment / POS |
The retailer should establish one clear master source for each important data field.
Customers expect a pre-ordered product to be available when they arrive.
The platform may therefore need to consider:
For high-volume operations, near-real-time stock synchronisation may be necessary.
For lower-volume environments, scheduled synchronisation may be sufficient.
The correct approach depends on store operations and the cost of stock errors.
Compliance needs to be part of the customer journey, not an afterthought.
The platform may require rules for:
Ideally, these rules should be configurable.
Hard-coding every rule into the storefront makes future changes difficult and expensive.
Alcohol and tobacco commonly require tighter control than standard products.
A practical rules flow might look like:
Journey + traveller age + destination + product category + basket quantity = eligible / restricted / limit reached
When a limit is reached, the customer should see a clear explanation immediately.
The platform should support the retailer’s legal and compliance rules, but the retailer should always confirm the exact requirements applicable to its jurisdiction and route.
Travel retail depends heavily on promotions.
The platform may need to support:
Where promotions already exist in ERP or POS, synchronising them is often better than maintaining separate offers manually.
There is no single checkout model for every duty-free retailer.
| Model | Customer Experience |
| Reserve & collect | Reserve online, pay in store |
| Pre-order & pay | Pay online, collect later |
| Deposit | Pay part online, balance at collection |
| Member reservation | Logged-in traveller reserves products |
| Assisted order | Store or support team manages part of the order |
The right model depends on local regulations, payment processes, POS capabilities and store operations.
The customer-facing website is only one half of the process.
Store staff need clear visibility of:
The fulfilment workflow can either sit inside the new platform or connect with the retailer’s existing POS or order system.
For most duty-free projects, integration is the most important technical layer.
The digital platform may need to connect with:
The goal should usually be to integrate existing systems rather than replace them unnecessarily.
| Information | Typical Flow |
| SKU | ERP/PIM → Website |
| Price | ERP/POS → Website |
| Stock | ERP/POS/WMS → Website |
| Offer | ERP/POS → Website |
| Order | Website → ERP/POS |
| Customer | Website ↔ CRM |
| Cancellation | Website ↔ ERP/POS |
| Refund | Payment/POS/ERP ↔ Website |
| Fulfilment status | Store/POS → Website |
| Pickup status | Store system → Website |
Some information may need real-time APIs. Other data may be synchronised on a schedule.
This is common in older travel retail environments.
It does not automatically mean the ERP must be replaced.
A custom integration layer can connect with legacy systems through methods such as:
The objective is to modernise the digital experience while protecting stable store operations.
A practical architecture may look like:
Traveller website
↓
Commerce platform
↓
API / middleware layer
↓
ERP + POS + Inventory + CRM + Payment
↓
Store fulfilment
This approach keeps system logic away from the frontend and makes future integrations easier to manage.
| Layer | Common Options |
| Frontend | React / Next.js |
| Commerce | Shopify / WooCommerce / Custom |
| Microsoft ecosystem | Dynamics 365 Commerce |
| Backend | Node.js / .NET / Java |
| Database | PostgreSQL / SQL Server |
| Integration | REST APIs / middleware/custom connectors |
| ERP | SAP / Dynamics / NAV/others |
| CRM | Dynamics / Zoho / Salesforce |
| Cloud | Azure / AWS |
| Search | Elasticsearch / OpenSearch |
| Payments | Region-specific gateway |
| Analytics | GA4 / BI/product analytics |
The right stack depends on the current systems and plans of the retailer.
Shopify is useful when the retailer wants faster commerce deployment and standard eCommerce capabilities already cover most of the storefront.
Custom development can then address:
WooCommerce is a good choice for retailers who want WordPress flexibility and moderate-scale commerce.
It can support:
Don’t rely on too many plugins for business-critical logic in complex environments.
Custom development becomes more suitable when the retailer has:
Retailers already operating in the Microsoft ecosystem may benefit from Dynamics 365 Commerce, particularly where store operations, ERP and digital commerce are already connected.
A headless model separates the customer experience from the commerce engine.
This can work particularly well where the retailer needs a highly customised travel journey but does not want to rebuild every standard commerce function.
It can provide more control over:
while still relying on a mature commerce backend.
| Project Scope | Typical Budget |
| Discovery & architecture | €5,000–€10,000 |
| Focused pre-order website | €20,000–€35,000 |
| Shopify/WooCommerce + custom integration | €25,000–€45,000 |
| ERP/POS-integrated platform | €40,000–€70,000 |
| Multi-location platform | €60,000–€100,000+ |
The main cost drivers are usually integration, business rules and operational workflows rather than page count.
Costs usually increase when the project requires:
A simple-looking platform can still require significant engineering if the backend integration is complex.
| Role | Responsibility |
| Business Analyst | Retail and travel workflow |
| Product Lead | Commercial priorities |
| UX/UI Designer | Traveller experience |
| Solution Architect | Technical architecture |
| Frontend Developer | Customer website |
| Backend Developer | Business logic |
| Commerce Developer | Shopify/WooCommerce/custom |
| Integration Engineer | ERP/POS/API integration |
| QA Engineer | Testing |
| DevOps Engineer | Cloud and deployment |
| Project Manager | Delivery |
Larger projects may also need ERP specialists, POS specialists, security engineers and onsite implementation resources.
1. Discovery
Understand locations, journeys, fulfilment, regulations and existing systems.
2. Technology Audit
Review ERP, POS, Inventory, CRM & Payment Systems.
3. UX Prototype
Full traveller journey design & testing prior to development.
4. Architecture
Define commerce platform, integration layer, cloud environment, security and data ownership.
5. Development
Build shopfront, back-end and operational workflows.
6. Integration
Connect ERP, POS, inventory, CRM and payments.
7. Testing
Test complete order, stock, payment and pickup journeys.
8. UAT
Store and operations teams test real-world scenarios.
9. Controlled Launch
Start with a limited location or group where practical.
10. Scale
Add more stores, routes, features and markets after the platform is stable.
| Test Type | What It Checks |
| Functional | Browse, basket, checkout, pickup |
| Integration | ERP/POS/API data flow |
| Inventory | Stock accuracy and reservation |
| Eligibility | Journey and traveller rules |
| Compliance | Category and quantity limits |
| Payment | Success, failure, refund |
| Promotion | Discount and offer logic |
| Performance | Peak traffic behaviour |
| Security | APIs, authentication and data |
| UAT | Real store and customer journeys |
| Regression | Existing features after updates |
Testing should cover real operational scenarios, not only happy-path customer journeys.
A cancellation may affect several systems.
A complete workflow may need to:
This logic should be designed early because incomplete cancellation workflows create reconciliation problems later.
A pre-order platform requires ongoing investment.
Typical recurring costs include:
A practical annual maintenance budget may be around 10–20% of the original development cost, depending on platform complexity and support requirements.
| Objective | KPI |
| Grow digital sales | Pre-order revenue |
| Increase basket size | Average order value |
| Improve conversion | Browse-to-order rate |
| Improve fulfilment | Successful pickup rate |
| Reduce stock issues | Unfulfilled order rate |
| Grow adoption | Repeat pre-order users |
| Improve efficiency | Preparation time |
| Improve reliability | Integration failure rate |
| Measure offers | Promotion conversion |
The best KPI is not just traffic.
A strong platform should increase the number of customers who can successfully order and collect with minimal manual intervention.
| Current Situation | Better Option |
| ERP works, no online pre-order | Build commerce layer |
| Website exists, no system integration | Integrate |
| Platform is outdated | Modernise |
| Several stores use different systems | Add middleware/integration layer |
| Existing platform cannot scale | Re-architect |
| Core retail technology no longer works | Consider replacement |
For many operators, modernising around the existing ERP and POS is more practical than rebuilding the complete retail technology environment.
Prepare the following information before speaking with a development company:
This allows the development partner to estimate the project based on real operational complexity.
A strong partner should understand both digital commerce and retail system integration.
Ask:
A company that only discusses website design is unlikely to solve the complete travel retail challenge.
iDigitalize has experience developing and supporting digital commerce solutions associated with:
Our approach is based on working with the retailer’s existing environment rather than forcing unnecessary technology replacement.
We can connect pre-order commerce with platforms such as SAP, Microsoft Dynamics, Dynamics NAV/Navision, Zoho, POS, inventory systems and custom retail software.
Depending on the requirement, the customer-facing commerce layer can be developed using:
The goal is to keep products, stock, prices, offers, orders, cancellations, refunds and fulfilment status synchronised while providing travellers with a simple online experience.
A successful duty-free pre-order platform needs to connect the traveller journey with store operations.
That means planning commerce, ERP, POS, stock, compliance, payment and fulfilment together.
iDigitalize can support:
If you already operate physical duty-free stores, start with the systems and workflows you already have.
Share your ERP, POS, store locations, catalogue and traveller journey with iDigitalize.
We can help define:
Build the digital platform around your retail operation, not the other way around.
1. How much does a duty-free pre-order platform cost?
A focused pre-order website may cost around €20,000–€35,000. ERP/POS-integrated platforms commonly move towards €40,000–€70,000, while larger multi-location platforms may exceed €60,000–€100,000+.
2. Can we integrate an existing SAP or Microsoft Dynamics system?
Yes. Depending on the available interfaces, most ERP systems can be integrated through APIs, middleware or custom connectors.
3. Can we keep our existing POS?
Yes, in many cases. The new commerce platform can sit above the existing POS and exchange products, orders, stock and fulfilment information.
4. Can Shopify be used?
Shopify can work well in environments where the standard commerce requirements are strong and the ability to add travel-specific logic via custom development and integrations.
5. Can WooCommerce work for duty-free pre-order?
Yes. It can be suitable for moderate scale projects which require WordPress flexibility if the critical business logic is carefully engineered.
6. Does the platform need passport information?
Not necessarily. This depends on the retailer’s operating model and local compliance obligations.
7. How are tobacco and alcohol limits managed?
The platform can apply configurable rules based on product category, quantity, destination, journey and customer eligibility.
8. Can stock be shown in real time?
Yes, if the connected ERP, POS or inventory system can provide current stock data.
9. Can offers be synchronised from ERP or POS?
Yes, where the source system supports it.
10. Can one platform support airports, ports and ferries?
Yes. A multi-location architecture can support different stores, inventories, journeys and pickup points from a single platform.
11. How long does development take?
A focused platform may take around four to six months. More complex POS/ERP-integrated platforms may require six to ten months or more.
