WOOCOMMERCE DEVELOPMENT · WooCommerce 開発

WooCommerce in Japan needs konbini payment, Japanese address format validation, and long-form product pages — the same requirements as Shopify Japan but on a different technical stack

WooCommerce stores targeting Japanese buyers require configuration that goes well beyond what the default WooCommerce setup provides. Konbini payment is not a niche preference in Japan — it is a mainstream payment method that a significant portion of online buyers use as their primary option. Japanese postal address format does not map to the WooCommerce checkout field order. Product pages that convert in Western markets — a title, a price, a short description, and an add-to-cart button — are considered information-thin by Japanese buyers who expect detailed specifications, measurements, materials, production information, and review breakdowns before purchasing. And SEO for a Japanese-language WooCommerce store requires correct WPML and hreflang configuration, not just Japanese translation. Ignited Nepal builds WooCommerce stores for the Japanese market with these requirements as the starting point, not as afterthoughts.

Request a WooCommerce Development Brief → View the evidence →
This is for you if

WooCommerce development in Nepal is relevant to you if any of the following describes your situation.

You are a Nepali retail or export brand that built on WordPress because your developer was familiar with it, and you added WooCommerce as the shopping layer. Your store works at a basic level but you are noticing that payment failures are increasing, pages load slowly, or your multilingual configuration is not sending the right traffic to the right language version.

You are running eSewa or Khalti as your payment gateway and have either installed the official WooCommerce plugin and found it breaks periodically, or you have not yet set up payment gateways at all and are handling transactions manually.

You have more than 500 products on your WooCommerce store and you are experiencing noticeably slower performance on product listing pages, the cart, or checkout — particularly during higher-traffic periods.

You have a Nepali/English store configured with WPML and you suspect — or have been told — that your hreflang implementation is incorrect and is affecting your organic search visibility with international buyers.

You know your WooCommerce installation has not been maintained properly: plugins are outdated, the WordPress version is behind, and you are uncertain whether your hosting configuration is adequate for your current traffic.

What's broken

Problems We Fix

Konbini payment not available

Japanese buyers expect to be able to pay at a convenience store — Lawson, FamilyMart, 7-Eleven — by generating a payment code at checkout and completing payment in person. WooCommerce has no native konbini gateway. GMO Epsilon and Komoju are the two most commonly used payment processors that provide WooCommerce plugins with konbini support. The plugin installation alone is insufficient — the gateway needs to be configured with live merchant credentials, the payment code display page needs to be customised to show the correct instructions in Japanese, and the order status workflow needs to reflect the pending-payment state that konbini orders remain in until the convenience store payment is confirmed. Stores that accept only credit card miss a material proportion of potential Japanese buyers.

Japanese address capture broken in WooCommerce checkout

Japanese postal addresses follow a different sequence from Western addresses: postal code first, then prefecture, then city/ward, then town/district, then building and apartment number. WooCommerce's default checkout fields present address line 1, address line 2, city, state/prefecture, and postcode in a Western order. Japanese buyers entering their address in WooCommerce's default field order are either entering incorrect data, abandoning checkout, or entering a workaround that breaks address parsing for fulfilment. The correct fix adds postcode-first address lookup (which auto-populates prefecture and city from the Japan Post postcode database), reorders the checkout fields to the Japanese convention, and validates addresses against the expected Japanese format.

WooCommerce product pages not extended for Japanese content depth

A Japanese product page that converts typically contains: product title, price with tax display, multiple product images including lifestyle and detail shots, full material and specification table, size guide with measurements in centimetres, care instructions, production or origin information, and a review section broken down by category. WooCommerce's default single product template renders a title, images, short description, and add-to-cart. Adding the content depth that Japanese buyers expect requires additional product tabs — implemented either through a WooCommerce tab plugin or custom template overrides — and additional custom fields for specifications, measurements, and production details. A template that is not extended for this content depth will underperform against Japanese competitor stores regardless of traffic quality.

