WOOCOMMERCE DEVELOPMENT

UK WooCommerce development means Klarna integration, ICO cookie consent in WordPress, VAT-inclusive pricing, and getting off shared hosting before the performance issues compound

Most UK WooCommerce stores are running on configurations that made sense at launch but have not kept pace with UK consumer expectations, payment provider requirements, or regulatory obligations. Klarna Pay-in-3 is expected at the product price line, not buried at the payment step. ICO compliance means blocking non-essential scripts before consent is given, not installing a cookie banner that looks compliant but does not actually stop pixels from firing. VAT-inclusive display is a legal requirement for retail-facing prices, not a preference. And shared hosting that was adequate at a hundred monthly orders breaks visibly at a thousand. Ignited Nepal fixes the WooCommerce configuration issues UK stores carry without realising they have them, and builds the integrations — Klarna, Sage, cookie consent, tax display — that the default WooCommerce setup does not handle correctly.

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

Klarna Pay-in-3 not appearing at the product price line

Klarna's official WooCommerce plugin places the instalment messaging at the payment step in checkout, not at the product price. UK buyers expect to see the Pay-in-3 amount next to the product price — "or 3 payments of £X with Klarna" — not at the point where they have already decided whether to buy. Getting this right requires a custom theme hook to inject the Klarna promotional widget into the correct position in the WooCommerce product template, and CSS to align it with the existing price display. The default plugin installation does not do this. Stores that have installed the Klarna plugin and assumed Pay-in-3 messaging is working at the product price should check — in most cases, it is not.

WooCommerce cookie consent not ICO-compliant

The most common UK WordPress cookie setups — Cookie Notice by dFactory, CookieYes, or Complianz — are installed and showing a banner, but the non-essential scripts are still loading on page load. Google Analytics, Google Ads conversion tracking, Meta Pixel, and Hotjar are all firing before the visitor has given consent. ICO guidance is explicit: non-essential cookies and tracking scripts must not load until the user has actively accepted them. Implementing this correctly requires the consent plugin to control script loading — either through a tag manager trigger configuration or direct script-blocking integration — not just display a notice. Most UK WordPress sites have not done this, which means they are non-compliant regardless of whether the banner is present.

VAT not displayed inclusive in product prices

WooCommerce's default tax display setting shows prices exclusive of VAT, with VAT added at the cart or checkout step. UK Consumer Protection from Unfair Trading Regulations require that prices displayed to retail customers include VAT. A product showing £83.33 on the product page and £100.00 in the cart is not presenting pricing in the way UK law requires for retail-facing stores. The fix requires configuring WooCommerce tax settings to display shop prices inclusive of tax, setting the shop base country correctly, and ensuring the tax rate for the UK standard rate is applied accurately. This is a configuration issue, not a development project, but it is present on a significant proportion of UK WooCommerce stores.

Sage 50 or Sage 200 not integrated with WooCommerce

UK SME businesses using Sage accounting software have no native WooCommerce connector maintained by Sage. Orders placed in WooCommerce need to create sales invoices in Sage 50 or Sage 200, and stock levels in Sage need to update WooCommerce product inventory. Without an integration, staff are re-entering orders manually or running CSV exports on a schedule, which introduces errors and delays. A custom REST API integration between WooCommerce webhooks and the Sage API resolves the sync gap. The integration covers order creation, invoice generation, customer record matching, and inventory update — the four data flows that manual processes are most likely to get wrong.

What we engineer

What We Build

Klarna Pay-in-3 promotional widget at product price line via custom theme hook

Klarna Pay-in-3 promotional widget at product price line via custom theme hook

ICO-compliant script blocking tied to consent state — analytics, advertising, and tracking pixels do not fire before consent

ICO-compliant script blocking tied to consent state — analytics, advertising, and tracking pixels do not fire before consent

VAT-inclusive price display configured across shop, cart, and checkout

VAT-inclusive price display configured across shop, cart, and checkout

Sage 50 or Sage 200 to WooCommerce order and inventory sync via REST API

