Odoo eCommerce development is the work of shaping Odoo's built-in online store around how your business actually sells: the catalog, pricing, checkout, delivery and customer accounts, all tied to your inventory and accounting. This guide explains what that work covers, when standard Odoo is enough, how a project runs, and what to check before you choose a team.
It is written for operations and IT leads at companies that sell online and already run Odoo, or are choosing it. If you want the wider picture of building on Odoo first, see our Odoo development services.
What Is Odoo eCommerce Development?
Odoo eCommerce is an app inside Odoo that runs an online store on the same database as your sales, inventory and invoicing. Out of the box it covers product pages and catalogs, product attributes, delivery methods, checkout, customer accounts and a customer portal where buyers can track orders and download invoices. It also works with payment providers such as Stripe, PayPal and Adyen, and shipping connectors such as UPS, DHL and FedEx.
Ecommerce development is everything you add or change on top of that. It ranges from configuration, which needs no code, to design work on the storefront, to custom modules that change how pricing, checkout or order handling behave. It also includes the integrations that connect the store to systems outside Odoo.
The key point is that the store is not a separate product. An order placed on the site becomes a sales order, reserves stock, and later becomes an invoice. Every change you make to the store has to respect that chain.
When Standard Odoo eCommerce Is Enough
Many stores need less custom work than they expect. Start with the standard app and add code only where a real requirement cannot be met by configuration. Our guide on standard Odoo features and custom code covers that decision in general; for a store, it usually looks like this:
| Store need | Standard Odoo covers it when | Custom work is justified when |
|---|---|---|
| Catalog and variants | Products use attributes such as size or color | Options depend on each other or need rules, drawings or a configurator |
| Look and layout | The website builder and theme settings give you the design | Your brand system needs a custom theme or new page blocks |
| Pricing | Pricelists handle the customer groups you have | Prices come from contracts, volume rules or an outside system |
| B2B buying | Customer accounts and portal access settings are enough | You need approval steps, credit checks or buyer roles |
| Checkout and delivery | Standard delivery methods and payment providers fit | Checkout needs extra steps, fields or carrier logic |
| Order handling | Orders follow the normal sales, stock and invoice flow | Orders need splitting, holds or special fulfilment rules |
If most rows land in the left column, you are configuring, not developing. Be honest about that early; it saves budget for the parts that do need engineering.
What Custom Odoo eCommerce Development Covers
When standard features run out, the work usually falls into five areas. Most of it is delivered as custom modules, which is why a store project benefits from a team that follows good module practice. Our guide on how to build a custom module in Odoo shows what that looks like.
Storefront and theme
This is the visible layer: a theme that matches your brand, new page blocks, product page layouts, and mobile behavior. Good theme work stays inside Odoo's website tools, so your team can still edit pages without a developer.
Product options and configuration
Simple attributes cover size and color. Custom work is needed when choices depend on each other, when a product is built to order, or when the price changes with the options chosen. The risk here is data: every option has to map to something your warehouse or production team can act on.
Pricing and B2B rules
Customer-specific prices, volume tiers, minimum order quantities, approval before purchase and credit limits are common B2B requests. Build them on top of Odoo's pricing and customer account model rather than beside it, so quotes, invoices and the store agree on the same price.
Checkout and payments
Checkout changes include extra fields, tax or delivery rules, payment methods for certain customers, and order confirmation steps. Keep these small. Every extra step in checkout costs conversions, and every custom rule must also hold when staff create the same order in the back office.
Search, filters and content
Large catalogs need filters that match how buyers shop, and product pages need accurate specifications. This often depends more on clean product data than on code, so budget time for the data before the design.
If you want a partner to deliver this work, see our Odoo customization services.
Connecting the Store to Inventory, Accounting and Delivery
The strength of Odoo eCommerce is that one order moves through the whole business without re-keying. A typical order follows this path:
- The customer checks out, and Odoo creates a sales order with the price, tax and delivery method chosen on the site.
- The payment provider confirms the payment, and the order is confirmed.
- Stock is reserved and a delivery order goes to the warehouse, with the carrier connector if you use one.
- The invoice is created and the payment is matched to it, depending on how you have set up invoicing.
- The customer follows the order, and downloads the invoice, from the portal.
Custom development should protect this chain, not bypass it. Three places need the most care:
- Stock levels. What the site shows as available must match what the warehouse can ship. Decide which warehouse, or which stock location, feeds the store, and how reserved stock is treated.
- Taxes and pricing. The tax on the site, the sales order and the invoice must agree. Test each country and customer type you sell to, not just the default one.
- Payments. Test failed, partial and refunded payments as well as successful ones. A store that only works when everything goes right creates reconciliation work later.
If you are still setting up the wider system, our Odoo implementation services cover the wider rollout around the store.
Integrating with Outside Systems Through the Odoo API
Most stores need to talk to something outside Odoo: a marketplace, a shipping or tax service, a product information system, a mobile app or a separate storefront. These connections run through Odoo's external API or through webhooks, and a few points decide whether they last.
- Use the current API. Odoo 19 introduced the JSON-2 API. Odoo's documentation says the older XML-RPC and JSON-RPC interfaces are scheduled for removal in Odoo 20 (fall 2026), so new integrations should use JSON-2.
- Use scoped keys. JSON-2 authenticates with API keys. Odoo's documentation recommends a dedicated bot user with minimal permissions for automated integrations, and keys cannot last longer than three months, so plan how keys are renewed.
- Respect access rights. Standard access rights and record rules apply to API calls, so an integration user sees only what it is allowed to see.
- Check your plan. On Odoo Online, the documentation says external API access is limited to the Custom plan. Confirm your plan before you design the integration.
The practical rules are the ones every integration needs: make updates safe to repeat so a retry does not create duplicate orders, log failures where someone will see them, and test large volumes before a sales peak. Our Odoo API integration guide walks through requests, errors and duplicate prevention, and our article on Odoo webhooks and external system integration covers event-driven connections.
If you would rather hand this part to a specialist team, see our Odoo integration services.
A Practical Odoo eCommerce Development Process
A store project goes better when it follows a fixed order. This is a sequence we recommend, whoever does the work.
- Define what the store must do. List the customer types, the order types, the payment and delivery methods, and the systems the store must connect to. Mark each item as configuration, customization or integration.
- Prepare the product and customer data. Clean categories, attributes, units, images and prices before any design. Poor data causes more store problems than poor code.
- Configure first, then build. Set up the standard store in a test copy of your database and walk through real orders. The gaps you find become the custom development list.
- Build the custom parts as separate modules. Keep each requirement in its own module so it can be tested, switched off and upgraded on its own.
- Connect outside systems. Build integrations against the test database, with logging and safe retries from the start.
- Test the whole order chain. Run orders from checkout through stock, delivery, invoice and payment, including returns and failed payments, for every customer type.
- Launch with monitoring. Watch the first orders closely, check stock and invoices daily for the first weeks, and keep a rollback plan for the release.
A team that skips step 3 tends to build custom code for things Odoo already does, which adds cost now and upgrade work later.
Performance, Security and Upgrade Safety
Three concerns decide whether the store stays healthy after launch.
Performance
Shoppers and your staff use the same database. A heavy report or a slow custom query can make product pages slow at the worst moment. Keep custom code light on product and cart pages, avoid database queries inside loops, and test with a realistic catalog size. If pages are already slow, start with our guide on how to optimize a slow Odoo database.
Security
Give integrations their own user with the smallest set of permissions they need, and renew API keys on a schedule. Let the payment provider handle card details; the store should never store them. Review portal access rules so customers see only their own orders and invoices.
Upgrade safety
Every custom module becomes work again at the next major Odoo version. Keep customizations small, written as separate modules, and covered by tests so a version change shows quickly what breaks. If an upgrade is coming, our Odoo upgrade services assess custom modules before the move, and our Odoo maintenance checklist lists what to review regularly.
What Drives Cost and Timeline
No honest price exists without a scope, so this guide does not quote one. What you can do is know which factors move the effort, and ask every provider about them:
- How much is custom. A store that is mostly configuration is a short project. Each custom rule in pricing, checkout or order handling adds design, build and testing.
- Number of integrations. Each outside system needs mapping, error handling and testing. A marketplace or a separate storefront costs more than a shipping connector.
- Data condition. Cleaning products, categories and customer records can take as long as the build.
- Markets and tax setups. More countries, currencies, languages and tax rules mean more test cases.
- Design depth. A branded custom theme takes longer than the standard theme with your colors and images.
- Testing and launch support. Full order-chain testing and early monitoring cost time but prevent expensive corrections.
When you compare quotes, check that each one lists the same scope, states what is configuration and what is code, and says who maintains the work after launch. Our guide to Odoo consulting services costs covers what drives Odoo project pricing.
Common Mistakes to Avoid
- Building before configuring. Teams write custom code for features Odoo already has, then carry that code through every upgrade.
- Treating the store as a separate system. Custom checkout or pricing that does not follow the sales order flow creates mismatches in stock and invoices.
- Ignoring product data. A new theme cannot fix missing attributes, wrong units or inconsistent categories.
- Testing only the happy path. Failed payments, partial deliveries, returns and out-of-stock items are where stores break.
- Using a retiring API. New integrations built on the older XML-RPC or JSON-RPC interfaces will need rework when Odoo 20 removes them.
- No owner after launch. Without someone responsible for monitoring orders, keys and updates, small faults grow quietly.
Choosing a Developer and Next Steps
Whoever builds your store, ask them these questions before you sign:
- Which parts of my requirements are configuration, and which need code?
- How do you keep custom changes in separate modules, and how do you test them?
- Which Odoo API will you use for integrations, and how will keys be managed?
- How do you test failed payments, returns and out-of-stock orders?
- What happens at the next Odoo upgrade, and who owns the custom modules?
A good answer is specific to your store. A vague answer usually means the team has not yet looked at your order flow.
If you want a team that can both configure and extend Odoo, you can hire Odoo eCommerce developers from Versich, or start with an assessment of what your store needs. Share your catalog, customer types and the systems you connect to, and we will tell you which parts are configuration and which need development.
