Migrating away from Square Online to a custom Solidus store

What Square Online is, and who should stay on it

Square Online is the website builder in the Square family. You design a storefront in the browser, Square hosts it, and the shop sits alongside the rest of Square: the card reader on your counter, the Square Dashboard where you run the business, and the one item library that feeds them all. For a small retailer who already takes payments on a Square reader and wants a tidy online presence without hiring anyone, that tight fit is the whole appeal. Your shop stock and your till stock are the same list, a customer can buy in the shop or on the site with no extra setup, and the money lands in the same Square account. It is a sensible, low effort choice, and if that describes you, leaving it would be a waste of money.

I build custom shops on Solidus, the open source Ruby on Rails ecommerce framework, so you know where I stand. That is exactly why I will start with the honest half. This article is not for the counter shop that is happy. It is for the business that has outgrown the builder: the one whose online side has become the main event, whose checkout will not do the one thing the business actually needs, and whose owner has started to resent that the shop, the payments and the till are all locked inside a single company. If you have reached that point, read on.

This is a platform specific piece. The deep, platform independent questions, how customer records, products, orders, saved cards and subscriptions actually move, belong to the data type guides in this series, and I link each one where it matters rather than repeat it. Start with the overview, what moves and what does not, and come back. Where Square sits against the field, I set out in the platform comparison for a UK shop.

The ecosystem is the point, and also the lock

Most hosted platforms couple you to one thing: a checkout, say, or a theme engine. Square couples you to an ecosystem, and understanding that is the key to understanding the move.

Three things sit together inside Square. The first is the item library, the catalogue. Square Online, Square Point of Sale and the Square Dashboard all read from and write to one shared item library, so an item you create through the Catalog API is immediately visible in the Dashboard and on Point of Sale across every location.¹ The second is payments. A Square Online store is set up automatically to take card payments through Square's own payment processor, with no separate gateway to configure.² The third is the money and the customer records that flow from both, held in the same Square account.

For a small shop that is a gift. For a shop that wants to leave, it means the move is never only a website move. You are deciding, at the same time, what to do about the till in the shop and what to do about the company that processes every card you take. That is why I treat a Square migration differently from a Shopify or a WooCommerce one: the website is the easy part, and the payments and the point of sale are the questions that carry the risk.

What you own, and what Square holds

The useful way to look at any hosted platform is to ask what you walk away with on the day you leave.

On Square you own your business data and you can get most of it out, which is to Square's credit. Your item library exports to a spreadsheet, and the Catalog, Customers and Orders APIs let a developer pull the full detail programmatically. What you do not own is the machinery: the builder and its theme, the hosted checkout, the payment processing, the subscriptions engine, and the point of sale software on your counter. Those are Square's, and they stay behind. None of that is a scandal. It is simply what a hosted ecosystem means, and the point of this article is to help you price it honestly before you decide.

On Square Online	What happens when you leave
Item library (catalogue)	Exports to Excel or CSV, and through the Catalog API, so it moves cleanly13
Customer records	Export through the Customers API, passwords never come with them4
Order history	Reads through the Orders API, across the website and the till5
Saved cards (cards on file)	Held by Square as tokens, moving them needs Square's cooperation6
Subscriptions	Run on Square's engine against cards on file, no clean export7
Checkout, theme, hosting, point of sale	Square's own, and they stay behind

The export and the API, honestly

The raw material of a migration comes out of Square without a fight, and that is the good news.

Your item library exports from the Square Dashboard as an Excel or CSV file, and the same template imports back, which makes the catalogue a mapping exercise rather than a rescue operation.³ Two details are worth knowing before you plan. Square strongly recommends the Excel format over CSV, because opening a CSV full of SKUs in a spreadsheet editor can quietly corrupt them.³ And when you export in order to move items to a different account, Square requires the Token column to be present but blank, because that token is the internal identifier tying each item to this Square account.³ That token is a small, honest sign of the coupling: your catalogue is portable, but it is stamped with Square's own identifiers, and the stamp has to be cleared on the way out.

