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 22 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.
Current Posnic release metadata points to v1.6.1, whose manifest maturity is stable, and source commit 567a176b. Reproduced Posnic examples remain pinned to an archived evidence run and archived source snapshot; they are 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.
One fixture, comparable evidence
Run the same synthetic transaction day in every POS
Feature lists are hard to compare when every demonstration uses different items and totals. This fixture gives each candidate the same four fictional items, ten ordered scenarios, expected ledger and blank observation fields.
Testing boundary
All money values use XTS, the ISO 4217 code specifically reserved for testing purposes. Prices are exclusive of the fixture's synthetic tax, line discounts apply before tax, and returns reverse the original line values. The rates are arithmetic inputs, not tax advice.
Cash and electronic outcomes are labels only. No physical cash, payment terminal, authorization, capture or settlement is exercised. Internal strings such as TST-A-001 are test barcode inputs, not GS1 identifiers.
| Sequence | Event | Scenario | Expected result |
|---|---|---|---|
| 1 | SALE-001 | Two-line cash sale | XTS 47.50 and two stock movements |
| 2 | SALE-002 | Line discounts and two synthetic tax rates | XTS 26.85 after XTS 2.97 discount and XTS 3.85 tax |
| 3 | SALE-003 | Approved electronic test label | XTS 23.75; no real payment network |
| 4 | PAYMENT-DECLINED-001 | Simulated declined payment | No sale, tender or stock posting |
| 5 | VOID-001 | Void before completion | No sale, tender or stock posting |
| 6 | RETURN-001 | Partial return | XTS -10.00 and one unit restored |
| 7 | RETURN-002 | Return with discount and tax reversal | XTS -21.60 and one unit restored |
| 8 | REPLAY-001 | Duplicate transaction replay | No second financial or stock posting |
| 9 | ADJUST-001 | Reasoned stock adjustment | One unit removed with no sale or tender |
| 10 | CLOSE-001 | Closing reconciliation | XTS 66.50 total and four exact closing-stock values |
Measured Posnic result
Eight scenarios reproduced; two controls remain unexercised
On 22 August 2026, the publisher-run harness exercised exact development snapshot 53f89a15, whose package declares version 1.4.0. Real HTTP requests and an isolated MongoDB database reproduced the three sales, two returns, duplicate replay, reasoned stock adjustment and close reconciliation. This snapshot is not represented as a tagged public release.
| Scope | Observed result | Boundary |
|---|---|---|
| Sales and returns | SALE-001, SALE-002, SALE-003, RETURN-001 and RETURN-002 matched the expected transaction values and stock changes. | Receipt rendering, printer output, physical cash and provider payment were not exercised. |
| Duplicate replay | REPLAY-001 returned the duplicate result while sale count and fixture stock remained unchanged. | This establishes the tested transaction-reference path only, not every retry source or concurrent failure. |
| Inventory adjustment | ADJUST-001 removed one unit and retained the Damage reason plus synthetic note in the stock log. | It does not establish a customer's wastage, accounting or approval policy. |
| Close | Stored sales, tender labels, synthetic tax, discounts and all four stock values reconciled to XTS 66.50; the register persisted as closed. | No physical drawer count, provider settlement or printed close report was performed. |
| Payment decline | Not exercised. | No provider or terminal was connected, and this HTTP run had no provider-decline state. |
| Pre-completion void | Not exercised. | The harness did not drive the packaged Electron basket interface. |
The JSON records the exact source commit, source and fixture hashes, environment, scenario observations, 45 assertions, limitations and database cleanup method. It is publisher-supplied controlled-runtime evidence, not independent certification, a complete fixture pass, a customer result, a security or compliance assessment, or a performance benchmark.
Supplementary source checks
Receipt bytes and basket clear now have reproducible source evidence
A separate clean run on exact development commit ac56e4a2 passed 4 of 4 focused checks and all 635 product tests. Fixture-shaped SALE-001 values traversed Posnic's shipped receipt parser and ESC/POS renderer; the shipped pre-completion clear handler emptied the synthetic basket while instrumented network methods recorded no call.
| Source path | Observed result | Boundary |
|---|---|---|
| SALE-001 receipt | The parser preserved two synthetic item lines, XTS 45.00 subtotal, XTS 2.50 synthetic tax and XTS 47.50 total. Both roll layouts stayed within their column limits and produced hash-recorded byte streams. | Fixture-shaped markup and printer bytes only; no packaged till, operating-system queue, driver, printer, paper or drawer was exercised. |
| VOID-001 clear handler | The unsaved basket ended with 0 lines and 0 instrumented network calls. | JSDOM execution of the shipped client handler only; no packaged-interface click or running-database before-and-after comparison was performed. |
| Payment decline | Still not exercised. | No provider, terminal, authorization, decline, capture or settlement path was connected. |
This supplement does not upgrade the eight-of-ten API result, complete either remaining end-to-end scenario, establish physical receipt output or support a provider-payment claim. It makes the narrower source evidence inspectable.
1. Map, do not silently simplify
Record how each candidate represents the four items, test barcodes, discounts, tax inputs, returns, decline, void, duplicate control, adjustment and close. Keep unsupported mappings visible.
2. Run in the published order
Start from the stated opening stock, execute one event at a time and retain sale IDs, receipts, tender records, stock movements, screenshots or logs. Do not preload the expected result as an observed result.
3. Reconcile before scoring
Compare each event and the closing totals with the worksheet. A difference may expose a product defect, configuration choice or fixture mismatch; investigate it instead of changing the expected file after seeing a preferred result.
The manifest publishes file hashes, rules, expected close totals and limitations. The ISO 4217 Maintenance Agency amendment is the primary source for the XTS testing code. Posnic result submissions are public observations and do not become certifications, endorsements, performance claims, compliance results or customer outcomes. This pack is not a TPC benchmark or a claim that every POS must implement the same internal data model.
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.
archived Posnic evidence example: evidence, not a winner score
| Area | Recorded Posnic evidence | Required inference boundary |
|---|---|---|
| Release and source | The stable channel lists v1.6.1; packages, recorded sizes and SHA-256 values are published. Current release source is pinned to 567a176b. Inspect release details | The manifest labels maturity stable. Windows packages are signed and timestamped; macOS packages are signed and notarized; direct Linux packages have checksums and detached GPG signatures, and the APT repository is signed. 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. |
Posnic POS archived benchmark evidence coverage
Download the full 24-record Posnic evidence disclosure as a CSV that maps every benchmark record to observed scope, direct evidence, what remains unestablished and the next required test. Coverage is not a score, customer acceptance or independent review.
The TPC-C FAQ explains why a benchmark's workload, system scope and cost model must fit the intended environment. This Posnic file applies that disclosure principle to an acceptance checklist; it is not a TPC benchmark, throughput result or price-performance claim.
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.6.1 release and current release source tree define the download boundary; reproduced examples remain pinned to archived evidence source.
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.