Square and WooCommerce: the five sync problems every store hits

I’ve spent a good chunk of the last few years keeping Square and WooCommerce talking to each other. Partly for clients, and partly because I build and support SquareSync for Woo, which means I see the support inbox when it goes wrong. The same five problems turn up over and over. None of them are exotic. All of them are fixable.

1. Webhooks that never arrive

Square tells your store about changes by sending a webhook: a small message saying “this item changed” or “this order was paid”. If your site doesn’t receive it, nothing syncs, and nothing complains either. The usual causes are boring. A security plugin blocking the request because it doesn’t recognise Square’s servers. A caching layer answering the webhook URL with a cached page. A staging site that was cloned from production and is now receiving the live webhooks instead of the real store.

That last one cost a café client of mine most of a Saturday. Their staging copy was quietly eating every stock update while the live site sold pastries it didn’t have. The fix is to check the webhook subscription in the Square dashboard, confirm the URL points where you think it does, and exclude that URL from caching and firewall rules.

2. WP cron that doesn’t fire

WordPress doesn’t have a real scheduler. WP cron runs when someone visits the site. On a quiet store at 3am, nobody visits, so the scheduled sync job just sits there. Then a burst of traffic at 9am tries to run six hours of queued work at once, and the site slows to a crawl.

The fix is to disable WP cron’s visitor trigger and run it from a real server cron every minute or two. Most decent hosts let you set this up in their panel. If yours doesn’t, that tells you something about the host.

3. Variations that don’t map

Square thinks of a T-shirt in three sizes as one item with three variations. WooCommerce agrees in principle, but the details differ. Attribute names, option order, and whether “Large” and “L” are the same thing all matter. When they don’t line up, you get a variable product with one variation, or three simple products, or a variation that updates the wrong size’s stock.

Pick one system as the source of truth for product structure and set it up properly there. Then let the sync create the other side, rather than trying to match two catalogues that were built by different people on different days.

4. SKUs that aren’t really SKUs

Most sync tools match products by SKU. That only works if every product has one, and every SKU is unique. In practice I see blank SKUs, SKUs reused across sizes, and SKUs with a trailing space that makes them technically different. A homewares store I helped had 1,400 products and 212 of them shared a SKU with something else. The sync was doing exactly what it was told. It was just being told nonsense.

Before you sync anything, export both catalogues to a spreadsheet and check:

• Every product and variation has a SKU.
• No SKU appears twice.
• No SKU has leading or trailing spaces, or a mix of upper and lower case.

5. Stock that goes wrong in both directions

If you sell in a shop and online, stock moves in both directions. Two sales a few seconds apart, one at the counter and one on the website, can both read the same stock count, both subtract one, and both write back the same number. You’ve sold two and recorded one.

The fix is to sync stock as adjustments, not absolute numbers. “Subtract one” is safe to apply twice in a row. “Set to 4” is not. This is one of the main reasons I wrote SquareSync for Woo the way I did, and it’s the first thing I check on any setup someone else has built.

If your Square and WooCommerce setup is doing something odd, tell me what you’re seeing. Odds are it’s one of these five.