You sell stuff which costs money. But Norwegian Kroner, Euros and Japanese Yen are different kinds of money, used in different parts of the world. You need to handle this in some way.
If you only sell to one country, this will be very easy. You'll have one language, (most probably) one market and one currency to deal with. However, these are completely separate terms, and should not be handled in a 1:1:1 relationship.
You can, theoretically, sell in Swedish Kroners to the business market in Germany on a French site. And on the same site sell in US Dollars to consumers on Iceland with Dutch translations. These might not be super intuitive, as you probably noticed - but there's nothing stopping you from doing it.
A market is a conceptual group of customers. This might be things like "everyone in Sweden" or "everyone in Germany", but can also be "Businesses in Sweden" and "Consumers in Sweden". It depends on your site's customer base and demographics. If you only have one market (and this is not going to change anytime soon), you can probably be safe by using the default one. But think this through. Things might change in the future, so don't let all your code rely completely on this default-choice.
The market decides what products are available to the customer. If you're in the wrong market, you might not be able to buy certain things. If you need to have more than one market, you need to implement
ICurrentMarket for EPiServer Commerce to know what kind of customer it's dealing with.
Each market can support multiple currencies, countries and languages. The more combinations you need to support, the more complex things are going to be. Allow time in your project to deal with this. If you have a non trivial number of combinations, it will give you headaches at some point. Consider yourself warned.
- Will every product be available in every market? If not, how will this be controlled? Manually or via some automated job?
- Determine what markets you actually have. This is not a technical decision, and should most probably be made by your customer - but it will affect your job, and this should be reflected in your plans and estimates..
- Figure out your language-market-currency relations. This is not a technical decision, and should most probably be made by your customer - possibly together with you.
Be careful about what dependencies you hook onto each of these. You shouldn't usually be retrieving prices based on language - but it might be appropriate some times. And you should not retrieve language based on market - but it might be appropriate some times. Find out the logical connections between these. If it's "1:1:1" (so one market, one language and one currency always belong together), things might be easier. Consider these things, and find out what's right in your project.
Apart from that, localization behave more or less like in the CMS. It's inner workings, however, act differently. So debugging might be a chore in the beginning - allow extra time for this if you don't have any experience working with EPiServer Commerce.
This blog post is part of the series EPiServer Commerce project essentials which will give you a few tips on how to plan your projects.