SmartLink
Web design & development

E-commerce development in Pakistan: cost, timelines and platform choice

E-commerce development in Pakistan is sold as a storefront and delivered as an integration problem. SmartLink Services builds stores from Karachi on Next.js, WooCommerce or Shopify, with stock and pricing read from the system that already owns them and orders passed on to whoever picks and ships. Below are the questions the pricing pages on this search result answer badly. What a store costs at published market rates, how long it takes to launch once product data and a payment gateway exist, and when a ready made platform beats a custom build. Settlement and reconciliation are treated as part of the build rather than as an operations problem discovered later.

Discuss this service
Integration
ERP \u00b7 inventory \u00b7 payment
Payments
Local gateways
Stock
Live from ERP
Overview

A storefront is an integration project with a shop front attached.

The visible part of an online store is the part that is easiest to get right. Product pages, a cart and a checkout are well understood problems with well understood patterns. What decides whether the store creates revenue or creates work is everything behind it: whether the stock figure is true, whether the price on the page matches the price that will be invoiced, whether an order arrives in the system that dispatches it, and whether the money reconciles at the end of the month.

So we treat the back office as the design constraint rather than an afterthought. Which system holds the authoritative stock figure, and how quickly does the storefront learn about a change. Where do prices, discounts and tax rules live. What happens to an order between payment and dispatch, and which states can it be in. Answering those before the catalogue is built prevents the most common outcome, which is a store that sells things the warehouse does not have.

The storefront work then has a clear brief: a catalogue structure that supports how you actually merchandise, a checkout with as little friction as the payment rules allow, and analytics that show where people stop. We build against the payment gateways and courier arrangements you already use, and we build the reconciliation reporting at the same time as the store, because a store nobody can reconcile becomes a monthly argument between finance and operations.

Scope

What E-commerce development covers

Everything below is agreed in writing before any web & digital work starts, so both sides know what is in and what is not.

What the work covers

  • Catalogue structure, variants and pricing rule setup
  • Checkout and cart flow optimisation
  • Local and international payment gateway integration
  • Live stock and price synchronisation with ERP
  • Order, delivery and returns workflow to fulfilment
  • Conversion analytics and abandoned-cart handling

What you get at handover

  • Live storefront with staging
  • ERP integration specification
  • Payment and reconciliation procedure
  • Conversion analytics dashboard
  • Admin training and manuals

Typically involves

WooCommerce Shopify Payment gateway APIs ERP APIs
Discuss this service
01

Stock that is wrong costs more than stock that is missing

Overselling is the failure customers remember. Someone buys the last unit, receives a confirmation, and then receives an apology two days later, which converts a sale into a refund and a complaint. It happens because the storefront holds a copy of a number that lives somewhere else, and the copy is refreshed on a schedule that made sense during development. A nightly synchronisation is fine for a slow moving catalogue and completely unsuitable for anything that sells in volume.

The design decisions are about ownership and latency. The ERP or warehouse system is normally the system of record, and the store either queries it at the decisive moment or holds a cache with a known age. Fast moving lines can carry a buffer so the last few units are not offered online. Stock can be reserved when a customer adds to cart or when they pay, and each choice has a consequence: reserve too early and abandoned carts hide inventory, reserve too late and you oversell.

Whatever is chosen has to fail sensibly. If the integration is down, the store should either stop taking orders for stock controlled lines or accept them into a queue that is clearly flagged, not silently sell against a stale number for six hours. Alerting on synchronisation failure belongs in the build rather than in an operational wish list, because the symptom of a broken stock feed is not an error page. It is a normal looking day with orders nobody can fulfil.

  • A named system of record for stock, price and product data, agreed before build
  • Synchronisation frequency chosen per line speed, with buffers on fast moving items
  • An explicit reservation policy at cart or at payment, with the consequence understood
  • Defined behaviour when the integration is unavailable, rather than selling on stale data
  • Alerting on failed synchronisation, because a broken stock feed looks like a normal day
02

Checkout is where the excuses run out

Checkout is short, heavily used and unforgiving. Every extra field is a place to stop, every unexplained validation error is a reason to leave, and every forced account creation is a decision imposed on someone who only wanted to buy something. Address entry deserves particular attention in markets where formats vary and postcodes are inconsistent, because a form designed around a strict address model will simply reject a proportion of genuine customers who then go elsewhere.

