POS integration links the checkout system to the software around it, from accounting to stock to payments. For a loyalty team, the link that matters runs between the till and the loyalty platform. That link decides whether a member earns and redeems in the same sale. It also decides what the till does when the store loses its connection.
What does a loyalty POS integration do at checkout?
It runs the program inside the sale. Toast's loyalty spec defines six request types. One creates new accounts. The other five run the sale itself. Other POS systems name them differently, but a till that runs loyalty needs each job.
- Identify (search). The cashier scans a card or an app code, or keys in a phone number. The till finds the account.
- Inquire. The platform returns the rewards this member can use on this basket, and checks any already applied.
- Redeem. The chosen reward comes off the bill while the guest pays.
- Accrue. After payment, the till sends the basket and the platform posts the points.
- Reverse. A void or a return undoes an earlier redeem or accrue.
Give each of the five a named owner and a time limit. Each one also needs its own test case.
How should the till connect to the loyalty platform?
Direct API. The POS calls the loyalty API at each step. It gives the most control, and the POS team owns the code. Square shows the shape. Its Loyalty API has one call that works out the points a basket earns, so the till can show them as the order is built. A second call adds the points once the order is done.
Plug-in. The POS vendor publishes a loyalty spec, and the loyalty provider builds to it. On Toast, the POS app sends each check to the loyalty program, and the loyalty program decides the rewards. It needs the least custom code where it exists. The checkout flow belongs to the vendor, though, so you work inside it.
Middleware. A layer sits between many POS brands and one loyalty platform, and turns each format into one. It suits grocers and franchise groups that run several POS brands after mergers. It adds a hop to every call, so it needs its own speed targets and alerts.
Does POS integration have to be real time?
Yes, for every step the cashier waits on. Toast expects a 500 ms average response from a loyalty integration, with 5 seconds as the most it allows. Past that, Toast can close the socket and send the request again.
Accrual is different. Toast sends the accrue call after the guest pays, as a separate step that runs in the background. That split is a sound rule for any program. Identify, inquire and redeem run in real time. Accrue can sit in a short queue.
A nightly batch file is the simplest link to build. Members pay for it. Points show up a day late, and this morning's points cannot pay for lunch.
What happens to loyalty when the store goes offline?
On Toast, the till keeps selling and the loyalty work waits. Toast states that its loyalty integration is not supported during an internet outage. Its devices store payments and send the accrue requests once the network is back, and they do not process reward redemptions while offline.
Payments face clocks too. Square says offline payments process when the device reconnects within 24 hours, and no later than 72 hours. Write your own offline rules before launch. Queue each accrual with its first timestamp and transaction ID. Block redemptions, since the till cannot check the balance. Replay the queue in order, and alert when it gets old.
What data must the POS send to the loyalty platform?
A till that sends only the total supports one rule: flat points on spend. Every rule a loyalty team writes later depends on fields the till sends today. Agree on this data contract before any code is written.
| Field | What the platform uses it for | What breaks without it |
|---|---|---|
| Member ID or token | Ties the sale to one account | The sale stays anonymous and earns nothing |
| Store and lane ID | Store offers, partner funding, fraud checks | Local promos cannot fire, and fraud cannot be traced to a lane |
| One unique ID per sale | Lets retries and returns run safely | Retries post points twice, and returns cannot find the sale |
| Timestamp with time zone | Time-bound offers and tier windows | Happy-hour offers and year-end status counts go wrong |
| Line items with SKU, quantity, price and discount | Deals on one item, bonus points on a whole aisle, goods that earn nothing | Only flat spend rules work, and excluded goods earn points |
| Tender type | Rules that skip gift cards or reward a co-brand card | A bill paid with points earns new points |
| Totals before and after tax | Earn on the basis the terms state | Members earn on tax when the terms say they should not |
| The first sale's ID on a return | Takes back the right points | Members keep points on goods they brought back |
The tax row matters in practice. Square's accrual rules carry a tax mode that decides whether tax counts toward points.
How do returns, voids and retries stay accurate?
Each reversal must point at the sale it undoes. Toast's reverse call carries the ID of the earlier transaction it reverses, and a void of the check or of an item triggers it. Line-level data matters here too. With it, a partial return takes back only the points those items earned.
Retries are the quiet risk. Toast retries a request when no response arrives, and it does not flag the repeat. The loyalty side must spot the duplicate and return the first answer. Square handles the same problem with an idempotency key, a unique string that guards against duplicate calls. Offline replay makes this more pressing, since a whole queue can arrive twice.
How should you test and roll out a POS integration?
- Build against a sandbox with a written script of cases. Include a split tender, a partial return, a full void and a repeated call.
- Pull the network cable on a test lane, then check that the queued sales replay once and in order.
- Load test at your real peak, with real basket sizes, using the math in the next section.
- A pilot of a few stores should cover each POS model and store format you run.
- Response time and error rate get a daily check. So do unmatched sales and queue age.
- Roll out by region or banner, with a switch that drops the till back to plain checkout if the link fails.
How much load does a POS integration carry at peak?
For illustration, take a grocer with 300 stores and 12 lanes in each. At the Saturday peak, every lane closes a basket each 90 seconds. That is 3,600 lanes at 40 baskets an hour, or 144,000 baskets an hour.
Spread over 3,600 seconds, that is 40 checkouts a second. If 60% of baskets carry a member, 24 member checkouts land each second. At up to four calls each, from identify to accrue, the platform takes 96 calls a second at peak.
Now one store loses its line for two hours at that peak. Its 12 lanes close 960 baskets, and 576 member accruals wait in the queue. When the line comes back, the platform has to post all 576 on top of live traffic, and post each one once.
How GRAVTY handles POS integration
GRAVTY connects to the till through its real-time APIs. The integrations page lists the POS systems it integrates with. Oracle Simphony, Micros, Toshiba and D365 are among them. Those links cover member lookup and balance checks. They also post points and apply rewards and vouchers at the till.
The technology page lists a 120 ms accrual response for a 50-line-item basket and 30,000+ transactions per second at peak. It also shows a 99.99% Uptime SLA. Earn rates and tiers for each banner are set in Visual Rules, the patented no-code rules engine. Per the grocery page, those rules deploy without an IT ticket. One member record shows up at both the store POS and the forecourt.
Frequently asked questions
Should points post before or after payment?
Points should post after payment clears. If they post first, a declined card or a voided check leaves points behind. Toast follows this order: its accrue call runs after the guest pays, and a void sends a reversal.
Can members join the program at the till?
Yes, if the integration includes a sign-up call. Toast's spec has one that creates a new loyalty account from a phone number or email. The loyalty side must treat a retried sign-up as the same request, or one guest ends up with two accounts.
Does the POS have to calculate points itself?
No, the loyalty platform should do the math from the basket the till sends. Then a rule change goes live without a POS release. Toast puts the loyalty program in charge of the rewards accrued. Square supports both ways: send the order and let it work out the points, or compute them in your own code and send the total.
Does PCI DSS apply to a loyalty POS integration?
It applies when card data crosses the link. The standard covers entities that store, process or transmit cardholder data. A feed that carries only a member ID keeps card data out of the loyalty platform.
What is the difference between an integrated POS and a POS integration?
An integrated POS has a feature such as loyalty built into the product, and a POS integration links the POS to a separate system. A loyalty platform that also serves the app, the website and partners sits outside the POS, so it needs an integration.
What else does a POS integrate with besides loyalty?
Payments, stock, accounting and online orders are the usual links, and loyalty sits beside them. Each link carries different data on its own schedule. Loyalty and payments are the two that must answer while the guest waits.