A cross-border store is a specialized multistore setup where a VTEX account operates multiple localized stores for different countries or regions, each with its own pricing, logistics, and language configuration. Depending on the architecture you choose, the catalog may be shared across stores or managed separately.

In a cross-border context, a multistore setup allows a single VTEX account to manage multiple stores, such as:

• http://{storeName}.com/en (English store)
• http://{storeName}.com/pt (Portuguese store)

In this guide, you'll learn how to start implementing your cross-border operation, including:

• Store architecture: Define your operation and choose the architecture that best fits your business needs.
• Quickstart: Discover the initial steps to implement your cross-border store.
• Fundamental tools: Set up the tools you must have for your cross-border operation to work correctly.

Cross-border stores are available for Store Framework and for FastStore through the Localization feature in FastStore v4. FastStore Localization is in Closed Beta. To become a cross-border store or request Localization access, open a VTEX support ticket and request the setup of a multistore environment.

To choose the most appropriate architecture that meets your business needs, address some initial questions that define the operation.

Before implementing your cross-border store, make sure you have the following information ready:

• Target regions: Identify the countries/regions where your store will operate.
• Currencies and languages: Determine accepted payment currencies and supported site languages.
• Inventory management: Decide if inventory will be managed from a single country or locally in each country/region.
• Tax and export partner: Choose a partner for handling export taxes and fees for international operations. To find a partner, visit the Partners page on the VTEX website.
• Catalog translation: Check if your catalog is translated or needs localization for each country/region.
• Promotions: Plan the types of promotions for each store. Learn about the types available in Promotions guides.
• Operations: Consider any existing physical stores, sellers, or other operations abroad. Learn more in Accounts and architecture.
• Teams: Identify if different teams will manage each country/region's ecommerce operations.
• ERP systems: Confirm if each country/region has its own ERP or a centralized system.
• Payment gateway: Make sure you have a gateway that supports multiple currencies.
• Domains: Define the primary and secondary domains for your stores. Learn more in Rules for main hosts.

After defining your operation based on the topics above, choose the architecture for your cross-border store.

• Single account, multi-binding
• Multi-account, shared back-office systems
• Multi-account, independent back-office systems

See below the main differences between them:

All architectures support multi-currency through sales channels. The main differences lie in how prices are managed and where pricing logic is centralized.

Learn more about each approach in the Multi-language and multi-currency section of the Store architecture guide.

To start implementing your cross-border operation, follow the steps below:

On VTEX, a sales channel is a set of configurations that define a store's catalog, pricing, and logistics strategy. In a multi-binding architecture, each website is linked to a specific sales channel, allowing separate sites for different markets. Learn more in How sales channels work.

If the pricing, catalog, or logistics structure differs between markets, create separate sales channels. If two stores share the same logistics, catalog, and prices, they can use a common sales channel.

To request a new sales channel, open a ticket with VTEX Support, select the option Commercial, and click Create a trade policy. Learn more in Creating a sales channel.

When configuring sales channels, make sure the currency code and symbol, as well as the country code and cultural information, are set correctly.

On VTEX, binding is the process of linking a website, store name, and sales channel to create a unique identifier for each store. This is essential for managing multiple stores in a single VTEX account.

In a cross‑border setup, you create multiple bindings to connect each market's domain to its corresponding sales channel and locale, so each site runs with the right catalog, currency, and language.

To create a new binding, open a ticket with VTEX Support.

You can retrieve your store's binding ID by using the following API:

Alternatively, follow the instructions in the Checking your store's binding ID guide.

When multiple language versions of URLs are required, create one binding for each language. Using a single binding for multiple languages isn't the proper approach. In Store Framework, even if you manually create additional URLs via GraphQL calls, it can result in duplicate content because the page defaults to the primary language. In FastStore, even if a binding is configured with multiple locales, only the default locale is considered.

This step applies to Store Framework stores. In FastStore, currency is defined by the sales channel associated with each binding. Learn more in Handling internationalization with the Localization feature.

To enable the use of a custom currency symbol in your store, follow these steps:

1. In the VTEX Admin, go to Store Settings > Storefront > Store.
2. Click the Advanced tab.
3. Enable the Enable custom currency symbol option.

Use the currency symbol field defined in the sales channel.

The tools you need depend on your storefront technology. Sales channels, bindings, and catalog translation apply to both Store Framework and FastStore.

• Catalog translation: To translate catalog information (categories, products, SKUs, brands, specifications, and collections) and override the automatic translation, we recommend using the Catalog Multi-Language API. It provides granular control over translations for products, SKUs, categories, brands, and other entities, while integrating natively with Intelligent Search and supporting Translation Management Systems (TMS). To learn how to implement it, see the Catalog multi-language integration guide, including the implementation by storefront type.

  Product information on the Order Placed pages and in transactional emails is automatically translated. On the My Account page, product information isn't translated automatically and may require additional customization.

  The simultaneous use of both the Catalog Multi-Language API and the GraphQL catalog translation flow isn't supported for catalog entities. Once the Catalog Multi-Language feature is activated, you'll no longer be able to manage catalog translations using GraphQL. For stores that still use the legacy GraphQL translation flow, see Translating Catalog content.

• Locale Switcher: Allows switching languages on the site.
• Messages: Handles storefront component translations per language (binding). Use it especially for specifications, breadcrumbs, and filters. Learn more in Translating storefront content and Overwriting the Messages app.
• Translatable URLs: Cross-border stores that share the same catalog can translate catalog URLs (product, category, and brand slugs) per binding. For example, a product available as http://{storeName}.com/us/yellow-dress/p in one market can resolve as http://{storeName}.com/ar/vestido-amarillo/p in another. Catalog URL translations are accepted for each binding — not for multiple languages within a single binding. Learn more in Cross-border store content internationalization.

FastStore supports cross-border and multi-language stores through the Localization feature. Requirements and setup include:

• FastStore v4: Required for Localization.
• CMS: Localization works with the CMS and isn't available for Headless CMS (legacy).
• Bindings and sales channels: Each domain is associated with a sales channel (currency, catalog, and pricing) and a locale. Configure bindings with VTEX Support, then enable the localization flag in discovery.config.js and the localization button in the CMS Navbar.

For the full implementation, see Handling internationalization with the Localization feature.