Vendor-neutral acceptance method
How to benchmark open-source POS software
Test every shortlisted product against the same deployment profile, injected failures and retained evidence. This protocol does not declare a universal winner or turn a vendor statement into a site-acceptance result.
Method and evidence boundary
Reviewed 18 August 2026. The protocol adapts public guidance from OSI, NIST and PCI SSC into a practical purchase and acceptance record. It is not an OSI, NIST, PCI SSC, security, tax or payment certification.
Posnic examples are pinned to public stable-channel release v1.3.0, whose manifest maturity is beta, and source commit b531ef43. They are examples of evidence boundaries, not prefilled scores.
Write the deployment profile before testing
A result is meaningful only for a named site, version and operating model. Record these decisions before a vendor demonstration changes the test.
Business workflow
List shop type, representative products, taxes, discounts, returns, stock movements, reports, staff roles, opening hours and expected peak transaction volume.
System topology
Draw every till, database, local service, browser, server, router, cloud service and branch link. State what should happen when each dependency fails.
Named equipment
Record make, model, revision, firmware, driver, connection and operating-system build for printers, scanners, drawers, scales, displays and terminals.
Payment and fiscal owners
Identify the acquirer or provider and the person responsible for country-specific invoice, tax, fiscal, privacy and retention acceptance.
Recovery objectives
Set the maximum acceptable data loss and recovery time for till, database, device, site and provider failures. Define the temporary business process.
Exit and support
Name who owns updates, security, backups, incidents and support. Define which data must leave, in what format, and how an alternative system will read it.
Keep six evidence levels separate
| Level | What it can establish | What it cannot establish by itself |
|---|---|---|
| 1. Project statement | What a current official project page says about a feature, architecture, release or policy. | That the statement matches the tested version or works in the buyer's environment. |
| 2. Pinned documentation | What a version, release, commit, license, checksum or support document records at a point in time. | That the package was independently reviewed or the workflow completed. |
| 3. Source inspection | That relevant code, tests or configuration paths exist in the pinned source. | That the built package, real device, full workflow or production load behaves correctly. |
| 4. Controlled runtime | That a named package completed a recorded task under stated conditions. | That another platform, outage, data set, full shift or site has the same result. |
| 5. Physical site acceptance | That the exact staff, equipment, configuration and workflow passed at the intended site. | Independent security assurance, legal approval or future-release behavior. |
| 6. Independent or provider review | What a qualified assessor, payment provider, acquirer, adviser or authority accepted within its written scope. | A universal certification beyond that scope or date. |
Run 24 tests against every shortlisted POS
The downloadable scorecard groups these records into 12 weighted controls. Keep the observation and evidence blank until the test is actually run.
| Record | Control and test | Pass condition | Evidence to retain |
|---|---|---|---|
OS-01 | Source and license Pin the repository, release tag, source commit, license files and dependency notices for the exact build under test. | The team can trace the build to source and has an accepted license position for its intended use, modification, hosting and distribution. | Repository URL, tag, commit, license files, dependency notices and decision owner. |
OS-02 | Source and license Compare the installed package and published source or build instructions; record anything that cannot be reproduced or traced. | The package provenance is explained and any non-reproducible component is explicitly accepted as a risk. | Build log or vendor provenance, package hash, unexplained differences and approval. |
OS-03 | Release integrity Download from the canonical release channel and verify version, platform, size, checksum and available signature or notarization status. | Every package identity and trust warning is known before installation. | Release URL, file name, byte size, hash and signature result. |
OS-04 | Release integrity Upgrade a copy of representative data, then rehearse rollback or recovery after an intentionally failed update. | Required data survives and the team can return to an approved operating state within its recovery target. | Versions, backup hash, migration result, rollback steps and elapsed time. |
OS-05 | First sale Install or open the till, create representative items and taxes, complete payment, print or save a receipt and reopen the stored sale. | Ordinary trained staff can complete and retrieve the transaction without hidden developer intervention. | Elapsed time, setup blockers, sale identifier, receipt and stored record. |
OS-06 | First sale Run return, void, discount, price override and cancelled-payment cases against the configured approval rules. | Every approved exception changes the correct records and every denied action remains denied and auditable. | Original sale, exception record, stock effect, approval and audit entry. |
OS-07 | Outage behavior Inject the exact internet, LAN, host or service failure relevant to the proposed architecture while staff run approved counter tasks. | Each required task behaves as documented; unavailable tasks fail clearly without corrupting or silently losing data. | Failure injected, start and end time, tasks, errors, local records and screenshots. |
OS-08 | Outage behavior Restore connectivity or service, then reconcile queues, sequence numbers, payments, receipts, stock and reports across every affected till. | Recovery creates no unexplained duplicate, gap, stale balance or unowned manual correction. | Reconnection time, queue state, duplicate checks, reconciled totals and open actions. |
OS-09 | Returns and permissions Use separate cashier, supervisor, stock and owner accounts to attempt price, tax, refund, void, close, export and settings actions. | Least-privilege rules match the approved role matrix and cannot be bypassed through another screen or API path tested. | Role matrix, denied attempts, approved actions and account used. |
OS-10 | Returns and permissions Trace login, sale, return, void, stock correction, export and configuration changes to a user and time where the workflow requires accountability. | Sensitive actions retain enough context for the business to investigate who did what and reconcile the effect. | Audit entries, identifiers, before and after values and retention decision. |
OS-11 | Inventory trail Receive stock, sell, return, waste, transfer and correct representative items including variants or batches the business actually uses. | Each event creates an explainable movement and the calculated balance matches the expected ledger. | Opening quantity, transaction identifiers, movement history and expected balance. |
OS-12 | Inventory trail Count a controlled sample, enter variances, review negative or unusual stock and reproduce the closing quantity from source transactions. | The variance has an approved reason and the reported balance can be independently recalculated. | Count sheet, variance approval, movement export and recomputation. |
OS-13 | Physical hardware Run the exact printer, scanner, drawer, scale and customer display combinations required by the site with production-like documents and barcodes. | Named models, drivers, firmware, connections and layouts pass the agreed repetitions without unexplained failures. | Make, model, revision, driver, firmware, connection, samples and test count. |
OS-14 | Physical hardware Power-cycle and reconnect each device, restart the till and repeat failure cases such as paper-out, cable removal and malformed scans. | Recovery is clear to staff and does not create a duplicate sale, open drawer, wrong weight or lost receipt state. | Injected fault, operator message, recovery steps, retest and unresolved limitations. |
OS-15 | Payment and fiscal Test the real terminal or payment application with the acquirer or provider-approved cases for approve, decline, cancel, timeout, duplicate and reconciliation. | The responsible provider accepts the configuration and every payment can be matched to one business transaction and settlement outcome. | Provider, terminal and app versions, test references, transaction IDs and approval. |
OS-16 | Payment and fiscal Have the responsible tax, accounting or fiscal adviser review representative invoice, return, numbering, tax and retention workflows for the deployment country. | The business owner records an explicit acceptance or gap; the software page alone is not treated as legal or fiscal approval. | Sample documents, configuration, adviser or authority reference, decision and gaps. |
OS-17 | Backup and restore Create an off-device backup from representative data, retain its identity and test whether the copy is readable and protected as designed. | A named owner can locate a recent protected copy after loss of the primary till or database. | Schedule, location, encryption or access rule, hash, age and owner. |
OS-18 | Backup and restore Restore into a separate clean environment and verify users, settings, items, stock, customers, sales, payments and reports against pre-recorded totals. | Measured recovery point and recovery time meet targets and every required data class reconciles. | Backup ID, clean environment, duration, row totals, functional checks and sign-off. |
OS-19 | Data exit Export all business-owned data classes required for migration or audit and compare row counts, identifiers, dates, taxes and totals with the source. | Exports are documented, usable and complete enough for the agreed exit purpose without an undisclosed paid dependency. | Export files, field map, source and export totals, format and access conditions. |
OS-20 | Data exit Import a representative export into a neutral analysis or replacement tool and document credentials, keys, plugins and knowledge needed to leave. | The business has a practical exit path, not only source access or a button labelled export. | Import result, transformation rules, missing fields, dependencies and exit owner. |
OS-21 | Updates and security Review supported versions, security policy, advisory path, secrets, access controls, dependency status and vulnerability response ownership. | Named people can receive, assess and act on a security issue without relying on an unrecorded assumption. | Policies, supported-version statement, dependency report, contacts and response owner. |
OS-22 | Updates and security Apply an update in a staging copy, verify critical workflows, rotate a test secret and rehearse rollback plus incident evidence preservation. | The change process protects data and permits a controlled return or investigation when a release fails. | Change record, test results, secret rotation, rollback result and retained logs. |
OS-23 | Support ownership Assign cashier, software, hardware, hosting, database, network, payment, tax and security failures to named internal or external responders. | Every failure class has scope, contact, escalation, hours and evidence expectations accepted before go-live. | Responsibility matrix, service terms, contacts, escalation path and exclusions. |
OS-24 | Support ownership Run a production-like shift with representative staff and volume, then review open defects, workarounds, training and rollback criteria. | Business, technical and specialist owners sign the result or record the blocking gap and next action. | Shift record, participants, volume, defects, decisions, owners and due dates. |
Score only after mandatory gates are decided
Calculate a weighted percentage as sum(weight x score / 2), but never let an average hide a blocker. A high total cannot compensate for an unaccepted license, an unrecoverable database, required hardware that fails, an unapproved payment or fiscal path, or unusable business-data exports.
Set gates before the pilot
The business and specialist owners decide which controls block go-live and which conditions can be accepted temporarily. Do not invent the threshold after seeing a preferred product's score.
Keep failed tests visible
Record Not run, Conditional and Fail results with owners and due dates. Removing a failed row destroys the comparison and hides the actual deployment risk.
Retest material changes
A new release, operating system, device, payment app, database, network design, branch topology or recovery process can invalidate the previous result.
Posnic v1.3.0 example: evidence, not a winner score
| Area | Recorded Posnic evidence | Required inference boundary |
|---|---|---|
| Release and source | The stable channel lists v1.3.0; packages, recorded sizes and SHA-256 values are published. Evidence is pinned to commit b531ef43. Inspect release details | The manifest labels maturity beta. Windows and Linux packages are unsigned; macOS packages are signed but not notarized. A buyer must verify the file actually used. |
| Local sale | One Windows x64 cash sale, S-O2MA-000001, completed for INR 125 and the stored record reopened while external hosts were blocked inside Electron. | This was not an operating-system disconnect, router outage, power-loss test, payment-terminal run or complete production shift. |
| Backup and restore | One synthetic restore completed with 20 collections and 53 documents. | It did not establish a production backup schedule, off-site retention, representative database size, disaster recovery objective or full business reconciliation. |
| Source tests | The curated API Jest run recorded 7,953 passing, 0 failing and 13 skipped tests. Review the test boundary | This was not a hosted end-to-end run, physical-device test, customer acceptance, penetration test or independent security audit. |
| Hardware protocols | 35 printer-layout, receipt, report and scale-parser protocol tests passed with no physical equipment connected. Review hardware evidence | No named printer, scanner, drawer, scale, customer display or payment terminal has a public physical acceptance result in this evidence set. |
| Payments and compliance | The local runtime example used cash and did not connect a payment terminal. | No card authorization, capture, settlement, PCI validation, country-specific fiscal approval, tax acceptance or customer outcome is established. |
Use a repeatable test sequence
1. Baseline
Record clean starting data, versions, configuration, devices, users, expected totals and monitoring. Preserve the installer and checksum used.
2. Execute
Use representative trained staff. Record start and end times, transaction identifiers, screenshots or logs, physical outputs and every workaround.
3. Inject failure
Change one dependency at a time where possible: WAN, LAN, host, local API, database, device, power or provider. State exactly what was interrupted.
4. Recover
Restore service and reconcile transactions, sequence numbers, payments, receipts, stock, exports and reports. Measure recovery rather than writing that it was quick.
5. Decide
Business, technical and specialist owners mark Pass, Conditional, Fail or Not applicable with evidence, follow-up and an expiry or retest trigger.
6. Preserve
Keep the profile, blank and completed scorecards, evidence files, decision, unresolved risks and selected package together for later audit or replacement.
Primary method sources
Open Source Initiative
The Open Source Definition explains that open source requires distribution terms meeting defined criteria, not merely visible source code.
NIST contingency planning
NIST SP 800-34 Rev. 1 informs failure, recovery and evidence planning. It is federal-system guidance adapted here, not a claim of Posnic conformance.
NIST secure development
NIST SP 800-218 SSDF gives software producers and purchasers a common vocabulary for secure development and supplier discussions.
PCI Security Standards Council
PCI SSC secure technology guidance separates approved payment devices and validated payment software from general POS feature claims.
Posnic release evidence
v1.3.0 release and pinned source tree define the version boundary for the Posnic examples.
Editorial policy
Research and correction policy explains source precedence, review dates, corrections and evidence limitations.
Continue the evaluation
Open-source POS benchmark questions
How long should an open-source POS benchmark take?
Do not set a universal one-day promise. A narrow software walkthrough may fit one session, while physical hardware, outage recovery, a production-like shift, clean restore, payment-provider approval and fiscal review require separate test windows. The deployment profile and risk owners should set the schedule.
What is the most important POS benchmark test?
There is no universal single test. A shop should identify blocking risks from business impact: inability to complete and retrieve a sale, restore data, operate required hardware, reconcile payments, produce accepted documents or exit with usable data can each stop deployment.
Should a POS benchmark use real shop data?
Start with synthetic or anonymized representative data. Use an authorized protected copy only when the test purpose requires it, with access, retention and deletion rules set before the copy is made. Never expose live cardholder or sensitive personal data merely to make a demo realistic.
Does a passing benchmark prove that POS software is secure?
No. A benchmark records acceptance against one profile and date. Source tests, a controlled runtime result, physical site acceptance, provider approval and an independent security assessment are different evidence levels and must not be presented as interchangeable.
Should open-source POS software automatically score higher?
No. Source and license rights are one control. The selected product must still pass the required release, sale, outage, permission, inventory, hardware, payment, recovery, exit, security and support tests for the actual deployment.