WOOCOMMERCE DEVELOPMENT

WooCommerce in Qatar needs Arabic RTL, QAR pricing, and COD workflow — and the standard WooCommerce setup handles none of them correctly by default

A WooCommerce store launched for the Qatari market without Arabic RTL, correct QAR currency display, and a functioning COD verification workflow will underperform against local competitors that have addressed these requirements. Arabic is the primary language for a significant portion of Qatari online shoppers, and a store where the Arabic text sits in a left-to-right layout structure is immediately legible as foreign or poorly localised. QAR displayed as an ISO currency code rather than the Arabic riyal symbol is a minor signal but one that affects perceived quality. COD without a verification step generates high non-delivery rates in the Gulf e-commerce market — WhatsApp confirmation before dispatch is a standard operational practice that needs to be built into the WooCommerce order workflow. And BNPL options including Tabby and Tamara are expected at checkout by Qatari buyers. Ignited Nepal builds WooCommerce stores for the Gulf market with these requirements as foundation requirements, not optional additions.

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

Arabic RTL theme not configured

WPML with Arabic translation installed adds the translated content, but the theme CSS controls the direction of the page layout. Most WooCommerce themes are built for LTR layouts. When Arabic is selected, the text content changes to Arabic but the navigation, product grid, sidebar, checkout fields, and button positions remain left-to-right. Arabic readers reading right-to-left encounter a layout where the natural reading flow conflicts with the visual structure of the page. Correct RTL implementation requires the theme to detect the active language and apply `direction: rtl` and `text-align: right` at the layout level — not just on text elements — and to mirror the positional elements that are directionally dependent: navigation icons, cart icon placement, breadcrumb arrows, form field label alignment, and checkout progress indicators.

QAR currency not displaying the correct symbol

WooCommerce's default currency display for QAR shows the ISO code "QAR" before or after the price. Arabic-language product pages for Qatari buyers should display the Qatari riyal symbol ر.ق, which is the standard Arabic typographic symbol for the currency. The WooCommerce currency settings do not include this symbol by default. A custom function in the theme's functions.php file, or a currency customisation plugin, is required to replace the ISO output with the correct symbol. On bilingual sites, the symbol output should switch: the Arabic version of the store shows ر.ق and the English version shows QAR or the Latin QR notation, depending on brand preference. This is a small but visible signal of localisation quality.

COD workflow not automated

Cash on delivery is a widely used payment method across Gulf e-commerce markets. WooCommerce's native COD payment method processes orders immediately and moves them to the standard order queue without any verification step. In Qatar and the UAE, COD orders without prior confirmation — via WhatsApp, SMS, or phone — have materially higher non-delivery rates than orders where the buyer has confirmed their intent to pay in a brief pre-dispatch message. Building a COD verification step into the WooCommerce order workflow requires either a custom order status (e.g. "Awaiting COD Confirmation") inserted between order placement and processing, and an automated WhatsApp message triggered via a gateway such as Twilio or the WhatsApp Business API, or a manual admin workflow with a clear hold status and confirmation tracking. The specific implementation depends on order volume and team capacity.

Tabby or Tamara BNPL not integrated correctly

Both Tabby and Tamara have official WooCommerce plugins available. The most common issue is that the plugins are installed and visible at checkout, but the BNPL options are non-functional because the merchant credentials are test credentials or the currency configuration does not match the live account settings. Tabby's WooCommerce plugin requires QAR to be the active currency in the WooCommerce currency settings and the live API keys from a Tabby merchant account that has been approved for Qatar. Tamara has the same requirements. A second common issue is that neither BNPL option shows at the product level — the instalment amount is not displayed at the product price, which reduces BNPL adoption because buyers do not consider BNPL until checkout rather than at the product decision point.

What we engineer

What We Build

Arabic RTL theme configuration — layout-level direction switching, not text-only translation

Arabic RTL theme configuration — layout-level direction switching, not text-only translation

QAR ر.ق symbol display in WooCommerce on Arabic-language pages

QAR ر.ق symbol display in WooCommerce on Arabic-language pages

COD verification workflow — custom order status, WhatsApp gateway trigger, admin confirmation interface

COD verification workflow — custom order status, WhatsApp gateway trigger, admin confirmation interface

Tabby and Tamara BNPL integration with QAR live credentials and product-level instalment display

Tabby and Tamara BNPL integration with QAR live credentials and product-level instalment display

