E-commerce site development: the right platform, secure payments, consistent data.

We wrote this guide for brand and business teams who want to build a new ecommerce website or move their current store to another platform. What we describe is based on the official documentation of WooCommerce, Shopify and ikas, Google’s ecommerce and crawling documentation, schema.org, EMVCo’s 3-D Secure page and the payment page security publications of the PCI Security Standards Council (PCI SSC). We verified product and feature names against the source as of September 2026; we didn’t include prices. Our own field observations are marked separately under the heading “Expert note”.

An ecommerce website has three layers: the choice of platform, the store experience from product page to checkout, and the product, stock and order data connected together with measurement. The product feed and campaigns that go to ads are the subject of our ecommerce marketing page; this guide focuses on the store itself.

What decisions does building an ecommerce website start with?

Before choosing a platform, the work starts with putting in writing what you’ll sell, how you’ll deliver it and which systems the store will talk to. The requirements list we fill in together in the first meetings has six headings:

• Product structure: the number of products and variants, options such as size and color, and whether there are bundles or personalized products.
• Sales channels: marketplaces, social channels, physical stores and wholesale alongside the web store.
• Payment and delivery: the payment provider or bank you’ll work with, methods such as card installments (taksit: splitting a card payment into monthly installments, a common option in Türkiye) and bank transfer, shipping carriers and the returns process.
• Integrations: ERP (enterprise resource planning) or accounting software, warehouse and stock systems, e-invoicing, CRM (customer relationship management) and the email tool.
• Language and market: whether you’ll sell in one language, and whether there’s cross-border selling and more than one currency.
• Management: who will update products, campaigns and content from the panel, and how often.

When a choice is made without this list, the gaps are filled later with plugins or custom code; the maintenance load grows with every addition.

An off-the-shelf platform or custom ecommerce software?

For most stores, the right start is an off-the-shelf platform; custom ecommerce software is chosen, with reasons, when there’s a business rule or integration the platform can’t handle. WooCommerce is an ecommerce plugin that runs on WordPress and is hosted on the server you choose; on hosted platforms such as Shopify and ikas (a Türkiye-based platform), the server and maintenance sit with the platform, while coverage on the payment side varies by platform. Shopify writes that its Level 1 PCI DSS (payment card data security standard) certification covers the store, the shopping cart and web hosting, and that this compliance extends to all stores by default.¹

Custom development takes shape around every requirement, but it moves all responsibility, from payment security to backups, onto the store. For a requirement that pushes the limits of an off-the-shelf platform, we first look for a solution through an app, a plugin or an API; ikas, for example, exposes store data through a GraphQL-based admin API.³ We make the “custom software is needed” call only after this check.

How do you compare ecommerce platforms on scale and total cost of ownership?

Platforms are compared against today’s order volume plus the product, order and integration load in the growth plan; cost is calculated with all its annual items. The first thing we look at for scale is the data model. Up to version 8.2, WooCommerce stored orders in WordPress’s general content tables (_posts and _postmeta); since 8.2, released in October 2023, High-Performance Order Storage (HPOS) is enabled by default on new installs.² HPOS keeps order data, including order addresses, in four separate tables with their own indexes; according to WooCommerce, this structure reduces read-write operations and congestion on the tables.²

Six items go into total cost of ownership: the platform subscription or hosting, theme and design, paid plugins and apps, payment provider fees, integration development, and annual maintenance (updates, security, backups). On a hosted platform, the server item is bundled into the subscription, but monthly costs grow as paid apps are added; with WooCommerce and custom development, maintenance work is ongoing and should be itemized separately in the proposal.

How should category and product pages be built?

Category and product pages should sit in a tree where shoppers and search engines alike can reach every product through plain links from the menu, categories and subcategories. Google recommends this chain, and also writes that if category pages don’t link to every product in a category, Googlebot may not be able to find all the products by crawling alone.⁴ Links should be built with the <a href> tag; navigation through JavaScript events attached to other HTML elements isn’t recommended.⁴

Google generally works out site structure from the links between pages, not from URL format; as a general rule, the more internal links a page has, the higher its relative importance is considered.⁴ That’s also why Google recommends linking to a best-selling product from the home page, blog posts or the newsletter.⁴

