A square loyalty program can look healthy until a refund hits. Points are issued at the Square POS, then a return is processed in WooCommerce, and suddenly two ledgers tell different stories. One system credits. The other claws back. Or neither does, and the customer keeps points they should not have. This is loyalty drift, and refunds are almost always the cause.

The fix is not another sync plugin. It is a decision about the ledger of record. Plugins such as Loyalty Points and Rewards for Square can sync Square loyalty points between WooCommerce and Square, but they still require a separate Square-to-WooCommerce connector. Sync alone does not define who owns the balance or who reverses a refund.

This tutorial shows you how to reverse points once, in the right system. You will learn how Square Loyalty and WooCommerce each hold a balance, why refunds create drift, how the two refund paths differ, and what happens when both fire. You will also get a step-by-step reversal procedure, guidance on choosing the ledger of record, setup and reconciliation practices, and answers to common refund questions. The goal is simple: one refund, one reversal, no double credit or double clawback.

How Square Loyalty and WooCommerce Each Hold a Balance

A Square loyalty program tracks points against each customer profile, and customers earn or spend them against a Square loyalty card, digital or physical.

WooCommerce does not ship with a built-in points ledger; any balance a customer sees in their WooCommerce account is written there by a plugin, usually mirroring what Square already holds.

Points are created in three places: an in-store Square sale, an online WooCommerce order reaching the status your integration treats as paid, and a manual adjustment in the Square Dashboard.

The sync layer is two plugins, not one. A connector moves products, inventory, orders and customers; a separate loyalty plugin calls the Square Loyalty API to mirror reward rules and balances. Two systems therefore hold the same number. No connector we are aware of explicitly designates itself as the authoritative source for loyalty balances, that is a decision the merchant must make. Reward design compounds this: how reward points are redeemed through gift cards and cashback shows why one balance of record is easier to defend than two.

Why Refunds Are Where Loyalty Balances Drift

Points are credited when a sale completes. A refund arrives days later, often from a different system than the one that recorded the sale. That gap is structural.

Because the sync stack is layered (as covered above), each layer decides independently whether a refund is its concern. Two symmetric failures follow. A refund in Square may reverse points there while the WooCommerce order stays Completed, leaving a stale mirror. A refund in WooCommerce may reverse nothing at all.

Partial refunds, exchanges, returns funded by store credit or gift card, and refunds after a reward was redeemed all make "the refunded amount" ambiguous for points.

Do nothing and the reversal never happens. Silent drift sets in, and the customer spots the mismatch before you do. Learn how to sync loyalty rewards across Square and WooCommerce so refunds reverse once, not twice.

Two Refund Paths, Two Different Outcomes

A refund can be initiated in at least three places: the Square POS or Dashboard, the WooCommerce admin, or the payment gateway itself. Each fires a different set of events, and only some of those events reach the loyalty layer. Which ones arrive depends on your hooks, your order statuses, and whether your connector syncs refunds at all. That layering sits behind many of the sync problems Square and WooCommerce merchants face. The scenarios below are illustrative, not observed cases. Verify each behaviour against Square's current Loyalty API documentation and your own stack before you rely on it.

Worked Example A: The Refund Happens at the Square POS

A customer buys in store, earns 500 points against their Square loyalty card, and returns the item two days later at the counter.

Square adjusts those points as part of the refund, but the rule depends on program type and refund type. Full refunds remove all points; partial and custom refunds behave differently across amount spent, per visit, and per amount programs. Confirm your settings in the Square Dashboard rather than assuming, and check our loyalty setup troubleshooting guide if a deduction looks wrong.

In a typical stack, WooCommerce has no direct channel to receive a Square POS refund event, verify this against your own connector's documentation. If a loyalty plugin mirrors the Square balance into the WooCommerce account, that figure stays high until something forces a refresh. The customer may then spend points they no longer own, producing a failed redemption at the register while Square clamps the balance to zero.

The fix is directional: treat the POS refund as authoritative and push a correction into Woo, or make the Woo balance read-only so it cannot be spent.

Worked Example B: The Refund Happens in WooCommerce

Now reverse the direction: the sale starts online and the refund is issued in the WooCommerce admin. A customer orders, points are credited once the order reaches the status your integration treats as completed, then the merchant processes a refund. The order status moves to Refunded, but a plugin that hooks only certain order statuses may never fire a reversal. The money goes back; the points stay credited.

If your connector does sync the refund to Square, Square may reverse the points itself. Adding a manual clawback on top produces a double reversal, pushing the customer below a threshold they had already passed. If the connector does not sync refunds, the asymmetry flips: Woo drops the points, Square keeps them, and the customer loses points they legitimately earned before the refund.

The takeaway is procedural, not technical. Before anyone opens either admin screen, decide which system performs the reversal, and map your status settings in the WooCommerce → Square configuration so the refund path is explicit.

When Both Paths Fire: Double Credit and Double Clawback

The trouble starts when both paths fire at once.

Double credit: a refund lands in Square and WooCommerce and neither reverses, or a sync retry applies the adjustment more than once. The customer keeps points on goods they returned.