Payment introduces states that most first builds do not model. A card can be authorised and never captured. A redirect to a bank for additional authentication can succeed while the customer closes the tab before returning. A gateway can time out after taking the money. A webhook can arrive twice. An order therefore needs a state machine with explicit transitions and idempotent handling of gateway callbacks, so a duplicate notification cannot create a duplicate order or a duplicate dispatch instruction.

We also build the recovery paths, because that is where money is actually retained. Failed payments should tell the customer what to try rather than showing a generic error. Abandoned carts can be recovered where you have consent to contact the person. And guest checkout stays available: an account can be offered after the purchase, when the customer has a reason to want one, instead of being demanded before they have committed to anything.

  • Guest checkout available, with account creation offered after purchase rather than before
  • Address and contact fields tolerant of real world formats rather than one strict model
  • An explicit order state machine covering authorisation, capture, failure and cancellation
  • Idempotent handling of gateway callbacks so duplicate notifications cannot duplicate orders
  • Failed payment messaging that tells the customer what to do next
01

What e-commerce development costs in Pakistan

Published market rates for e-commerce in Pakistan run PKR 120,000 to 500,000 and upwards. The lower half of that band buys a catalogue on an existing platform: products loaded, a theme adapted, one payment method live and a delivery flow that works. The upper half and beyond covers what most businesses actually ask for once they think it through, which is a store connected to the systems already running the company. Where the requirement is genuinely custom, the applicable band is custom web application work at PKR 200,000 to 1,000,000 and upwards.

Hourly rates are worth asking for alongside the project number. Junior work is published at PKR 500 to 1,000 an hour and full stack development at PKR 3,500 to 8,000, and the difference between a theme installer and an engineer who has reconciled a gateway settlement is the difference between those two figures.

Catalogue shape drives the price more than product count does. Twelve thousand simple items is a data loading exercise. Four hundred items with size, colour, pack quantity, a trade price list and a customer specific discount is a pricing model, and pricing models are where store projects overrun. Stock synchronisation with an ERP is the next line, and it is priced with its failure handling rather than its happy path, because the expensive outcome is selling something you do not have. Payment gateways add merchant onboarding and a reconciliation report. Fulfilment adds a courier integration, a returns flow and the awkward cases: a partial delivery, a refused parcel, an exchange. Where FBR digital invoicing applies to your sales, published market pricing for adding e-invoicing to an existing system runs PKR 150,000 to 400,000, and whether your business is a notified person is a question for your tax adviser rather than for us. All of this is market pricing. A real figure follows discovery, once the catalogue, the integrations and the payment methods are agreed.

  • E-commerce pricing published at PKR 120,000 to 500,000 and upwards as the market anchor
  • Pricing rules, variants and trade price lists costed ahead of product count
  • Stock synchronisation quoted with its failure handling, not only its normal path
  • Courier, returns and partial delivery flows treated as scope rather than as detail
  • FBR e-invoicing at a published PKR 150,000 to 400,000 where it applies to your sales
02

How long an e-commerce build takes

Reported delivery timelines give six to twelve weeks for a focused single scope go live, which fits a catalogue on an existing platform with one payment method and a straightforward delivery flow. Three to six months is the honest band once live stock from an ERP, several payment methods, trade pricing or a migration from an existing store are involved.

Payment gateway approval is the dependency that catches people out, and it belongs on the plan in week one. Merchant onboarding needs documents, a bank relationship and a review that runs at the provider's pace rather than yours, and a store that cannot take money has not launched however finished it looks. Ask for the sandbox credentials on day one and test against them early.

Product data is the second and the larger delay in practice. Photographs at a consistent size and background, descriptions written by somebody who knows the product, weights and dimensions the courier will need, and a decision about what to do with the four hundred items that have never had a proper description. That work belongs to the business and it does not compress.

Migration from an existing store is the third variable and it carries its own calendar. Order history, customer accounts, addresses and the addresses of every product page that search engines already know about: each is a mapping exercise, and a store relaunched without redirects loses the traffic it inherited.