On the product page, everything the shopper asks before deciding sits on the first screen or just below it: variants, stock, price, shipping cost, delivery time and return terms. On category and product templates, mobile speed is often set by images and third-party scripts; we explain our measure-then-speed-up method on our website speed optimization page.

How do site search and filters affect crawling?

Filters make it easier for shoppers to narrow down and find products, but when every filter combination creates a new URL, they can turn into an endless crawl load for search engines. According to Google, faceted navigation is most often implemented with URL parameters and can create infinite URL spaces; crawlers crawl a large number of these URLs before realizing they’re useless, and new, useful URLs are discovered later.⁵ The site search box isn’t a route to product discovery either: Googlebot generally doesn’t submit queries to search boxes while crawling.⁴ We set up filter URLs with these rules:

1. Filters that don’t need indexing: blocked from crawling with robots.txt; Google says crawling filtered URLs is often unnecessary, and recommends allowing only product pages and an unfiltered listing page to be crawled.⁵ Filters can also be kept in the part of the URL after the # sign; Google generally doesn’t support that part for crawling and indexing.⁵
2. Filters you want indexed: the standard “&” is used as the parameter separator; if filters are in the path, their order always stays the same and the same filter doesn’t appear twice.⁵
3. Combinations with no results: a filter combination that returns no products isn’t redirected to a generic error page; it’s answered with a 404 status code at the same URL.⁵
4. Canonical and nofollow: Google writes that rel=”canonical” and rel=”nofollow” are generally less effective in the long term than the methods in the first item; we don’t rely on them alone.⁵

How do the checkout flow and the virtual POS work, from cart to order?

The checkout flow starts with the cart, continues with card authentication and ends with the order record; each step is built with as few fields as possible so it doesn’t surprise the shopper or put unnecessary obstacles in the way. EMVCo also writes that unnecessary friction added to the payment process often leads to abandoned purchases.⁶

In Türkiye, a store takes card payments through a virtual POS (sanal POS): the online card-acceptance account a bank or payment provider opens for the merchant, much like a merchant account with a payment gateway elsewhere. Installment options and the 3D Secure flow run through this account. The agreement is made in your company’s name, and we connect the account to the platform.

3D Secure is the protocol in which the bank that issued the card verifies the shopper’s identity in an online card payment; it carries transaction, payment method and device information between the store and the bank.⁶ The bank uses this data to assess risk; in many transactions, the shopper just presses the “Buy” button and the payment is approved.⁶ For a transaction seen as high risk, the bank may ask for extra authentication, such as a one-time password, a knowledge-based question or biometric authentication.⁶ The protocol works both in the browser and in mobile apps; EMVCo recommends considering version 2.2 or later for optimal functionality.⁶

Shopify describes the flow like this: the shopper is redirected to the card-issuing bank’s domain for authentication, then returns to the store’s domain to complete the payment.⁷ For a payment authenticated with 3D Secure, liability for fraudulent chargebacks shifts from the store to the card-issuing bank.⁷ This protection isn’t unlimited: Shopify writes that card issuers have policies that remove the liability shift when too many chargebacks occur.⁷ We confirm this limit with the payment provider during setup.

Shopify Payments uses 3D Secure only when the card-issuing bank asks for it to approve the transaction.⁷ The part we build is the store side of the flow: authentication opening without interruption on a phone, the order being recorded once and with the right status on return from the bank, and the cart being kept when authentication fails.

What does PCI DSS require for payment page security?

Even when card data is entered in the payment provider’s form embedded in your site, PCI DSS requires the store to secure that page: one of the eligibility criteria for using the SAQ A self-assessment questionnaire in v4.0.1 is that the store has confirmed its site isn’t susceptible to script attacks.⁹ PCI SSC writes that scripts running in the shopper’s browser have become a major target for attackers trying to steal card data, and that these attacks, known as “e-skimming”, have increased significantly.⁸ Requirements 6.4.3 and 11.6.1 of the standard aim to have scripts on the payment page authorized, their integrity checked and monitored for changes, and security-impacting HTTP headers managed too.⁸ According to PCI SSC, the new requirements of v4.0.1 took effect on 1 April 2025.⁹ How the payment form sits on the site sets the boundary of responsibility:

PCI SSC recommends confirming whether SAQ A is right for a store with the acquiring bank (acquirer) that holds the merchant agreement or with the relevant card brands;⁹ we get this confirmation together during setup.

