International ecommerce platform capabilities

An Australian store selling overseas needs to give each target market the right products, prices, language and checkout experience. Compare platforms by following a representative customer journey, then check how staff maintain the differences between markets.

Use the same destination and product when you test each platform. This makes it easier to compare market configuration and spot where a capability depends on an app or integration.

Platform Capabilities for International Ecommerce in Australia

Define each market before comparing platforms

For each destination, record the intended products, customer language, displayed and charged currencies, delivery destinations and payment methods. Name the team responsible for regional content and prices. Treat these as requirements for the proposed configuration, not outcomes guaranteed by a market setting.

Ask Shopify or the shortlisted vendor whether the proposed market configuration can meet requirements for product availability, pricing, currency, domains and languages. Ask to see the intended configuration in a demonstration, rather than relying on the feature name alone.

BigCommerce can support multiple storefront websites through channels and sites within one store and catalogue. In either model, apps and integrations need to handle the relevant market or channel context.

For each destination, record the domain and URL requirements you expect. Ask the vendor to show how the proposed market or storefront maps to them, and check that the same setup gives customers the intended products, language and checkout.

Shopify’s documentation names catalogues for markets. Ask Shopify to demonstrate whether the intended market configuration can meet your product and pricing requirements.

Customer Journey for International Market Testing

Separate currency display from payment

Record the currency customers see, the currency they pay in and the currency the business receives. For Shopify and any other shortlisted platform, verify that the proposed processor and market configuration support the currencies and payment flow required for each destination.

BigCommerce distinguishes display-only currency, where checkout charges the default currency, from transactional currency, where the customer is charged in the displayed currency. Check the proposed processor, gateway and storefront setup before relying on either option.

Ask shortlisted platforms which pricing approaches they support, such as automatic conversion, manual rates, percentage adjustments or fixed product prices, and test them against the business's pricing rules. Include a refund in the review: the customer-facing price alone does not establish the eventual payout or refund conversion.

Shopify’s documentation names setting up currencies for markets. Test the required currencies in the proposed configuration, including what customers see and what happens at checkout.

BigCommerce’s multi-currency setup has specific prerequisites: a Stencil theme, Optimized One-Page Checkout and an enabled payment gateway compatible with multi-currency. Transactional currencies must be added through the active multi-storefront-enabled control panel; they cannot be created through the API. Treat these as configuration checks for the proposed storefront, not assumptions about every BigCommerce setup.

Do not change a BigCommerce store’s default currency as a shortcut to regional pricing. The documentation warns that changing it can cause conversion issues and does not recalculate catalogue prices. Check the default currency and catalogue pricing behaviour before approving a currency configuration.

Pre-Implementation Checklist for International Market Configuration

Treat translation as ongoing work

List the text customers encounter, including product details, navigation, promotions, checkout and order messages. Decide who updates and approves each translation when source content changes.

For Shopify, consult the current Translate & Adapt documentation and test the required languages and content types in the proposed storefront. BigCommerce's Storefront GraphQL API can return localised product data for an enabled locale, but returns global product data if local data is absent. Neither capability establishes that a complete storefront, theme or connected app is translated.

For BigCommerce product data, check the locale actually resolved for the storefront channel. A channel can use its default locale, the global locale or the shopper’s browser language; an integration can also specify a preferred locale through an Accept-Language header or GraphQL directive. Test representative products for missing translations.

BigCommerce’s API example uses the locale code fr. Test the locale codes required for your customers and confirm which locale the storefront resolves, rather than assuming that a translated product means the whole shopping journey is localised.

Key Requirements for Australian Stores Selling Internationally

Check product eligibility through the whole journey

Use an item sold in Australia but excluded from an overseas market. Inspect search, its direct URL, a saved basket and checkout.

For each shortlisted platform, confirm how the proposed configuration handles product availability across these paths. Check delivery eligibility and staff-created orders separately.

Repeat the test with an item that is available in the overseas market. This checks both that excluded products stay out of the journey and that eligible products remain purchasable.

Choose a structure the team can maintain

One store with market rules may suit a largely shared catalogue and operating team. Multiple regional storefronts may help when navigation, content ownership or channel configuration differs substantially. A separate domain does not, by itself, require an independent commerce store.

Ask shortlisted vendors to show the same products and destinations in their proposed configuration. Record what is built in, what depends on an app or custom work, and who maintains each variation. Confirm payment coverage, delivery and local obligations for the actual destinations before making the final platform decision.

BigCommerce channels represent places where a store sells, including storefront websites, marketplaces, point-of-sale systems and marketing feeds. Each store starts with a default channel for its first Stencil storefront, and that channel cannot be deleted. Multi-storefront setups can customise the shopping experience across websites, but partner apps may need changes to support multi-storefront and multi-channel selling.

Check that integrations preserve the shopper’s channel throughout the journey. BigCommerce’s API guidance says carts and checkouts created by an integration should specify the channel ID; correctly configured channel-to-site relationships then direct shoppers to the corresponding site. Order-management integrations should also include the channel ID so orders can be associated with the storefront where they were placed.

A storefront’s category structure may also need a channel-specific check. BigCommerce allows multiple category trees and assigns each tree to a storefront or other channel, but a tree can currently be assigned to a maximum of one channel. Confirm which tree is assigned to each proposed storefront and whether the catalogue organisation suits that market.

Compare the ongoing work required to keep product, currency, language and channel settings accurate. Choose the structure the team can operate consistently across the destinations it intends to serve.

BigCommerce vs Shopify: Key Trade-offs for International Selling