Your storefront on Nexpura
Your tenant subdomain — your-slug.nexpura.com — is the customer-facing catalogue, appointments, repair enquiry, and tracking surface. Lead-capture and informational, not checkout: sales flow through your connected Shopify or WooCommerce store. What ships, what doesn't, and how the parts fit together.
Quick reference
- Your storefront lives at your-slug.nexpura.com — the subdomain you picked at signup. The root URL renders the home page; sub-routes render catalogue, appointments, repair enquiry, contact, and the tracking entry.
- Customer-facing surfaces under the subdomain: / (home), /catalogue (browse inventory), /catalogue/[itemId] (item detail with enquiry form), /appointments (consultation booking), /repairs (repair enquiry form), /enquiry (general contact), /track (tenant-scoped tracking entry).
- Catalogue items render from inventory rows where is_published = true, status = active, and quantity is greater than zero. Filtering by category, metal type, or stone type uses the same structured fields you set on the inventory row.
- Submitted enquiries (from any of the three forms) land in the jeweller-side /enquiries inbox. The conversion flow — turning an enquiry into a customer plus a repair / quote / sale — is covered on the Receiving web enquiries page.
- The storefront is a lead-capture and catalogue surface, not a checkout. Sales flow through your connected Shopify or WooCommerce store, not through the subdomain. The honest disclosure below names what is and isn't built today.
What your customer walks through
1. Home page
The root URL of your subdomain (your-slug.nexpura.com/) renders either a template-driven home page (if you applied a Phase 1 website template through the website builder) or the legacy hardcoded layout (the fallback when no template is published).
Both versions show: your business name, your tagline if set, a hero image if uploaded, a featured-collection strip (up to eight published items pulled from inventory, ordered by recency), an About section if you filled in the about-text field, a Visit Us block with address / phone / email if those are set, and a footer with your social links if you configured them. The template-driven version composes the same content into configurable sections; the legacy version is the hardcoded template the early storefronts use.
Customers arrive at the home page from a Google search for your business, a direct URL share, a QR code on printed marketing, or a link from your main website if you have one. The nav strip at the top points them at Catalogue and Enquire — the two surfaces the home page funnels into.
Screenshot pending
Storefront home page on a tenant subdomain — top nav strip with business name and Catalogue / Enquire links, dark hero with the business name + tagline + 'Browse Catalogue' button, Featured Collection grid showing six product tiles, About section underneath, Visit Us contact block, footer with social links.
2. Catalogue
The customer browses your published inventory at /catalogue. The grid shows each item's primary image, name, metal type and stone type if recorded, and price (if your website config has show_prices = true). Items where is_published = false or the quantity is zero don't appear — your “not for the storefront” and “sold out” items stay off the public page.
Filter chips at the top of the catalogue narrow by category, metal type, and stone type. The filter options are sourced from the actual distinct values on your inventory rows, so a store that doesn't stock platinum doesn't see a Platinum filter chip surface. Filters compose — “Rings + Gold + Diamond” shows only items matching all three.
3. Item detail
Clicking an item in the catalogue lands the customer on /catalogue/[itemId] — a single-product page with the primary image (and any additional images you uploaded), the structured fields (metal, stone, ring, provenance), the price if your config allows showing it, and an item-enquiry form beneath the product details.
The enquiry form on the item page is pre-keyed with the item — when the customer submits, the inbound row in /enquiries references the specific item the customer was looking at. This is the lead-capture surface for “I'm interested in this piece” — see the Receiving web enquiries page for how the inbound is converted into a customer plus a downstream record.
4. Appointments
The customer books a consultation at /appointments — pick an appointment type (general consultation, ring-sizing, valuation, etc., configurable on your side), a preferred date and time, and submit. The submission lands in /enquiries as an enquiry-typed row, which you can convert into a booked appointment with the right customer attached.
The appointment surface is intentionally a lead form, not a live calendar booking. The customer requests a time; you confirm or counter-propose through the enquiry conversion flow. This keeps you in control of which appointments actually land on the calendar — the customer asks, you accept.
5. Repair enquiry
At /repairs the customer fills in a repair enquiry form — item description, the issue, photos if they have any, contact details. The submission lands in /enquiries flagged as a repair-typed enquiry; you convert it (Convert → Repair) and the system creates the customer row (if new) plus a repair record carrying the enquiry details across.
This is the entry point that pairs with the take-in counter for stores who want to capture repair leads before the customer physically arrives — the photos and description give the bench an early read on what the job involves before the piece is in hand.
6. General enquiry / contact
The catch-all contact form lives at /enquiry — the customer types a name, email, phone, and a message. The submission lands in /enquiries as a general-typed enquiry. From there you can convert into a customer plus optionally a quote or repair, or just reply directly without a downstream record.
7. Tracking entry on the subdomain
The subdomain also exposes a tracking entry at /track — a customer-friendly lookup page scoped to your shop's repairs and bespoke jobs. The customer types their tracking ID and lands on the per-order tracking detail. This is the same underlying tracking surface as the marketing-domain /track, presented as part of your storefront's nav so customers don't leave your subdomain mid-flow. See Repair tracking for the order-page details.
Honest disclosure
Checkout is not a built-in storefront feature. Sales flow through your connected Shopify or WooCommerce store; the storefront on your Nexpura subdomain is a catalogue and lead-capture surface. What you see today named explicitly:
What ships on the storefront subdomain
- Catalogue browsing. Published inventory renders on /catalogue with filters by category, metal, and stone — the customer-facing read on what you stock.
- Item detail + item-scoped enquiry. The single-product page exposes the structured fields and an enquiry form pre-keyed with the item.
- Appointment request form. A lead-capture form for consultation bookings — lands in your enquiries inbox for you to confirm.
- Repair enquiry form. A lead-capture form for pre-arrival repair tickets — lands in your enquiries inbox to convert into a repair record.
- General contact form. A catch-all contact entry — lands in your enquiries inbox.
- Customer-side tracking entry. /track scoped to your shop, hosting the same per-order detail as the marketing-domain equivalent.
- Branding controls. Primary colour, secondary colour, font, logo, hero image, business name, tagline, social links, contact details — all configurable from the website-builder settings.
- Template-driven home pages. Optional Phase 1 templates compose the home page from configurable sections instead of the legacy hardcoded layout.
What isn't built on the storefront
- No native cart. The storefront has no shopping-cart concept, no add-to-cart action, no persistent basket between sessions. The item-detail page exposes an enquiry form where a cart would sit on a typical e-commerce template.
- No native payment. The storefront does not collect payment from the customer. There is no Stripe checkout, no card form, no Apple Pay / Google Pay button, no PayPal integration on the subdomain itself.
- No native order confirmation. Because there is no checkout, there is no order confirmation page, no receipt email triggered by the storefront, no “your order is on the way” shipping notification originating from the subdomain. The customer's receipt comes from wherever the transaction actually happened — Shopify or WooCommerce on their respective domains.
- No native shipping calculation. Shipping rates, address validation, courier-rate integrations, tax-by-jurisdiction calculation — none of that lives on the storefront subdomain. All of it is a downstream-integration concern.
What this means in practice
A customer who lands on your subdomain and wants to buy a piece does one of two things, by design.
One: they submit the item-scoped enquiry form, you reply, you take them through a high-touch sale (often the right shape for the kind of jewellery that comes with a passport — these aren't impulse t-shirt purchases).
Two: if you have a connected Shopify or WooCommerce store and the piece is also listed there (or you want to give the customer a direct path to checkout), the integration handoff sends the customer over to your existing e-commerce stack. Your Shopify or WooCommerce remains the merchant of record; Nexpura remains your inventory, repairs, and clienteling system. The two-platform split is intentional — it keeps the payments side of your stack on infrastructure that's already vetted by your bank, your accountant, and your existing operational habits.
Talk to us if these are load-bearing for your store.
Common questions
Why isn't checkout built into the storefront?
Two design rationales threaded together. The first is “merchant of record” cleanliness: the platform you use to take payments is the one your bank, your accountant, and your tax authority already know about. Layering a second payments entity inside Nexpura would either fragment your reconciliation across two systems or force the same e-commerce surface to live in two places. Channeling checkout through your existing Shopify or WooCommerce keeps payments on one set of rails with one set of compliance. The second rationale is operational: the kind of jewellery Nexpura is built for tends to be high-touch — a passport-backed piece almost always involves a conversation, an appointment, a fitting, a custom-work consultation. The lead-capture enquiry shape on the storefront matches the way the sale usually happens, even when an e-commerce path also exists.
Do I have to use Shopify or WooCommerce?
No. If your business runs on in-person sales, appointments, and repair work — which describes a large fraction of bricks-and-mortar jewellers — you don't need an integrated e-commerce platform at all. The storefront subdomain still works as a marketing surface, a catalogue, and a lead-capture funnel without any e-commerce integration behind it. The integration is the path for stores that already sell online and want their two stacks to share an inventory source.
Can I show prices on the storefront if I'm not selling through it?
Yes — the storefront has a per-tenant show_prices toggle. With it on, prices from your inventory rows render on the catalogue grid and item detail; with it off, prices stay hidden (typical for higher-end appointment-only stores where pricing is intentionally a conversation, not a label). The toggle is independent of whether you have an e-commerce integration connected.
Why is /track reachable from both my subdomain and nexpura.com/track?
The tracking surface is the same underlying page; both URLs route to it. The subdomain version is there so a customer doesn't feel like they're leaving your shop to check on their piece — the URL stays on your-slug.nexpura.com, the chrome matches your brand. The nexpura.com/track version is the fallback for customers who arrived without a shop-scoped link (typed nexpura.com into their browser, clicked through to the tracking entry from Nexpura's marketing site). Same lookup, two entry doors.
What if my domain is something other than nexpura.com?
Custom-domain mappings — pointing your own purchased domain at the storefront — are configurable. Once the DNS is set up, your storefront resolves at both your-slug.nexpura.com and the custom domain you mapped; both URLs render the same shop. The DNS, certificate provisioning, and the specifics of the cutover are handled by your Nexpura administrator on the operations side.
How fresh is the catalogue the customer sees?
The storefront reads inventory rows directly at request time (no aggressive caching layer on the tenant side). When you publish a new item, mark one as unpublished, change a price, or sell the last unit, the catalogue reflects the change on the customer's next page load. The storefront is intentionally a live view of your published inventory — the absence of a cache avoids confusing a customer with a stale price or a sold-out item that still shows as buyable.
Troubleshooting
Customer says the catalogue is empty even though I have inventory
Symptom: a customer visits /catalogue and sees no items, but you have published inventory on the jeweller side. Cause: the storefront filters to is_published = true, status = active, and quantity greater than zero. An item missing any of those three falls off the public grid. Fix: open /inventory, filter to your published items, and check each row's status and quantity. Items with status other than active (draft, archived) and items at zero quantity are intentionally hidden; flip the right fields if you wanted them visible.
Storefront subdomain shows “not found”
Symptom: visiting your-slug.nexpura.com returns a 404 / sterile not-found page. Cause: usually one of: your website config is not published yet (the storefront only renders for tenants with the published flag set), your tenant was soft-deleted (the storefront hard-cuts on soft-deleted tenants by design — no metadata leak), or the subdomain you typed doesn't match the slug on your tenant. Fix: open /settings and confirm the website config is published. If the slug is wrong, the correct subdomain is shown on your settings page next to the published toggle. If the tenant is soft-deleted, recovery is an admin-side operation.
Customer submitted an enquiry and it didn't arrive in /enquiries
Symptom:a customer says they sent a form from the storefront; you don't see it in your inbox. Cause: usually the inbox filter — the default view on /enquiries shows the New status only. A previously-handled enquiry from the same customer may have already been marked Contacted or Booked, hiding it from the default view. Fix: open the inbox, change the status filter to All Statuses, and search by the customer's email or phone. If the row is genuinely missing, check the customer's browser console — the most common send-failure cause is a network error on their end, not a server-side issue.
Storefront colours look wrong / template hasn't applied
Symptom: you applied a website template or changed the primary colour, but the storefront still shows the old layout or palette. Cause:the template is saved but not published, or you're looking at a preview branch instead of the live one. The storefront renders the published template; an unpublished draft doesn't surface to public traffic. Fix: open the website builder, confirm the template is published (not just saved), and reload the storefront in an incognito window to bypass any local cache. Branding fields (primary colour, logo, business name) on the published-config record reflect on the next request without a redeploy.
Related
- Shopify integration — the e-commerce path that handles checkout
- WooCommerce integration — the other e-commerce option
- Receiving web enquiries — what happens to storefront form submissions
- Repair tracking — the per-order surface reachable from your subdomain's nav
- Inventory overview — the rows that drive what shows up on the storefront catalogue