How to build a POS system: a step-by-step guide

To build a POS system you need six working parts: a product catalogue with prices and tax, a sell screen, payment with a durable numbered receipt, a stock ledger the sale writes to, a register that opens and closes with a counted cash variance, and returns that undo everything the sale did. Build them in that order: catalogue → sell → tender and receipt → stock → register close → returns → roles and approvals → reports, and add purchasing, loyalty, multiple shops or offline selling only if you need them. As a rough guide, a single-shop counter is days to a few weeks of work for one experienced developer with a coding agent, and a multi-shop system with purchasing and loyalty is months; the assumptions behind those ranges are further down. Whether you call it building or making a POS system, the hard part is the same, and it is not the sale.

Every POS can take money. They fail afterwards: the refund that keeps the loyalty points, the void that erases a sale from the report meant to catch theft. This guide is grounded in a hand count of 60 real retail POS products across 127 inspected source pages, and in a build-off where three coding models built a POS from the same brief. All three are live, so the failures below are things you can go and check.

Build, buy or customise?

Answer this before writing any code. For most shops, buying is the right call.

If you are building, the rest of this page is the order to do it in.

What a POS has to do, by how often real products ship it

Our research counts what 60 real retail POS products document publicly. A missing capability means "not shown in the public evidence", not "the product lacks it", so the low rows are underreported rather than unimportant.

Checkout is universal, so it does not separate a good POS from a bad one. The bottom half of the table does. Register close is underreported because marketing pages do not sell it.

The build order

Each step has a test you can run before moving on. If the test fails, the next step will be built on something broken, and the failure gets more expensive to find.

Step 0: Decide the store model before the stack

Our research splits retail POS into three depths, a useful scoping tool either way:

• Basic, one store. Sell, simple products, real stock rows, cash and card tender with a receipt, sales history, an honest refund rule, register close if you take cash, a daily report.
• Moderate. Adds variants and labels, held sales, full exchanges, customer history, stock counts, purchase orders and receiving, and staff roles.
• Advanced. Adds transfers between shops, loyalty, gift cards, offline recovery, integrated card payments and ecommerce sync.

Write down what you are leaving out, too. Restaurant tables, pharmacy dispensing, warehouse management and accounting ledgers are separate products; if they creep in, the counter never gets finished.

Step 1: Catalogue first, because the sale snapshots it

A sale line copies the price and tax rate at the moment of sale. That only works if products, variants, barcodes, prices and tax classes exist as real records first. Two details matter early. Variants (size, colour) are separate stock-keeping units with their own barcode and stock count, not a note on the product. And tax is a class on the product with a rate that can change, never a number typed into the sell screen.

Ask what hardware the shop already owns before you build; the research lists hardware incompatibility as a recurring complaint. A browser or PDF receipt is a safe default, and a specific printer needs its own test print.

Step 2: The sell screen is the product

The cashier is the person a POS has to win over: complete a correct sale fast without losing the queue. Search, scan, quick keys, an editable basket and a clear total belong on one screen. Settings, audit logs and policy menus do not belong in the cashier's navigation at all.

The common mistake here is checkout as invoice entry: a customer field, a line grid and a save button. It works, and it is far too slow at a real counter.

Step 3: Payment and receipt in one transaction

Payment completion, receipt number, stock decrement, register totals and customer history should commit together or not at all. A failed payment must not leave a paid sale, a stock movement or a register balance behind. Receipt numbers must survive a restart and come from the database, not from a counter in memory.

Treat a completed sale as a document that never changes. Corrections are new documents (a void, a return) that point back at the original. That one decision makes the rest of the build tractable, and the POS database design post walks through why.

Step 4: Stock is a ledger, not a number

If stock is one integer per product that the sale decrements, you cannot explain why it changed, and returns, receiving, counts and transfers each make it drift further. Record every change as a movement row (product, location, signed quantity, reason, who, and the document that caused it) and derive on-hand from the movements. The stock screen should open on real rows with quantities, not a dashboard of tiles.

Step 5: The register close is the trading day

The full lifecycle: a cashier opens a register and declares a float, sells, records cash in and out, counts the drawer, and sees expected against counted with the variance, before a manager confirms the close. The system works out expected cash from the sales and movements. A close where the cashier types the expected figure checks nothing.

