Two balances for one customer is not a rounding error. It is a trust failure. Cross-platform loyalty programs rarely break at earning points. They break at expiration and downgrades. If Square Loyalty expires points on one schedule and WooCommerce applies another, customers see inconsistent balances, support teams chase false discrepancies, and reconciliation becomes guesswork. The fix is to define expiry windows and tier thresholds once, then mirror those rules in both systems, including how in-flight points behave during a downgrade.

This tutorial examines why these mismatches happen and how to close them. You will learn how Square Loyalty handles point expiry and expiration-policy changes, why tier downgrades split balances across platforms, and what should happen to pending or in-flight points during a downgrade. We will define five rules to agree on, configure matching settings in Square and WooCommerce, and test alignment before customers notice. We will also cover the compliance gap around retroactive expiry and consumer protection, then conclude with a practical checklist for aligning the clock before adding new tiers.

Why Expiry and Downgrade Rules Quietly Break Cross-Platform Loyalty

Two clocks, two balances: a member checks their Square loyalty card view and sees 480 points. WooCommerce shows 620. Both systems are working as configured; the rules simply disagree.

Expiry creates the first split. If Square expires points on one schedule and your WooCommerce loyalty plugin applies a different window, identical activity produces two balances, the exact duration depends on how each is configured.

Downgrades widen it. A tier threshold measured on rolling 12 months in WooCommerce and a calendar year in Square can demote the same customer in one system and retain them in the other. If the threshold metric differs, spend versus points earned, the mismatch becomes permanent.

Trust erodes quietly. Points that vanish on one date but remain redeemable on another look like lost value. Support tickets tend to surface around renewal windows when members first notice a discrepancy, and members stop believing the balance they see. The same trust dynamics appear across markets, including Telstra Rewards Store Explained for Australian Merchants.

Setup guides rarely help. They document earning and redeeming, then treat expiration policy changes and downgrade timing as edge cases. This tutorial defines expiry windows and tier thresholds once, mirrors them, and decides what happens to in-flight points during a downgrade.

How Square Handles Point Expiry and Expiration Policy Changes

The mismatch starts on the Square side, because Square does not treat an expiration policy change as a purely going-forward rule.

According to a Square developer forum response dated July 2025, changing a loyalty program's expiration policy rewrites expiry on all existing points, not only on newly earned ones. The concrete example given: moving a Square loyalty program from a 6-month policy to "never" clears the expiration time on every point already issued to members. The reverse also applies. Switching from "never" to 6 months assigns a 6-month expiry to all existing points, including points earned long before the change.

Treat this as forum-reported behaviour, not published Square policy. The responding account acknowledged the specifics might not be explicitly detailed in official documentation, framing expiry under general loyalty program management.

Verify before quoting. Open Square's Loyalty API overview, the tier creation help article, and the program management page directly. The research extracts for those pages contained no body content, so nothing there currently confirms or contradicts the forum answer.

The practical implication matters more than the sourcing gap. Any change to a Square loyalty program policy is effectively a retroactive event: existing member balances can be rewritten the moment a setting is saved. Your WooCommerce side must be ready to mirror that change the same day, not at the next scheduled reconciliation. Syncing loyalty rewards across Square and WooCommerce is where that mirroring becomes an event-driven task rather than a manual cleanup.

Why Tier Downgrades Split Balances Across Two Systems

Tier downgrades split balances because each system evaluates tier independently.

A tier threshold is only meaningful when both platforms evaluate the same metric (spend, points earned, or visits), over the same period, on the same schedule. Let each platform evaluate the same member on a different schedule, one rolling, one calendar-year, and the same customer gets demoted in one system but retained in the other. That same rule drift compounds when you sell across wider channels, as covered in Online Retail Marketplaces: What Every WooCommerce Merchant Needs to Know.

Square's tier structure starts with a base tier; test its behaviour directly rather than inferring it from documentation.

A split evaluation typically surfaces as a "wrong balance" complaint rather than a visible configuration error, because the member sees only the number, not which system produced it.

Decide up front what a downgrade actually does: lower the earn rate, reset points, or change only the label. Programme administration attracts regulatory scrutiny (CFPB Circular 2024-07), so treat every demotion as a deliberate, documented event rather than a side effect of mismatched clocks.

What Happens to In-Flight Points During a Downgrade

Once a downgrade lands differently in each system, the next question is what happens to points already in motion. In-flight points are earned, posted, or pending but not yet redeemed at the moment the tier changes. No available source defines their fate, so verify with Square API documentation and a live sandbox downgrade before you claim a rule.

Test three candidates:

• Points keep the earn rate of the tier under which they were earned.
• Points convert to the new, lower rate at the downgrade moment.
• Points keep the old tier's expiry schedule.

Redemption gaps matter. If Square expires a point at 23:59 on the policy date while WooCommerce still shows it as redeemable, the member hits a phantom balance at checkout. That is a support ticket, not a rounding error.

