Square Online isn't overcharging you. It's deciding for you.

No, and this is the single most important thing to get right about Square Online. Unlike Shopify, which adds 0.5% to 2% per sale when you use an outside payment gateway, Square does not layer a platform fee on top of the processing rate. You pay Square's card rate and nothing else per transaction. As of mid-2026 that rate is 2.9% plus 30 cents for online orders on the free and Plus plans, dropping to 2.6% plus 30 cents on Premium; verify current rates before you budget, because processors reprice. That structure means the usual argument against hosted platforms — a percentage skimmed off the top — does not apply here. What Square does instead is remove the choice: Square Online sells exclusively through Square's own processing, so the rate you pay is the rate they publish. On a custom store, processing and the storefront are separate decisions, which is where the difference shows up at volume rather than on any individual sale.

Not as your checkout processor. Square Online is built to run on Square Payments, and the platform exists in large part to feed that processing business. You can add PayPal or Afterpay as an additional buyer-facing option on some plans, but you cannot replace Square as the underlying processor and you cannot route card volume to a different merchant account. That matters most once you are processing real money. A store doing $500,000 a year in card volume at 2.9% plus 30 cents pays roughly $16,000 in processing. The same volume on a negotiated interchange-plus agreement at an effective 2.4% is about $13,000. Square does offer custom pricing to higher-volume sellers, but you are negotiating with the only supplier you are allowed to use. A custom store connects to Stripe, Braintree, Authorize.net, a bank merchant account, or whichever processor quotes you best this year, and you can switch without touching the storefront.

For a lot of businesses, you shouldn't. The free plan is real: a working catalog, a working cart, Square checkout, and no monthly fee, with Square branding and a square.site address until you move to a paid plan. If you are selling a handful of products, testing whether there is demand, or running a shop that is a secondary channel to a physical location, that is the correct spend and a custom build is not. The case for custom is not that Square is expensive, because usually it isn't. It is that Square Online has a ceiling: a checkout you cannot restructure, URL paths you do not control, a processor you cannot leave, and a feature set that stops where the builder stops. The build is worth paying for when hitting that ceiling would cost you more than the build does — when organic search is a real acquisition channel, when your selling model needs a checkout Square will not build, or when the store is a long-term asset you intend to own.

Usually not, and any page telling you otherwise is doing the math wrong. Square Online Plus at $29 per month billed annually is about $1,740 over five years. Premium at $79 is about $4,740. Add a loyalty or marketing add-on at $45 per month and a loaded Square stack reaches roughly $7,440. A custom build at $2,800–$5,000 plus managed hosting at $60 to $180 per month lands between $6,400 and $15,800 over the same five years. Against bare Square Plus, custom costs several thousand dollars more across five years. It only reaches parity against a fully loaded Premium-plus-add-ons stack, and only on the $60 Core hosting tier. The honest framing is that you are not buying a cheaper store; you are buying processor freedom, checkout control, an uncapped feature set, and an asset you own. If cost per month is the deciding factor and the ceiling does not bother you, Square wins that comparison outright.

Square Online's checkout is Square's checkout. You can set which fields appear, whether tipping is offered, what pickup and delivery options exist, and how the confirmation reads, all within the options Square provides. What you cannot do is restructure the flow: no conditional steps that appear only for certain products, no cart-contents-driven upsell logic of your own design, no custom quote or approval step, no B2B purchase-order path, no field validation Square did not anticipate. For most retail and food ordering, the stock checkout is fine and arguing otherwise would be dishonest. It becomes a constraint when your selling model is unusual — made-to-order goods needing spec capture, rentals needing date ranges, wholesale needing tiered pricing by account, or services needing intake before payment. On a custom store the checkout is code, so the flow follows the sale rather than the sale bending to the flow.

Square Online sites are rendered by a visual site builder — the engine traces back to Weebly, which Square acquired in 2018 — and builder-rendered pages carry the weight that comes with that: a layout framework, an editor runtime, and generalized scripts that have to cover every possible section a merchant might drop onto a page. In practice a Square Online product page tends to become usable on mobile in roughly two and a half to four seconds depending on how many images and sections it carries. A hand-coded store sends finished HTML directly to the browser with no builder runtime in front of it, which typically puts the same page under a second. The gap matters most on mobile product pages, where each additional second measurably increases the share of visitors who leave before buying, and Google's page experience checks read the same numbers. If your traffic arrives from ads or your Square POS receipts, that gap is worth less to you than it is to a store competing in organic search.

Partially. Square Online lets you edit page titles and meta descriptions, generates a sitemap, and connects to Google Search Console, which covers the basics well enough to rank in low-to-moderate competition categories. What it does not give you is structural control. The builder decides the URL pattern for product and category pages and you work within it; you cannot design a hierarchy like /leather/wallets/bifold/ that groups your catalog the way people actually search for it. You do not control server-level headers, and the structured data Google reads is whatever the platform emits rather than markup you author per product. On a custom store the URL architecture is a design decision, product schema is written into the template with price and availability and review data, and canonical and redirect handling is yours. In a competitive category that difference is measurable; in a category where you are one of three local sellers, it usually is not.

Significantly, yes, and this is the strongest case for staying. If you run a Square register in a physical location, Square Online shares one item library with it: sell the last unit at the counter and the online listing updates without an integration, without a sync job, and without a nightly reconciliation. Orders, customers, and payouts all land in one dashboard and one deposit. Rebuilding that on a custom store means integrating against Square's APIs — which is possible and which we do — but it converts something free and automatic into something built and maintained. For a shop where in-person is the majority of revenue and online is the overflow channel, that trade rarely pays. Where it starts to pay is when online becomes the primary channel and the storefront needs to do things the builder will not do, at which point a custom store with a Square inventory integration keeps the sync and removes the ceiling.

You can export your item library, customer list, and order and transaction history as spreadsheets, and if you bought your domain elsewhere you keep it. What you cannot take is the store: the pages, the layout, the checkout configuration, and the site itself live inside Square's platform and do not exist as portable files. Leaving means rebuilding somewhere else and pointing the domain at the new build. That is not unique to Square — it is true of every hosted builder — but it is worth naming before it becomes urgent, because the migration cost is what makes any future price or policy change something you absorb rather than negotiate. A custom store is the inverse: PHP source files, a database, and images on a server you control, delivered to you at launch. Moving hosts or changing developers is a file transfer, not a rebuild.

Custom e-commerce builds are quoted per project because catalog size, checkout complexity, and integrations vary too much for a flat price to mean anything. Most standard stores — a defined catalog, card checkout, customer accounts, discount codes, and an order admin — land in the $2,800–$5,000 range. After launch the only recurring cost is hosting: managed hosting starts at $60 per month for SSL, nightly backups, uptime monitoring, and server-level patching, with content edits and application-level patching at the $100 tier and same-day critical response plus a test environment at $180. There is no long-term contract; cancel with 30 days' written notice and no cancellation fee, and take the source files. Against Square Online Plus at roughly $1,740 over five years, a custom build on Core hosting at about $6,400 costs more money. What the extra buys is the processor of your choice, a checkout built for your sale, a URL structure you designed, and a store that is an asset on your books rather than a subscription on your card.