No Japanese SEO configuration

A bilingual Japanese/English WooCommerce store requires correct WPML configuration, correct hreflang tag output, and correct Yoast or RankMath setup for Japanese-language meta titles and descriptions. Common issues include: WPML configured but hreflang tags pointing to the wrong language URL; Yoast SEO generating meta titles in English for Japanese pages because the separator and template settings were not updated per language; Japanese product content not indexed separately from English because WPML translation was set to synchronised rather than separate posts; and sitemap not including the Japanese language URLs. Each of these is a configuration issue but each has a material effect on whether the Japanese version of the store appears in Japanese Google search results.

What we engineer

What We Build

Konbini payment gateway integration — GMO Epsilon or Komoju — with Japanese-language payment instructions

Konbini payment gateway integration — GMO Epsilon or Komoju — with Japanese-language payment instructions

Japanese address format checkout — postcode-first lookup, correct field order, prefecture auto-populate

Japanese address format checkout — postcode-first lookup, correct field order, prefecture auto-populate

Extended WooCommerce product page template with specification tabs, size guide, care instructions, and production detail fields

Extended WooCommerce product page template with specification tabs, size guide, care instructions, and production detail fields

WPML Japanese/English configuration with correct hreflang, separate indexation, and Japanese sitemap

WPML Japanese/English configuration with correct hreflang, separate indexation, and Japanese sitemap

Yoast or RankMath configured for Japanese meta title and description templates

Yoast or RankMath configured for Japanese meta title and description templates

Custom WooCommerce theme developed for Japanese UX conventions — information density, trust signals, social proof positioning

Custom WooCommerce theme developed for Japanese UX conventions — information density, trust signals, social proof positioning

Product page review section with star breakdown and verified purchase labels in Japanese

Product page review section with star breakdown and verified purchase labels in Japanese

LINE share integration on product and post-purchase pages

LINE share integration on product and post-purchase pages

Request a WooCommerce Development Brief →
What changes

What a correctly built and maintained WooCommerce store looks like

