E-commerce Development for Canadian Retailers

The tax rate belongs to your customer, not to you

This is the single most common thing that is wrong with a store built for Canada by a team that has not built for Canada. Sales tax here is charged according to place-of-supply rules, which for most goods sold online means the destination province. A retailer in Alberta shipping to Ontario charges the Ontario rate. The same retailer shipping to Nova Scotia charges a different one, and shipping within Alberta charges GST alone. One store, one product, several correct answers depending on the delivery address.

The structure underneath is genuinely layered. There is a five percent federal GST. Several provinces have merged their provincial tax into a single harmonised HST at a combined rate that differs between them. Quebec runs QST, which is administered by Revenu Québec rather than the CRA and requires its own registration. British Columbia, Saskatchewan and Manitoba each levy their own separate provincial tax that sits alongside GST with its own rules about what is taxable. So the correct handling is not one lookup table but several regimes with different registration obligations, filing schedules and exemption lists.

What it means for the build is that tax is a service, not a field. The rate has to be resolved from the shipping address at cart time, displayed before the customer commits, recalculated when the address changes, applied correctly to shipping charges themselves where the province taxes them, and recorded per line so remittance and returns reconcile. Whether you are registered in a given province, and from what threshold, is a question for your accountant — but the store has to be built so the answer can be configured rather than hard-coded, because it changes as you grow.

Shipping across a country this size is a pricing decision

Canadian retailers underestimate domestic shipping more consistently than any other cost in the model. The population is concentrated in a narrow band, and the moment an order leaves it the economics change completely. A parcel to a Toronto or Vancouver address and the same parcel to a northern community are separated by a multiple, not a margin, and remote-area surcharges apply to a long list of postal codes that most rate calculators handle badly by default.

That leaves a real strategic choice which the store has to implement rather than assume. Flat-rate shipping is simple and predictable for customers and quietly loses money on the long-tail destinations. Live carrier rates are accurate and produce checkout numbers that make customers abandon. Free shipping over a threshold is the most effective conversion lever in Canadian retail and only works if the threshold is set from real order data rather than copied from an American store where the underlying distances are smaller.

We build the rate logic so it can be tuned rather than replaced: real carrier rates available at cart, the ability to zone the country and price zones differently, thresholds configurable by zone, and honest handling of remote surcharges instead of discovering them on the invoice. The dimensional weight question matters too — bulky, light products are priced on volume rather than mass, and a store selling those needs accurate package dimensions per product or every quote will be wrong.

A bilingual catalogue is a data model before it is a translation job

Where the Charter of the French Language applies to your store, it is not only the interface that needs French — it is the catalogue. Product names, descriptions, specifications, care instructions, size charts, category names, filter values, shipping and returns policies, and the transactional email that follows the order. On a store with a few dozen products this is a translation invoice. On a store with thousands of SKUs and a supplier feed updating daily, it is an architecture problem.

The failure mode is predictable. French is added as a duplicate set of product records, the two sets drift within weeks, a supplier feed updates the English descriptions and silently leaves the French ones describing last season's specification, and eventually the French store is quietly wrong about prices and availability. We build one product entity with translatable fields instead, so stock, price and status are shared and only language-bearing fields differ — that way a feed update cannot desynchronise the two storefronts because there is only one of them.

The related decisions follow from that. Which fields genuinely require translation and which are language-neutral, such as a model number or a dimension. How to handle a new product that arrives without French copy — publish in both languages or hold, and it should be hold. How search and filtering behave in French, including accent-insensitive matching, because a customer typing "etagere" without accents expects to find "étagère". And URL structure, so that the French product page is a proper indexable page in its own right rather than a query parameter on the English one.

Questions worth asking any vendor

These apply to us as much as to anyone else bidding for your work.

• Ask how tax is calculated and get a specific answer. If the reply is a single rate or a single field, the store will be wrong for most of the country from day one.
• Ask what happens to shipping cost on an order to a remote northern postal code. If the rate table does not distinguish it, the long-tail orders are losing money silently.
• Ask whether cross-border orders quote landed cost or disclose duties before payment. A store that does neither is generating refused deliveries it will blame on the courier.
• Ask whether French products are separate records or translatable fields on one record. Separate records are the reason French storefronts end up with stale prices.
• Ask whether Interac is part of the payment plan. Card-only checkouts convert worse here and the reason rarely shows up in analytics.