Online store
A storefront that is fed by the same catalogue you already keep
Most store builders ask you to maintain a second product list — one for the shop floor and one for the internet, drifting apart a little more every week. Akkad's storefront reads the catalogue you already keep. Publish an item and it is on the site; change a price and the site has the new price; take the last one off the shelf and the site stops selling it. The building part is about how the store looks and behaves, not about re-typing what you sell.
Every organisation gets a subdomain of its own — a lowercase name you claim, checked live for availability and screened against a reserved list so the platform's own names can never be taken. That subdomain is the address of your store from the moment you publish it, and it keeps working after you attach a domain you bought yourself.
The storefront is one multi-tenant application rather than a copy per merchant. It works out which store to serve from the incoming host: a name under akkad.io resolves to a subdomain, anything else resolves to a custom domain, and a first path segment that is not a known route and contains no dot resolves to a sub-website. That single piece of routing is what lets one deployment serve a subdomain, a purchased domain and several storefronts under the same business without any of them knowing about the others.
One catalogue, many storefronts
A business is not always one shop. A wholesale front and a retail front, a seasonal microsite, a separate site per brand — these are different storefronts over the same stock, and Akkad treats them that way.
One main site, any number of others
Exactly one website is the main one and is served at the bare subdomain. Every other carries a slug of up to 50 characters and is served at your subdomain followed by that slug. Slugs are unique within the business and screened against the same reserved list. The main site cannot be deleted while it is the only one you have.
Each one configured independently
Template, style, colours, language, banners, announcement bar, checkout form, pixel IDs and feature toggles are all per site. Two storefronts on the same catalogue can look and behave nothing alike.
Per-category visibility, per site
Each site carries its own visibility flag and sort order for every category. A wholesale front can show the categories a retail front hides, and the ordering of the category rail is a per-site decision rather than a global one.
Publishing is yours alone
A new site starts unpublished. The publish switch belongs to the owner and is never touched by the system — not on a downgrade, not on an expiry, not on any automated process.
Orders know where they came from
Every order records both its source and which storefront produced it, so a business running four sites can tell them apart in reporting rather than seeing one undifferentiated pile of online orders.
The catalogue stays single
There is no second product list to maintain. Stock, prices, variants, pack sizes and images are the ones already in your catalogue, and a sale on the site moves the same number a sale at the counter moves.
Five templates, four presets, six controls
A template decides the shape of the store — how items are laid out, how categories are reached, what the header does. There are five, and they are genuinely different designs rather than colour variations of one layout.
Style is a second, separate axis. A preset changes the temperament of whichever template you chose: how categories are drawn, how hard the edges are, how much air sits between things. Underneath the presets are six individual controls, each of which you can override on its own when the preset is right about five things and wrong about the sixth.
- The template and the style preset are chosen independently — any of the five with any of the four.
- Presets are a starting point, not a lock: every one of the six controls remains individually settable.
- Colours, logo shape and language sit outside both axes and apply to whatever combination you land on.
Your own domain, with certificates handled
Attaching a domain you own is four states and one DNS record. There is no certificate to buy, upload, or remember to renew.
- 1
Enter the domain
It must begin with www. Addresses under akkad.io are rejected, and a domain can only ever be claimed by one business. The site stays reachable on its subdomain throughout, so nothing goes dark while you set this up.
- 2
Point a CNAME at stores.akkad.io
One record at your registrar. The backend resolves the CNAME itself to confirm it points where it should, which is why the state is called pending DNS — it is waiting on your registrar, not on us.
- 3
The certificate is issued on demand
Once DNS verifies, the domain moves to SSL pending and an immediate HTTPS warm-up request is made against it, which triggers issuance. The web tier asks the backend before issuing anything, and only domains already in SSL pending or active are allowed — so nobody can point a CNAME at us and have a certificate minted for a domain we have never heard of.
- 4
Active — or a state that tells you why not
A background job re-checks every SSL-pending domain every five minutes and finishes the job when propagation is slow. After a set number of attempts the domain moves to an error state rather than sitting in limbo, so a typo in a DNS record surfaces as a problem you can act on.
Cart and checkout
The part where a browse becomes money. Everything here is priced by the server, because the browser is a place a customer can edit.
Server-side repricing at order time
The cart shows a preview; the server recomputes the authoritative total when the order is created. Items, shipping rules, discount rules, promo code, tax and cash rounding are all recalculated from your live configuration. Amounts sent by the client are never trusted.
Variants and pack sizes in the cart
A line can carry a variant and a pack size — “Box of 12” prices per pack, with the quantity meaning the number of packs. The server refuses a pack that does not belong to the exact item and variant on the line.
A checkout form you build
The fields shown, which are required, their order and their labels are yours to set. A business that delivers by courier asks for different things than one that ships by post, and the form should say so.
The carrier's real address tree
When a courier integration is connected, the city and region pickers are populated from that carrier's own lists. The address a customer picks is an address the courier recognises, which is where most delivery failures actually start.
Saved information and phone validation
Returning customers get their details back. Where the business is set to Iraq, phone numbers are validated against the real local format rather than a generic length check.
Double submissions cost nothing
Every checkout carries a client-generated request identifier. A retried submit — lost response, impatient second tap — returns the original order rather than creating a second one or deducting stock twice.
Social proof you did not write
Reviews from people who actually received the item
A review section is only worth having if a shopper believes it. Akkad's reviews are written by verified purchasers only: to leave one, you must have a delivered order containing that specific item. Shipped is deliberately not enough — an order in transit is not yet an opinion about the product. One shopper gets one review per item, and the merchant's power over what is written is deliberately limited.
The merchant may hide and reply, but never delete
You can hide a review, unhide it, and reply to it once. You cannot delete it — only its author can. That asymmetry is the whole point: a review section a merchant can prune is a marketing section, not a review section.
Stars, text and up to three photos
One to five stars with optional body text and a maximum of three photos. The public list is paged ten at a time, newest first, with an average, a count and a full star distribution. When there are no reviews yet, nothing renders at all rather than an empty shell.
Emails never reach the public page
The merchant's own view of a review carries the shopper's email address so you can follow up. The public view never does. A shopper's own profile name takes precedence over the name their sign-in provider supplied.
The shopper always knows where they stand
Rather than a button that silently fails, the storefront asks the server whether this person can review this item and gets a specific answer: reviews are off, not signed in, already reviewed, not purchased, or go ahead.
Installed on a phone like an app
A returning customer should not have to find you through a browser tab. The storefront installs to a home screen, and everything the phone needs to do that is generated per tenant.
The native prompt where it exists
On Chromium browsers the install button fires the browser's own install dialog — one tap, no instructions to read.
A real guide on iOS
Safari has no install prompt, so instead of a button that does nothing, iOS shoppers get a short Share to Add to Home Screen walkthrough. iPadOS reporting itself as a Mac is detected too, which is a common way this check goes wrong.
Hidden once installed
The install option disappears when the store is already on the home screen. On by default, and present in both the footer and the drawer.
A manifest per tenant
Generated on request with the store's name, a twelve-character short name, standalone display, the brand colour as the theme colour, and the correct language and text direction. Cached for five minutes.
Icons generated on the fly
192 and 512 pixel icons in both standard and maskable forms, a 180-pixel Apple touch icon and a 64-pixel favicon, all produced from your logo. Maskable matters: without it, Android crops your logo into its own shape and usually cuts something off.
Full-bleed, and correctly cache-busted
The icon pipeline fills the frame rather than leaving a white border. Icon URLs carry a version marker derived from the logo itself, so changing your logo changes the icon instead of leaving the old one cached on every device that ever visited.
Questions
Do I have to maintain a separate product list for the store?
No. The storefront reads the catalogue you already keep. Publishing an item puts it on the site, and its price, stock, variants, pack sizes and images are the same records the rest of the system uses. There is nothing to sync and nothing to drift.
Can I use a domain I already own?
Yes. The domain must start with www, and you point a CNAME record at stores.akkad.io. Once that record resolves, the certificate is issued automatically and renewed without you doing anything. A background job re-checks pending domains every five minutes, so slow DNS propagation resolves itself.
What happens to my store if my subscription lapses?
Sites beyond what your plan covers return a temporary-unavailable page, oldest sites staying live first. Your published setting is never changed by the system, so re-subscribing restores exactly the site you had — the same template, colours, banners, category ordering and content.
Can I run more than one storefront on the same stock?
Yes, depending on your plan's site allowance. One site is the main one served at your bare subdomain; others are served under a slug. Each has its own template, style, language, banners, checkout form, pixels and per-category visibility, and orders record which site produced them.
Who can leave a review?
Only a signed-in shopper with a delivered order containing that item, once per item. You can hide a review or reply to it once, but you cannot delete it — only the author can. The public view never shows a reviewer's email address.
Does the store work if a shopper's connection is slow or JavaScript is blocked?
The pages are server-rendered, and the announcement bar's first message is rendered in full on the server specifically so it is readable and crawlable before any script runs. Animation and infinite scroll are enhancements layered on afterwards.
Related
Landing pages
One product, one page, one URL. Where to send ad traffic when a whole store is too much.
Growth and marketing
Pixels, server-side conversion events, catalogue sync and shopper accounts.
لەسەر کاتالۆگی خۆت تاقی بکەرەوە
بە پلانی گونجاو دەست پێبکە، کاڵاکانت لە فایلێکی ئێکسڵەوە بهێنە، و هەر لە هەمان ڕۆژدا فرۆشگا، کاشێر و دەفتەری داواکاریی کارات هەبێت.
پلانی بێبەرامبەر بەردەستە. بۆ تاقیکردنەوە پێویستی بە کارت نییە. هێنانی داتا لیستی کاڵای ئێستاکەت لەگەڵ خۆت دەهێنێت.