Sage 50 or Sage 200 to WooCommerce order and inventory sync via REST API

WooCommerce migration from shared hosting to managed WordPress hosting (WP Engine, Kinsta, or Cloudways)

WooCommerce migration from shared hosting to managed WordPress hosting (WP Engine, Kinsta, or Cloudways)

Custom WooCommerce theme development from Figma or existing brand guidelines

Custom WooCommerce theme development from Figma or existing brand guidelines

Payment gateway configuration: Klarna, Stripe, PayPal, and bank transfer

Payment gateway configuration: Klarna, Stripe, PayPal, and bank transfer

WooCommerce REST API integrations with ERP, fulfilment, and warehouse systems

WooCommerce REST API integrations with ERP, fulfilment, and warehouse systems

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 Klarna Pay-in-3 messaging to WooCommerce product pages at the price line?

The Klarna official WooCommerce plugin does not place promotional messaging at the product price by default. Adding it at the price line requires a custom action hook targeting the `woocommerce_single_product_summary` hook position — typically at priority 15 to place it directly after the price — and a call to the Klarna On-Site Messaging (OSM) widget with the correct data-key and data-purchase-amount attributes. The data-purchase-amount must be dynamically populated with the product price in the correct pence/integer format. CSS adjustment is usually required to match the widget appearance to the existing price display. This is a theme development task, not a plugin configuration task.

How do I make my WooCommerce cookie consent ICO-compliant for UK users?

ICO compliance requires that non-essential tracking scripts — Google Analytics, Google Ads, Meta Pixel, Hotjar, and others — do not load until the user has accepted them. Installing a cookie banner plugin is not sufficient if the scripts still load on page load. The correct implementation either uses a consent management platform that integrates directly with Google Tag Manager consent mode (so GTM fires tags only when the relevant consent category is granted) or uses the cookie plugin's script blocking feature to wrap each third-party script in a consent condition. After implementation, verify compliance by loading the site in an incognito window with network monitoring open and confirming no third-party tracking requests fire before accepting the consent banner.

How do I display VAT-inclusive prices in WooCommerce for UK retail customers?

In WooCommerce, go to Settings > Tax. Set "Display prices in the shop" to "Including tax" and "Display prices during cart and checkout" to "Including tax". Ensure your tax rate is set up correctly under Tax Rates with the standard UK rate of 20% applied to taxable products. Set the "Price display suffix" to empty or to a label such as "inc. VAT" if you want to make the inclusion explicit. Confirm that the base country for your store is set to United Kingdom. If you entered product prices inclusive of VAT when adding products, and WooCommerce was calculating VAT on top of that, you will need to recalculate your product prices after changing the tax display settings — the stored prices and the display setting interact.

How do I connect Sage 50 or Sage 200 to WooCommerce?

There is no official Sage plugin for WooCommerce. Third-party connectors exist (Codeless Platforms, Patchworks) but require configuration and ongoing maintenance. A custom integration uses WooCommerce webhooks to push order data to an intermediary API layer that maps WooCommerce order fields to Sage invoice fields and creates records via the Sage 50cloud API or Sage 200 REST API. The integration needs to handle customer matching (create new Sage customer if the email does not exist, match to existing if it does), product code mapping, tax code mapping, and inventory decrement. Payment reconciliation between WooCommerce and Sage is a separate data flow that depends on whether Sage is being used for bank reconciliation.

What is the best hosting for a WooCommerce store in the UK?

For UK WooCommerce stores, managed WordPress hosting with a server location in London or Dublin reduces latency for UK visitors and improves Core Web Vitals scores that affect Google UK rankings. WP Engine (UK data centre available), Kinsta (London region), and Cloudways on AWS eu-west-2 (London) are the three most reliable options for stores processing between 100 and 5,000 orders per month. Shared hosting — including WP Engine's entry-level plans, GoDaddy managed WordPress, and SiteGround's shared plans — does not provide the isolated resources needed for WooCommerce to perform consistently under load. The performance difference between shared and managed hosting becomes measurable on Core Web Vitals reports at around 200 concurrent visitors.

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.