WPML Arabic/English configuration with correct RTL/LTR switching per language

WPML Arabic/English configuration with correct RTL/LTR switching per language

Custom WooCommerce product page template built for Gulf market content conventions

Custom WooCommerce product page template built for Gulf market content conventions

Payment gateway integration: Stripe, PayTabs, or MyFatoorah for card payment alongside COD and BNPL

Payment gateway integration: Stripe, PayTabs, or MyFatoorah for card payment alongside COD and BNPL

WooCommerce performance optimisation on Gulf-region hosting or CDN configuration

WooCommerce performance optimisation on Gulf-region hosting or CDN configuration

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.

Common questions

Frequently Asked Questions

How do I add Arabic RTL to WooCommerce correctly — what is required beyond WPML translation?

WPML translation changes the content language but does not change the layout direction. Correct Arabic RTL in WooCommerce requires: the theme to apply `direction: rtl` to the HTML or body element when the Arabic language is active; all absolute and float-based positional CSS to be mirrored for RTL (left becomes right, padding-left becomes padding-right); flexbox and grid layouts to use `flex-direction: row-reverse` where directional; and WooCommerce template overrides for checkout, cart, and single product to be tested in Arabic for layout integrity. The WPML language switcher detection is the trigger — when `ICL_LANGUAGE_CODE === 'ar'` is true, the RTL stylesheet or direction override should load. Test each page type — homepage, category, product, cart, checkout, account — in Arabic and audit for layout direction errors before going live.

How do I display the QAR ر.ق symbol in WooCommerce instead of the ISO code?

In WooCommerce Settings > General, the currency symbol for QAR defaults to "QAR". Add a filter in your theme's functions.php: `add_filter('woocommerce_currency_symbol', function($currency_symbol, $currency) { if ($currency === 'QAR') { return 'ر.ق'; } return $currency_symbol; }, 10, 2);` This replaces the ISO code with the Arabic riyal symbol across all WooCommerce price displays. On a bilingual site, wrap the filter in a language condition so that the Arabic symbol only displays when WPML's active language is Arabic, and the ISO code or your preferred Latin notation displays for the English version. Confirm the symbol displays correctly in the product price, cart, checkout, and order confirmation email.

How do I add a COD verification step to WooCommerce for Qatar orders?

Register a custom WooCommerce order status — for example "pending-cod-confirmation" — using `register_post_status` and `wc_register_order_statuses`. Configure WooCommerce so that orders placed with the COD payment method receive this status instead of "processing". Set up a WhatsApp Business API integration (via Twilio, 360dialog, or a similar gateway) to send an automated message to the buyer's phone number when an order enters the "pending-cod-confirmation" status. The message should confirm the order details and ask the buyer to reply to confirm. When the buyer confirms, an admin user changes the order status to "processing" and the standard fulfilment workflow continues. Orders that do not receive confirmation within a set period can be automatically moved to "on hold" or cancelled.

How do I configure Tabby or Tamara in WooCommerce for Qatar buyers?

For Tabby: install the official Tabby WooCommerce plugin from the WordPress plugin directory. In the plugin settings, enter your live API public key and secret key from the Tabby merchant dashboard. Set the currency to QAR in both WooCommerce currency settings and in the Tabby plugin configuration. Enable the Tabby promotional widget on product pages by activating the product price widget option in the plugin. For Tamara: the process is identical using Tamara's WooCommerce plugin. Both plugins require that the merchant account has been approved for Qatar and that live credentials are used — test credentials will show the BNPL option at checkout but will not process payments. After configuration, test a full purchase flow with a small order value to confirm the payment completes and the order status updates correctly.

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

Shopify has strong Gulf market support — Shopify Payments is not available in Qatar, but PayTabs and MyFatoorah are supported gateways, and Tabby and Tamara both have Shopify apps. Shopify's Arabic RTL support is built into the Dawn theme and Shopify's theme architecture, which makes RTL implementation more reliable than custom WordPress theme RTL development. WooCommerce is a better fit when the brand requires deeper product data customisation, has existing WordPress infrastructure, needs complex custom integrations with Gulf-based logistics or ERP systems, or has a specific requirement for data hosting within the region. For a new store without existing platform investment, Shopify with Gulf-compatible gateways is a faster and more maintainable launch. For an existing WooCommerce store, the correct path is to fix the RTL, currency, and payment issues on the current platform unless there is a strategic reason to migrate.

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
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.