For anything beyond a flat file, Square gives you a genuine API, and this is where a careful migration is done. The Catalog API manages items, variations, categories, modifiers, discounts, taxes, images and pricing rules, with up to 250 variations per item.¹ The Customers API manages customer profiles, name, email, phone, address, birthday and group membership.⁴ The Orders API records line items, price adjustments, fulfilments and the payments linked to each order, and it can retrieve orders that originated anywhere in the account, including those marked as coming from Square Point of Sale.⁵ That last point matters for a shop that sells both in person and online: your order history is one combined stream, and a developer can pull all of it.

The one operational thing to plan around is the rate limit. Square does not publish a fixed number of requests per second. Its guidance is that endpoints may enforce different limits, that going over returns a RATE_LIMITED error with an HTTP 429 status, and that you should retry with increasing delays and a randomised jitter so your retries do not bunch up.⁸ In practice that means the export is a paced, scripted job that backs off politely when Square asks it to, not a single afternoon, and it is one reason I rehearse the full import on a copy of your data before anyone commits to a date.

One hard ceiling, the same on every platform and worth stating plainly: passwords do not come across. The Customers API holds a profile's contact details but has no password field at all, so a customer brought into the new shop is simply asked to set a password on their first visit.⁴ That is correct and expected, not a failing, and the customer accounts and addresses guide explains how I turn that reset into a planned relaunch message rather than a cutover day surprise.

The traps that are particular to Square

Every platform has a handful of places where leaving is harder than the clean export suggests. On Square these are the ones to look at first, and three of them are about payments.

The checkout and the payment processing are Square's, not yours. A Square Online store is configured out of the box to process cards through Square itself, and Square turns on its own extras, Afterpay, Apple Pay, Google Pay, Cash App Pay and Square gift cards, from the same settings.² That is effortless while you are inside Square and a wall the day you want something Square does not offer: a delivery slot step, a trade customer's negotiated pricing, an invoicing rule your accountant insists on. On a shop you own, the checkout is your own application code and the payment provider is your choice.

Saved cards are cards on file held by Square. This is the single most important thing to settle before you move. When a customer saves a card on a Square store, that card is stored as a token by Square, linked to the customer profile, and Square uses network tokenisation so that even internally the real card number is replaced by a token from the card network.⁶ You never hold the card number, which is exactly as it should be, but it means the saved cards do not simply fall out in an export. Moving them to a new processor is the hardest single part of a Square migration and needs Square's cooperation. I treat it as the first question, not the last, and the payment tokens and saved cards guide walks through how to confirm what is possible for your shop, as does the wider warning in the hidden dangers of switching payment gateways.

Subscriptions run on Square against those cards on file. If you sell a monthly box or a membership, Square Subscriptions charges a card on file on a schedule, and the whole arrangement, the plan, the billing date, the customer and the stored card, lives inside Square.⁷ Square itself notes that bank accounts cannot be stored and charged this way, so the recurring money depends on the very card tokens that are hardest to move.⁷ Confirm the route out before you commit to anything, exactly as the subscriptions and recurring payments guide sets out. This is the single question that most often decides whether a Square move is simple or hard.

The catalogue is shared with the till, so a change is never only online. Because Square Online and Square Point of Sale read the same item library,¹ a shop that runs both has to decide what the point of sale does after the move. If you keep taking card payments on a Square reader in the shop, your in person catalogue and your online catalogue are now two systems to keep in step, and someone has to own that. If you move the counter onto the same system as the new online shop, that is a second project with its own hardware. Neither is wrong, but the decision belongs in discovery, not on cutover day.