Before
After
Before eSewa has an official WooCommerce plugin, but it is updated irregularly. When eSewa updates its ePay API — which it has done multiple times — stores relying on the official plugin begin experiencing payment failures that are difficult to diagnose because the error messages from the plugin are not specific. Customers reach the eSewa payment screen and are either unable to complete the transaction or are returned to the WooCommerce store with an order status that does not match what happened in eSewa's system. For production WooCommerce stores that depend on eSewa as a primary payment method, a custom plugin built directly against eSewa's ePay API is more reliable than the official plugin. It gives your development team direct control over the integration logic and means a future eSewa API update does not break checkout until an official plugin update is eventually released.
After Payment failures from eSewa drop significantly. Orders that were previously getting stuck at the payment gateway — or completing on the eSewa side but not updating in WooCommerce — are processed correctly and order statuses are reliable. Your operations team stops spending time manually reconciling eSewa payments against WooCommerce orders.
Before WooCommerce is a database-heavy platform. Every product page, cart update, and checkout step triggers database queries. On a correctly configured server with Redis or Memcached object caching, many of those queries are served from cache rather than hitting the database on every request. On a shared hosting environment — such as those commonly used by Nepali WooCommerce stores on Vianet, Subisu, or similar providers — object caching is typically not enabled by default. The result is that your WooCommerce store runs every query against the database on every page load. Product pages are slower than they need to be. The cart and checkout are particularly affected because they involve non-cacheable operations that stack on top of the already uncached database queries. Customers experience slow load times that are not a code problem — they are a server configuration problem. Configuring Redis or Memcached object caching, combined with a page caching plugin such as WP Rocket or LiteSpeed Cache, significantly reduces database load and improves page response time without changing any of your WooCommerce code.
After Product pages load faster. The combination of object caching, page caching, and database optimisation means your store is not running unnecessary database queries on every page load. The improvement is most visible on product listing pages and checkout, which are the two points in the purchase path where slow performance most directly affects conversion.
Before WPML is the most widely used multilingual plugin for WooCommerce and WordPress. When it is set up correctly, it creates separate Nepali and English versions of your product pages and tells Google which version to serve to which audience using hreflang tags. When it is configured incorrectly — which happens frequently because the WPML hreflang settings interact with both your WordPress permalink structure and your SEO plugin — Google does not receive clear signals about which page is for which language. The consequence for a Nepali e-commerce brand targeting both domestic Nepali buyers and international English-speaking buyers is that Google may serve the Nepali-language page to an English-language searcher from Australia or the US, or it may index both versions as duplicate content and reduce the ranking authority of both. Fixing WPML hreflang configuration requires auditing your current hreflang output, correcting the WPML language settings, ensuring your SEO plugin (Yoast or Rank Math) is not overriding WPML's hreflang, and validating the output with Google Search Console.
After Your multilingual store sends the right traffic to the right page. English-speaking buyers from international markets reach your English product pages. Nepali-speaking buyers reach your Nepali pages. Google Search Console shows correct hreflang implementation and you stop seeing international organic traffic going to Nepali-language pages.
Before WooCommerce stores accumulate database weight over time. Every product update creates a post revision. Every session creates a transient. Orphaned product metadata from deleted or edited products accumulates in the wp_postmeta table. Stores that have been running for two or more years with 500 or more products, and that have not had a database maintenance pass, typically have wp_postmeta tables three to five times larger than necessary. The effect is slow product listing pages — particularly collection pages that query across many products — and slower checkout performance. This is not a hosting problem and not a code problem. It is a database problem that is resolved by removing post revisions, clearing expired transients, removing orphaned metadata, and running a database optimise pass. Following that, implementing a database maintenance schedule and limiting the number of stored revisions in wp-config.php prevents the problem from recurring.
After Your development team can maintain the store reliably. Custom plugins are documented. Plugin count is rationalised. The WordPress and WooCommerce installation is on a current version with a defined update process. You are not dependent on a single developer who knows the undocumented configuration history of the store.
How it works

How we work on WooCommerce projects in Nepal

  1. 01

    Technical discovery

    Before any development work begins, we audit your current WooCommerce installation. This covers: WordPress and WooCommerce version, active plugin list and last-updated dates, hosting environment and available server-level caching, database size and table health, current payment gateway configuration, and any known issues you have been experiencing. For new builds, we scope the technical requirements based on your product catalogue, payment methods, and any integration requirements.

  2. 02

    Brief and scope

    We document the specific work to be done, the expected outcomes, and the timeline. For complex projects — custom payment gateway plugins, multilingual store configurations, or migration work — we include a technical specification that describes the implementation approach. You review and approve the scope before work begins.

  3. 03

    Development

    Development work is carried out in a staging environment that mirrors your production hosting. For payment gateway integrations, we test against the sandbox environments provided by eSewa and Khalti before going to production. For performance work, we measure before and after using consistent benchmarks so the improvement is documented.

  4. 04

    Testing and quality review

    We test the complete purchase path — product discovery, product page, cart, checkout, payment, order confirmation, and post-order email — in both languages where applicable. Payment gateway integrations are tested for success, failure, and timeout scenarios. We document any edge cases encountered during testing.

  5. 05

    Deployment and handover

    We deploy to production during a low-traffic window and monitor immediately after deployment. We provide documentation for any custom plugins developed, and a written summary of the configuration changes made. If your team needs training on ongoing maintenance tasks, we provide that as part of the handover.

Request a WooCommerce Development Brief →
Common questions

Frequently Asked Questions

How do I add konbini payment to WooCommerce for Japanese buyers?