Write the rule down before you need it: state whether pending points inherit the old tier's value, the new tier's value, or stay frozen until the next earning event. Store the downgrade moment in a dedicated field (check your platform's API documentation for the correct field name), so both platforms can be reconciled after the fact instead of argued about.

Define Once, Mirror Everywhere: Five Rules to Agree On

Once that field is written down, the rest of the alignment work reduces to five definitions. Record them in one spec document and treat it as the source of truth.

1. Expiry window. Choose one duration and one anchor: the earn date or the posting date. State it explicitly, and test any duration you choose rather than assuming documented defaults.
2. Tier threshold. Define the metric (spend, points earned, visits), the evaluation period (rolling 12 months or calendar year), and the boundary behaviour. Decide whether spend exactly at the threshold qualifies.
3. Downgrade timing. Pick a single evaluation date and time, then decide whether demotion is immediate, applied at period end, or deferred by a grace period.
4. Grace period. Set how long a downgraded member keeps the higher tier's benefits, then confirm both systems honour the same end timestamp to the minute. Legacy programs such as Woolworths Rewards points show how published terms shape member expectations.
5. Clock and timezone source. Nominate one authoritative clock, either the Square loyalty program timezone or the store's WooCommerce timezone, and check whether either platform stores UTC underneath.

None of these five rules are enforced by default in either platform; they are decisions you enforce. Publish them in member-facing terms so the configured rule and the stated rule match.

Step by Step: Configuring Matching Rules in Square and WooCommerce

With the five rules written down, translate them into configuration. Work through these steps in order.

Step 1: Audit Square. Square sellers have one loyalty program, managed in the Seller Dashboard and readable via GET /v2/loyalty/programs/{program_id} with LOYALTY_READ. Export expiration policy, tier thresholds, and evaluation schedule to a shared spec sheet. This is a single-program export, not a multi-program sweep.

Step 2: Audit WooCommerce. Read your loyalty or points plugin against the same five rules. Flag every field with no counterpart on the other side. Those gaps are where balances will diverge. How to Redeem ANZ Reward Points (And What It Teaches Merchants About Loyalty) illustrates how published terms and system behaviour must agree.

Step 3: Change Square first. Because a policy change can retroactively rewrite existing point expiry (see the expiry section above), edit Square before touching WooCommerce, then re-sync and compare balances.

Step 4: Add a sync layer. SquareSync for Woo syncs products, inventory, orders, customers, loyalty programs, and discounts between Square and WooCommerce in real time, keeping one balance authoritative instead of two.

Step 5: Re-run the comparison. Repeat after every policy change, not just at setup. A retroactive rewrite on one side can silently invalidate a configuration that previously matched.

Testing and Verifying Alignment Before Customers Notice

Configuration ends where verification begins. Build a test member with a known earn date and tier, then drive test data through the expiry boundary on both platforms. Snapshot balances at three moments: immediately after earning, one day before expiry, and one day after a tier downgrade.

Do not compare settings pages. Compare timestamps. Two configurations can read identically while the applied expiry or downgrade moment differs by hours. Read balances through the API rather than the dashboard where possible; Square's loyalty accounts can be enrolled, searched, and read individually, which gives a consistent snapshot.

Timezone drift is the most common seam. If the WooCommerce store sits in one timezone and the Square loyalty program in another, the same point can expire on different calendar days. Confirm which clock is authoritative and whether either side stores UTC underneath.

Log every discrepancy with the member ID, both balances, and the exact timestamp. Then re-test after each Square program policy change, WooCommerce plugin update, or checkout-level modification, since checkout changes can alter the earn timestamp that feeds expiry.

Trust the alignment only after three clean test cycles.

The Compliance Gap: Retroactive Expiry and Consumer Protection

Once your test member confirms alignment, the remaining risk is legal rather than technical. Square's position on retroactive expiry defers compliance responsibility to the merchant: the developer forum reply advises consulting legal experts familiar with consumer protection laws rather than citing any platform rule.

That distinction matters because a policy change can shorten the life of points members already earned. Reducing an accrued benefit is precisely the scenario consumer protection regulators scrutinise.

No statute, regulator, or jurisdiction is named in the available sources. Treat the forum-reported Square behaviour and this article as starting points only, and consult a qualified lawyer before altering an expiry policy.

Practical mitigation:

• Give members notice before the change takes effect.
• Honour a grace period, so previously earned points keep their original window.
• Keep an audit trail recording when each rule changed and who approved it.
• Keep member-facing terms and platform settings in sync, so the expiry and downgrade rules you configured match the ones you published.

Settings and published terms drift apart easily, particularly when several storefronts share one loyalty program. The WooCommerce multi store model guide covers keeping those configurations consistent across locations.

Conclusion: Align the Clock Before You Add Another Tier

The compliance caveat settles what you must publish. The engineering fix settles what you must build: one clock, one threshold, one documented rule set.

Write the five rules into a single spec document that both the WooCommerce and Square teams read: expiry window, tier threshold, downgrade timing, grace period, and clock source. That document is the contract: if a rule is not in it, it is not agreed.

Treat any Square expiration-policy change as potentially retroactive, re-test after every policy change or plugin update, and log the result.

Mirror the spec into WooCommerce through a synchronization layer, so customers see one balance rather than two and downgrades land on the same calendar day in both systems.