POS software that keeps payment, order, and settlement in step.

Custom POS software development creates or extends the software that records a sale, accepts approved tender types, updates connected systems, issues receipts, handles refunds, and reconciles settlement. It is justified when a maintained POS cannot support a distinct merchant, store, device, payment, or integration model without fragile workarounds.

Buy when an established POS supports your market, hardware, taxes, payments, inventory, reporting, updates, and service model. Build or extend when the transaction model is proprietary, the POS must sit inside a wider product, or critical integrations and operating controls cannot be configured safely.

Every RaftLabs project starts at $10000. That can fund a bounded codebase audit, device and payment proof, or transaction-state prototype. A focused production v1 is priced separately after the risky boundary is understood; cost grows with hardware, payment certification, offline acceptance, inventory depth, several locations, migration, settlement, and finance integrations.

A focused release for one operator group, payment path, device profile, and core integration starts after provider access and acceptance examples are ready. Certification, several device types, complex tax, deep inventory, or a large migration can extend the plan.

Some functions can work offline, but payment acceptance depends on the provider, terminal, market, merchant settings, risk limits, and certification. The release must define what can be stored, what cannot be promised, how retries avoid duplicates, and how uncertain transactions are reconciled when the connection returns.

Yes. A connector or operating layer is often the better first move when the POS still records store transactions reliably. We identify the authoritative records, available APIs or local data, sync frequency, mapping, failure handling, and reconciliation before deciding whether replacement is justified.

The merchant, payment provider, acquiring partners, qualified assessors, and relevant advisers determine the applicable obligations and evidence. We put the approved architecture and controls in place within the contracted scope. Software delivery alone does not make an organisation compliant or a payment product certified.

The client owns project-specific code and controls the repository, cloud accounts, transaction data, analytics, and provider relationships, subject to third-party licence and service terms. Handover includes the state model, integrations, monitoring, recovery, and operating notes another capable team needs.

Longer than the demo suggests. Production grade means peak-volume, multi-processor, audit-ready. Payment processor certifications and PCI-DSS compliance are human approval processes no tooling compresses. Plan the gap, not the demo.

PCI scope expands with every added terminal or location: the cardholder-data environment grows with each new endpoint. Build on tokenization and encryption from the start: the design decisions that keep card data out of your systems are made at architecture time, not audit time. Budget the run rate, not just the build.

Demand tamper-evident audit trails and verify the software's compliance position. Some POS products have included electronic sales suppression: the tool that hides sales from tax records. Your system must record every transaction as an explicit state (sale, refund, reversal, void), with evidence of who changed what. If a vendor cannot show the audit trail, that is the compliance position: there isn't one.

Pull the internet cable. The deciding question is whether the POS keeps selling during an outage: offline-first with cloud sync is a core requirement, not a feature. Watch the money states: does the system define sale, refund, reversal, and dispute as explicit states, or does it infer success from a loading screen? Ask who owns payment certification and how long it takes. And check the audit trail: can the system explain who changed what, or does the history disappear?

A controlled pilot comes first. We compare POS, processor, inventory, and finance records, watch failed and uncertain states, and correct defects in the agreed scope under the 60-day warranty. Later phases can add merchant groups, locations, devices, tender types, inventory, and reporting when the first path is stable.