Double clawback: both systems reverse the same refund, leaving a negative balance or undoing a reward already redeemed in good faith.

Timing compounds it. Refunds often follow the sale by days, and events can arrive out of sequence or after a support ticket has closed.

Detect drift by logging every points adjustment with its source system, reason and timestamp. A customer complaint should never be the first signal. Real-time order and customer syncing, as covered in how to sync Square inventory with WooCommerce, reduces the events that go missing.

Write one rule down: exactly one system is allowed to write the reversal for a given refund. Naming that system is a decision, not a default.

Choosing the Ledger of Record for Square Loyalty Points

Pick one system to own the balance.

Three criteria decide it. First, where does the customer redeem? If rewards are spent at the counter, Square holds the balance that matters, because that is where a redemption can be refused.

Second, where do most earn events originate? A POS-heavy business and an online-heavy business will land on different answers, and that is fine as long as the answer is deliberate.

Third, enforcement. The ledger of record should be the system that can block a negative balance and stop the same points being spent twice.

For a Square loyalty program, nominate Square as the ledger of record. Treat WooCommerce as an earn channel and a display surface, not a second source of truth.

Ownership blurs at the connector–loyalty boundary, confirm which layer handles each event.

The Reversal Procedure, Step by Step

With Square nominated as the ledger of record, the reversal becomes a short, disciplined routine:

1. Confirm the refund is final. If an exchange or replacement order follows, resolve it first. Reversing points for a sale that is effectively still standing creates fresh drift.
2. Open the ledger of record first. Identify which system owns that specific order's balance before touching either admin screen. This habit prevents most double clawbacks.
3. Reverse once, with a matching reason code. Choose the adjustment reason that reflects the refund type, whether full, partial or a return, so the audit trail stays readable.
4. Verify the mirror. Confirm the other system's balance updated before closing the ticket. If it did not, correct the mirror manually and log why. Never re-run the refund.
5. Record the adjustment: order ID, customer, points, source system, operator and date.

Kept in this order, any staff member can follow the process without interpretation.

Make Refund Handling an Explicit Setup Step

Vendor documentation itself hints that merchants struggle to set up a Square loyalty program at all, and refund handling is easy to overlook during initial configuration. Make it a go-live checklist item: run one test refund in each channel, POS and WooCommerce, and watch both balances move. If one stays still, you have found the gap before a customer does.

Then name who may adjust points, and define the escalation path for a disputed balance so nobody improvises a correction under pressure. Ownership blurs at the connector–loyalty boundary, confirm which layer handles each event. When your stack spans several sales channels, the same blur applies to every online retail marketplace you sell on.

Finally, put the policy where staff will actually see it: a help desk macro, an SOP document, or a pinned admin note, not a PDF nobody opens.

A Reconciliation Cadence That Catches Drift Early

With the policy written and visible, drift still needs a detection rhythm.

Weekly, export customers holding a balance in both Square and WooCommerce and diff the two figures. A spreadsheet is enough at first. Just seeing the gaps listed side by side tells you whether the problem is growing.

Monthly, spot-check every refund from the period against the points adjustments recorded for it. Look both ways: refunds with no adjustment, and adjustments with no refund. Set a tolerance, for example ignoring differences under a handful of points, so the report stays readable and staff actually run it.

Watch for orphaned events specifically: retried webhooks, refunds processed after a reward was redeemed, and manual corrections that were never documented.

Fewer moving parts means fewer places for drift to hide. A connector that syncs customers and orders in real time, such as SquareSync for Woo, keeps the loyalty layer and the WooCommerce account closer together.

FAQ: Square Loyalty Refunds and Reversals

Reconciliation catches drift; these answers settle the refund questions that cause most of it.

What happens to Square loyalty points when I refund an order in WooCommerce? It depends on two things: whether your connector syncs refunds and whether your loyalty plugin hooks the refunded order status. Verify both in your own stack.

Can I reverse points in both Square and WooCommerce? No; that is the double clawback. Reverse once in the ledger of record, then correct the mirror only if it fails to update.

Why does my WooCommerce customer show a different Square loyalty balance? Usually a refund one system processed and the other never received, or a stale mirror that was never refreshed.

Do Square loyalty cards still hold points after a refund? If the refund is reversed in Square, the balance tied to that Square loyalty card reflects it. POS-heavy programs should nominate Square as the ledger.

Does a partial refund reverse all the points? Not automatically. Decide in advance whether partial refunds reverse proportionally, in full, or not at all, and encode that in your policy.

Which plugin should own the reversal? Whichever system you nominated as the ledger of record. Mirrors never write first.

Reverse Once, In the Right System

The sections above each addressed one piece of the system; this one names the actions to take.

Check your connector first. SquareSync for Woo syncs customers, orders and inventory in real time, giving refunds fewer places to disappear.

Conclusion

The ledger-of-record decision is the single most important choice in a Square loyalty setup: make it deliberately, document it, and let every mirror follow from it.

Your next step: choose your ledger of record today, write the reversal procedure, and run a test refund this week.