Odoo eCommerce Implementation
Online shop with payment + shipping.
Full-stack eCommerce with product variants, pricelists, payment gateways, shipping rules, abandoned cart, and loyalty.
Odoo eCommerce is a storefront over Sales and Inventory rather than a separate shop system. A basket is a draft sale order. A published product is the same record the buyer and the warehouse already use. Availability on the product page is read from real stock, not a synced copy. That is the reason to choose it, and also the reason it exposes every weakness in the catalogue sitting behind it.
The licence line surprises buyers. Website Builder and eCommerce are Community apps, and that covers variants, pricelists, coupons, gift cards, the payment framework and the customer portal. Enterprise holds Studio, Subscriptions, Rental, Marketing Automation, the Amazon connector, the full Accounting app and most of the country e-invoicing modules. Sellers usually end up on Enterprise for an accounting or tax filing obligation, not for the shop itself.
Project time goes somewhere predictable. Building the catalogue and deciding how variants are generated. Agreeing whether prices show tax and how tax is derived per country. Finding a payment provider that carries the methods the market actually uses. Moving the old URLs so search traffic survives the switch. The theme is the visible part of the work and usually the smallest part of it.
Who Odoo eCommerce is for
- → Brands and distributors selling one catalogue to trade accounts at agreed prices and to the public at list price, out of a single stock.
- → Retailers already running Odoo Inventory or Point of Sale who want the website reading the same on hand quantity instead of a nightly export.
- → Manufacturers with configurable products, where attributes and an extra price per option replace a long list of hand maintained part numbers.
- → Wholesalers running an invitation only trade portal, where each account signs in to its own pricelist, payment terms and order history instead of a public price list.
- → Not for multi vendor marketplaces. Odoo has no seller onboarding, split settlement or commission ledger for independent merchants, and building one is a product, not a configuration.
- → Not for a fifty product shop with no ERP behind it, where a hosted platform is cheaper to run and faster to launch.
Key features
- ✓ Product variants & configurator
- ✓ Multi-currency & multi-language
- ✓ Payment gateways & BNPL
- ✓ Shipping carriers
- ✓ Abandoned cart recovery
- ✓ Coupon & gift card
What Odoo eCommerce actually does
Variants, options and exclusions
An attribute can create variants instantly, create them dynamically as they are ordered, or never create them at all. That single choice decides whether a template becomes one record or a thousand. Values carry an extra price, a display type such as a colour swatch, radio button or pill, and exclusion rules that stop impossible combinations existing. Optional products are offered when the item is added, accessories appear in the cart, alternatives sit on the product page.
Pricelists, currency and tax display
Pricelists are shared with Sales and resolve as rules on product, category, quantity break and date window. A pricelist holds one currency, can be limited to a country group, and can be offered to the visitor as a selectable choice. A website setting decides whether prices are shown tax included or tax excluded, and fiscal positions derive the tax itself from the customer country rather than from the product.
Payment providers and checkout
The standard providers cover Stripe, PayPal, Adyen, Mollie, Razorpay, Authorize.net, Buckaroo, Mercado Pago, Flutterwave, Xendit and Amazon Payment Services, plus offline methods for wire transfer and cash on delivery. Tokenised cards, manual capture, express checkout and partial refunds depend on the provider, not on Odoo. Guest checkout and accounts on invitation are settings. Every attempt is stored as a payment transaction, which is what you audit when an order and a bank line disagree.
Delivery methods that price themselves
A delivery method can be a fixed price, free above an order value, or a rule set computing on weight, volume, price or quantity, with a margin applied to the rate a carrier returns. Odoo ships connectors for a short list of mostly international carriers, among them DHL Express, UPS, FedEx, bpost, Sendcloud, Easypost, Shiprocket and Starshipit. Domestic couriers outside that list mean a paid apps store module or an API build, and that decision belongs in the budget.
Promotions, gift cards and cart recovery
The Loyalty app covers discounts, promotion codes, coupons, gift cards, eWallets, loyalty points and next order rewards, and the same programs run in Point of Sale, so a card sold online is redeemable in the shop. Abandoned checkout emails go out after a delay you set, but only to a visitor whose email address is already known. Getting an address early, rather than at the payment step, is therefore a design decision with revenue attached.
Content, SEO and several storefronts
The builder carries the pages, blog and forms around the shop, with a meta title, description and social image per page, an automatic sitemap and editable redirect records. One database can run several websites, each with its own domain, theme, published products, pricelist and company, and additional languages are served under their own URL prefix. Product URLs stay editable, which is what makes a migration off another platform survivable.
How we configure Odoo eCommerce
Build the catalogue before the theme
Decide the internal reference scheme, the attribute list and the variant creation mode first, because changing an attribute once variants exist is destructive. Load weights and dimensions at the same time, since delivery pricing depends on them. Set costs, or margin reporting reads the full selling price. Publication is per product and per website, so a bulk import lands unpublished until you say otherwise, which is the safe way round.
Settle tax display and rounding on day one
Choose tax included or tax excluded display, and choose whether tax rounds per line or globally, before a single order exists. Both change every total. A shop quoting VAT inclusive prices derives the net by division, and the cents that fall out are what finance reconciles later. Fiscal positions handle export, free zone and reverse charge cases. Overriding the tax by hand on each product does not, and it fails the first time a foreign buyer checks out.
Pick the payment provider by market and by hosting
Work out which local methods buyers expect, then establish whether Odoo ships that provider, whether a paid apps store connector exists, or whether it is an API build. Check hosting before signing anything. Odoo Online runs no custom modules, so a market whose only route is a third party connector pushes the project onto Odoo.sh or your own server. That is a hosting decision made by the checkout.
Decide what the product page is allowed to promise
Per product you choose whether an out of stock item can still be ordered, and what message replaces the buy button when it cannot. Separately you choose whether a quantity is shown at all, and the threshold below which the page starts saying how few are left. Publishing a live number invites arguments about it on the phone, and it moves every time somebody corrects a count. A stated lead time is usually easier to keep than a live number, and it survives a stock adjustment without embarrassing anyone.
Wire the order to invoice path before launch
Decide whether invoicing is on ordered or delivered quantities, because that governs whether a prepaid web order can be invoiced before it ships. Turn on automatic invoicing if paid orders should produce an invoice without anyone touching them. Trade accounts buying on payment terms need a different path from card buyers. Agree who refunds, from which document, and what the customer sees, before the first return rather than after it.
Treat the migration as a search problem
Products, customers and open orders are the easy part. Passwords never come across, so a reset campaign belongs in the launch plan rather than in the support queue on day two. Closed history is better held as posted invoices than as rebuilt web orders nobody will ever fulfil. The line that is routinely underbudgeted is the URL map, because what a bad migration costs you is search traffic, not data.
Where Odoo eCommerce projects go wrong
Draft carts flooding the sales pipeline
The draft order behind every basket takes its number from the sales sequence the moment it is created. Within weeks the quotation list is thousands of abandoned carts and the confirmed order numbers have gaps in them that finance will ask about. Any report that does not filter on state reads those drafts as pipeline. Decide early how long carts are kept, who clears them and whether sales users should see the list at all. It costs nothing to settle in month one and it is a cleanup project by month four.
Selling the last unit twice
Nothing is held while a basket sits open. Reservation happens after the order is confirmed, under the rule set on the delivery operation type, so two shoppers can buy the same last unit inside a minute. There is no reserve on add to cart, and no sellable buffer sitting under real stock, so the choice is between blocking the sale at zero and taking the order with a stated lead time. Fast moving lines with long replenishment are where that decision costs money.
The website is looking at the wrong warehouse
Availability is computed for the warehouse assigned to that website, not for the company total. A retailer with stock across branches shows the shop warehouse only, and the shortfall surfaces as cancelled orders rather than as an error. If the shop should sell from group stock, that is a replenishment and routing design, not a website setting, and it is cheaper to decide before the catalogue is published.
Delivery rules built on weights nobody entered
Price rules on weight are only as good as the weight field. Catalogues imported from a spreadsheet arrive at zero, so every basket falls into the cheapest bracket and the shop quietly subsidises freight, or the carrier API rejects the request outright. Connectors also want dimensions, a live account and a package type, which tends to surface in the week before launch when the account is not open yet.
Payment states read as order states
An order paid by wire transfer or cash on delivery is confirmed with no money in the bank, and a transaction left pending leaves the order as a quotation while the customer believes they have bought something. Provider webhooks have to reach the server, so a staging URL left in the provider dashboard breaks confirmation silently. Test a refund and a failed capture before go live, not after the first dispute.
A theme that has to be rebuilt at every upgrade
Shop pages are QWeb templates, and deep inheritance into the product page, cart or checkout is the part of an Odoo project most likely to break on a version upgrade, because Odoo reworks those templates between releases. Keep changes to building blocks, snippets and styling wherever the requirement allows, and keep a list of every template override. That list is the upgrade estimate.
What it works with
- + Sales, since a web order is a sale order on the same pricelists, invoicing policy and delivery terms
- + Inventory, for the availability shown on the shop, the warehouse behind each website and the picking behind every order
- + Invoicing in Community, or the full Accounting app in Enterprise where tax reporting and country e-invoicing modules live
- + Website Builder, which carries the pages, blog, forms and redirect records around the shop
- + Loyalty, for coupons, promotions, gift cards and eWallets shared with Point of Sale
- + Point of Sale, where store and website sell from one stock and one loyalty balance
- + Payment providers and delivery carrier connectors, for checkout, live rates and labels
- + Studio, Marketing Automation, Subscriptions and the Amazon connector on Enterprise, for custom fields, campaigns, recurring orders and marketplace listings
Odoo eCommerce by country
Saudi Arabia (KSA)
mada is the card most Saudi shoppers carry, so a checkout offering only Visa and Mastercard loses orders. Amazon Payment Services is the regional provider in the standard list, and whether mada is presented depends on the acquiring account behind it rather than on Odoo. Moyasar and HyperPay sit outside that list. A web sale to a consumer is a simplified tax invoice under ZATCA phase two, carrying a QR code and reported within twenty four hours, and the Odoo module that does the reporting is Enterprise. That clock is why paid web orders are usually set to invoice automatically, since a batch somebody remembers to run on Friday is already late.
United Arab Emirates
Tax structure decides more here than the checkout does. Qualifying free zone income is taxed at zero and other profit at nine percent above AED 375,000, so which entity sells online is a finance question asked before the website exists. VAT at five percent with zero rated exports belongs in fiscal positions rather than in per product taxes. Cards clear through a regional acquirer, and the domestic Jaywan scheme arrives with that acquirer rather than as an Odoo module. The other real job is the bilingual storefront. Arabic is a right to left language, so Odoo builds mirrored stylesheets for it, but custom snippets and hard coded alignment need checking page by page, and every product name, description and attribute value is a separate translation somebody has to write.
Pakistan
Most baskets are still cash on delivery, so the checkout confirms an order with no money taken and the real work happens weeks later, matching courier remittances to sale orders. Odoo covers the checkout side of that as an offline payment method. The localisation is a chart of accounts, so FBR digital invoicing is an integration to build or buy. Domestic couriers such as PostEx, TCS and Leopards sit outside the standard connector list, and return to origin rates run high enough that delivered margin, not order margin, is the number worth reporting to the board.
India
Razorpay ships with Odoo and carries UPI, RuPay, netbanking and wallets on one account, so a working checkout needs nothing bought. The place of supply decides whether GST is IGST or CGST plus SGST, which makes the delivery address a tax field rather than a logistics detail, and fiscal positions have to be driven from the state on the shipping address. The e-invoicing and e-way bill modules are Enterprise. Consumer sales sit outside e-invoicing, but the goods movement still needs an e-way bill.
Turkey
A sale to a consumer leaves as an e-Arsiv document, while a buyer registered for e-Fatura must receive an e-Fatura, so the checkout has to capture a tax identity and check it against the registered user list before deciding which document to issue. The Turkish localisation in Odoo is a chart of accounts. No edition ships e-Fatura or e-Arsiv, so GIB reporting goes through a licensed integrator, reached from Odoo by a third party connector or a middleware call. No Turkish acquirer appears in the standard provider list either, and instalments at checkout are an ordinary expectation rather than a promotion.
Egypt
The compliance split matters more than the payment page. The Enterprise ETA module addresses the business to business invoice clearance stream, while the consumer e-receipt system is separate and switched on in waves, so confirm which stream your sales fall in before promising anything. Either way the work lands on the catalogue rather than the checkout, because every invoice line has to carry a recognised item code, and that is data entered product by product. Amazon Payment Services covers Egypt in the standard list. Fawry and the local wallets do not, and enough volume still moves cash on delivery that the courier account is part of the design rather than an afterthought.
United Kingdom
Stripe ships with Odoo and the methods shown at checkout follow what is enabled on the Stripe account, so cards, wallets and buy now pay later come from one integration. VAT registration is compulsory above 90,000 pounds and returns go through Making Tax Digital, which in Odoo means the Enterprise accounting reports rather than Community Invoicing. Consumer orders carry a fourteen day cancellation right that starts on delivery. Royal Mail is not in the box and comes from a paid module built on Click and Drop.
Germany
Buying on invoice or by direct debit is an ordinary consumer expectation, so a card only checkout underperforms, and both routes reach Odoo through an acquirer such as Mollie or Adyen rather than a dedicated module. SEPA direct debit collection sits in the Enterprise accounting modules. The product page itself is regulated: the Preisangabenverordnung wants a price per unit, which the base unit price fields on the product template produce, and the fourteen day Widerrufsrecht needs its cancellation policy and form reachable from checkout. The native DHL connector is DHL Express, not DHL Paket.
Odoo eCommerce FAQs
Do we need Odoo Enterprise to run an online shop?
No, the storefront itself runs on Community. What usually pulls a shop onto Enterprise is one of three things: the statutory e-invoicing module for the country it sells in, the full Accounting app because Community ships Invoicing without accounting reports, bank synchronisation or asset handling, or Studio because somebody wants fields and screens changed without a developer. Licensing counts internal users only. Customers, portal accounts and site visitors are never billed, so a shop run by two people in the back office is a two user licence however many buyers it has.
Can Odoo replace Shopify or WooCommerce?
For a catalogue sold from real stock with real accounting behind it, yes, because the order, the picking and the invoice are one chain rather than a nightly sync between two systems that disagree by Monday. Where the storefront is the entire business and the back office is two people and a spreadsheet, the hosted platforms still win on theme choice, checkout apps and never having to run an upgrade. The test is how much of the value sits behind the checkout rather than in front of it.
How many product variants is too many?
The count matters less than what each variant drags behind it. Every generated combination is a stockable record with its own barcode, its own quants and its own line in every inventory report. Five attributes with four values each is over a thousand of those on one template. Attributes that only move the price are better set to dynamic creation, where the record appears the first time somebody orders it. Attributes that are pure presentation can be set to create no variant at all, so the choice is captured on the order line and no new product exists. Exclusion rules then keep the impossible combinations from ever being generated.
How do B2B and B2C live on the same website?
Pricelists give trade accounts their agreed prices and fiscal positions give each buyer the right tax, so the pricing side is configuration. Two things are not. Odoo has no switch that hides prices from anonymous visitors, so a genuinely closed trade catalogue needs an apps store module or a small customisation. And the presentation pulls in opposite directions: trade buyers want tax excluded prices, fast reordering and payment terms, consumers want tax included prices and a card. When those pull far enough apart, the cleaner answer is a second website on the same database, sharing the catalogue and the stock.
Can we run several country stores from one database?
Yes, and the storefront side of it is configuration. The harder question is legal entities. If each country invoices from its own company, that is a multi company database with a chart of accounts, tax positions and number sequences per entity, and each site is tied to one of them. Stock is the second question, since one warehouse feeding several countries changes both the delivery rules and the tax treatment. Settle the company and warehouse map first.
Will we keep our search rankings after moving to Odoo?
It depends entirely on the redirect work, and one part of it is easier than people expect. An Odoo product URL is the product name followed by its database id, and the page resolves on the id, so renaming a product later does not break a link that is already indexed. Nothing from the old platform matches, though, so every old URL needs a redirect record in place before the domain moves. Odoo offers 301 permanent, 302 temporary, 404 and a rewrite type, and 301 is the one that carries ranking signals across. Build the list from a crawl of the live site rather than from the product export, because the export will not contain the category, filter and article URLs that hold most of the older links.
How does the shop handle cash on delivery?
Odoo ships cash on delivery as an offline method, so the order is placed and confirmed with no money taken. What needs designing is everything after it: whether stock is reserved for an unpaid order, what the courier remits and when, how failed deliveries are cancelled and restocked, and how any surcharge is charged. That reconciliation is a finance process with a courier statement at one end, not a checkout setting.
Can we sell subscriptions or rentals through the shop?
Both exist and both are Enterprise. Subscriptions turn a web order into a recurring contract with its own invoicing schedule and renewal handling. Rental prices a product by duration and tracks what is out and what is due back. Neither is available on Community, so if the plan includes a recurring revenue line, the licence decision is made at that point rather than at the accounting stage.