Then the reconciliation rehearsal. Before launch we run a settlement cycle end to end against a real gateway account, because the first time the money does not match should not be the first week of trading. Content, catalogue and gateway owners go on the plan next to the technical milestones, each with a date.

  • Six to twelve weeks reported for a catalogue on an existing platform with one payment method
  • Three to six months once ERP stock, trade pricing or a store migration are in scope
  • Merchant onboarding and sandbox credentials requested in the first week
  • Photography, descriptions, weights and dimensions owned by the business with a date
  • A settlement cycle rehearsed before launch rather than discovered in week one
03

A ready made platform or a custom build

Most businesses asking us for a store should be on a platform, and an agency that never says so is selling its own capacity. WooCommerce and Shopify have both solved the parts that are tedious and unglamorous: the cart, the tax rules, the order states, the emails, the discount codes, the admin screens somebody has to work in every day. Rebuilding those is spending money to arrive where the platform already stands, and it is a decision worth having to justify.

The platforms differ in ways that matter locally. A hosted product removes the server, the updates and the patching, and charges a monthly fee with a transaction component, so check which local payment methods are supported before committing rather than afterwards. Self hosted WooCommerce gives you every plugin and every plugin's security record, needs a properly sized server once the catalogue and the traffic grow, and puts the maintenance obligation on somebody who must be named. Neither choice is permanent, but migrating a live store with order history is a project rather than an afternoon.

Custom earns its cost in a narrower set of cases than enthusiasm suggests. Trade pricing where each customer sees their own contracted rate and the rules live in the ERP. A configurator where the product is assembled rather than picked. Ordering rules that a platform cannot express, such as a minimum order by branch or a credit limit checked live. A catalogue whose truth lives in a system the platform cannot reach without a layer being built anyway. In those situations the integration is the project and the storefront is what you can see of it.

There is a middle route that suits a good number of Pakistani businesses. Keep the platform for the catalogue, the checkout and the admin, then build the integration layer that carries stock, pricing and orders between it and the ERP. You get the platform's mature commerce behaviour and your own logic where the difference actually is. We have moved a store off a custom build for exactly that reason and said so in writing, because the maintenance was buying nothing the platform did not already provide.

  • A platform first, since cart, tax, order states and admin screens are solved problems
  • Local payment method support confirmed on a hosted platform before committing
  • Custom reserved for trade pricing, configurators, credit rules or unreachable catalogue data
  • A platform storefront with a custom integration layer offered as the middle route
  • Migration of an existing store with order history planned as a project in its own right
How we deliver

Delivering E-commerce development

Nothing is drawn until we know what the existing site has already earned. The six steps below start with an audit and end with a maintenance schedule, because that is where sites are actually lost.

  1. 01

    Discover

    Every existing URL is crawled and matched against analytics, so we know which pages earn traffic and which have never been read. Content owners are named in the same week, with dates attached.

  2. 02

    Blueprint

    Address structure, the content model and the authorisation rules for any signed in area come first. Wireframes follow, and the redirect map from old URLs to new is drafted before a template is designed.

  3. 03

    Build

    Components are built once and reused, to WCAG 2.1 AA, with content areas that an editor can change without a developer. Portal screens are wired to the source system, not to a copied database.

  4. 04

    Test

    Keyboard navigation, screen reader order, form labelling and contrast are checked against the standard, not assumed. Checkout is tested with a real payment provider in test mode, including a declined card.

  5. 05

    Go live

    Redirects go live with the site, and we watch server logs and search console for the ones we missed. Certificate, domain and analytics property are checked as a list, in your accounts.

  6. 06

    Run

    Framework and plugin updates go on a schedule, staged before production. Uptime monitoring requests a page that exercises the database, because a site can answer and still be broken where it counts.

Working together

When a custom store is not the right answer

Not every business needs a built store. If you sell a small number of lines, take a handful of orders a week and have no integration requirement, a hosted platform with a good theme will serve you better than anything we would build, and we will tell you that rather than quote for it. Custom work earns its cost when there is real complexity: stock that has to be accurate, pricing that varies by customer, an ERP that has to receive the order, or a checkout that local payment rules complicate.

Where that complexity exists, the integration is the project and the storefront is the visible tenth of it. We build both, deliver a staging environment, hand over the source and the integration specification, and put the reconciliation reporting in place at launch rather than after the first difficult month end.

Credentials

Accreditations behind Web & digital