It appears in only 18 of the 60 products' public evidence, and self-built systems skip it most. If the shop takes cash, it is not optional.

Step 6: Returns undo everything the sale did

A sale takes money, moves stock, earns loyalty points and sometimes spends stored value such as a gift card or store credit. A return must reverse all of them, in proportion, exactly once, inside one transaction. Find the original sale, pick eligible lines and quantities, choose whether the item goes back on the shelf, get approval if policy requires it, and show whether money is owed in either direction for an exchange.

The classic miss is loyalty: return the item, keep the points, and buy it again tomorrow.

Step 7: Roles and the second signature

A shop needs at least a cashier, a manager and an owner, and often a stock clerk. Enforce roles on the server, not only by hiding buttons. Then add the control that makes a POS trustworthy: refunds, large discounts and material cash variances need approval from someone other than the person doing it. Checking that "a manager approved" is the weak version. Checking that the approver is not the requester is the real one.

Step 8: Reports that drill to source rows

Owners want to know what sold, how cash balanced, what stock is at risk and what needs attention. Every number on that overview must open the rows it came from. A report that shows totals nobody can trace will eventually show a wrong one, and nobody will notice. Make sure voids and returns appear in the reports rather than vanishing from them.

Step 9: Branches only by decision

Purchasing, loyalty, transfers, offline selling, integrated cards and ecommerce sync are all real and all optional. Each changes the data model (multi-shop puts a location on nearly every table), so add them by decision, not because the agent had time left over.

The data model in brief

A POS that holds up has a small number of document types and a lot of rows that point at them: stores, registers and staff; products and variants with price and tax; register shifts; sales with sale lines that snapshot price and tax; tender rows (a split payment is just two rows); returns and voids as new documents linked to the original; stock movements written by every document that moves stock; and an approvals table that records who asked, who approved, and for what.

We have written the full schema, with SQL, an ER diagram, the load-bearing constraints and a sample database, in POS database design. Rather than repeat it here, build from that.

Hardware and payments: you build the POS, not the payments

This is the part people worry about most, and it is smaller than it looks. Building the POS software does not mean building card payments. Card terminals and readers come from a payment processor, and your software tells the processor's device what to charge and gets back a result.

Two examples from the official documentation, checked on 19 October 2026:

• Stripe Terminal offers SDKs for Android, iOS, JavaScript and React Native plus an API-based integration, and Stripe documents it as the way to build a custom POS integration. It also supports Tap to Pay on compatible iPhone and Android devices, and its docs state that Terminal payments are end-to-end encrypted by default (how Terminal works).
• Square's Terminal API lets a custom POS app send checkout requests to a paired Square Terminal and receive the result, and the Mobile Payments SDK adds in-person payments to your own iOS or Android app with a Square Reader or Stand. Square lists it for accounts in the US, Canada, the UK and Australia.

Country availability and supported readers differ by processor, so check the processor you will actually use before you design around it.

The simplest version needs no integration at all. Many shops take cards on a standalone terminal and record the card tender in the POS manually. That is a legitimate Basic design, as long as the screen says so. What is never acceptable is a "card approved" message for a payment that never reached a processor. In our build-off, all three builds kept card payment in an honest test mode, and one stated in the payment dialog itself that card was unavailable without a live provider.

The rest (scanner, receipt printer, cash drawer) is ordinary hardware; POS system cost covers its price.

How to build a restaurant POS system

A restaurant POS is a different product, not a retail POS with tables added. It needs an open check that stays editable for an hour, modifiers that change both the price and the kitchen ticket, items sent to kitchen stations, splitting by seat or amount, and tips on the tender. Our retail research deliberately excludes it for that reason. If that is what you are building, start from the Restaurant Management planner, which treats counter service, dine-in, bar, takeaway and other venue types as separate scopes.

Build it with an AI coding agent

A coding agent can build every step above. Given a one-line prompt, it builds the sale and stops, because the controls after the sale never appear in a screenshot.

What to hand the agent. A written spec, before any code: the depth from step 0, the exclusions, the build order, and the done-when test for each step. Tell it explicitly that completed sales are never edited, that returns reverse stock, loyalty and stored value in one transaction, that the close computes expected cash itself, and that approvals need two different people. The Retail POS planner is that spec in a form the agent runs itself: it asks the scoping questions, writes the build spec, and holds the build to those lifecycles.

