POS Integration Checklist

How to use this checklist

A POS-to-loyalty integration has two vendors, and each will assume the other one handles the hard parts. This checklist splits the questions by who has to answer them, so nothing falls into the gap between the two support desks. Work through it on the vendor calls themselves, not afterwards: the goal is written answers before you sign, not impressions.

The section that matters most is failure handling. Every integration works in a demo. The real test is a Saturday rush with flaky Wi-Fi, a refund processed while the loyalty API is down, and a cashier who typed a phone number wrong. Ask about those moments explicitly — a vendor who has good answers has been through them; a vendor who improvises has not.

The page is self-contained: tick items off as you go, print it for the demo, and keep the completed answer worksheet at the bottom with your contract.

Questions for your POS vendor

These determine whether a loyalty integration is even possible on good terms. Ask them before you evaluate any loyalty platform.

• Is there a public, documented API — or partner-only access?

  Partner-gated APIs mean every integration waits on the POS vendor's timeline, and sometimes a certification fee. Ask to see the docs before signing.

• Does the API expose transaction-level data, or only daily summaries?

  Spend-based and item-based loyalty needs line items, totals, and timestamps per transaction. Daily summaries can only power visit counting.

• Are webhooks fired on completed transactions, or must the loyalty system poll?

  Webhooks enable real-time earning at the till. Polling introduces delay and rate-limit pressure; ask what the minimum polling interval is.

• What are the API rate limits, and what happens when they are hit?

  Get the numbers per credential and per location. A busy multi-till site can exhaust a low limit at peak — exactly when loyalty events matter.

• Is there a free sandbox with test transactions?

  You cannot test failure handling against a live till. No sandbox means the loyalty vendor tests in your production store.

• Which loyalty platforms are already certified or listed in your marketplace?

  An existing certified integration is months of de-risking. Ask how long the most recent certification took a new partner.

• What does API access cost — per call, per location, or bundled?

  Some POS vendors charge for API tiers or per-location app fees. Get this in writing; it changes the loyalty program's real running cost.

• What is the API deprecation policy and notice period?

  Ask for the notice period in months and whether old versions keep working during it. A breaking change with short notice can take your loyalty program offline.

• How does the till behave offline — are transactions queued and replayed to the API?

  If offline sales are replayed later, ask whether the replay carries the original timestamp and any customer identifier attached at sale.

• Can a customer identifier be attached to a transaction at the till?

  Scanned code, phone lookup, or card reference — whatever the method, it must land in the transaction record the API exposes, or matching happens by guesswork.

• For multiple locations: one unified account, or separate API credentials per site?

  Per-site credentials multiply setup, rate limits, and failure points. Ask how a new location gets connected and by whom.

• Who supports integration issues — engineers, a partner team, or a community forum?

  Ask for the escalation path and typical response time for a broken integration, not for general support.

Questions for your loyalty vendor

These establish how the loyalty platform actually connects to your POS — and what you keep if you ever leave.

• Which integration method do you actually use with my exact POS and version?

  Native API, middleware, or staff keying purchases by hand are very different products. Ask for a reference customer on the same POS.

• Is earning real-time at the till, or batch-processed?

  Overnight batch means every customer's balance is wrong all day and rewards cannot be redeemed on the visit they were earned.

• How is the customer identified at purchase?

  Scanned pass or code, phone lookup, physical card, or payment-card matching. Each has a different speed at the till and a different error rate — ask which they recommend for your counter flow.

• If identification is a barcode or QR code, does my existing POS scanner read it?

  Some tills need scanner reconfiguration or a separate device for screen-based codes. Test it on your actual hardware during the demo.

• Do you support Apple and Google Wallet passes, so balances update on the customer's phone without an app?

  Wallet-native platforms — PushNotice is one — put the card and its live balance in the phone's wallet, which removes the app-download hurdle from enrollment.

• What happens to points when a transaction is refunded or voided?

  Points should reverse automatically. Ask what happens if the reward was already redeemed before the refund came through.