A portal is only as good as the system behind it, so these credentials describe what our web work reads from and runs on.

Oracle

Partner

Portals and dealer dashboards read order status, invoices and statements from the Oracle databases behind your ERP, through read only views and an integration layer rather than a nightly copy.

Microsoft

Partner

Entra ID gives partner and dealer portals a sign in that a customer administrator can revoke. Azure hosts the site, and SQL Server frequently holds the catalogue behind an e-commerce build.

Google

Partner

Analytics and Search Console are configured before launch so a baseline exists to compare against, and Google Cloud hosts the site where a specific region or scale is required.

FBR digital invoicing

Compliant integrations

An online checkout that raises a sales tax invoice has to report it. The order confirmation carries the invoice reference number and QR code, and the customer can download the invoice afterwards.

HIPAA

Compliant practices

Patient portals and appointment booking need encryption in transit, session handling that logs a shared terminal out, restricted logging so health data stays out of it, and a business associate agreement.

Client words

What Web & digital clients say

Comments from people who run web & digital systems day to day.

  • They wrote our requirement documentation knowing it had to survive a tender committee, and they were direct when one of our requirements could only be met by a single supplier. We would not have caught that ourselves. The audit trail design has since been through a full review without a finding.
    IT Director Public sector authority
  • Our first concern with FBR integration was simple: what happens to the tills when the line drops. They built the queueing and retry before anything else and demonstrated it by pulling the connection in front of us. Trading carried on, and the invoices went up when the link came back.
    Operations Manager Retail chain, Pakistan
  • Every vendor we spoke to said they could handle style, colour and size. This team asked to see our order book first, then told us which of the shortlisted platforms would need thousands of item codes to do it. That one piece of advice probably saved us a year.
    General Manager Textile exporter
Questions

Questions about E-commerce development

Published market rates run PKR 120,000 to 500,000 and upwards. The lower half buys a catalogue on an existing platform with one payment method; the upper half covers integration with the systems that already hold your stock and pricing. Genuinely custom work is priced against the custom web application band of PKR 200,000 to 1,000,000 and upwards. We quote a scope after discovery.

Reported timelines give six to twelve weeks for a catalogue on an existing platform, and three to six months once live ERP stock, trade pricing or a migration are involved. Payment gateway approval and product data are the two things that move the date. Merchant onboarding runs at the provider pace, and photographs and descriptions belong to your team.

It depends on who maintains it and which payment methods you need. A hosted platform removes servers and patching for a monthly fee, so confirm local payment support before committing. WooCommerce gives more control along with the obligation to keep it patched on a properly sized server. Custom only earns its place where trade pricing or ordering rules cannot be expressed on a platform.

Yes, and how it behaves when the ERP is unavailable is the part worth specifying. We agree a refresh interval, a rule for what the store shows when a figure is stale, and a reservation approach so two customers cannot buy the last item. Selling something you do not have costs more than showing an item as unavailable for an hour.

It depends on whether your business falls within a notified category, and that determination belongs to your own tax adviser rather than to us. Where the requirement applies, the mechanics are the same as anywhere else: the invoice is posted to FBR, the invoice reference number and QR code that come back are stored, and both appear on the document. Published market pricing for adding this to an existing system runs PKR 150,000 to 400,000.

With a daily report nobody has to build by hand. What the gateway says settled, what the order records say was paid and what the ledger shows, compared automatically with the differences listed. Refunds, partial captures and failed authorisations all create mismatches, so the report is designed with those cases in it and is rehearsed against a real settlement cycle before launch.

More in Web & digital

More Web & digital services

Web design & development

UX & UI design

Research, journeys, wireframes and a high-fidelity interface design before a line of production code.

Open service page → Web design & development

Corporate website design & development

Marketing sites built for speed, search and editing by non-technical staff.

Open service page → Web design & development

Web portals & dashboards

Customer, dealer and partner portals over your enterprise data, with permissioned access.

Open service page → Web design & development

Design systems & brand application

One component library and token set so every screen and page looks like the same company.

Open service page → Web design & development

Website maintenance & support

Updates, backups, security patching, uptime monitoring and content changes on a retainer.

Open service page →

Selling online and fighting your own stock figures?

Tell us what you run today and where e-commerce development is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All web & digital