Point-of-sale guide and verified product evidence
What is a POS system?
POS stands for point of sale. A POS system combines software, a checkout device and any connected payment or receipt hardware to calculate a sale, record what happened and update the business records behind it.
This guide explains the transaction, terminology and operating models first. It then shows which Posnic v1.3.0 workflows were reproduced or source-tested, what remains unproved, and what a business should test on its own counter.
POS meaning in one minute
The phrase describes both the moment of checkout and the system that supports it. Separating the parts prevents a payment device, cash drawer or invoice screen from being mistaken for the whole operating system.
| Term | Plain-English meaning | What it does not prove |
|---|---|---|
| Point of sale | The time and place where a customer completes a purchase. | It does not identify the software, payment method or equipment in use. |
| POS software | The application that builds the basket, calculates the amount, records the sale and can manage related stock, customer and report records. | A software feature name does not prove that the exact workflow, device or local rule has been accepted. |
| POS hardware | The computer or tablet and optional scanner, printer, cash drawer, scale, display or other device used at checkout. | A connector or protocol in source code does not certify every make, model, cable, driver or operating system. |
| Payment terminal | A device that captures an electronic payment method and works with a processor to request authorization. | A card reader is not the whole POS system and does not by itself manage items, stock, returns or reports. |
| POS system | The complete checkout arrangement: software, records, device, people, procedures and any payment or peripheral integrations. | Buying the parts does not prove that the complete counter will reconcile, recover from failure or fit the business. |
POS system specifications to write before comparing products
A useful specification says what the complete counter must do, the conditions it must survive and the evidence required for acceptance. A processor speed or feature list alone cannot describe a working POS system.
| Specification area | Write down before selection | Evidence before approval |
|---|---|---|
| Checkout workflow | Sale, discount, tax, tender, receipt, hold, correction, void, return, credit and day-close rules. | Representative normal and exception transactions completed by the intended cashier and manager roles. |
| Items, stock and records | Required identifiers, units, variants, barcodes, weighed goods, receiving, adjustments, movement history, reports, exports and retention. | Reconciled sample records that can be opened independently and traced from source event to report. |
| Computer and platform | Exact operating system and architecture, processor, memory, free storage, display, update policy and replacement-device plan. | Installation, normal load, restart, update and clean-device recovery on the planned specification. |
| POS peripherals | Exact printer, scanner, drawer, scale and display models; interface, protocol, driver, firmware, paper, cable and fallback. | Observed output, reconnect, restart, queue, failure and fallback results for each exact device. |
| Payments and network | Cash rules, processor and terminal scope, authorization and settlement path, required connectivity, outage behavior and reconciliation owner. | Approved, declined, reversed and refunded cases matched between the POS record, terminal and processor settlement. |
| Access, backup and recovery | Roles, sensitive-data boundary, update owner, backup location, retention, encryption, restore target, recovery time and incident steps. | Permission checks plus an off-machine backup restored into a disposable or replacement setup. |
| Service, exit and total cost | Implementation, migration, training, support hours, escalation, hardware replacement, data export, cancellation and every recurring or usage charge. | Named owners, dated terms, a tested complete export and a cost model that keeps quoted, estimated and unknown amounts separate. |
Turn each specification into a pass condition
Record the expected result, exact configuration, observed result, retained evidence, owner and stop-or-go decision. Keep product-specific computer and peripheral claims separate from the requirements every candidate must meet.
Download the 12-point scorecard Check Posnic hardware requirements
How a POS system works
A useful POS creates an explainable record from item selection through payment, stock movement and closing. The exact sequence varies, but a buyer should be able to reproduce these six stages.
- Build the sale. The cashier scans or selects an item or service. The system resolves its identity, quantity and current selling rule.
- Calculate the amount. The POS applies configured prices, discounts, taxes and rounding, then shows the amount due before payment.
- Record the tender. Cash can be recorded in the POS. An electronic payment may be authorized by a separate terminal and processor, then linked back to the sale.
- Commit the transaction. The system saves the sale according to its completion rules and issues the required receipt or invoice record.
- Update connected records. Depending on the setup, the sale can create stock movement, customer, order, tax and report records. These updates must be tested rather than assumed.
- Reconcile and recover. Staff compare POS totals with cash, terminal settlements, returns and selected stock, then preserve a restorable backup and an exception trail.
Payment is one part of the transaction
The POS basket and the payment authorization are related records, not automatically the same record. Test approved, declined, cancelled, reversed and refunded electronic payments, then reconcile the processor settlement independently. Use the PCI Security Standards Council merchant resources to identify payment-data responsibilities for the actual setup.
Benefits of a POS system, and how to verify them
A POS system can make checkout and business records more dependable, but the benefit comes from an accepted workflow, not from the product label. Set a measurable pass condition before treating any outcome as proven.
| Potential benefit | Required system behavior | Acceptance evidence |
|---|---|---|
| Faster checkout | Items, prices, discounts, taxes, tender and receipt steps remain usable during representative normal and rush transactions. | Timed test baskets, correction counts, queue observations and cashier sign-off on the exact counter setup. |
| More reliable sale records | The basket, amount, tender, receipt, return and correction records can be traced to the same transaction without unexplained gaps. | Sample transactions reconciled from source action to stored sale, receipt, payment record and report. |
| More explainable inventory | Receiving, sale, return, waste and adjustment events create dated stock movements with responsible users. | An opening count plus representative movements reconciled to the closing system balance and physical count. |
| Stronger cashier control | Individual roles restrict price, discount, void, refund, tax and close actions, while approved exceptions retain an audit trail. | Denied-action tests, approved exception records and a reviewed permission matrix for cashier and manager roles. |
| Quicker day close | Sales, returns, discounts and tender totals remain separately visible and can be compared with cash and processor records. | A mock closing that matches POS totals, counted cash, terminal settlement and unresolved variance records. |
| Better recovery from failure | The business knows which tasks continue during each outage and can restore required data and configuration from a separate copy. | Controlled network and device drills plus a timed clean restore whose records are checked after recovery. |
POS system, cash register and card terminal compared
| Tool | Primary job | Records commonly expected | Question before buying |
|---|---|---|---|
| Cash register | Total a sale and hold cash. | Basic transaction or till totals, depending on the model. | Does the business also need item-level stock, returns, permissions and searchable history? |
| Card terminal or reader | Capture and authorize electronic payment. | Authorization, reversal, refund and settlement records from the processor. | How will terminal results link to the POS sale and reconcile when either side fails? |
| Billing or invoicing software | Create a bill, invoice or receivable record. | Invoice, tax, customer and payment-status records, depending on scope. | Does it support the live checkout, stock movement, returns and hardware the counter needs? |
| POS software | Run the checkout and retain the sale workflow. | Basket, price, tax, tender, receipt, return, stock and report records, depending on configuration. | Which functions were observed end to end on the exact release and equipment? |
| Complete POS system | Join software, devices, payment paths, people and operating procedures. | Transaction evidence plus separate payment, cash, stock, backup and exception records. | Can staff complete, reconcile and recover a representative business day? |
Types of POS systems
Deployment labels describe where the application and records depend on running. They are starting points for testing, not guarantees of availability, ownership or security.
Local or on-premise POS
The shop computer or a local server runs the primary application and stores operational records. This can reduce dependence on a hosted service during selected workflows, while making local backup, updates, device recovery and physical security explicit owner duties.
Cloud POS
A provider-hosted service supplies the application or primary data path. It can simplify remote access and centralized updates, while connectivity, account access, export, provider recovery and service terms remain dependencies to verify.
Hybrid or offline-capable POS
Local work continues for defined tasks and synchronizes with a hosted service later. Test exactly which tasks continue, how conflicts are resolved, what users see during an outage and how delayed records reconcile.
Mobile POS
A phone, tablet or handheld device runs the checkout. Portability can suit tableside, queue-busting, market or delivery work, but battery life, connectivity, payment support, permissions and receipt options still need an on-device test.
Self-service kiosk POS
A customer-facing screen lets the buyer build or pay for an order. Accessibility, product availability, payment recovery, staff intervention, receipt output and downstream fulfilment are part of the system.
Multichannel POS
Store, mobile or online orders share selected product, customer, stock or payment records. Define the owner of each record and test duplicates, returns, delayed events and channel conflicts before calling the data unified.
Evidence and review scope
Evidence reviewed 21 August 2026. The review uses stable release v1.3.0, pinned source commit b531ef4308c4dc3a25f250551a54fc5616e3b8d9, reproduced local runtime evidence, a 21-check inventory lifecycle record, a 49-check opening-to-close counter-session record, focused source tests, product documentation and current primary operational guidance.
The counter session was a compressed synthetic API run, not a packaged-interface or clock-length staff shift. No complete retail, restaurant or kiosk operating day, physical POS hardware, card terminal, physical cash count, production database, disk-loss event, macOS run, Linux run, independent security audit or hosted-cloud acceptance test was included.
Evidence at a glance
These results are intentionally labelled by evidence type. A passing source test is not presented as a completed shop rollout.
| Area | Observed evidence | Boundary |
|---|---|---|
| Local sale | One synthetic INR 125 cash sale completed and reopened on Windows x64 while external hosts were blocked inside Electron. | Not an operating-system-wide network disconnection, power-loss test, payment-terminal run or full shift. |
| Inventory lifecycle | Twenty-one API checks passed: stock moved from 100 to 120 after receiving, to 118 after a two-unit sale, and to 119 after a one-unit return. Duplicate sale and refund replays made no second stock change; the report reconciled to INR 138 net sales. | Synthetic endpoint-level run; no packaged interface, physical hardware, external payment network, customer production data or complete trading day. |
| Counter session | Forty-nine API checks passed: one register opened and closed; 12 sales covered 20 units; one return restored stock; duplicate sale and refund replays made no second change; and stored and graphical-report net sales both reconciled to INR 2,622. | Compressed synthetic API session. Cash, UPI and Card were labels only; no packaged interface, physical cash, terminal, customer data or clock-length trading day. |
| Backup and restore | A synthetic backup restored 20 collections and 53 documents with matching source and destination totals. | Disposable test data, not a production database, damaged disk or full disaster-recovery exercise. |
| Receipts and reports | 37 focused receipt and report, local-asset and sales call-path source tests passed. | No physical receipt, packaged-interface shift or clock-length staff acceptance day was run. |
| Retail and supermarket support | 57 vertical-supporting source tests passed across item, weighed-quantity, receipt, report and related paths. | No complete retail or supermarket day and no physical retail hardware. |
| Kiosk support | 24 focused kiosk source tests passed for settings, availability, guarded routes, order paths and reports. | No physical kiosk order, payment, kitchen print or report was executed. |
| Hardware paths | 35 hardware protocol and source tests passed for receipt, report and weighing-scale paths. | No physical printer, scanner, drawer, scale, display or payment terminal was connected. |
| CSV templates | Six tests checked all seven shipped CSV templates under the application's parser. | An actual bulk import was not executed through the user interface. |
| Local API | A curated API Jest run reported 7,953 passed tests and zero failures. | Curated suite only; conflicting endpoint totals remain in three documents and no stable public plugin or sync contract is claimed. |
See the product records, not a mock-up
These screens come from the reviewed Posnic application. Buyers should reproduce the same records with their own item, tax, user and hardware setup.
POS feature map
Treat each group as a workflow to verify, rather than a checkbox that guarantees a business outcome.
Sales and billing
Product documentation covers sales, returns, customers, taxes and reporting. Validate prices, discounts, tax, payment, permissions, correction records and receipt output with representative transactions.
Stock and purchasing
A synthetic API run received stock, saved and replay-protected a sale, processed and replay-protected a return, retained three movement records and reconciled the report. Accurate live stock still depends on units, receiving, wastage, adjustments and physical counts.
Restaurant operations
v1.3.0 documents KOT and Easy Table workflows, and the source contains six KOT report views. Table service, kitchen routing, modifiers and close-out were not run end to end.
Kiosk workflow
The source includes kiosk settings, item availability, guarded routes, order-processing paths and reports. Accessibility, enclosure, payment, kitchen output and staff recovery need an on-device acceptance test.
Local backup
Configurable backups are documented and a synthetic restore passed. The default same-disk location does not protect against disk loss, so copy backups off the till and rehearse recovery.
POS hardware
The hardware matrix covers receipt-printer, scanner, drawer, scale and display paths by support level. Match the exact model, interface, operating system, driver, paper width and fallback before purchase.
Data import
Seven CSV templates passed parser-oriented structural and sample-data checks. Trial a reversible import with representative duplicates, tax groups, units and malformed rows before loading a live catalog.
Local API and source
The desktop process starts a local API and database on derived port ranges. Review the pinned source and API limitations before building an integration or depending on undocumented behavior.
Optional cloud services
Cloud is a separate paid service described for sync, off-site backup and remote dashboards. Confirm current availability, data flow, conflict handling, recovery, support and commercial terms before rollout.
Local privacy model
The local edition documentation says it needs no Posnic account and sends no analytics or telemetry to Posnic. Optional services and business-selected integrations change the data-flow review.
Source and package licences
Posnic's own public source is AGPL-3.0-only. The v1.3.0 packages also bundle MongoDB Community Server 7.0.14 under SSPL-1.0, which MongoDB states is not OSI-approved. Inspect the package evidence and review each component before distribution or deployment.
Published installers
The stable release publishes Windows x64, macOS Intel and Apple Silicon, and Linux x86_64/amd64 builds. This review reproduced runtime behavior on Windows x64 only.
Dependencies to test outside the feature list
| Workflow | Current evidence level | Outside dependency | Buyer test |
|---|---|---|---|
| Local cash sale | Limited Windows runtime result plus source tests | Computer, power, staff permissions, item and tax setup | Run normal and exception sales, then reconcile the saved records. |
| Receive, sell and return stock | One 21-check synthetic API lifecycle with duplicate-write guards and report reconciliation | Catalog quality, units, supplier records, staff procedure, damaged stock, adjustments and physical counts | Repeat the lifecycle with representative goods, users and exception paths, then reconcile movement history to a physical count. |
| Open, operate and close a counter | One 49-check compressed API session with 12 sales, one return, register close and record reconciliation | Staff procedure, physical cash and denominations, exact devices, payment providers, shifts, outages and management sign-off | Run a clock-length acceptance day in the packaged application, count the drawer, match provider totals and retain independent sign-off. |
| Electronic payment | No physical terminal run in this review | Processor, terminal, network, settlement and refund process | Match approved, declined, reversed and refunded payments to POS records. |
| Receipt and drawer | Focused source and protocol tests | Exact printer, driver, interface, paper width and drawer wiring | Print representative long receipts and test the failure fallback. |
| Barcode and weighed item | Source tests and standards review | Barcode data, scanner mode, scale model, interface and calibration | Test good, duplicate, unknown and damaged labels plus weighed quantities. |
| Restaurant or kiosk | Documentation and focused source tests | Screen, enclosure, accessibility, payment, kitchen routing and recovery | Run a complete customer order through fulfilment, correction and report. |
| Backup and recovery | One synthetic restore | Separate storage, retention, encryption, owner and replacement machine | Restore an off-machine copy into a disposable environment and verify records. |
| Optional cloud | Edition documentation only in this review | Hosted service, connectivity, account, support and commercial terms | Complete a written acceptance test for sync, conflict, outage, export and recovery. |
What this evidence does not prove
- It does not prove compatibility with a buyer's physical printer, scanner, drawer, scale, display or payment terminal.
- It does not prove a clock-length retail, restaurant, supermarket or kiosk day under production load; the recorded counter session was compressed synthetic API evidence.
- It does not reproduce runtime behavior on macOS or Linux, even though stable installers are published for those platforms.
- It does not establish country-specific tax certification, payment certification or legal compliance.
- It does not replace an independent security audit, penetration test or business-specific threat review.
- It does not establish hosted-cloud availability, branch-sync acceptance, an integration SLA or a stable public sync/plugin contract.
- It does not prove stock will be accurate without disciplined receiving, units, returns, wastage, adjustments and physical counts.
Ten tasks before a POS go-live
- Write the required sale, return, purchase, stock, tax, payment, permission and day-close workflows before configuring software.
- Create representative items including variants, discounts, tax groups, weighed goods, duplicate barcodes and awkward quantities.
- Use the exact computer, operating system, printer, scanner, drawer, scale, display, payment setup and network planned for the counter.
- Run cash and electronic sales, holds, discounts, returns, cancellations and credit paths with the intended cashier and manager roles.
- Receive a purchase, sell and return stock, record an adjustment, then explain each quantity from the movement history and a physical count.
- Test every required receipt, report, export and tax field against the business's accounting and record-retention process.
- Disconnect each external dependency separately and document what continues, what stops, how staff are warned and how transactions recover.
- Close a mock day and reconcile sales, returns, discounts, cash, processor totals, open credit and selected stock independently.
- Copy a backup off the till, restore it on a disposable setup and verify representative items, sales, stock and reports.
- Record rollout ownership, support contacts, update windows, incident steps, replacement-device setup, export procedure and rollback criteria.
Keep a 20-record POS acceptance log
Record the exact release, configuration, expected result, observed result, retained evidence, owner, specialist review and stop-or-go decision for each critical workflow. The blank log separates an advertised feature from a feature your business has actually accepted.
A blank row is not a pass. Keep screenshots, receipts, exports, provider records and restore evidence outside the till, then link or identify them in the log.
Primary sources and product evidence
Stable source and user guide
Inspect the exact source snapshot and documented workflows used by this review.
Hardware evidence matrix
Review support levels, exclusions and buyer-test requirements for POS devices.
PCI merchant resources
Use primary payment-security guidance to map terminal, processor, vendor and card-data responsibilities.
GS1 retail barcode standards
Use the standards owner for EAN/UPC identity, symbol and scanning guidance rather than assuming every code or scanner behaves alike.
NIST CSF 2.0 for small business
Use current primary guidance to assign governance, protection, detection, response and recovery responsibilities.
Reproducible product evidence
See the release, source commit, runtime boundaries, test files and evidence-maintenance method in buyer-readable and machine-readable records.
Verify Posnic specifications · Read the counter-session evidence JSON
Questions buyers ask
What does POS stand for?
POS stands for point of sale: the time and place where a customer completes a purchase. A POS system is the connected software, checkout device and optional hardware used to calculate, record and complete that transaction.
What is a POS system?
A point-of-sale system records a sale and coordinates the checkout workflow. Depending on the setup, it can calculate prices, discounts and taxes; record cash or electronic tender; issue a receipt; update stock; and retain records for returns, reconciliation and reporting.
Is a card terminal the same as a POS system?
No. A card terminal or payment processor handles electronic-payment authorization and movement. POS software records the basket, prices, taxes and sale. They may be integrated, but each has separate failure, security and reconciliation responsibilities.
Does every POS system need the internet?
No single answer applies to every system. Cloud services, card authorization, downloads and remote sync may require a network, while some local or offline-capable systems can continue selected cash-sale workflows. Buyers should test each dependency separately.
How much does a POS system cost?
Total cost can include software, checkout computers, payment devices, printers, scanners, setup, data migration, processing fees, support, backups, updates and downtime. A zero software price does not make the complete operating setup cost-free.
What should POS system specifications include?
Write the required checkout and exception workflows, data and export rules, computer and device configuration, payment and network dependencies, access controls, backup and restore targets, support ownership, exit terms and total cost. Give every requirement an observable pass condition.
Which Posnic POS features were tested at runtime?
The review reproduced one synthetic local Windows sale, one synthetic backup-and-restore drill, and a separate 21-check API inventory lifecycle covering receiving, sale, duplicate-sale protection, partial return, duplicate-refund protection, stock logs and report reconciliation. The inventory run did not drive the packaged interface or physical hardware.
Has Posnic tested every supported POS device?
No. Thirty-five focused protocol and source tests passed, but no physical printer, scanner, drawer, scale, customer display or payment terminal was connected in this review.
What should a business test before using Posnic POS?
Run a representative sales day on the exact operating system, items, taxes, users, printer, scanner, payments and network planned for the business; reconcile cash and stock; then restore an off-machine backup before approval.
Is the free Posnic desktop application a timed trial?
No. The v1.3.0 desktop packages have zero software price and no trial clock. Posnic's own source is AGPL-3.0-only; the packages also bundle MongoDB Community Server under SSPL-1.0. Optional cloud services are separate and should be evaluated against current availability and terms.