• Can staff manually adjust a balance, and is every adjustment logged?

  Manual adjustment is your fallback for every integration failure. It must record who, when, and why — otherwise it is also your fraud surface.

• Can I export my full member list, balances, and transaction history at any time?

  Ask for the format (CSV or API), the cost, and whether export is available mid-contract — not only at termination.

• What triggers pricing — locations, members, messages, or transactions?

  A per-member or per-message price grows with your program's success. Model the cost at 3x your current volume before comparing vendors.

• When the integration breaks, who owns the fix?

  The honest answer names one party. If each vendor debugs only their half, you become the project manager of every outage.

• Do you maintain the integration when the POS ships a new API version?

  Ask who monitors POS deprecation notices and how past migrations were handled. This is recurring work someone must own for years.

Failure handling, retries, and manual fallback

Ask both vendors these together, ideally on the same call. Vague answers here predict exactly how outages will feel later.

• If the loyalty API is unreachable at the moment of sale, does the till block, skip silently, or queue?

  Blocking the sale is unacceptable; silent skipping loses points invisibly. Queue-and-retry is the only good answer — confirm which one you are getting.

• What is the retry schedule and cap for failed events?

  Ask for specifics: backoff intervals and how long retries continue. A retry window shorter than a realistic outage means permanent data loss.

• Are retried events idempotent?

  A replayed transaction must not award points twice. Ask how duplicates are detected — an idempotency key per transaction is the standard answer.

• Is there a visible log of failed events, or do failures vanish?

  You need a queue or dead-letter view you can open yourself. If only the vendor can see failures, you will learn about them from customers.

• How and when am I alerted that the integration is failing?

  Ask for the mechanism (email, dashboard banner) and the threshold. An integration that fails quietly for a week does more damage than a loud one-hour outage.

• Can staff award a missed purchase afterwards from a receipt?

  This is the manual fallback for every gap: outage, typo, scanner failure. It should take under a minute at the counter and appear in the audit log.

• Is there a reconciliation report comparing POS transactions to loyalty events?

  A daily or weekly count comparison is how you discover silent drops. Ask whether it exists, who runs it, and where the numbers come from.

• After a POS offline period, are replayed transactions still matched to the right customers?

  Offline replay is where identifiers get lost. Ask both vendors to walk you through this exact path in the sandbox.

• What happens when a refund is processed while the loyalty side is down?

  The reversal must queue and apply like any other event. If refunds are handled on a separate, non-retried path, points drift upward forever.

• If a customer identifier is entered wrong, how are orphaned points recovered and merged?

  Typos at the till are routine. There should be a merge or reassignment tool, not a support ticket per incident.

• Is there a written recovery runbook for integration outages?

  Ask to see it. A vendor with a runbook has done this before; a vendor whose runbook is 'contact support' has not.

• Will you demonstrate a failure in the sandbox before I sign?

  Have them disconnect the integration, ring a test sale, reconnect, and show the retry succeeding with no duplicate. Fifteen minutes, and it verifies half this page.

Reading the answers: strong versus weak

Use this as a marking guide while you fill in the worksheet below. No named vendors — the same checkpoint separates good and bad setups on any platform.

Vendor answer worksheet

Fill this in during the calls and the sandbox demo. Written answers here are what you attach to the contract.

Before you sign

Three habits turn this page from a list into leverage. First, get every material answer in writing — an email summary the vendor confirms is enough. Verbal assurances about retry windows and export rights do not survive an outage or a renewal negotiation. Second, insist on the sandbox failure demo; it is the single highest-value fifteen minutes in the entire evaluation, and a vendor's willingness to run it tells you as much as the result. Third, file the completed worksheet with the contract, because the person handling the first outage may not be the person who ran this evaluation.

If either vendor cannot answer the failure-handling section, that is your answer. Integrations do not fail in demos — they fail at peak, quietly, and the cost lands on your counter staff and your customers. Choose the vendors who have clearly been through that and built for it.