Headless commerce separates the customer-facing storefront from the backend commerce engine, so the same product data and APIs can power websites, mobile apps, kiosks and other channels. Globally, 73% of businesses use headless architecture, while 42% of Australian shoppers are omnichannel, according to the Australian industry reporting cited by Inside Retail.
You may recognise the problem before you recognise the architecture. Your Shopify or WooCommerce store works, but every new channel creates another integration, every design change needs developer attention, and your ERP knows a different version of stock from the one customers see. Marketing wants richer product pages, operations wants reliable inventory, and customers expect checkout to work consistently across mobile, web and physical touchpoints.
Headless commerce addresses that tension by splitting the presentation layer from the systems that manage products, carts, orders, payments and stock. It can be a powerful model, but it isn't automatically the right answer. The decision depends on your channels, integrations, engineering capability and tolerance for ongoing technical ownership.
Why Headless Commerce Matters for Modern Retailers
A fashion retailer launches a major promotion. The WooCommerce theme becomes sluggish under pressure, mobile shoppers wait for product content, and the marketing team can't publish a new landing page without filing a developer ticket. The retailer doesn't necessarily have a broken commerce engine. It has a storefront that is too tightly coupled to the way the backend works.
Headless commerce separates that storefront from the commerce engine. Product information, pricing, cart actions and order services remain available through APIs, while a separate frontend decides how those services appear on a website, mobile app, kiosk or another customer touchpoint. A React or Next.js storefront might consume the same catalogue API as a mobile application, while the backend continues handling order rules and inventory.
Australia's retail environment makes this architecture relevant. Industry reporting places global headless adoption at 73%, and Australian reporting on WP Engine research places local adoption at 72%, close to the global level, as discussed by Fontis on Australian retailers and headless commerce. The same Australian market reporting identifies 42% of Australian shoppers as omnichannel, meaning retailers need to manage journeys that move between channels rather than treating each one as an isolated website visit.
The practical pressure behind the buzzword
A mid-market retailer may need to:
- Launch content faster: Give marketing control over editorial pages without changing checkout logic.
- Share trusted data: Present consistent pricing, availability and product information across channels.
- Support custom journeys: Build trade portals, subscriptions, kiosks or app experiences that a standard theme can't express cleanly.
- Protect the core engine: Improve the customer experience without replacing every back-office system.
The phrase why agencies choose headless commerce is useful because it shifts attention from visual novelty to delivery constraints. Agencies and solution teams typically consider the model when a business needs more control over customer experiences while retaining established commerce services, as outlined in WebInOne's explanation of headless commerce platforms.
Headless isn't a faster template. It's an operating model for connecting multiple experiences to shared commerce capabilities. The following sections examine the architecture, the Australian cost implications, Odoo ERP integration, local payment considerations and the situations where a conventional Shopify, WooCommerce or other monolithic setup remains the more sensible choice.
The Core Architecture of a Headless Commerce Setup
A restaurant analogy makes the separation easier to understand. The storefront is the dining room, where customers browse the menu and decide what they want. The API layer is the waiter, taking an order from the dining room and communicating it to the kitchen. The backend commerce engine, ERP and payment services are the kitchen, pantry and cash register.
The three planes
Presentation plane: This is the customer-facing experience. It may include a headless CMS such as Sanity, Contentful or Strapi, plus a frontend built with React, Vue or Next.js. The presentation plane controls layout, content composition, navigation, rendering and interaction.
Orchestration plane: This is the traffic controller. An API gateway or backend-for-frontend, commonly called a BFF, receives requests from the storefront and directs them to the appropriate service. It can combine product data, customer context, stock availability and delivery information into a response designed for a particular channel.
Systems-of-record plane: These systems hold operational truth. A commerce platform such as Shopify can manage catalogue and order functions through its Storefront API. WooCommerce can expose commerce functions through REST. Odoo ERP can provide product, price, inventory and operational data through XML-RPC or JSON-RPC, while payment gateways, search and personalisation services handle their own responsibilities.
A typical request might begin in a Next.js product page. The frontend calls a GraphQL or REST endpoint, the orchestration layer requests catalogue and pricing information from Shopify or WooCommerce, checks relevant stock in Odoo, and returns a structured response. At checkout, a payment API processes the transaction, while order events flow back to the commerce engine and ERP.
Practical rule: Keep ownership clear. The commerce engine shouldn't become an accidental ERP, and the storefront shouldn't contain business rules that belong in services or systems of record.
A monolithic platform combines the storefront template, application logic and database in one deployable unit. That arrangement can be straightforward to operate, but a change intended for the website may affect the whole application. Headless architecture creates more freedom, but it also creates more interfaces to design, monitor, secure and maintain.
Headless Commerce Compared With Traditional Ecommerce
The central trade-off is simple. Traditional ecommerce reduces architectural complexity by keeping the storefront and commerce engine together. Headless commerce increases technical complexity in exchange for greater control over presentation, channel delivery and integration design.
| Dimension | Traditional Monolithic Ecommerce | Headless Commerce |
|---|---|---|
| Storefront changes | Usually tied to platform themes and templates | Frontend can evolve independently through APIs |
| New channels | Often require platform-specific extensions or separate builds | Web, mobile, kiosk and portal experiences can consume shared services |
| Performance control | Constrained by platform rendering and theme structure | Frontend team controls rendering, caching and delivery patterns |
| Odoo integration | May rely on plugins or tightly coupled connectors | Middleware can coordinate commerce, Odoo, payments and other services |
| Operational model | Fewer moving parts | Separate frontend, APIs, services and monitoring |
| Cost profile | Lower initial complexity, with platform fees and add-ons | Higher build and maintenance commitment |
| Best fit | A focused catalogue and a small number of channels | Complex journeys and several experiences using shared data |
A greenfield headless build in Australia is commonly cited at approximately AUD 80,000 to AUD 200,000 or more, with ongoing maintenance of about AUD 5,000 to AUD 15,000 per month, according to Australian headless ecommerce implementation guidance. Those figures are indicative, not a quote. Integrations, data quality, authentication, search, checkout and operational support can materially change the effort.
Where the investment can make sense
Headless becomes easier to justify when one product and order foundation must serve a website, mobile app, kiosk, marketplace feed and B2B portal. The value isn't the architecture label. The value is avoiding disconnected channel logic and giving teams a controlled way to improve each experience.
A Shopify or WooCommerce monolith is often a sound choice for a single-channel retailer with modest operational complexity. It can provide a faster path to market, familiar administration and a smaller support surface. Before choosing headless, review the practical constraints described in Shopify limitations and possible solutions, especially where platform checkout, data access or custom workflows may affect the roadmap.
For an Australian retailer, the comparison should include three-year ownership rather than only the launch budget. Count frontend development, API hosting, observability, security, specialist support, platform subscriptions, agency involvement and the cost of maintaining integrations. Headless is a strategic choice, not a cosmetic upgrade.
Real Australian Use Cases Across Retail, Manufacturing, and Hospitality
A useful headless decision starts with a business problem. The same architecture can solve very different problems in fashion, manufacturing and hospitality, but the required services and measures of success won't be identical.
A Sydney fashion retailer
A Sydney fashion retailer has outgrown a WooCommerce theme. The team releases products frequently, runs editorial campaigns and wants a more controlled mobile experience. A headless frontend built with Shopify Hydrogen could provide the presentation flexibility, while Algolia could handle product discovery and filtering.
The important design decision is not merely replacing WooCommerce with Shopify. The team must define which system owns product records, prices, promotions, customer accounts and orders. It should also decide how search indexes update, how content editors publish campaigns and how stock changes reach the storefront.
A credible outcome would be assessed through operational measures such as page response behaviour, campaign publishing effort, search relevance and support incidents. It would be misleading to promise a specific page-load improvement without a measured baseline and testing plan.
A Victorian food manufacturer using Odoo
A Victorian food manufacturer already uses Odoo ERP for operational processes and needs a B2B portal. Dealers require authenticated access, negotiated pricing tiers and visibility into available stock. A custom storefront can consume commerce services while middleware exchanges inventory and customer information with Odoo through XML-RPC or JSON-RPC.
Here, headless supports a custom buying journey without forcing the ERP to become a customer-facing web application. The team can design account-specific catalogues, approval flows and reorder tools while keeping fulfilment, stock and financial processes within Odoo implementation boundaries.
The outcome should focus on data integrity and staff effort. Useful measures include fewer manual stock corrections, fewer pricing exceptions and clearer order status ownership.
An Adelaide hospitality group
An Adelaide hospitality group wants customers to interact through a website, a branded iOS app and in-venue kiosks. A shared booking engine can expose availability through an API, allowing each frontend to present the experience in a channel-appropriate way.
The group doesn't need three separate booking databases. It needs one reliable availability and reservation service, with authentication, payment handling and operational rules applied consistently. The kiosk might prioritise speed and simplicity, while the app can support account history and the website can carry richer venue content.
A strong use case has a shared operational problem and multiple customer experiences. A custom frontend alone doesn't make a project headless.
Integrating Headless Storefronts With ERPs and Existing Systems
A headless stack works only when each system has a defined responsibility. Australian businesses often have a CMS for content, a commerce platform for carts and orders, an ERP for operations, payment services for transactions and analytics for measurement. The integration layer connects these parts without allowing every system to write conflicting versions of the same data.
Start with ownership, not endpoints
The content layer may use Sanity, Contentful or Strapi for editorial pages, campaign content and reusable components. The commerce layer may use Shopify, BigCommerce, Medusa or Saleor for products, carts, checkout and orders. Odoo ERP typically sits in the back office, managing inventory, fulfilment, customers and finance.
Middleware then coordinates the exchanges:
- Order webhooks: Notify Odoo or an integration service when an order is created or updated.
- Stock synchronisation: Pull or receive inventory changes and publish the correct availability to customer-facing channels.
- Customer events: Update customer records when account details, consent or order history changes.
- Payment events: Confirm successful, failed or pending transactions without trusting only the browser response.
Teams should document whether the commerce engine or Odoo owns each field. Product descriptions might belong to the CMS, sellable stock to Odoo, and checkout state to the commerce platform. Without that agreement, an API integration can automate confusion rather than remove it.
Use phased Odoo implementation
Australian Odoo projects are commonly delivered through discovery, requirements mapping, planning, module mapping, configuration, integration testing, system testing and go-live support, as described in this Australian Odoo implementation guide. A wholesale rollout example places a 20- to 50-user implementation at 14 to 22 weeks for a single warehouse, or 22 to 36 weeks for a multi-warehouse business with a B2B portal and Peppol live from day one, according to Odoo guidance for Australian wholesale distributors.
That timeline supports a release-based approach. Deliver a small storefront and core product flow first, connect inventory and order processes next, then add advanced account, payment and channel capabilities. A phased Odoo implementation reduces the risk of discovering data, process or integration problems immediately before launch.
For practical system design, teams can also review ERP integration best practices before selecting middleware patterns, event ownership and testing responsibilities.
How Headless Supports Australian Payments and AI Shopping
The payment question exposes whether a headless proposal is technically serious. A decoupled storefront isn't valuable if the checkout still assumes one fixed template, one payment path or one device.
Australian payment conditions are diverse. Market commentary describes pressure from real-time settlement, contactless and mobile wallets, BNPL and NPP, while reporting places Australian online retail sales at AUD 62.3 billion in 2025 and NPP activity at 1.24 billion transactions worth AUD 1.1 trillion in 2025, as outlined by Australian headless commerce and omnichannel payment analysis.
| Payment Method | Traditional Ecommerce Support | Headless Storefront Support |
|---|---|---|
| NPP and pay-by-bank flows | May depend on available plugins and fixed checkout options | API orchestration can route the flow across web, app or kiosk |
| BNPL, including Afterpay and Zip | Often added through platform extensions | Payment services can be presented consistently across custom frontends |
| Apple Pay and Google Pay | Commonly tied to platform checkout configuration | Wallet flows can be designed into channel-specific experiences |
| Card payments | Usually supported by standard gateway modules | Gateway APIs can support custom checkout and status handling |
| Refunds and payment events | Often managed inside the commerce admin | Webhooks can coordinate commerce, ERP and customer communications |
AI-assisted shopping adds another requirement. The Australian source reports that 50% of Australians have used AI assistants for shopping, while 78% expect them to become mainstream. A catalogue that only looks attractive in a browser isn't enough for systems that need structured product facts, availability, pricing and purchase actions.
That means product data needs clear names, attributes, identifiers, availability rules and structured schema. Stable APIs help channels retrieve information without scraping page layouts. A headless frontend can support machine-readable discovery through consistent product endpoints, but the architecture alone doesn't guarantee visibility in ChatGPT, Gemini or future agentic shopping surfaces.
Payment integrations also need careful treatment of fraud controls, customer authentication, refunds, tax, failed payments and webhook reliability. Payment gateway integration guidance is relevant because checkout orchestration is a systems problem, not just a button-placement exercise.
Trade-offs and When Headless Is the Wrong Choice
Headless commerce adds moving parts. A business may need frontend specialists, backend integration skills, DevOps capability, testing discipline and people who understand commerce operations. If those capabilities aren't available internally, the business must fund them through a partner or managed support arrangement.
The warning signs are clear:
- Single-channel selling: If the website is the only meaningful customer touchpoint, a conventional platform may provide enough flexibility.
- Limited engineering capacity: A decoupled stack needs people who can maintain APIs, deployments, monitoring and security.
- Small catalogue complexity: Straightforward products and standard checkout rarely justify a bespoke orchestration layer.
- Unclear ownership: If teams haven't agreed where pricing, stock, customers and orders live, adding more systems increases risk.
- Unfunded ambition: A project that can fund the build but not ongoing maintenance is not ready for headless.
A SaaS platform such as Shopify Plus may suit a growing business that wants managed infrastructure and standardised commerce capabilities. A monolith such as Magento may suit an organisation that needs deeper control in one integrated platform. Headless is more suitable when channel variation and integration requirements outweigh the operational simplicity of a joined platform.
| Factor | Headless Commerce | SaaS, such as Shopify Plus | Monolith, such as Magento |
|---|---|---|---|
| Frontend freedom | High | Controlled by platform capabilities unless extended | Moderate to high within one platform |
| Maintenance | Distributed across several services | More infrastructure managed by vendor | Concentrated but still technically demanding |
| Channel strategy | Strong for several custom experiences | Strong for supported channels | Effective when channels remain closely integrated |
| Internal skills | Requires frontend and integration capability | Lower technical burden | Requires platform expertise |
| Cost planning | Build plus recurring technical maintenance | Subscription, apps and implementation | Licensing, hosting, development and support |
| Best starting point | Complex channel and ERP environment | Standardised commerce with managed operations | Customised integrated ecommerce platform |
Use a three-year total-cost view. Include the implementation, platform subscriptions, app fees, integration support, monitoring, incident response and future feature work. A lower starting quote can become expensive if every new channel requires custom work, while a headless build can become wasteful if the business never uses the flexibility it paid for.
Getting Started With Headless Commerce and Next Steps
Start with the business scenario, not a platform demo. A retailer adding a mobile app, B2B portal or marketplace needs to know whether its commerce services and operational systems can support those channels without creating conflicting product, stock and order data. Use five questions to establish fit:
- How many channels matter now? List web, mobile, marketplaces, kiosks, trade portals and in-store experiences, then separate current needs from possible future work.
- Which system owns operational truth? Confirm whether Odoo ERP, Shopify, WooCommerce or another platform controls products, stock, customers and orders.
- What must be custom? Distinguish genuine customer or operational requirements from design preferences that a standard theme can already support.
- What budget supports the whole lifecycle? Include implementation, integrations, hosting, monitoring, support and future releases.
- Who will operate the stack? Name the internal engineers, delivery partner and business owners responsible for decisions, incidents and data quality.
For Australian Odoo projects, the wholesale example may take 14 to 36 weeks, depending on warehouse, portal and Peppol requirements. A phased plan therefore gives the team useful checkpoints before every channel and integration is launched at once.
A practical delivery sequence
Discovery and architecture: Map customer journeys, data ownership, catalogue structure, ERP processes, payment requirements and channel priorities. Define an integration contract before developers build screens, including ownership, error handling and synchronisation rules.
MVP storefront and core integration: Deliver the primary product and purchase journey. Connect catalogue, pricing, stock, orders and customer records, then test failed payments, unavailable stock and interrupted sessions, not only successful checkout.
Expansion and optimisation: Add mobile, B2B, kiosk or marketplace experiences after the core flow is stable. Prepare product data for AI-assisted discovery, review NPP, BNPL and wallet flows, and confirm GST and tax-engine responsibilities.
An organisation comparing platforms should also review alternatives to Shopify for e-commerce, particularly when its requirements include Odoo ERP, custom B2B pricing or multiple frontends. The suitable route may be Shopify implementation, WooCommerce, a headless commerce engine or a staged combination.
For retailers, manufacturers and hospitality operators in Sydney, Adelaide and across Australia, Wistec can scope headless ecommerce builds, Shopify implementation, WooCommerce replatforming, Odoo ERP integration and broader software development in Sydney and Adelaide. A paid discovery sprint can turn channel, data and integration requirements into an architecture and delivery plan.
Frequently Asked Questions About Headless Commerce
What is headless commerce in simple terms?
Headless commerce separates the customer-facing storefront from the backend systems that manage products, carts, orders, inventory and payments. APIs connect the layers, so the same commerce capabilities can support different websites, apps, portals or kiosks.
Is headless commerce the same as a headless CMS?
No. A headless CMS manages content independently from its presentation layer. Headless commerce applies the same separation to shopping functions, including catalogue, cart, checkout and order services. A project may use both a headless CMS and a headless commerce platform.
Can headless commerce work with Odoo ERP?
Yes. Odoo can remain the operational system for inventory, fulfilment, customer records or finance, while the storefront and commerce engine handle customer-facing interactions. Integration commonly uses XML-RPC or JSON-RPC, supported by middleware, webhooks and scheduled or event-driven synchronisation.
Can Shopify or WooCommerce be used in a headless setup?
Yes. Shopify can expose commerce capabilities through its Storefront API, and WooCommerce provides REST interfaces for integrations and custom storefronts. Using either platform headlessly still requires careful decisions about checkout, authentication, data ownership and ongoing maintenance.
Does headless commerce automatically make a website faster?
No. Headless gives the frontend team more control over rendering, caching, asset delivery and page composition. Performance depends on how the frontend, APIs, hosting, search and third-party services are designed and operated.
Is headless commerce suitable for a small retailer?
It can be, but it often isn't the most economical starting point if the retailer has one channel, standard requirements and limited engineering support. A managed Shopify or WooCommerce implementation may deliver the required outcome with less operational complexity.
How much does headless commerce cost in Australia?
Australian guidance cites indicative build costs of AUD 80,000 to AUD 200,000 or more, plus ongoing maintenance of AUD 5,000 to AUD 15,000 per month. Actual cost depends on platform choice, ERP integration, data migration, checkout design, channel count and support expectations.
How does headless support AI shopping?
It can expose structured, machine-readable product information through APIs and consistent schema. That helps external experiences retrieve product facts and availability, but discoverability also depends on data quality, permissions, search visibility and the rules of each AI shopping surface.
What should a retailer do first?
Begin with discovery. Document channels, customer journeys, systems of record, payment methods, Odoo or other ERP requirements, catalogue quality, internal capability and three-year ownership. Then choose a delivery phase that proves the highest-risk integration before expanding the channel footprint.
Wistec offers practical headless ecommerce development, Shopify or WooCommerce implementation, Odoo ERP integration and software development for Australian businesses in Sydney, Adelaide and beyond. Visit Wistec to discuss a paid discovery sprint and turn your commerce requirements into a clear technical and delivery plan.