Clover loyalty program options: what the register can actually do

If you run a supplement store on Clover and you are shopping for loyalty, you are being sold outcomes: “increase repeat visits,” “reward your regulars.” Fine. But every practical difference between the options lives one layer down, in what the software is allowed to do to a ticket that is open on your counter right now. This post is that layer: what can run on the device, what can be written to an open order, and what triggers points. Everything else — apps, dashboards, texts — sits on top of those three.

What can actually run on Clover hardware

Clover devices are Android tablets in retail clothing. That matters, because it means a loyalty vendor has two genuinely different places to put the member-facing software:

• On the register itself, as an app installed from the Clover App Market. Your associate taps out of the sale screen, into the loyalty app, and back — same device, same ticket.
• Beside the register, on a separate tablet or iPad. This is how the older loyalty vendors did it, and it still works. But the second screen doesn't know what's on the ticket, so the discount has to be keyed into Clover by hand.

Neither is wrong. A self-serve tablet facing the customer has a real advantage — customers check themselves in, so your Saturday rush doesn't skip the question, and we build one for exactly that reason. But if the reward is a dollar amount off, the software that names the reward should be the software that applies it. Otherwise someone is keying a discount by hand every time, and manual discounts are where loyalty programs go to die.

A register-resident app can do four things in one pass:

1. Look a member up by phone number while the ticket is open, and show their points and available rewards.
2. Enroll a new customer on the spot — with an SMS consent checkbox that the customer actually taps, not a verbal “can I get your number.”
3. Apply a discount to the open order, so the total on the customer display drops before payment.
4. Add a free item to the ticket and zero exactly that one unit — more on the “exactly one” below, because it is a real bug class.

Touching the open ticket: discounts and free items

Two reward shapes cover almost everything an independent store offers, and they behave differently on Clover.

Dollar-off and percent-off rewards

These are the easy case. The app pushes a discount onto the open order and the total drops. The thing to check with a vendor is which order it lands on. If the app is running on the register, it knows the exact order id and there is no ambiguity. If the discount is being pushed from a kiosk or the back office instead, the platform has to guess — usually “the most recent open order at this merchant” — which is correct almost always and wrong exactly when two associates are ringing at once. Ask how that is resolved. Our answer: the register app posts the exact order id; the kiosk path falls back to the latest open order, and we say so rather than pretending it's the same thing.

Free-item rewards

This is where the bugs live, and worth being specific because we shipped the bug ourselves once. A “free shaker” reward has two possible states at redemption: the shaker is already on the ticket, or it isn't.

• Already on the ticket: the reward must discount that line, by that line's amount. Adding a second shaker and zeroing it leaves the customer paying for the first one.
• Not on the ticket: the app adds one unit of the item and zeroes that unit.

The failure mode is quantity. If the customer is buying two shakers and the reward zeroes the line rather than one unit of it, you gave away both. We hit exactly that on a Shopify free-shake reward in August 2026 and carried the same guard into the Clover path: one unit, never the line. Ask any vendor to ring up two of the free item and redeem — ninety seconds, and it tells you whether anyone has run this at a counter.

One more honest limit: the app finds the item by SKU, then item code, then name. If your Clover inventory has the reward item under none of those, the right behaviour is to tell the associate “hand it over manually” rather than report success on a reward that never landed. Silent success puts a discrepancy in your till that nobody can trace.

If you want to see a real lookup, a real discount, and a free-item redemption run against a ticket — including the two-of-the-same-item case — book a demo and we'll do it live rather than describe it.

Why points award — or silently never do

Points-per-dollar has to be triggered by something. The reliable trigger is not the lookup and not the discount — it's Clover telling the loyalty platform that a payment was taken. That happens over a webhook: one URL on the vendor's side, registered once in the Clover dashboard, with a list of event types subscribed to it.

Here is the operator-relevant part. If the webhook subscription does not include payment events, Clover sends nothing for payments, and no points ever award. The integration shows as connected. Lookup works. Redemption works. Every purchase earns zero. Nothing in the interface says “you forgot to subscribe to payments” — it just looks like a program nobody uses.

So the diagnostic, if points aren't showing up: don't start with the points rules. Start with the event subscription. Payments subscribed, or not. It's a thirty-second check that saves a week of arguing about earn rates.

Two smaller things in the same family worth asking about:

• Idempotency. Webhooks retry. If the same payment event arrives twice, does the member get double points? The answer should be no, because the platform keys each award to the order id.
• Authentication. On Clover, the verification code from the dashboard is the auth token the events carry. If the vendor isn't checking it, anyone who learns the URL can post fake payments into your points ledger.

The install-time permission trap

This is the single most useful thing on this page, and it is not on any vendor's marketing site — including, until now, ours.

Clover grants an app its permissions at install time, not at authorize time. When a merchant installs a loyalty app, the app receives a token scoped to whatever permissions the app declared at that moment. If the vendor later adds a permission — say they build free-item rewards and now need to read inventory — re-running the authorization flow does not widen your existing token. The new calls keep failing with a permission error, and the dashboard checkboxes will show the permission as granted anyway, which is how you lose an afternoon.

The only fix is for the merchant to uninstall and reinstall the app. And uninstalling expires every token the app held, so anything running against your merchant account stops until the reinstall completes.

In operator terms: if your vendor ships a capability needing a new permission, every store on their platform gets a “please uninstall and reinstall the loyalty app” support event. One store, mildly annoying. Forty stores, a week of someone's life. Which means:

• The permission set has to be right before launch, not iterated toward.
• It is a completely fair question to ask any Clover loyalty vendor: “What permissions does your app request, and have you added any since your last release?” A vendor who has thought about this will answer in one breath. A vendor who hasn't will tell you permissions are handled automatically.

For a loyalty app, the honest minimum is: Merchant read, Orders read and write, Payments read, Customers read and write — and Inventory read only if free-item rewards are added to the ticket automatically. Employees, ecommerce, and inventory write are not needed for loyalty. If a vendor asks for inventory write, ask why; selling an item already moves your stock, and nothing about a rewards program should be editing your catalogue.

Diagnose it by probing each endpoint with the stored token rather than trusting the dashboard. The checkboxes lie; the 401 doesn't.

Clover's own built-in loyalty — when it's enough

Say the honest thing first: if all you want is punch-card-style rewards for customers already in front of you, Clover's own loyalty tooling is right there, it's cheap, and it needs no third party. Genuinely consider it — no integration, no permission story, no webhook to forget.

What you give up is everything that happens away from the counter. The reason independent stores outgrow built-in loyalty is usually one of these:

• Nothing reaches the customer between visits. A points balance the customer can only see at the register can't bring anyone back. Lapsed-customer texts are the single highest-return thing a supplement store does with its member list, and they require a marketing platform sitting on that list — see how the SMS side works.
• The reward menu is thin. Dollar-off is one shape. Free items, tiers, and margin-aware rewards are how you keep a program from becoming a permanent discount on your best sellers — that's what a real rewards catalogue is for.
• The program isn't yours. Built-in loyalty is branded by the POS. A white-labeled program on your own subdomain with your logo is a marketing asset; a generic points screen is plumbing.
• More than one location, or more than one channel. One member record spanning two stores plus your Shopify site is a different product than a per-register punch card.

If none of those are problems for you yet, you might not need us for this. Come back when the second store opens or when you want to text 800 people about a restock.

Straight answers

Do I have to replace my Clover hardware? No. A loyalty app installs onto the Clover devices you already have. A customer-facing check-in kiosk is an iPad and a mount — not new payment hardware.

What happens to my existing customer list? Phone number is the identity key. A migration matches on it, and a member's name and email can be mirrored back into Clover's customer record so the POS and the loyalty platform stop disagreeing. Phone itself should never be quietly rewritten by a loyalty vendor — it's the key everything else hangs off.

Can the register enroll someone and text them later? Only if consent was explicit: an actual opt-in tick with a source and a timestamp, because that's the record carriers ask about during A2P registration. A verbal “what's your number” collects a phone number and no permission to market to it.

What if I'm on Lightspeed, Shopify, or something else? Different mechanism per POS, same shape of question. Our integrations page lists what connects and how, and the supplement retail solution page covers the whole stack rather than one register.

The five questions to ask any Clover loyalty vendor

1. Does your app run on the Clover device, or on a separate tablet? If separate, who keys in the discount?
2. When a reward is redeemed, which order does the discount land on — and how do you know?
3. Ring up two of a free-item reward and redeem it. Does one unit go free, or both?
4. What permissions does your app request, and have you added any since your last release?
5. Is your webhook subscribed to payment events? (If they hesitate, the points may not be awarding for anyone.)

None of those are gotchas. They're the five places a Clover loyalty integration is either real or decorative, and you can ask all five in a ten-minute call. Whoever you buy from, ask them.