Talk to us about your retail POS project.
Tell us your location count, current POS setup, product complexity, and loyalty requirements. We'll scope the right system and give you a fixed cost.
POS system that can't handle your product variants, locations, or tender types without manual workarounds at checkout?
Loyalty and POS on separate systems so staff manually look up points and customers have no real-time balance?
Custom POS software for multi-location retailers, specialty retailers, and retail tech companies -- built for your product variants, tender mix, and loyalty integration rather than the median retailer the off-the-shelf platforms were designed for.
We build POS systems that handle complex product catalogues, multi-tender splits, loyalty earning and redemption at the till, and offline operation when connectivity drops -- all without the workarounds that slow down every checkout.
Multi-tender checkout handling card, cash, gift card, voucher, and split payments in one transaction
Real-time inventory deduction at point of sale with low-stock alerts across all locations
Customer lookup and loyalty earning and redemption integrated directly at the till
Offline transaction processing when connectivity drops, with automatic sync on reconnect
RaftLabs builds custom retail POS software for multi-location retailers, specialty retailers, and retail tech companies. A custom POS is the right choice when product variants, tender types, or loyalty integration exceed what Square or Lightspeed can support without manual workarounds. Most retail POS projects ship in 12--14 weeks at a fixed cost with full source code ownership.
Square and Lightspeed are built for common retail use cases. If you sell clothing with size and colour variants, run multiple locations with separate stock pools, accept gift cards and loyalty vouchers alongside card and cash, or need a loyalty programme that actually integrates with the till rather than sitting next to it, you will spend a lot of time working around the platform rather than through it.
The cost of those workarounds is real. Staff slow down every checkout to handle the exception. Managers reconcile discrepancies between what the POS recorded and what the loyalty system shows. Inventory counts drift because the POS can't track stock at the variant and location level. These are not edge cases -- they are the daily reality of running a serious retail operation.
A custom POS is scoped to your product structure, your tender mix, your loyalty programme, and your location setup. The result is a system where checkout is fast because it handles every transaction correctly, not just the simple ones.
Barcode scanning for item lookup supports EAN-13, UPC-A, Code 128, and QR Code symbologies via a connected USB or Bluetooth scanner using the Zebra Scanner SDK or a camera-based scan using a device's rear camera. Item lookup resolves to the correct product variant (size, colour, style) instantly so the cashier sees the right line item without manual selection. For retailers using a Zebra handheld scanner, the SDK provides inventory count functionality from the same device used at the till.
Multi-tender checkout accepts card, cash, gift card, voucher, and split payment across any combination in a single transaction. Card payments are processed via Stripe Terminal or Adyen POS using EMV chip (ISO 7816) and contactless NFC (ISO 14443) readers, which handle the cryptographic card authentication required for chipped cards and NFC taps including Apple Pay and Google Pay contactless payments. Cash handling records the tendered amount and calculates change due. Vouchers and gift cards are validated against your redemption ledger in real time.
Receipt printing uses the ESC/POS protocol, which is the de facto standard for thermal receipt printers -- Star Micronics and Epson are both supported. The receipt template is configurable: logo, line item format, loyalty points balance, and return policy footer. Email and SMS receipt options reduce paper waste and give the customer a digital copy without an app download. Returns and exchanges reference the original transaction by barcode or receipt number and reverse the inventory movement and tender accurately without creating a manual correction entry.
Real-time stock deduction at the variant and location level occurs at the moment a transaction is completed, not at end-of-day batch. Each sale reduces the on-hand quantity for the specific SKU (size, colour, configuration) at the specific location where the transaction occurred. Multi-location inventory visibility is maintained across all sites from a single inventory service, so a cashier at one store can tell a customer whether an out-of-stock item is available at a nearby branch without making a phone call.
Low-stock alerts are triggered when on-hand quantity falls below a configurable threshold per SKU per location -- displayed at the till as a notice to the cashier and sent to the buying team via email or notification. Automatic reorder triggers fire when the reorder point is breached, sending a purchase order request to your procurement system or buying team with the SKU, current stock level, and the reorder quantity calculated from your configured par levels.
Backorder and pre-order handling lets customers purchase a product not currently in stock at their location, with the order flagged for fulfillment from another location or from the next incoming shipment. Stock reservation for click-and-collect orders deducts the reserved quantity from the fulfilling location's available stock immediately when the order is placed online, so the same units cannot be sold to an in-store customer before the collection. The inventory accuracy that means your stock report at closing time matches what is physically on the shelf, without a reconciliation session.
Customer lookup at checkout works by phone number, email address, loyalty card number, or QR code scan from a mobile wallet app -- the cashier finds the customer in under two seconds without leaving the transaction flow. The POS calls the loyalty engine API in real time when a customer is identified, retrieving their current points balance, active tier status, and any available rewards or vouchers before the transaction is finalised.
Points earning is calculated and posted automatically on transaction completion based on configurable accrual rules -- points per pound or dollar spent, bonus multipliers for specific product categories, or flat-rate earn per visit. No manual staff entry is required. Points redemption at the till shows the cashier the customer's available points balance and the equivalent redemption values, allows partial redemptions, and posts the deduction to the loyalty engine in the same transaction completion call. The customer-facing display shows the live points balance before and after the transaction so there is no ambiguity about what was earned.
Tier status (Silver, Gold, Platinum, or your programme's naming) is visible to the cashier at customer lookup, enabling personalised acknowledgement and tier-specific benefits like queue priority or exclusive access to apply automatically without the cashier needing to check a separate screen. Customer purchase history -- last purchase date, frequency, favourite categories, total spend -- is accessible during the transaction for personal service conversations. The end-of-day cash drawer reconciliation report includes loyalty activity by transaction so discrepancies between expected and issued points are visible without cross-referencing a separate loyalty report.
Till assignment and cashier session management starts the day with an individual cashier login tied to a specific till, a cash float declaration that sets the opening cash balance for the reconciliation at close, and a session that tracks every transaction made by that cashier on that till during the shift. Session close captures the declared cash total, computes the expected cash based on cash sales minus change, and flags any discrepancy for the manager to review.
Cashier permissions are configured by role, not by individual -- store manager, senior cashier, and cashier roles each have a defined set of permitted actions. Discount limits control the maximum percentage a cashier can apply without manager approval. Void authority limits which roles can cancel a posted transaction. Override capability allows authorised staff to process transactions outside standard rules when a manager PIN is entered. Permission changes apply across all locations immediately without a system update.
Stock transfer requests are initiated directly from the POS when a customer wants an item available at another location -- the cashier raises the transfer request, the fulfilling location receives it, and the stock reservation is applied immediately. Consolidated reporting across all locations from a single management view shows total sales, transaction counts, tender mix, and void rates per location and in aggregate for any date range. Location-specific promotions and pricing rules are configured centrally in the back office and pushed to each store's POS automatically, so a location-specific sale price does not require a manual update at the till. The multi-location control that gives you one consistent version of the data across every site.
Offline mode is built on a local SQLite database that maintains a working copy of the product catalogue, pricing rules, and cashier permissions on the device. When internet connectivity drops -- whether from a network outage, router failure, or ISP interruption -- the POS automatically switches to local mode and continues processing transactions at normal speed with no error messages or degraded experience visible to the cashier or customer.
Transactions queued locally are written to the SQLite store with a pending-sync status and a timestamp. When connectivity returns, the sync process replays the transaction queue against the central server in chronological order, applying the inventory deductions, loyalty points, and payment records as if the transactions had posted in real time. The central system uses the transaction timestamps to maintain correct ordering for reporting and reconciliation purposes.
Conflict resolution handles the case where the same inventory item was sold at multiple locations while both were offline simultaneously -- a stock quantity could go negative if both locations sold the last unit. The conflict resolution logic flags these situations for manager review rather than silently accepting the conflict, and presents the resolution options (accept both sales and back-order one, or cancel the second sale) for the operations team to decide.
Loyalty points earned during the offline period are held in a pending state in the local queue and credited to the customer's account automatically on sync -- no manual points adjustment is needed. The card payment terminal operates independently of the POS's internet connection via its own cellular connection in most modern Stripe Terminal and Adyen POS devices, so card payments can still process even when the POS application is in offline mode.
End-of-day cash drawer reconciliation compares the system's expected cash total (opening float plus all cash sales minus change given) against the cashier's declared cash count. Discrepancies above a configurable threshold are flagged for manager review and recorded against the cashier session. The reconciliation report is generated automatically at session close so the manager sees the result immediately rather than assembling it manually from the transaction log.
Sales reporting covers product-level sales (units sold, revenue, average selling price), category performance, tender type breakdown (cash, card, gift card, voucher), and location-level comparison for multi-site operators. Reports are available for the current day, prior day, current week, and any custom date range. Void and discount reporting with cashier attribution shows every voided transaction and every discount applied, with the cashier who applied it, the discount reason, and the amount -- giving the loss prevention team a clear picture of discount policy compliance without manual audit.
Hourly transaction volume charts show the busiest periods of the day so staffing decisions are based on actual transaction data rather than estimates. The data feeds directly into workforce scheduling decisions. Export to accounting systems (Xero, QuickBooks, Sage) and BI tools (Power BI, Tableau) uses standard CSV or JSON formats generated on demand or on a scheduled daily basis. The reporting layer that takes minutes to review rather than an hour to compile -- delivered automatically at end of day without requiring a manager to assemble it from multiple system exports.
Frequently asked questions
Off-the-shelf POS platforms handle standard retail well: simple product ranges, card and cash payments processed via EMV chip (ISO 7816) and NFC (ISO 14443), single-location stock. Square and Lightspeed are the right choice when your retail operation fits the model they were designed for.
Custom POS makes sense in several specific situations. First, complex product variants: if your catalogue has combinations of size, colour, length, and configuration that exceed what Square or Lightspeed's variant model supports without workarounds, you will constantly encounter errors at checkout that create friction and incorrect inventory records. Second, loyalty programme integration: off-the-shelf loyalty add-ons typically update points with a delay or require a separate staff action -- custom integration calls the loyalty engine in real time at transaction completion so points accrue and redemptions apply in the same flow. Third, tender types: multi-voucher splits, proprietary gift card balances, and complex discount stacking rules often require workarounds on generic platforms that slow checkout and create reconciliation errors. Fourth, multi-location inventory accuracy: real-time variant-level stock deduction at each location with SQLite-based offline mode requires a custom data architecture that off-the-shelf platforms don't expose at the configuration level.
If your staff spend time working around checkout limitations every day, the annual cost in staff time and errors avoided typically justifies a custom build within the first year. We can model that cost comparison during scoping.
We build POS software that runs on standard retail hardware: Windows-based till computers (x86, typically running Windows 10 or 11), Android tablets (Android 9 and above), and iPads (iOS 15 and above). The choice of hardware platform typically depends on your existing estate and what your store fit-out supports.
Receipt printer support uses the ESC/POS protocol, which is supported by Star Micronics (mC-Print, TSP series) and Epson (TM series) thermal receipt printers -- both are widely available and have well-documented ESC/POS command sets. Virtually any thermal printer labelled as ESC/POS compatible will work.
Barcode scanner support covers USB HID scanners (plug-and-play on any platform), Bluetooth scanners for tablet-based setups, and 2D imager scanners that read QR codes as well as traditional 1D barcodes. For retailers using Zebra handheld scanners for both POS and stock takes, we integrate the Zebra Scanner SDK to handle the device communication layer. Camera-based scanning is also available on tablet setups for environments where a dedicated scanner is not practical.
Payment terminal integration is handled via Stripe Terminal or Adyen POS for new deployments, both of which support EMV chip (ISO 7816), NFC contactless (ISO 14443), and Apple Pay/Google Pay tap-to-pay. If you have existing payment terminals under a contract, we integrate against your current provider's SDK. Customer-facing display support covers dual-screen setups where a second screen shows the customer their line items, subtotal, and loyalty balance during checkout.
The POS connects to the loyalty engine as a real-time API call at checkout, with two integration points: a customer lookup call when the cashier identifies the customer, and a transaction completion call when the sale is finalised.
The lookup call retrieves the customer's current points balance, active tier status, and any available rewards or vouchers that can be applied in this transaction. This data is displayed in the POS UI before the transaction is completed, so the cashier can communicate the customer's balance and offer redemption options without switching to a separate screen.
The transaction completion call sends the transaction total, the line items (item IDs and amounts, which allows the loyalty engine to apply category-specific earn rates), and any redemption amounts. The loyalty engine returns the points earned, the updated balance, and the redemption confirmation. This is written to the transaction record and displayed on the receipt and customer-facing screen.
Points accrual per transaction is configurable in the loyalty engine: flat rate (e.g. 1 point per dollar), tiered rate by spend band, category-specific multipliers (double points on selected product categories), or bonus earn for specific promotions. The POS simply passes the transaction data -- the accrual logic lives in the loyalty engine so it can be updated without a POS code change.
If you have an existing loyalty platform (SAP Emarsys, Yotpo, or a custom-built system), we build the POS integration against its REST API. If you need a loyalty platform built alongside the POS, we scope both together so they share data models and work as a single system from day one rather than requiring reconciliation between two separate stores.
A custom retail POS covering EMV and NFC transaction processing via Stripe Terminal or Adyen, real-time inventory sync with SQLite-based offline mode, cashier session management and cash drawer reconciliation, basic loyalty API integration, ESC/POS receipt printing, and end-of-day reporting typically takes 10 to 14 weeks from requirements sign-off to go-live on a pilot location. The phases are roughly: core transaction processing and hardware integration (weeks 1 to 4), inventory sync and offline mode (weeks 5 to 7), loyalty integration and customer lookup (weeks 8 to 9), cashier management and reporting (weeks 10 to 11), and QA and pilot preparation (weeks 12 to 14).
Multi-location rollout, complex loyalty programme integration with custom accrual rules, barcode scanning via Zebra SDK, and offline mode conflict resolution add time depending on scope complexity. Offline mode with full conflict resolution typically adds 1 to 2 weeks to the standard timeline.
The deployment model is pilot-first: the first location goes live and runs in production for two to four weeks before the rollout extends to your full estate. This is not a risk-management convention -- it is the point at which real transaction data reveals edge cases that UAT doesn't catch. Issues that surface in one location are far cheaper to resolve than issues discovered simultaneously across 50 stores. We scope the full rollout plan including staff training and hardware preparation as part of the project scope, not as an afterthought.
What clients say
Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.

RaftLabs was outstanding at addressing our complex platform needs, delivering a stable, high-performance loyalty application that has been genuinely loved by the customers.
01 / 02
Tell us your location count, current POS setup, product complexity, and loyalty requirements. We'll scope the right system and give you a fixed cost.