Lightspeed loyalty: how rewards get onto an R-Series register

If you run a supplement store on Lightspeed Retail R-Series and you have shopped for loyalty, you have probably been shown a tablet. Customer types their phone number into a second screen, associate reads the reward off it, associate keys a discount into Lightspeed by hand. That works. It is also 2014.

There's a better door, and R-Series has had it for years. It's worth understanding whichever vendor you pick, because it explains why some integrations feel like part of the register and others feel like a sticky note taped to it.

The one door in: a Custom Menu button

R-Series lets a merchant add their own buttons to the register. In Lightspeed, that's Settings → Custom Menus, a menu placed on Register: Sale Tab, with the action Open Web Page and a URL. That's the whole install. No app store approval, no APK, no third-party hardware. You add a button called “Rewards” and it points at the loyalty vendor's page.

The useful part is what Lightspeed does to that URL when the associate taps it. It doesn't just open your page — it appends the live context of the sale that is open right now:

• the sale — which ticket is open
• the shop — which of your locations this register belongs to
• the register — which terminal
• the employee — who is ringing
• the customer, usually — if one is attached to the sale
• a return URL, so the page can send the associate back to the ticket
• and a signature, plus the key id and expiry that go with it

Read that list again from an operator's point of view. Everything needed to do the job correctly is in it. The page knows which ticket to discount, so it can't discount the wrong one. It knows which store the sale is at, so a two-location business gets the visit attributed to the right shop. It knows which employee is ringing, which is how you audit a reward that looks suspicious. None of that is available to a tablet sitting beside the register.

The signature is the credential

Here's the part worth slowing down on, because it's the difference between a secure integration and an open door.

That URL is just a URL. It arrives over the public internet. If the receiving page trusted it as-is, then anyone who worked out the shape of it could type their own sale id, their own shop id, and their own customer id and ask for a reward. No login, no store, no purchase — a fabricated ticket, and a real points balance drained or a real discount minted. It's not an exotic attack. It's guessing a number.

That is why Lightspeed signs the URL, and it's why the receiving app must verify that signature. The signature is computed over the parameters, using a key Lightspeed holds privately and publishes the public half of. The app recomputes it against the published key. Matches, real. Doesn't match, or isn't there at all — refuse. Fail closed, every time, not “log a warning and carry on.”

Two practical follow-ons that a careful implementation handles:

• Expiry. A signed link is good for a short window. That's deliberate — a link screenshotted from a register shouldn't work tomorrow.
• Don't keep using the link. The right pattern is to verify the signature once, at open, and trade it for a short-lived session token scoped to that one sale — ours lasts about thirty minutes. After that trade, the original signed URL is spent. Even if the link leaks out of a browser history, it can't be replayed into a new redemption.

When you're evaluating any vendor's R-Series integration, that's the question: do you verify Lightspeed's signature on the button URL, and what happens if it's missing? “We verify it and refuse the request” is the answer you want. Anything vaguer means the sale id in that URL is being taken on faith.

If you'd like to see the register button, the signed hand-off, and a reward landing on a sale in one sitting, book a demo — it's a ten-minute walkthrough and you'll know exactly what you're buying.

Why the reward should use your own discounts

Now the reward has to actually reduce the total. There are two ways to do that, and only one of them leaves your books alone.

The good way: map each loyalty reward to a discount you already defined in Lightspeed. You have discounts set up — “Loyalty $5,” “Member 10%,” whatever you call them. The loyalty platform holds a small mapping table: reward “$5 off” → your discount, reward “10% member” → your other discount. Redemption applies your discount to the sale.

Why this matters more than it sounds: your Lightspeed reporting keeps working. Discount reports, margin by category, end-of-month reconciliation — all of it is built on the discounts you defined. If a loyalty vendor instead injects arbitrary negative amounts, those reductions land in your numbers as something your reports don't recognise, and every month your discount total and your loyalty redemption count tell different stories. Nobody notices for a quarter, then someone tries to work out why gross margin moved and spends a day on it.