The builder has a customisation and SEO ceiling, and the URLs are Square's. Square Online is a visual builder, which is its strength for a small shop and its ceiling for a growing one: the design, the page structure and the finer points of how the site is marked up for search are only as flexible as the builder allows. When you move, every product and category address on the old site has to redirect to its new home, or the traffic and rankings behind those pages drain away through a wall of 404 errors. Google's own guidance is to map every old URL to its new one, use permanent 301 redirects straight to the destination, and keep them in place for as long as possible.⁹ That redirect map is the least glamorous and most valuable deliverable of the whole project, and the products and catalogue data guide covers how it is built.

The honest move to a shop you own

A migration off Square Online onto a custom Solidus store is not a button. It is a project, and done properly it is a calm one, because Solidus is an ordinary Ruby on Rails application and a PostgreSQL database that you own outright, on servers you control, under a permissive open source licence, which you can hand to any Rails developer tomorrow.¹⁰

The sequence is the one I follow for every platform. In discovery we decide what actually moves, who on your side owns the data, and, for Square above all, what happens to the saved cards, the subscriptions and the till. I build the new shop and write the import scripts against a copy of your real Square export, running them again and again until the result is clean. We run the two shops in parallel for a few weeks with the catalogue frozen, rehearse the final import at least twice, and cut over on a quiet weekday morning with the old shop left untouched for thirty days as a fallback. Each data type follows its own guide: products, customers, orders, payment tokens and subscriptions.

For Square, three questions carry the whole risk, and I settle them first. Can your cards on file move to a new processor, or do you keep a Square connection alive for a while to let them age out? Can every live subscription move with its billing date and payment method intact? And what happens to the point of sale on your counter? If the answers are clean, the rest is careful data work. If they are not, we know the real cost before anyone signs, which is the entire point of asking first. For the money side of the decision over five years, build and hosting included, read the five year total cost of ownership, and for the deeper question of who holds your records and on what terms, who actually owns your business data. If you are weighing Square against the other lightweight builders before deciding to own, the Ecwid version of this guide covers the near neighbour.

A worked example

Let me make it concrete with an invented shop.

Fathom Coffee Roasters (fathomcoffee.example) is a Brighton roaster with a small shop on the seafront. The counter runs on a Square reader, and the website is Square Online, where it ships bags of beans across the country and runs a monthly coffee club of about 300 subscribers. It has been on Square for three years, on a paid plan, and it works well until it does not. The owner wrote to me after a good year with two complaints. First, the coffee club was now a real business, and the plan Fathom actually wanted, where a customer builds a rotating selection and pauses over the holidays, was not something the Square subscriptions engine could express. Second, the online side had overtaken the shop, and the owner had started to dislike that the website, every card payment and the till were all one company she could not change piece by piece.

The export was the easy part, exactly as it should be on Square. The item library came out as an Excel file, the Token column cleared for a fresh start, and the customer and order history came through the Customers and Orders APIs, the order stream combining shop and online sales into one history.¹³⁴⁵ The passwords stayed behind, as they always do, so the plan included a service message to every account holder before cutover and a short welcome page that set a new password on first visit.⁴

The three Square questions carried the risk, and we answered them before fixing a date. The coffee club cards were cards on file held by Square, so moving the live subscriptions meant working with Square on the card tokens rather than assuming a clean export. Where a subscriber's card could not move, the plan was a short, honest message asking them to re enter it on the new club page.⁶⁷ The new Solidus shop connected to Fathom's own chosen payment provider, so from launch the shop owned its payments outright. And the seafront counter stayed on Square for the first season, with the online catalogue now the master copy and a nightly sync keeping the till in step, until the owner was ready to move the point of sale too as a separate, unhurried project.

The rotating, pausable coffee club that Square could not express became ordinary Rails code in the new shop, tested like everything else. Fathom now owns its website, chooses its own payment provider, and runs its subscription on billing logic the business can see and change. That is an invented shop, not a client story, but every step in it is a step I would take.

When you should stay, and when to move

I will end where I began, because the honesty is the point.

