Taking money across a border looks like the same job as taking money at home, with a currency symbol changed. It is a different job with its own tolls, and the tolls are where stores lose profit they never see. My first overseas orders taught me that the displayed price and the money that lands in the bank are two different numbers, and the gap was wider than my margin on half the SKUs.
The fees hide in layers. Card networks and the acquiring side take their cut on cross-border transactions, which sits above the domestic rate. Then the currency conversion takes a slice, and the payout conversion takes another. A buyer in Europe paying in euros for goods priced in dollars can cost me 4% or more end to end when the numbers are stacked, against roughly 2% for the same buyer at home. Chargebacks cost extra attention too: a disputed overseas order means shipping evidence in three time zones, and the card network’s rules decide who eats it.
Local payment methods change the math and the completion rate. In the Netherlands buyers expect iDEAL, in Germany many prefer bank transfer style checkout, in China wallets dominate. Listing a familiar method at checkout does two things: it raises the share of orders that complete, and it usually converts cheaper than a foreign card. I add a market’s local method once orders from that market pass a few dozen a month, which is where the setup effort starts paying.
I price in the buyer’s currency and check the landing margin per market monthly. A store that converts prices once and forgets them will find its euro prices slowly becoming uncompetitive or unprofitable as rates move. Round numbers help too: a price of 29 euros reads better than 31.40, and buyers compare local prices against local shops rather than against my home currency.
On payouts, the choice is between the platform’s default conversion and a provider that holds balances in local currency and converts when I decide. When overseas volume is small, the default is fine and the simplicity is worth a point of margin. Past a certain monthly volume, that point is real money, and stores in that position tend to move to a dedicated stablecoin payment service built for exactly this flow. I reassess the arrangement every time the overseas share of revenue doubles, because the right answer at 5% of orders is the wrong one at 40%.
Refunds run the same gauntlet in reverse. Returning money in the buyer’s currency, at the rate of the day rather than the rate of the sale, quietly costs another point or two, and a refund is an order where margin is already gone. I keep a small per-market buffer for that and I count it as part of the cost of selling there. Cross-border selling is profitable when every layer of the toll is on a spreadsheet and watched monthly. Hidden in the platform defaults, it just eats.
Shipping is the last price a buyer sees and the one they remember. Get it wrong and it turns up in abandoned carts, complaint emails, and one-star reviews that mention postage by name. Get it right and buyers stop thinking about it, which is the goal. After a dozen stores, my shipping pricing has come down to three setups, and I pick between them by what the average order looks like.
Free shipping is a lie everyone agrees to. The cost moves into the product price, and on the right catalog nobody minds. I do the math before committing: if the average order is 60 dollars and postage averages 6 dollars, I raise prices around 8 to 10% and advertise free shipping. On a pet supplies store, that swap lifted average order value by about 4% and cut shipping-related support tickets to near zero. Buyers compare item prices far more carefully than they compare postage, and a single line that says “free shipping” does quiet work on the product page.
The version that never works is free shipping promised and then paid for out of margin. I have watched stores subsidize postage for a year and discover it during a cash-flow crunch. The price list has to carry the parcel, or the arrangement falls over later.
When the catalog is cheap or heavy, I set a free-shipping threshold instead. The number I use is roughly the current average order value plus 15%. At that height it is close enough to reach and far enough to stretch for. A basket at 42 dollars with free shipping at 50 gets extended more often than not, and I watched that single rule lift average order value 11% on a stationery store within a month. The threshold is a suggestion with a prize attached, and buyers like prizes far more than they like a shipping table.
The two catalogs where flat and free both fail are heavy goods and international orders. Parcels get priced on whichever is greater, actual weight or dimensional weight, so a lamp that weighs two kilos but ships in a one-meter box costs like a five-kilo parcel. I learned that on a lighting store where the postage bill came in 40% over the quotes in month one. After that I measure every box and keep a rate card with the real numbers before any product goes live.
Overseas, I price by zone and keep the count of zones small: home country, one or two neighbors, one catch-all. Three zones cover the map honestly. Ten zones create a table nobody reads and a support queue for people who guessed. Where a country costs more than my margin carries, I do not ship there and I say so on the shipping page. A short list kept honestly beats a wide one kept badly.
What I tell buyers about delivery
Flat rates come next, one per zone, printed on the product page. A buyer should never meet a shipping price for the first time at checkout. Surprise postage at the payment step is the single most reliable abandonment trigger I know, and it is also the easiest to fix: state the number where the buyer decides.
Delivery time is part of the price, so I publish it plainly. “Arrives in 3 to 5 working days” or “Ships next working day” on the product page, matching whatever the carrier actually does that season. Parcels that land inside the promised window generate thanks. Parcels that land outside it generate disputes, whatever the actual delay was. I would rather under-promise on a slow lane than lose a week of email over a promised two days.
Under the hood I keep it boring: two carriers with real contracts, packaging weighed on a scale rather than guessed, and every parcel’s actual cost recorded next to what the buyer paid. When those two numbers drift apart by more than a couple of percent for a month, the price list gets a rewrite. Shipping pricing is a living thing. It gets checked every quarter like stock levels.
I have rebuilt stores on four platforms and regretted two of the choices. The regret always cost time first and money second. A platform pick looks like a software decision and behaves like a staffing decision: what matters is who has to keep the thing running on a Tuesday night in November. So I pick platforms now with the maintenance crew in mind, and the crew is usually me.
Before anyone demos anything, I ask one question: how does this store need to grow? A forty-SKU shop with straightforward shipping has almost nothing in common with a two-thousand-SKU catalog with wholesale pricing tiers, per-customer discounts, and a sales rep who needs quotes. Most platform pain I have watched came from a small store buying machinery for a big one, or a complex store squeezing into a simple one. The catalog, the pricing model, and the number of people who touch the store weekly decide the answer. The logo on the platform does not.
My second question is who patches it. Every platform needs updates: security fixes, payment API changes, tax rule changes. Somebody has to run those updates and fix what breaks. If the honest answer is “a guy I hire when things break”, then the platform with the biggest community and the most available freelancers wins, regardless of features.
I learned that question from a shop that picked a platform on features and lost a month to it. It was a beautiful fit on paper: custom pricing rules, multi-warehouse stock, a product configurator. In practice nobody on the team could update it without a developer on call, so updates lagged, a payment plugin broke quietly, and orders from one card type failed for nine days before anyone noticed. The features were right and the staffing was wrong. The staffing is the part that repeats every week.
Shopify is the fastest road from nothing to a paid order. Basic runs about 39 dollars a month, card rates start near 2.9% plus 30 cents through Shopify Payments, and a third-party gateway adds a surcharge of around 2% on that plan. The store is hosted, patched, and backed up for me. The trade is control: checkout customization is fenced off below the Plus tier, and apps solve gaps at 10 to 50 dollars a month each, which stacks up faster than anyone budgets for. I have watched a Shopify store’s real monthly cost hit 300 dollars across apps while the plan itself stayed at 39.
WooCommerce is a free plugin on paid hosting. Real hosting for a store that matters runs 20 to 60 dollars a month, plus extensions for subscriptions, shipping rules, or anything beyond basics. I own the updates, the backups, and every conflict between plugins. It is cheap in cash and expensive in hours. When I have a developer in the loop anyway, or I want to touch every line of the store, it earns its keep.
Magento (the open-source edition) is a different animal. The license costs nothing and the implementation does not. Catalogs with complex pricing, B2B quoting, multi-store setups, or ERP hooks are where it earns its reputation. For a straightforward retail shop it is heavy machinery, and heavy machinery needs an operator. I spent years inside that ecosystem and I respect what it can do. I also know exactly what a Magento store costs in hosting and developer hours, and a 40-SKU shop should think hard before signing up for it.
BigCommerce sits between the poles. It does not add transaction fees on top of payment processor rates, and it bundles features like real-time shipping and gift cards that other platforms sell as apps. The app store is smaller, and the themes are a narrower field. For a mid-size catalog that wants fewer moving parts, it is a reasonable place to land.
Whatever the quotes say, I build the three-year number myself. Hosting or plan, plus apps and extensions I know I will need, plus a realistic allowance for developer hours, plus payment fees on an honest sales forecast. On a store doing 20,000 dollars a month, the three platforms above landed within 15% of each other on total cost, and the order of the list flipped depending on how many hours I priced my own time at. The monthly subscription was the smallest line in every version of the sheet. It is the line people compare anyway.
Every platform has a tax it collects later. Shopify’s tax is the app stack and the checkout fence. WooCommerce’s tax is the plugin conflict that appears after an update at the worst possible week. Magento’s tax is the developer invoice, monthly, forever, plus hosting that starts at a hundred dollars a month and climbs with traffic. BigCommerce’s tax is hitting a plan ceiling on revenue and getting moved up a tier whether or not the features are wanted. I pick the tax I would rather pay, because there is always one.
Moving between platforms later has its own price, and it is high. Product data survives a migration. URLs need mapping or you lose the pages buyers and other sites link to. Customer accounts move with care or they do not move. Order history often gets archived instead of migrated. I budget a full month of distracted work for any migration, which is exactly why the two-week prototype matters so much up front.
The two-week rule
My process is narrow on purpose. I shortlist two platforms at most. I build a real prototype on each: twenty products, a shipping rule, one payment method, a working refund. I time how long it takes to get from empty store to a test order placed by a friend. Then I check the maintenance surface: how updates arrive, how backups run, how fast a bad plugin or app can be disabled. Two weeks, both prototypes, one decision.
The loser of that exercise is never wasted time. It is the cheapest month I never lose. The platform that wins is the one that got me to a real paid order fastest and that I can picture myself patching in three years without swearing. That is the whole method, and it has held up on every rebuild since.
Every extra step between cart and paid order costs a slice of the order, and the slice compounds. I call it the checkout tax: the revenue that leaks out of a store purely because buying is annoying. Industry abandonment studies put roughly seven in ten carts unfinished, and every store I have audited leaves more money here than it spends on ads.
The usual offenders show up in the same order on almost every store. A forced account creation before payment. Shipping costs that appear only at the last step. Sixteen form fields where five would do. A coupon field sitting at the top of the summary, which sends a chunk of buyers off to hunt for codes, and some never come back. On one store I traced a full 8% of sessions leaving at the coupon field alone. Those buyers were ready to pay and went looking for a discount instead.
Phones add their own tax. A numeric keyboard that does not appear for a card field, an address box that fights autocomplete, a page that reloads and drops the form when the buyer switches apps to check an OTP. Half my traffic arrives on a phone and phones convert worse in checkout on every store I have logged. Every one of those fixes is unglamorous plumbing, and each one returns a fraction of a percent that never gives it back.
Guest checkout is the cheapest win I know. On a home goods store, switching it on took checkout completion from 58% to 71% in three weeks, with no other change and no drop in account signups. Flat shipping costs declared on the product page closed most of the rest of the shipping surprise. Address autocomplete cut average checkout time by about forty seconds on mobile. Adding Apple Pay and Google Pay turned phone checkout into a thumbprint for the buyers who use them, and they now carry a real share of orders on every store I run. Four changes, none of them clever, and the tax got roughly a third smaller.
One more habit earns its keep: I read the payment failure log monthly. Declined cards, expired cards, wallets that error out. On one store, a shipping rule was silently rejecting an entire country, and the log showed a week of doomed attempts before anyone noticed. A checkout that fails quietly collects the tax anyway, and the log is where the store confesses.
The pattern holds every time: friction removed today shows up in this week’s numbers. A clean checkout is the highest-return surface in the store, and it is also the one owners look at least.
A product page has one job: clear the reasons a buyer hesitates. I build mine from support tickets, because a ticket is a record of what the page failed to say. Before a new SKU goes live, I write down every question a buyer has ever asked about something like it, and then I answer all of them on the page.
On a kettle store I ran, the questions were always the same five: how much water it holds, how long a boil takes, whether the cord detaches, how loud it gets, and what happens when the kettle boils dry. So the page listed those five answers in that order, in plain type, above the fold. Support tickets for that SKU fell by about half after the rewrite, and the return rate settled down with them. The tickets were writing the copy for me. I just had to stop hiding the answers in a tab nobody tapped.
Concrete answers also survive scrutiny. “1.7 liters, boils in six minutes, 72 decibels” tells a buyer something. “Powerful and elegant” tells them nothing, and they know it. Numbers are what people screenshot and compare.
A good photo is a spec sheet with no reading. I shoot every product with three frames in mind: the thing alone on white for clarity, the thing in use for scale, and the awkward angle that shows a seam, a plug, a mounting point. Buyers zoom into exactly the parts they would pick up and turn over in a shop, and they forgive a plain photo far faster than a vague one. On the kettle store, adding one photo of the kettle beside a mug settled the capacity question for good.
Every product has a limitation, and the limitation is usually why it gets returned. I put mine in writing: a chair that does not fit a desk over 74cm, a jacket that runs small, a lamp bulb that ships separately. On one furniture store, adding a real dimensions diagram and a short “check this before ordering” note took returns from 6.1% to 3.4% in a quarter. Returns are the most expensive sentences on the site, and they cost a fraction of that to prevent.
The habit is simple. Every question I answer before checkout is one ticket I never staff and one parcel I never ship back. That is the whole trick.
I pick a store theme in one afternoon and then let it run the business for three years. That gap is why I stopped judging themes by their demo pages. A demo holds twelve products, flawless photos, and no shipping rules at all. My stores hold hundreds of SKUs and exactly three of them sell. Those are different jobs.
A theme is a stack of decisions someone made before you arrived. Where the price sits relative to the photo. How many taps separate the home page from a completed order. Whether the cart shows shipping before or after the coupon field. Whether the mobile layout keeps the add-to-cart button pinned while a buyer scrolls a long description. You inherit all of it. Buyers feel those choices even when they never name them.
Colors and fonts get the conversation time, and they are the cheapest part of the theme to change later. I can repaint a store in an afternoon. I cannot repaint its information architecture without surgery, so I spend my inspection time on structure: how categories nest, how filters behave, where the search box lives on a phone, what a buyer sees when a product is out of stock. Structure is what the theme author decided for me, and structure is what I have to live inside.
I count a theme as equipment, same as the card terminal in a physical shop. It either helps the sale or gets in the way. Three things decide which: how fast pages load on a phone, how much thinking a product page demands, and how short the road to payment runs. Everything else is trim.
The clearest example I have is a clothing store I rebuilt with a different theme and nothing else. Same photos, same prices, same products, same suppliers. Add-to-cart rate went from 2.1% to 2.9% over six weeks. The new theme did three things the old one refused to do: it kept the buy button visible on mobile, it put size and stock status above the fold, and it cut the home page from 3.4MB to 890KB. A few tenths of a percent sounds polite until you multiply it across a year of sessions. On that store it paid for the rebuild in under two months.
Performance gets handled like a hosting problem, and I have fixed it with layout choices instead. A theme that loads a slider library, three icon fonts, and a background video before the product photo is making a bet on the buyer’s patience. On hotel wifi that bet loses. My floor is largest contentful paint under 2.5 seconds on a mid-range Android. Past 4 seconds, mobile revenue dips on every store I have measured, and the dip is always bigger than the page-weight savings that caused it.
One store carried a home page video because it looked sharp in the demo. Cutting it halved the page weight. Session depth went up, and the store looked slightly less impressive in screenshots. I took that trade again twice since, and I will take it again.
Selling online has a long settled history, and the general shape of the job is old ground. The Wikipedia article on e-commerce is a fair map of it if you want the long version. What keeps changing is what buyers expect at the end of the checkout: which payment wallets, how fast a parcel should land, how much of the order runs on a phone. A theme picked in 2019 is now serving 2026 expectations, and the mismatch shows up in the numbers before it shows up in complaint emails.
My pre-install list is short and unglamorous. Load the demo on a phone with the connection throttled, and count taps from home page to paid order. Find a product with a long description and check that the buy button stays on screen while scrolling. Add twenty products to the cart and see whether shipping appears before the payment step. Read the changelog and check the last release date. A theme updated monthly is a theme someone is still making decisions for.
I also load a category page with a hundred products on it and sort it three ways. Sorting is where weak themes crack: broken pagination, filters that reset, images that reload from scratch. And I open the store on a laptop at 1280 pixels wide, the width of a cheap office machine, because that is where a lot of real buying happens and where themes designed for designer monitors fall apart.
Then I ask the seller the rude question: what happens to this theme in two years? If the answer involves a page builder I can drive myself, nested blocks I understand, and a changelog with real dates, good. If the answer is a portfolio of screenshots, I keep shopping. The theme is the shop floor. I want to know who maintains the floor.
