The term “market” refers to a place where people gather to exchange goods or services. The parties involved are sellers and buyers. A single trade is also known as a transaction. In most cases, sellers exchange their products for money, and every market has its own rules. In fact, markets can differ by products sold, currency, payment methods, selling process, government regulation, taxes, and so on.
Markets may also have very different geographical boundaries. The Internet has eliminated many of those barriers, allowing merchants to reach customers worldwide by opening an online store. However, cultural, commercial, and legal differences between markets still exist, and it is the seller who must adapt, not the buyer.
This publication was meant to retrace the steps my co-founder Massimo and I took while building Commerce Layer, article by article. This is my tenth piece, and I couldn't think of a better topic to honour my promise than describing how we designed markets in Commerce Layer and how powerful our model is, in all its simplicity.
The market model
A market can be modeled as an aggregation of business settings. Following is a diagram that illustrates the main resources involved and their relationships.
Each resource has a well defined role. Let's look at each of them one by one and see how they can be used to support some common use cases.
Merchant
The first resource that defines a market is the merchant, or the seller who gets paid for the goods. The merchant is the brand’s or retailer’s legal entity, which is liable for ensuring PCI compliance and paying taxes in a market. Even if the customer always sees the same logo and domain, behind the scenes the “merchant of record” can vary market by market.
Before July 2021, Europe had distance selling thresholds that required companies to register new legal entities in the countries where their sales volume exceeded a certain limit. Italian brands, for example, had to register a legal entity in Germany if they exceeded 100.000 EUR in online sales annually. In France, it was 35.000 EUR, and in the Czech Republic, 1.140.000 CZK.
These EU distance selling thresholds no longer exist and instead, you must charge VAT at the rate of the member state where your customer is located. To help businesses streamline their VAT reporting, the EU has introduced two new special schemes: the One Stop Shop (OSS) and the Import One Stop Shop (IOSS).
By using these schemes, online businesses can report taxes in one member state instead of registering multiple entities. However, registering different legal entities is still a very common need when selling cross border or in those markets where the business is run through a distributor.
Price list
Different markets can have different currencies or different price lists within the same currency. Moreover, customers expect the exposed prices to include taxes in some markets and not in some others. For example, B2C customers expect prices to include VAT, whereas B2B prices are shown without taxes. In the United States, prices do not include sales taxes, which are calculated at checkout.
In addition to containing the actual list of prices, the price list model associated with a market allows all these options to be configured. Furthermore, it is used to filter the SKUs that can be sold in a particular market. A SKU that has a price is sellable, otherwise it is not.
A new price list can be activated by switching the market's price list ID. In this way, you can import prices asynchronously from ERPs or CSV files and put them live with just a single API call.
Inventory model
Another component of a market is the inventory model, which consists of the stock locations that serve that market as well as order splitting and routing strategies. Product availability and delivery lead times are determined by the inventory model.
Depending on how stock is distributed, a SKU could be available in one market and unavailable in another, or possibly available in two markets but with different delivery times. By presenting this information on the product page or at checkout, you can provide customers with accurate information about stock and build omnichannel experiences such as Buy Online Pick Up In Store or Ship From Store.
Customer group
It is possible to restrict access to a market to a group of customers who must be authenticated in order to access its configuration. This type of restriction can be used to apply specific business rules to a particular customer segment or to an individual customer.
For example, it might be necessary to define specific price lists and assortments to B2B customers, offer them reserved payment methods, shipping options, and order fulfilment workflows.
Alternately, you might consider defining different customer groups based on loyalty program tiers and unlocking promotions based on each tier. You could offer VIP private sales or build an employee-only store by integrating a company SSO authentication system.
In any case, it is important to emphasize that regardless of different business rules for different markets, there must be a single view of the customer. Therefore, the customer model itself shouldn't be market-specific and could potentially be shared across markets.
Tax calculator
Every market has its own tax calculator, which determines the tax amount per order. VAT calculation is relatively simple in Europe, since each country has a flat tax percentage that only changes by product category. In the United States, instead, tax calculation can become very complicated, with sales taxes determined by cities, states, counties, districts, and physical or economic nexus.
It is therefore recommended that you connect each market to a tax calculation service. TaxJar and Avalara are two of the most popular alternatives, providing great APIs and offloading all calculation efforts.
Payment methods
Customers want to use their local payment methods to pay. Wikipedia lists 77 payment service providers around the world. Among the most popular gateways are Stripe, Adyen, Braintree, PayPal, Apple Pay, Google Pay, Amazon Pay, and Alipay.
Depending on the market, one provider might be better than another. The idea of servicing all countries with a single payment gateway just doesn't scale well. Thus, connecting different payment gateways to different markets is imperative to optimize conversions and reduce transaction costs.
If you have two markets with two different merchants, you can also connect the same payment gateway with different merchant accounts. This way, customers just pay for their orders, and the market model will take care of orchestrating the actual merchant account that receives the funds.
Shipping methods
Similar to payment methods, shipping methods should also be localized based on the local market. More than 55 shipping carriers are supported by Commerce Layer, including UPS, USPS, Fedex, and DHL. Connecting different shipping carriers to different markets (also more than one per market) enables merchants to serve customers faster and optimize shipping fees.
Promotions
Promotions must be market-specific. Some types of promotions work better in some cultures than others. In addition, promotions are often tied to holiday seasons events that vary from market to market. Ideally, you should be able to "set and forget" a calendar of promotions that activate during specific times in each market. For marketers, a promotion engine that makes it easy to accomplish that can be a game changer.
Selecting a market
After a market has been configured, the market ID allows you to identify all the related configurations. Commerce Layer uses the OAuth2 authentication system for this. A market ID can be put into scope when requesting an access token with a sales channel application (i.e., as a guest customer). JWT access tokens generated by that process contain the market ID in their payloads. With that token, any API call will automatically determine the merchant, price list, inventory model, and all the other business configurations described above.
Access tokens obtained using the password flow (or custom JWTs obtained from third-party identity providers) are associated with both the logged-in customer as well as the market in scope. Using this token, you will have access to the customer's private information, including order history, address book, payment wallet, and returns. Whenever the market is restricted to a customer group, the logged-in customer must be a member of that group to receive a valid access token.
By using this simple, yet powerful mechanism, you can connect any logic or data model to a market. Common scenarios include tying the market ID to a country object. As soon as a customer selects a country from a country selector, you can get an access token putting the associated market ID within scope. Instead, if you want to model a B2B store, you will be required to log your customers in and obtain an access token that contains the market ID that is restricted to their particular customer group.
Naming things is hard
The examples mentioned above are just a few of the possible ways to use a market. A market isn't just a geographical segment of your business; it's an aggregation of business rules that can be related to any business logic.
Massimo and I chose a name that would have made more sense in many application scenarios, but this resource offers much more. Don't get misled by its name. In the end, we all know that naming things is one of the two hard things in Computer Science, and our "market" model was no exception.