Which systems do product, stock and order data talk to?

An ecommerce website should have a single source of truth for product, stock and order data; the store, ERP, Merchant Center and analytics should be fed from that source with the same IDs. Platform APIs are the foundation of this connection. In ikas’s developer documentation, the permissions defined for v1 of the admin API cover products and variants, orders across all sales channels, customers, stock locations and stock levels; ikas recommends v2 to new API users.³ On the WooCommerce side, HPOS makes it easier to apply read-write locks and prevent conflicts in concurrent operations (race conditions);² we pay attention to this difference in stores where the ERP reads and writes orders often.

Google’s Content API for Shopping shut down on 18 August 2026; from 1 September 2026, requests to this API began failing gradually, and the Merchant API replaced it.¹⁰ Stores that send products through a partner app, such as the Google & YouTube app on Shopify, don’t need to do anything; the provider handles the migration.¹⁰ Stores that send data with their own software need to move their integration to the Merchant API; this API can update a single product without sending all the required fields, and those who need more time can apply for extended access.¹⁰

How are measurement and structured data verified before launch?

Measurement and structured data are verified before launch by putting a real test order side by side with the store record. In GA4, the transaction ID (transaction_id) is required for purchase and refund events; for events that send a value, the currency is also set at the event level.¹¹ In the test order, the transaction ID, amount and product codes in GA4 must match the store record exactly; the full list of events is on our ecommerce marketing page.

The structured data on the product page is generated from the same source. On schema.org, the Product type is defined as any product or service offered for sale; it has properties such as offers, brand, SKU and GTIN.¹² A GTIN value must be a number of 8, 12, 13 or 14 digits with a valid GS1 check digit (or a GS1 Digital Link URL based on it); the SKU is the seller’s own stock code.¹² Size or color variants can be connected to a product group (ProductGroup) with the isVariantOf property.¹²

How do our ecommerce development services run up to launch and through the first 30 days?

The right order is this: the scope is put in writing, the platform is chosen against that scope, payments and integrations go live after testing, and the first 30 days are tracked with measurement.

1. Discovery: the requirements list, a URL inventory of the current site, and payment provider and integration decisions.
2. Platform and design: platform comparison, the sitemap and design of the store screens.
3. Development and integration: the theme, the payment and 3D Secure flow, the ERP and Merchant Center connection, GA4 events, structured data.
4. Testing and launch: three test orders, redirects, an end-to-end check on a phone.
5. The first 30 days: order and payment errors, crawl and 404 reports, and the gap between GA4 and order records are read weekly.

The domain, hosting or platform subscription, payment agreement, Merchant Center, Analytics and code repository are opened in your company’s name; the markention team runs the setup, integration and post-launch operation. We build the site so that product, campaign and content changes can be made from the panel without code.

How should you choose an ecommerce development company?

Proposals from companies that build online stores are often compared on design samples; yet how the store will run for years is decided by the reasoning behind the platform, payment security and data ownership. Ask about these points in the meeting:

1. Platform reasoning: on what basis was the ecommerce platform recommended, and does the company only ever build on one platform?
2. Exit route: if the store will run on the company’s own rented software, the format in which you can take product, customer and order data when you leave should be in writing.
3. Payment page: who inventories the scripts running on the payment step, and how changes to them are monitored.
4. Single source of truth: which system writes and which reads stock, price and orders, put in writing before integration starts.
5. Account ownership: the domain, platform subscription, virtual POS agreement, Merchant Center and Analytics opened in your company’s name.
6. Migration plan: if you have a current store, redirecting old URLs one by one and moving order and customer history across.

What determines ecommerce website pricing?

Ecommerce website pricing has two separate parts: the service fee for setup and operation, and provider fees that go to the platform, plugins and payment provider. We listed the provider items in the total cost of ownership section above; the service fee depends on these factors:

We clarify the scope together in the first meeting, then send a proposal with the items written out separately. The platform subscription, paid plugins and payment provider fees are paid directly to the provider from accounts opened in your company’s name; they’re separate from our service fee.

Ecommerce website pricing: starting prices and ranges

The lower end of each range is the starting price; excluding VAT. Scope is confirmed in a written proposal after the first meeting. As of October 2026.

If you’d like to draw up your store’s requirements list together, pick a meeting day that suits you below.