There's a practical bonus too: because the discount is yours, you can rename it, re-rate it, or retire it in Lightspeed without asking your loyalty vendor for anything.

The fallback: a fixed-dollar reward that hasn't been mapped yet can be applied as a negative line on the sale. It works and the total is right, but it's a second-class path — it's the one that muddies reporting. Treat any unmapped reward as a setup task, not a permanent arrangement. Mapping takes a few minutes during onboarding: the platform reads your discount list out of Lightspeed and you pick one per reward.

And the honest third case: some reward shapes can't be pushed cleanly onto an R-Series sale. When that happens, the correct behaviour is for the register page to say “apply this one manually” and show the associate exactly what to key in. It must not report success on a reward that never landed. A false success is worse than a manual step, because the member's points are spent and the customer paid full price — and you'll find out from the customer, not the software.

The tablet-beside-the-register problem

Compare the button to the older approach — a dedicated tablet on the counter running the loyalty vendor's app. Three costs, all of them ongoing:

1. A second screen and a second cable. Counter space in a supplement store is already contested by a card reader, a scanner, and a stack of sample tubs. Every device is a thing to charge, mount, update, and replace.
2. Two systems that don't know about each other. The tablet shows a reward; Lightspeed knows nothing about it until a human retypes it. Anything a human retypes gets skipped in a rush, keyed wrong sometimes, and is untraceable when the numbers disagree.
3. A member record that only updates when someone remembers. This is the expensive one. If the tablet is the only capture point, then your member data is a record of the times your staff had a spare ten seconds. Saturdays vanish. New hires vanish. Then you go to text your lapsed customers and discover half your regulars never got logged.

The register button removes the retyping, because the page already holds the sale. Worth saying plainly though: a customer-facing screen is genuinely useful — as a self-serve check-in, where the customer taps their own number and their own SMS consent without occupying an associate. That's a different job from applying discounts, and it's the job a tablet is actually good at. The mistake isn't having a tablet; it's making the tablet the only bridge between the ticket and the member record.

Who is the member on this sale?

One last mechanic, because it decides whether the button feels fast or annoying. When the page opens, it should already know who the member is wherever possible:

• A customer attached to the sale. If the associate has already put a Lightspeed customer on the ticket, resolve the member from that. Zero typing.
• A recent self check-in at that store. If someone checked themselves in at the kiosk in the last few minutes at this shop, that's almost certainly who's standing there. This is exactly the behaviour the tablet-based vendors have — the difference is that here it's a fallback, not the only path.
• Then, and only then, ask for a phone number.

Getting that order right is the difference between a button your staff use on every sale and a button they use when they remember. And because the URL carries the shop, each visit is attributed to the right store — which is what makes per-store targeting possible later instead of texting everyone about one store's restock.

What we'll tell you straight

Our Lightspeed R-Series integration is available and included in the platform — the register button, the signature verification, the session trade, the discount mapping, and the lookup order above, with no per-register fee and no add-on line. It's also our newest POS integration, which is why we set it up with you rather than handing over a doc: we connect the account, map each reward to a discount you already defined, and run it on one register before it goes on the rest. We'd rather be in the room for your first busy Saturday than read about it afterwards.

Some honest guidance on whether you need any of this:

• One store, a few hundred regulars you know by name, no texting? You may not need a loyalty platform at all yet. A program you don't market to is a spreadsheet with extra steps.
• One store but you want lapsed-customer and reorder-cycle texts? Then you want the member list and the messaging more than you want the register button. Start with the loyalty engine and add the register integration when the counter friction starts to annoy you.
• Two or more stores on R-Series? This is where the button earns its keep, because per-shop attribution on every sale is what makes everything downstream correct.

Whatever you decide, the four questions to put to any Lightspeed loyalty vendor are: how do you get onto the register, do you verify Lightspeed's signature, do you use my own discounts, and what does the screen say when a reward can't be applied. The answers are short, and they tell you almost everything.

More on our side of it: the Lightspeed loyalty feature page, the full stack on the supplement retail solution page, and what else connects on integrations.