Loyalty points that never post: the rewards program bug costing you repeat customers

A customer places her twelfth order. She expects to see enough points for a free product, like the app promised. Instead the balance shows what it showed three months ago. She doesn't email support. She doesn't file a complaint. She just quietly stops noticing the program exists, and on her next purchase she checks a competitor's price instead. That is the entire failure mode of a broken loyalty integration: no error message, no outage, just a slow leak of the exact behavior the program was supposed to create.

Why rewards bugs are invisible by design

Most loyalty and rewards apps, whether built for Shopify, WooCommerce, or BigCommerce, work by listening for order events and then writing points or store credit back to a customer record. That round trip involves at least three systems: the storefront checkout, the app's backend, and your platform's customer or metafield data. Any one of those can fail without throwing a visible error on your dashboard.

A webhook can be delayed or dropped entirely. An app update can silently change the event name it listens for. A plan downgrade can quietly cap the number of point-crediting transactions per month, after which new orders simply stop earning. None of these produce a 500 error. The order completes, the confirmation email sends, and the only victim is a number in a loyalty widget that nobody but the customer is watching.

This is the same category of problem covered in our look at duplicate orders from webhook retries: webhook-dependent features fail quietly because the parts that matter to the customer are downstream of a message that may never arrive.

The redemption side fails just as often as the earning side

Store owners tend to worry about points not being awarded. The redemption side breaks just as often, and arguably costs more, because it happens at the moment a customer has decided to buy. A shopper redeems points for a discount code, the code doesn't apply at checkout, and now you have an abandoned cart from your most loyal customer rather than a new one.

This overlaps with issues we've described in 7 gift card and store-credit bugs that quietly break checkout for your best customers: store credit logic is often bolted onto checkout through the same kind of third-party app integration that handles loyalty points, and it inherits the same fragility. A currency rounding error, a code that expires one day early, or a conflict with another discount rule can all block redemption without anyone flagging it as a bug.

The result is an ecommerce retention bug in the truest sense: the program designed to keep customers coming back becomes the reason they stop. A customer who tries to redeem points and fails once is unlikely to try twice.

Integration failure modes worth knowing

A handful of specific failure patterns show up repeatedly across loyalty app integration failures, regardless of platform:

Points not syncing after a theme or checkout update. Many loyalty apps inject a script or widget into the checkout or thank-you page. A theme update, a checkout extensibility migration, or a new checkout version can remove the injection point entirely, so the app stops seeing completed orders. Stores going through a Shopify checkout or theme upgrade should treat this as a standard regression check, the same way we recommend in Shopify theme updates: what breaks, what to test, and how to roll back.

API rate limits silently dropping events. High-volume days, like a flash sale, can generate more order events than the loyalty app's API plan allows per minute. Some apps queue and retry, others drop the excess silently. This is the same mechanism discussed in when your apps throttle you, applied to a program you'd never think to check during a sale.

Customer account mismatches. If a customer checks out as a guest once and logs in the next time, some loyalty apps fail to merge the two records, splitting points across two invisible accounts. This compounds over time and is almost never caught except by the customer, who sees a balance lower than expected and assumes the program is broken (which, in a sense, it is).

What to check, and how often

Loyalty bugs are hard to catch from an admin dashboard because the dashboard shows the app's own records, which can be wrong in exactly the same way the customer-facing balance is wrong. The more reliable check is behavioral: pick two or three real customer accounts each month, place a small test order, and confirm points post within the app's stated window. Then test a redemption end to end, including applying the resulting discount at checkout.

It's also worth tracking whether your loyalty app's webhook or API status has changed recently. App marketplaces rarely flag breaking changes loudly, and a minor version bump can rename an event type without warning. Treat your loyalty integration the same way you'd treat any other revenue-critical dependency: something to monitor continuously rather than check in on only when a customer complains.

This is part of why broader store monitoring matters beyond uptime. Cassian™ watches order flow, pricing, and stock continuously and rolls store health into a single Cassian Score™, so integration regressions like a stalled loyalty webhook show up as a pattern rather than staying invisible until a customer notices first.

Treat the loyalty program like infrastructure

A rewards program is a promise with a technical dependency attached, and like any dependency it needs occasional verification rather than blind trust. The fix isn't usually complicated: a quick test purchase, a redemption check, a glance at whether the app's API limits match your order volume. What's expensive is letting the gap sit unnoticed for months while repeat customers quietly recalibrate how much your incentives are actually worth.