Stay on Square Online if the shop is small, if the counter and the website being one tidy system is a benefit rather than a cage, and if Square's checkout and subscriptions do what your business needs. At that size Square runs the whole thing for a modest plan fee and a published card rate, 3.3% and 30p per online payment on the free plan, 2.9% and 30p on the paid plans,¹¹ and leaving would cost more than it saves. Square is a capable ecosystem and plenty of shops are right to stay inside it.

Move when the online side has become the business, when the checkout or the subscriptions logic has hit a wall Square cannot take down, and when you would rather own the shop, choose your own payment provider and keep the point of sale decision in your own hands than have all three locked together. If that is where you are, the move is a known quantity once the three payment questions are answered, and the result is yours.

If you want a second opinion on your own numbers, bring them to a free workshop, and the first two weeks of work are on me. We will go through what moves cleanly, what the cards on file and the subscriptions really allow, what you do with the till, and whether a move off Square actually pays for you. Sometimes the honest answer is to stay, and if it is, I will say so. My rates are on the pricing page.

Footnotes

1. Square Developer documentation, Catalog API overview (one shared item library across the Square Dashboard and Point of Sale, managing items, variations up to 250 per item, categories, modifiers, discounts, taxes, images and pricing rules), accessed 14 November 2026, https://developer.squareup.com/docs/catalog-api/what-it-does ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Square Support, Accept Payments on Square Online (the website is automatically set up with Square's payment processor, Afterpay enabled automatically, Apple Pay, Google Pay, Cash App Pay and Square Gift Cards configured in Dashboard), accessed 14 November 2026, https://squareup.com/help/us/en/article/7014-accept-payments ↩ ↩²

3. Square Support, Import and export your item library (export and import as Excel or CSV, Excel strongly recommended over CSV for SKUs, the Token column required but left blank to transfer items to a new account), accessed 14 November 2026, https://squareup.com/help/us/en/article/5153-import-items-online ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Square Developer documentation, Customers API overview (customer profiles hold name, email, phone, address, birthday and group membership, with no password field, cards are associated through the Cards API), accessed 14 November 2026, https://developer.squareup.com/docs/customers-api/what-it-does ↩ ↩² ↩³ ↩⁴ ↩⁵

5. Square Developer documentation, Orders API overview (orders record line items, price adjustments, fulfilments and linked payments, and the API can retrieve orders across channels including those from Square Point of Sale), accessed 14 November 2026, https://developer.squareup.com/docs/orders-api/what-it-does ↩ ↩² ↩³

6. Square Developer documentation, Cards API overview (a card on file is stored securely by Square and linked to a customer, network tokenisation replaces the primary account number, cards are stored in the seller account), accessed 14 November 2026, https://developer.squareup.com/docs/cards-api/overview ↩ ↩² ↩³

7. Square Developer documentation, Subscriptions API overview (recurring billing charges a card on file on a schedule, bank accounts cannot be stored and charged this way, and the plan, plan variation and subscription are tied to a customer profile), accessed 14 November 2026, https://developer.squareup.com/docs/subscriptions-api/overview ↩ ↩² ↩³ ↩⁴

8. Square Developer documentation, Handling errors (a RATE_LIMITED error returns HTTP 429 Too Many Requests, endpoints may enforce different rate limits, and the guidance is to retry with increasing delays and a randomised jitter), accessed 14 November 2026, https://developer.squareup.com/docs/build-basics/general-considerations/handling-errors ↩

9. Google Search Central, Site moves with URL changes (map every old URL to its new one, use permanent 301 redirects straight to the destination, keep them in place), accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩

10. Solidus, solidusio/solidus repository and licence on GitHub (open source Ruby on Rails ecommerce under the BSD 3 clause licence), accessed 14 November 2026, https://github.com/solidusio/solidus ↩

11. Square, Our fees (online or invoice card payments at 3.3% plus 30 cents on Square Free and 2.9% plus 30 cents on Square Plus and Square Premium), accessed 14 November 2026, https://squareup.com/us/en/payments/our-fees ↩