Store architecture diagrams represent the fundamental structure for a particular project, providing a unified vision to all stakeholders and translating business needs into software components and project requirements. In this guide, we present an overview of basic store architecture models on VTEX.

There are different types and levels of architecture, but they generally work as a reference for technical and business teams. Moreover, store architectures define for all stakeholders the roles and responsibilities of each player, how different systems interoperate, and how data is transmitted between them.

To demonstrate how VTEX integrates with the ecosystem, we created VTEX reference architecture models based on common digital commerce strategies. These blueprints illustrate interactions between VTEX modules and the business, serving as a project starting point. Learn more about the structure of these models in Understanding VTEX reference architectures.

The main use cases for common scenarios are the following:

• Business-to-customer (B2C)
• Business-to-business (B2B)
• Franchise accounts (Omnichannel)
• Multi-language and multi-currency
  • Single account, multi-bindings
  • Multi-account

The following diagrams represent one single VTEX account and assume that the customer is using Store Framework as a storefront solution.

Business-to-customer (B2C) is the most common business model with VTEX customers. It serves as a foundation for other models.

The diagram below shows the main components of a B2C commerce implementation. Components highlighted in pink are offered out-of-the-box (OOTB) by VTEX. However, the diagram also shows other parts that may come from customers' internal back office systems or third-party providers.

Below is an integration flow diagram in a B2C architecture, where the asynchronous calls (not in real time) are represented by black arrows, and synchronous calls are represented by blue arrows (real time).

An example of an asynchronous call is the stock update, which is represented by a black arrow pointing from the ERP to the Inventory module. A real-time update of rates in a payment is represented by a blue arrow, with information exchange in both blocks. This last scenario is synchronous because it is a sensitive stage in the customer purchase flow.

The architecture suggested here may go beyond B2C, as you can see in the following sections.

The main characteristic of a business-to-business (B2B) model is that transactions occur between two or more legal entities.

The diagram below presents an example where the business model is B2B using B2B Suite, which is represented within the B2B Core Modules. In this architecture, the main account acts as a marketplace for other VTEX sellers.

B2B Suite is a set of VTEX IO apps tailored to streamline B2B store management. This collection of apps empowers the store to oversee organizations (the companies enabled to make purchases in the store), as well as other functions and permissions for storefront and checkout. For instance, the store can offer specific price tables, collections, and custom payment methods for organizations. Also, customers can have different user roles within organizations, among other features.

The main account has more modules than the sellers, sharing only some, such as the Order Management System (OMS) and Catalog, as you can see in the diagram below.

Declaring these modules in the architecture not only makes the process clearer but also makes the visualization of player responsibilities easier to understand. In this case, for example, Master Data remains with the sellers because customer approval is done at the seller level.

In B2B scenarios, real-time communication between B2B Suite and sellers is common, as the information is always up-to-date, and also for any calculations of fees and taxes at checkout, since the end customer needs to have a smooth purchasing experience.

In the diagram above, you can see the synchronous communication between the Organizations component in the main account and the sellers.

• Streamlined organization management: Fosters efficient management of multiple organizations from a centralized platform by grouping storefront users into organizations and dividing them into cost centers.
• Customized user experience: Tailor the user experience for each organization, providing personalized pricing, payment methods, and product catalogs to meet specific business needs.
• Enhanced security and control: Assign roles and permissions to B2B customers, ensuring appropriate access levels and maintaining control over sensitive information and transactions. Learn more in the Storefront Permissions and Storefront Permissions UI app documentation.
• Optimized quoting system: Facilitates quote requests and its management, enhancing negotiation and ensuring accurate pricing by integrating the quote-to-order process.
• Efficient order processing: Simplifies the checkout process with shared shipping addresses for cost centers, reducing errors and streamlining order fulfillment.

• B2B Suite - Overview

This is a very common architecture model that integrates physical stores with ecommerce as franchise accounts on VTEX.

A franchise account is linked to a main account and has the following characteristics, which you can see in the reference architecture below:

