Is Medusa ready for the Japanese market?
— a Tokyo native's gap map

Medusa ships no first-party scaffolding for the two things a Japanese commerce site legally needs. A B2C store is expected to publish a 特商法に基づく表記 page (Specified Commercial Transactions Act disclosure — seller, address, returns, pricing). A B2B store, since the インボイス制度 took effect in October 2023, must issue 適格請求書 (qualified invoices) carrying the seller's registration number. Medusa provides neither a 特商法 template nor 適格請求書 fields out of the box; the merchant builds both from scratch.

docs.medusajs.com — no 特商法 / 適格請求書 template or guide

This is the gap that's unique to a commerce engine. A typesetting tool with no 特商法 page is awkward; a store with no 特商法 page can't open for business to Japanese consumers, and a B2B store with no 適格請求書 can't sell to Japanese companies that need the input-tax deduction. The merchant who picks Medusa discovers this after building, not before.

A 特商法に基づく表記 template wired into the storefront, and 適格請求書 (registration number, tax-rate breakdown) support in the order/invoice flow. Both are commerce-compliance features, not translations — they need someone who has shipped a Japanese store.

Medusa's admin dashboard ships a full Japanese translation — ja.json sits in the i18n translations directory alongside ko, zhCN, zhTW and 30+ others. So Medusa already speaks Japanese to the merchant. Yet at the same time, products with Japanese (or any non-Latin) titles could not be created at all until recently: handle generation failed on non-Latin characters. That was issue #14378, fixed in PR #15346 (32 comments). The Japanese capability is partly built, was partly broken, and is entirely undiscoverable from the funnel.

github.com/medusajs/medusa #15346 — non-Latin (Japanese/Chinese/Korean) product handles fixed

A Japanese merchant who tried Medusa before that fix added a product named in Japanese and hit an error on day one — the worst possible first impression for a store builder. Even now, the Japanese admin translation that already exists never gets advertised to the Japanese audience, because the docs and marketing that would surface it are English-only.

Surface the existing Japanese admin in the Japanese funnel, and add a CJK test to the product/handle path so Japanese product names are a first-class case, not a regression risk.

docs.medusajs.com/ja returns 404 — there is no Japanese documentation. The marketing site has no Japanese landing page and no hreflang ja. Medusa Cloud's own pricing is presented in USD only ($0 / $29 / $99 / $299), with no JPY path for the team paying for the managed tier.

docs.medusajs.com — English only, /ja → 404

Medusa is chosen by developers building a custom store, and Japanese developers evaluate infrastructure tooling in Japanese first — they read the docs before they commit a quarter of engineering to a commerce backend. With no Japanese docs and a USD invoice for the managed tier, the Japanese team weighing Medusa against a domestic headless-commerce option starts at a disadvantage that has nothing to do with the product.

Japanese documentation for the core build path (storefront + admin + the Japan-commerce specifics), and a JPY invoicing path for Medusa Cloud.

With no Japanese pages indexed, Medusa surfaces for none of the queries a Japanese team types when scoping a custom store: 「ヘッドレスコマース オープンソース」, 「Shopify 代替 自社EC」, 「Next.js EC 構築」, 「自社EC プラットフォーム 比較」.

The decision to self-host a commerce backend is made early, in the research phase, almost always in Japanese. If Medusa never appears there, it never enters the shortlist — the team picks the domestic option that did publish Japanese pages, and Medusa loses a six-figure build it was never evaluated for.

Japanese pages targeting the headless-commerce build queries, anchored to the 特商法 / インボイス story — the exact concerns that make a Japanese team hesitate to build on a foreign commerce engine.