The thing that breaks an electronics catalogue on Shopify isn't the theme. It's that Shopify tracks how many you have, never which ones. Every fashion-first theme and most standard setups assume a size-medium tee is interchangeable with the next size-medium tee. A 65-inch panel with serial MX4471902 is not interchangeable with the one next to it, because one of them will come back in eleven months with a dead backlight and someone has to prove when it was sold. So a workable Shopify electronics store setup starts with three decisions made before a single product is imported: where serial numbers live, what date the warranty clock starts on, and whether your return window is one number or several.
Get those three wrong and you will spend the next two years reconciling WhatsApp screenshots against Shopify order IDs. We've cleaned that up more than once. It is not fun.
Shopify counts stock. It does not track units.
Inventory in Shopify is a quantity per variant per location. There is no unit record underneath it. The barcode field on a variant is one value for all units of that variant, meant for an EAN or UPC, and the single most common mistake we see is someone stuffing a serial number into it. That works until you receive the second unit.
You have three honest options.
- Don't track units at all. Fine for accessories, cables, chargers, anything under about ₹2,000 where a warranty claim is settled by replacing the item and moving on. Most catalogues have more of these SKUs than founders expect.
- Track units at the point of dispatch. The product stays a normal variant with a quantity. At the pack station, someone scans the serial off the box and it gets written against that order line. This is the right answer for 90% of new-goods electronics sellers.
- Make every unit its own product. Only for refurbished and pre-owned, where each device has a grade, a battery health percentage, cosmetic notes and its own photos. One unit, one SKU, quantity one. Painful to merchandise, and the only structure that tells the truth.
If you are selling refurbished phones and you try to run them as variants of a single "iPhone 13 128GB" product, the first customer who receives a Grade B when the listing photos showed a Grade A will tell you why it doesn't work.
Where serial numbers actually live
Metaobjects are the cleanest native home for this. Define a Device Unit metaobject with fields for serial or IMEI, a product reference, purchase order reference, an order reference, a warranty start date, a status (in stock, dispatched, returned, RMA open, written off) and a free-text condition note. When the packer scans a box, an app or a small internal tool creates or updates that entry and links it to the order.
Mirror the serials onto an order-level metafield as a JSON list keyed by line item, so customer support can see them on the order page without hunting. Support staff will not click through to a metaobject. They will click on the order.
Two constraints worth knowing before you commit. Metaobjects are storage, not a database with a query planner, so once you're carrying tens of thousands of unit records with staff searching them by serial all day, you want a real backend and Shopify holding only the display copy. And serials should not appear on the order confirmation email, because at that point nothing has been picked. Put them on the shipping confirmation instead, where they're also your best defence against a swap-return.
Building the scan-to-serial step is usually a small piece of custom app work rather than an off-the-shelf install, because it has to match how your warehouse already packs. A generic app that forces the packer to open a browser tab per unit gets abandoned inside a week.
Warranty starts on delivery, not at checkout
Every brand service centre in India works from the invoice date, and every customer works from the day the box arrived. Those are five to nine days apart for a Tier-3 delivery. On a twelve-month warranty that difference is noise, until a claim lands on day 368 and your policy says one thing while the courier's POD says another.
Store warranty duration as a product metafield in months, an integer. Store warranty type as a separate field: brand warranty, seller warranty, or none. Then compute the expiry from the fulfilment's delivery timestamp, not created_at on the order. Write the computed date back to the unit record so nobody has to recalculate it during a support call.
Two edge cases that catch people. Replacements under warranty inherit the original unit's clock, they don't restart it, so your RMA flow needs a parent-unit link. And extended warranty sold as a separate line item is a different product with a different duration that starts when the manufacturer's cover ends. If you sell those, model them properly on day one, because retro-fitting them across a year of orders is genuinely awful.
One return window across the store is the wrong shape
Shopify's return rules give you a store-wide window, with final-sale exclusions you can set by collection. That's enough for apparel. It isn't enough here, because electronics returns split into at least three cases that carry different costs:
- Dead on arrival. Usually 48 to 72 hours, replacement only, and it should be the easiest path in your entire support flow. Fighting a genuine DOA costs more in reviews than the unit is worth.
- Change of mind, seal intact. 7 or 10 days, full refund, and "seal intact" has to be defined in writing with a photo on the policy page. Otherwise every opened box is an argument.
- Change of mind, seal broken. Either refused, or accepted with a restocking deduction. Say which. Vagueness here is what generates chargebacks.
Put the applicable window on a product metafield and render it on the PDP near the buy button, not buried in a policy link. A phone case and a laptop can sit in the same cart with different windows, and the customer should see both before they pay. Then the same metafield drives your support macros, so an agent doesn't have to remember which category the SKU belongs to.
Also: accessory completeness. Charger, cable, manual, warranty card. Photograph every outbound high-value box at pack time. This costs nothing and settles disputes in one message.
The COD arithmetic most electronics sellers get backwards
Take 1,000 COD orders at an ₹8,500 average and an 18% RTO rate. That's 180 undelivered parcels. At ₹95 forward and ₹95 reverse, shipping on the failures is ₹34,200. Packaging at ₹40 a box adds ₹7,200. Say five of those come back with the seal broken and get moved at 20% off, a ₹1,700 hit each, another ₹8,500. Total leak: ₹49,900, against 820 delivered orders. That's about ₹61 per delivered order.
Now price the usual fix. A 3% prepaid discount on ₹8,500 is ₹255. Offer it to all 1,000 orders and you've given away ₹2,55,000 to stop a ₹49,900 problem. Even converting every single COD order to prepaid, you lose five times over.
So don't blanket-discount. Gate COD instead: cap it at a rupee threshold above which the order must be prepaid, block it for pincodes and phone numbers with a prior RTO, and add an OTP confirmation on high-value COD before it enters the dispatch queue. Save the discount for the segment that's genuinely price-sensitive on payment method. The threshold worth arguing about is where you set the COD cap, and the honest answer is that it depends on your category margin, not on what another store does.
Specs are structured data, not a paragraph
The place fashion themes fail hardest is filtering. Colour and size are two flat lists. Electronics buyers filter on panel size, refresh rate, wattage, socket type, chipset, RAM, battery capacity, warranty length, and above all compatibility: does this fit my model. None of that works if the specs are typed into the description field as a paragraph.
Build a metafield definition set per category, populate it at import, then render both the spec table and the collection filters from the same source. One place to correct a wrong figure. For a catalogue past a few hundred SKUs, native Shopify filters run out of room quickly, and FilterPro is what we reach for when a collection page needs spec-level facets and search that understands a model number typed three different ways.
Compatibility deserves its own model: a metaobject listing supported devices, referenced from the accessory. Guessing from the product title is how you end up shipping a case for the wrong variant.
GST, HSN and invoices that survive a warranty claim
Most consumer electronics sit at 18% GST, and the HSN code belongs on the product record, not in the accountant's spreadsheet. For phones, print the IMEI on the tax invoice, because that invoice is what the service centre asks for. If the customer's PDF doesn't carry it, your support team becomes the service centre's document-retrieval department.
Separately, check whether your categories need BIS registration and whether you're liable under e-waste EPR rules as an importer or brand owner. Neither is a Shopify configuration problem, but both become one when a marketplace or a payment partner asks for documentation and nobody can produce it.
The order we'd build it in
Metafield and metaobject definitions first, before any product import, because re-importing 2,000 SKUs to add a field is a day nobody enjoys. Then the unit record and the dispatch scan. Then return windows on the PDP and in the support macros. Then filters and spec tables. Theme polish last.
That sequence is unpopular because it means the store looks unfinished for two weeks longer. It also means you never have to reconcile a year of warranty claims by hand. If you're weighing what this costs against a plain catalogue build, our notes on Shopify development pricing in India break down where the hours actually go, and a store audit will tell you which of the three decisions above your current setup has already made for you by accident.