What to check after each step. Run the done-when test yourself rather than accepting the agent's summary, then try to break it: refresh mid-sale, or paste a manager URL as a cashier.

What our build-off actually caught. We gave one POS planner (twenty capabilities, run to the full advanced scope) to three models. GPT-5.6 Sol built Saffron Till (91), Claude Opus 4.8 built Cedar & Row (89) and Grok 4.5 built Bright Corner (87). The scores and findings are on the retail POS benchmark, and all three run as live demos. With a spec that spelled out the money path, all three got returns and second signatures right. The failures were elsewhere:

• A sale that could be erased. Cedar & Row's own review found that one person could ring up a sale, take the cash and remove the record. The build removed the void entirely and routed every correction through Returns. We drove it live: a loyalty customer's balance went 110 → 134 → 110 across a three-item sale and full return.
• A production build that did not compile. Bright Corner ran perfectly in development, where it was tested, but one file was missing an import that only fails in a production build. Its handover said the production build had been verified.
• Test data in the money tables. Cedar & Row's database held payment types named "banana" and "unicorn" from its own testing. A system that accepts any payment type will eventually record one.
• Self-assessments wrong in both directions. One sign-off condemned work that was fixed 83 minutes later; another claimed a verified build that was not.

The full write-up is in three models, one POS system.

The mistakes that show up every time

A checklist to run against any POS, whoever built it:

• Return a sale that earned loyalty points. The points should go back. Then return one paid partly by gift card and check the card balance.
• Return more than was sold, in two partial returns. The second should be refused.
• Give ten small refunds in a row. If a per-transaction limit lets all ten through, the limit protects nothing. One build on our board caps refunds per person over 24 hours for this reason.
• Look for a delete or void on a completed sale, and check the sale still appears in the day's report afterwards.
• Run the production build, not the development server.

How long does POS system development take?

These are rough ranges, not measurements. They assume one experienced developer working with a coding agent, a single standard retail counter, a written spec before coding, and a processor's standalone terminal or SDK for cards. Our build-off timed none of this, so treat them as planning guesses.

The spread inside each row is mostly testing, not typing.

FAQ

How much does it cost to build a POS system?

The software cost is mainly your time, or a developer's, at the effort ranges above, plus hosting. The costs that do not go away are hardware and card processing, and processing usually dominates because it is a percentage of everything you sell. POS system cost breaks down all four components with current vendor prices and a three-year comparison, which is the number a build has to beat.

What tech stack should I use to build a POS system?

Any mainstream web stack with a relational database that enforces transactions and foreign keys (Postgres is a safe default). The hard parts are transactions and document design, not the framework. Decide early whether you need offline selling, because it changes the architecture, and pick your payment processor first if you want an integrated terminal, since its SDK platforms limit your choices.

How do I make a POS system for Android?

Build a native Android app or a web app that runs on Android tablets, and take cards through a processor SDK: Stripe Terminal and Square's Mobile Payments SDK both support Android (see the payments section above). The build order does not change; only the sell screen's layout does.

Can I build a POS system with no-code tools?

You can build a prototype. The parts that make a POS trustworthy (sales that cannot be edited, returns that reverse several ledgers in one transaction, receipt numbers without gaps, approval by a second person) depend on database transactions and constraints that most no-code tools do not expose. For a small shop, a well-built spreadsheet is often a better interim step; a POS system in Excel shows how.

Do I need to be PCI compliant if I build my own POS?

If card data goes through a processor's reader or SDK, the processor handles the card, and your POS records a payment result. Your exact obligations depend on your processor and integration, so ask them; Stripe, for example, documents end-to-end encryption by default for Terminal payments. Never have your own software read or store card numbers.

The shortcut

If you would rather not discover each of these failures one at a time, the Retail POS planner encodes them. Point your coding agent at it and it runs a discovery pass, picks the depth and store model with you, and writes a locked build spec in which the sale, return, register-close and approval lifecycles are gates rather than suggestions, all grounded in the 60-product count above.

Three models built from it. The scores, the findings behind them and the lowest score in full are on the build-off board, and you can ring a sale through each one in the live demos. Sell to a loyalty customer, return it, and watch the points.