• No separate website: Franchise accounts do not have their own dedicated website, as they operate within the main account's ecommerce site, effectively acting as part of a larger marketplace.
• Customer data storage: Customer data is stored in the main account’s Master Data.
• Seller type: Each franchise account automatically functions as a white label seller within the main account.
• Catalog: Franchise accounts inherit their catalog from the main account.
• Logistics and OMS: Each franchise account has its own logistics settings and performs its own order management.
• Prices and payments: Each franchise can have its own price and payment methods, or they can inherit prices and payment methods from the main account.
• Promotions: It is possible to create promotions for each franchise account and for the main account.

This architecture model works well for brands that have multiple physical stores, franchises, or representatives. In these cases, each physical store/franchise/representative can have a franchise account on VTEX integrated with the brand’s main account. This allows them to deliver the products sold through the brand’s ecommerce site from an omnichannel perspective.

• Potential to reduce the percentage of out-of-stock items.
• More shipping options, potentially reducing logistics costs.
• Physical stores can be configured as pick-up points.
• Physical stores can function as small warehouses, operating with the ship-from -store strategy.
• Possible gain from inventory reduction through the implementation of the Endless Aisle strategy, which is done by using VTEX Sales App.

VTEX Sales App is available in Brazil and some LATAM countries. To find out if it is available in your country, open a ticket with VTEX Support.

Some of our customers are present in multiple countries and want to have every local store running on VTEX. We provide a multi-language and multi-currency architecture for this scenario, explained in the following sections.

In this architecture, a single VTEX account is configured to support multiple languages and currencies, using a multi-domain approach.

The reference architecture below exemplifies its main characteristics:

• Separate website: One single account, but each store has its own domain, bound to different trade policies by bindings.
• Search: Search settings are the same for all websites.
• CMS: Shared access to the Content Management System (CMS) between websites.
• Customer data storage: One single Master Data for all stores.
• Catalog: One single catalog, segmented by trade policies.
• Logistics: Each store has its logistics operation managed by different warehouses in the same logistics panel.
• Order Management System (OMS): One single Order Management System panel for all stores.
• Payments: Shared payment settings between all stores.
• Prices and promotions: It is possible to configure different prices and promotions for each store, as you can segment them by trade policy. Still, prices and promotions for all stores are managed in the same panel.
• Message Center: One single Message Center for all stores.

This model is easier to set up, integrate, and maintain compared to the multi-account approach, but it may not be efficient for large and complex operations. This architecture is recommended for operations present in more than one country that require configuring different languages and currencies, but without the need for data segregation, as all core services are shared. Therefore, it may work well for operations managed by a single, centralized team.

Why choose this architecture?

• Supports multi-currency natively.
• Supports multi-language with Messages and the Catalog translation app.

Product names are not translated on the Checkout and My Account pages. These modules directly call the Catalog API to get product data, so the information does not pass through the Messages API.

In this architecture, one main account will act as a seller in secondary accounts that act as marketplaces.

The reference architecture below exemplifies its main characteristics:

• Separate VTEX account: Each store has its own VTEX account.
• Separate website: Each store has its own website and may customize its frontend with a different style per store.
• Customer data storage: Segregated by marketplace account. There is no customer information within the main account’s Master Data.
• Promotions: Promotions from the main account have limited capabilities, as every information that comes from the customer will not be accessible by the main account. For example, if you want to create promotions for a customer cluster in the main account, it won’t work because it doesn’t have access to the marketplace Master Data.
• Checkout, Order Management System (OMS), Payments, and Message Center: Each store manages these modules independently in its own Admin panel, without relying on the main account.
• Catalog, Pricing, and Logistics: The main account is the source of truth for these VTEX Core services, but management is independent, as each account has its own Admin panel. The product assortment can vary between accounts but is always based on the main account catalog, as the main account is the owner.

Assembly options, attachments, and services are not supported.

This architecture is recommended for operations in more than one country that require configuring different languages and currencies, where different teams manage each localized store.

Why choose this architecture?

• Supports both single fulfillment (all items shipped from one account) and multiple fulfillment (items shipped from different accounts within the same purchase), ensuring efficiency by optimizing logistics based on item availability and proximity to the customer.
• Having the seller (main account) act as catalog owner and the accounts for each country act as marketplaces enables a multi-language solution. This allows each store to manage its language and currency locally within its own store.
• Support better translations compared to the single account, multi-binding model, as there is an independent catalog translation. Therefore, you don’t need to rely on Messages or the Catalog translation app.

• Accounts and architecture
• Choosing between a multi-store architecture or an additional environment