Konbini payment requires a Japanese payment processor that supports convenience store collection. Komoju provides a WooCommerce plugin with konbini support and is straightforward to set up for international merchants selling to Japan. GMO Epsilon is the larger Japanese processor and is used by higher-volume stores, but requires a Japanese business registration for the merchant account. After installing the plugin, configure the konbini payment instructions page in Japanese — the page displayed after checkout confirmation showing the payment code and store instructions. The WooCommerce order status for konbini orders should remain "pending payment" until the processor confirms receipt, not move to "processing" immediately on checkout submission.

How do I fix the address format for Japanese customers in WooCommerce checkout?

Japanese address format requires the postcode to appear first and to trigger an auto-lookup that populates prefecture (state) and city. The WooCommerce Checkout Field Editor plugin allows field reordering, but the postcode-to-address lookup requires a separate JavaScript integration with the Japan Post zipcode API (yubinbango.js is the most commonly used library for this). After adding the lookup script, configure the field order to: postal code, prefecture (auto-populated), city (auto-populated), town/ward, building and room number. Relabel the WooCommerce field labels in Japanese. Test with multiple postcodes across different prefectures to confirm the auto-populate is working correctly before going live.

How do I add product specification tabs and size guides to WooCommerce product pages in Japanese?

WooCommerce has a native product tabs system that can be extended. The WooCommerce Tab Manager plugin adds custom tabs at the product level, which works for small catalogues. For larger catalogues, custom product meta fields (registered via `register_post_meta` or ACF) mapped to custom tab template partials give better control. For a Japanese store, the standard additional tabs are: specifications (仕様), size guide (サイズガイド), care instructions (お手入れ方法), and product story or origin (商品について). Each tab should include the Japanese label and the content should be editable from the WooCommerce product edit screen. Avoid putting all specification content in the short description field — it loses the structured display that Japanese buyers expect.

How do I configure SEO for a Japanese WooCommerce store using WPML and Yoast?

With WPML and Yoast SEO installed on a WooCommerce store, go to WPML > Languages and enable "Different SEO fields per language". In Yoast, set SEO titles and meta descriptions separately for each WPML language — the Japanese versions need Japanese-language templates, not English templates with Japanese content. Ensure WPML is set to use separate URLs for Japanese (e.g. /ja/ subdirectory or a separate domain) rather than URL parameters. In the Yoast sitemap settings, confirm that both language versions are included in the sitemap. Check the hreflang output by viewing source on a Japanese product page — you should see two hreflang tags: one for ja and one for the default language. If hreflang is pointing to the same URL for both languages, WPML's language URL configuration needs to be corrected.

Should a Japanese e-commerce brand use WooCommerce or Shopify?

Shopify's Japan market support has improved significantly — Shopify Payments accepts Japanese payment methods including konbini via GMO-PG, and Shopify's Japanese app ecosystem is well-developed. WooCommerce is a better fit when the brand already has a WordPress content presence that it does not want to separate from the store, when it requires custom product data structures that WooCommerce's custom fields handle more flexibly than Shopify's metafields, or when it has specific hosting or data residency requirements. For a new store with no existing platform investment, Shopify with the correct Japanese payment and checkout configuration is faster to launch. For a store with existing WordPress infrastructure, custom product data, or complex integration requirements, WooCommerce on managed WordPress hosting is the more maintainable path.

Our team

The people behind the work

Not a black box. Real specialists you can call, with their names on the work.

Niraj Raut

Niraj Raut

Founder — Ecommerce SEO
Keshab Joshi

Keshab Joshi

PPC Expert
Hawrry Bhattarai

Hawrry Bhattarai

Google Ads Expert
Arogya Rijal

Arogya Rijal

SaaS SEO Expert
About Us →
Start here

Start with a WooCommerce development brief

If your WooCommerce store has payment gateway failures, performance problems, or a multilingual configuration that is not working correctly, a development brief is the right starting point. We audit what is actually broken before scoping any work.

Request a WooCommerce Development Brief →