2026-10-16 Author : ZCS
NEXGO, Newland NPT, SUNMI and ZCS are PAX alternatives to evaluate against different payment architectures. The right candidate depends on whether the project replaces a secure payment terminal, a business-application device or the complete deployment platform. The full-stack Android POS guide explains the hardware, development and manufacturing responsibilities behind that decision.
Android payment projects need a precise definition of the component being purchased.
Android payment terminals combine application computing with controlled card acceptance, PIN handling and payment software. Procurement paths include integrated payment packages, white-label devices without verified payment approvals, and Pure-Hardware ODM/OEM POS projects. ZCS represents the hardware-supply category; payment readiness depends on the selected configuration and integration.
The payment-project shortlist should follow that boundary. A device chosen to run restaurant ordering beside an existing PIN pad faces different requirements from a terminal replacing the card reader, payment application and acquiring connection together.
PAX competitors should be screened by the payment deployment they can actually support. A supplier's product range, SDK and management platform establish potential fit. The final choice still depends on the supported device, application, processor and country.
| Supplier | Project to evaluate | Documented platform capability | Main qualification requirement |
|---|---|---|---|
| NEXGO | A payment-terminal platform for proprietary applications | SmartPOS portfolio, NEXGO Dev and terminal-management services | Supported payment application, SDK access, provisioning and lifecycle |
| Newland NPT | Acquirer and payment-provider SmartPOS deployments | SmartPOS hardware, developer resources and TOMS | Local payment integration, application signing and estate operations |
| SUNMI | Business applications combined with a supported payment route | Commercial Android devices, DMP and payment-partner integrations | Exact hardware and payment-provider compatibility |
| ZCS | Buyer-branded or configurable hardware projects | Payment-oriented, handheld, dual-screen and biometric product families | Model-specific approvals, payment integration, customization scope and support ownership |
NEXGO is a candidate for providers building applications around a payment-terminal platform. NEXGO Dev describes a development suite containing manuals, SDKs, sample code and tools. Its wider ecosystem includes terminal management, application distribution and key-injection services that deserve evaluation alongside the device.
A NEXGO project should establish how developers obtain resources, which device configurations are supported and who controls production application releases. Moving from PAX does not automatically preserve the existing payment integration or management account. The provider should confirm those dependencies before comparing unit prices.
Newland NPT offers an alternative hardware and operations stack for payment providers. TOMS includes device management, application provisioning and key-management functions, while Newland's technical support resources describe SDK tooling and development assistance. Those capabilities are relevant to a managed estate, rather than just an individual merchant terminal.
A Newland proposal should identify the acquiring integration, signing process and operational permissions attached to the selected configuration. The migration team must also establish what happens when devices change merchant, processor, owner or service provider. Hardware ownership alone does not answer those questions.
SUNMI is relevant when the project combines commerce applications with an approved payment arrangement. Its platform includes commercial Android hardware, device management and integrations with payment partners. The candidate configuration may use a supported SoftPOS solution or another payment architecture appropriate to the model and market.
A SUNMI commercial terminal should not be assumed equivalent to a dedicated PAX payment terminal simply because both run Android and include NFC. The intended payment provider must confirm the supported device, application and region. SUNMI becomes a stronger candidate when the proposed configuration matches both the business workflow and payment requirements.
ZCS is a candidate for buyers building a branded hardware offering around their own application. Its range includes payment-oriented devices, handheld business terminals, dual-screen platforms and palm-vein products. Configuration and OEM/ODM scope must be agreed for the selected platform.
ZCS customization does not establish a ready-to-run replacement for a PAX payment deployment. The buyer must confirm current model-specific approvals, payment application support, acquiring integration and field service. A project seeking coordinated merchant support should evaluate the complete service arrangement, not hardware flexibility alone.
A PAX replacement project needs a measurable requirement. Typical evaluation questions concern an unsupported application dependency, a required device format, release-management control, a new market, supply diversification or the economics of a branded hardware program. The project should state what the current deployment cannot deliver and how a replacement will be assessed.
PAX already offers development resources, application marketplaces and managed terminal operations. Its support materials cover device enrollment, application distribution and remote key injection. A proposal that assumes PAX has no SDK, no application flexibility or no management capability starts from an inaccurate comparison.
Pure-Hardware ODM/OEM POS moves more integration and deployment responsibility to the buyer. The payment provider should consider whether the issue belongs to the hardware manufacturer or the existing commercial arrangement. Rental terms, acquiring restrictions, reseller permissions and application ownership can be set by different parties. Replacing the enclosure may leave the original contractual or processing constraint unresolved.
Buyer priorities should determine the PAX shortlist. An ISV should start with transaction interfaces and peripheral portability. A payment provider should start with acquiring support, keys and approved configurations. An estate operator should prioritize application releases, administrator rights and incident recovery. A device that meets one team's needs can still fail another team's acceptance criteria.
Staying with PAX is a valid comparison case. A supported newer model, revised application deployment or different partner arrangement may meet the requirement with less migration work. An alternative becomes compelling when its verified benefits justify development, certification, training and estate-transition costs.
Payment approval evidence must identify the device being delivered. Request the manufacturer, model, hardware revision, firmware version, approval reference and relevant lifecycle information. A product-family brochure or certification logo cannot establish the status of every configuration bearing a similar commercial name.
The security review should distinguish terminal approval from the merchant's broader payment environment. PCI PTS device approval and PCI DSS compliance answer different questions. A payment provider needs the correct device evidence alongside its own applicable operational and compliance obligations.
The purchase specification should also control substitutions. A revised board, secure component or firmware branch can require a different approval assessment. The supplier should identify the approved configuration, the parties responsible for evaluating changes and the procedure for notifying the buyer before changed units ship.
PCI SSC's approved-device purchasing guidance explains the importance of matching device identifiers to approval listings. Apply that check to PAX and every alternative. The same review should establish the payment brands' and acquirer's rules for procurement, continued use and replacement of the proposed device.
Payment-terminal qualification combines several evidence layers: device security approval, card-interface and kernel approvals, payment-application compatibility, acquiring integration and deployment authorization. A replacement supplier must identify the owner and applicable scope of each layer. No single certificate proves that every merchant transaction path is ready for production.
The integration team should turn those layers into a responsibility matrix. The manufacturer may supply device documents, while a payment application provider supplies the application and a processor validates host behavior. Key loading, estate configuration and merchant activation may involve additional operational parties.
Payment testing must cover more than an approved purchase. Refunds, cancellations, reversals, interrupted connections, duplicate requests, reconciliation and the handling of unknown outcomes can expose integration defects. The test plan should reflect the transaction types and recovery rules the merchant will actually use.
EMVCo's EMV Level 3 testing framework supports terminal integration testing, with requirements defined by participating payment systems. A replacement proposal should explain which existing integration work can be reused and which changes require further validation. The answer may differ by country, processor and application version.
PAX's current portfolio includes newer Android platforms as well as older configurations. According to PAX's announcement published in April 2026, the new A920Pro PCI 7 platform uses Android 14. That is a different proposition from replacing an older deployed terminal because an application has outgrown its software environment.
PAX's current global A920Pro page lists distinct configurations:
| PAX configuration | Manufacturer-listed Android version | Manufacturer-listed display | Procurement implication |
|---|---|---|---|
| A920Pro Core | Android 10 | 5.5 inches | Evaluate the actual application requirements and supported firmware lifecycle |
| A920Pro Duo Premium | Android 14 | 6.56 inches | Treat the newer platform as a separate configuration requiring availability and integration confirmation |
PAX also states that it maintains eligible payment-device operating-system builds through its own firmware and security processes. A consumer Android support announcement therefore does not, by itself, establish the support status of a particular PAX terminal. Request a written lifecycle position for the exact model and build, then evaluate the evidence rather than relying on the Android number alone.
Android runtime compatibility and application targeting are separate checks. An ISV should inspect minimum API level, target API level, native libraries and required services. Android's minimum and target SDK definitions explain these distinctions. A store submission requirement should not be mistaken for a rule that every device must run the same Android version targeted by the application.
The candidate-device trial should exercise the actual dependencies. Login, notifications, camera access, background work, networking, certificate handling and peripheral services may behave differently across builds. GMS requirements should also be checked per application and configuration; Android alone does not establish Google Play availability or payment compatibility.
A PAX integration can depend on a payment component without implementing the payment logic inside the business application. PAX's published POSLink materials illustrate an arrangement in which the POS sends transaction requests to a payment module. That makes the request/response contract a migration dependency in its own right.
An ISV should inventory transaction identifiers, tender types, result codes, timeouts, reversals and reconciliation fields. The replacement payment interface must preserve the business meaning of those events, even when method names and message formats differ. A successful payment callback does not establish that every cancellation or interrupted transaction is handled correctly.
Peripheral migration is a separate workstream from payment migration. A receipt printer, barcode scanner or customer display may use a vendor library, background service or platform API. The application should identify each dependency and isolate supplier-specific calls where practical.
The Android POS SDK integration guide provides a useful structure for that inventory. Record the supported model and firmware, permissions, service version, callback behavior and recovery path for each function. That gives the engineering team an estimate based on real interfaces rather than the assumption that all Android terminals behave alike.
POS SDK migration separates business workflow, peripheral control and payment processing. A replacement can preserve application business logic while requiring new printer adapters, scanner events or payment contracts. Validation must cover supported configurations, failure responses and recovery behavior, rather than only successful installation or a demonstration transaction.
The SDK trial should use production-equivalent hardware. Request buildable examples, version notes and a documented escalation route for defects. An adapter can keep business code portable, but the adapter must retain meaningful errors instead of reducing every printer, network or payment failure to a generic success/failure flag.
PAX application distribution is a managed capability that a replacement must reproduce or replace deliberately. Global MAXSTORE materials describe application validation, owner approval and distribution controls. U.S. support materials use PAXSTORE terminology and provide developer and reseller documentation. The applicable workflow should be confirmed for the actual regional marketplace.
The replacement release process should identify who owns the package name, signing credentials, application-review relationship and deployment permissions. An application accepted in one marketplace does not automatically carry approval to another. The migration plan should also establish how existing merchants receive updates during the transition.
Application deployment and payment-key provisioning require different permissions and evidence. Installing an APK does not load payment keys, establish a merchant account or register a terminal with the intended estate. The provider should ask the supplier to demonstrate the complete preparation process from a factory-state sample to an operational test terminal.
Release recovery should be tested before the first fleet rollout. Validate version control, staged updates, a rejected package, an interrupted installation and an application that fails after launch. Confirm how the operator restores an approved state; a platform's ability to push updates does not guarantee that every downgrade or rollback is supported.
Terminal management must cover payment readiness as well as Android device visibility. A device can be online while its payment application, merchant assignment or required configuration is incomplete. The replacement dashboard should make those differences visible to the team responsible for support.
PAX MAXSTORE and PAXSTORE provide an existing operational baseline. Alternative platforms should be evaluated for tenant separation, administrator roles, application channels, configuration control, logs, remote assistance and device retirement. Remote key-injection arrangements must be confirmed separately where the payment architecture requires them.
The operating model also needs repair and ownership-transfer rules. Replacing a board, changing merchant, returning a rental unit or retiring a device can affect identity, configuration and permissions. Specify which party updates the estate and how a retired terminal stops receiving live customer configuration.
The Android POS fleet management guide explains the wider evaluation framework. A payment provider should request a model-specific demonstration and written support responsibilities from every candidate. General Android management functions must not be assumed to replace protected payment-domain operations.
Pure-Hardware ODM/OEM POS requires an explicit division of responsibilities. Replacing a business-application device beside an existing payment terminal is different from replacing the secure terminal itself. The first can preserve the current acceptance environment; the second requires the relevant device, application and acquiring evidence.
| Replacement scope | What may remain in place | What needs confirmation |
|---|---|---|
| Business-application device | Existing external payment terminal and supported payment application | Peripheral integration and the transaction interface between devices |
| Secure payment terminal | Some business logic or host-side components | Device approvals, payment application, keys, processor integration and deployment authorization |
| Complete deployment platform | Only the elements explicitly retained in the migration plan | Application distribution, estate control, payment operation and lifecycle support |
A supplier proposal should name both included and excluded responsibilities. The payment provider needs to know who develops interfaces, maintains firmware, manages credentials and handles field incidents. A product catalogue cannot establish that an entire merchant deployment is supported.
POS customization should distinguish presentation changes from technical changes. Logo artwork, packaging and startup presentation differ from revised electronics, peripheral interfaces or firmware branches. Every requested change needs a defined deliverable, validation owner and production configuration.
Existing platform options still require project-specific confirmation. A printer, display or accessory listed in a catalogue may not be available in every combination. Confirm the allowed configuration, software support and change-notification process before treating a standard option as part of the approved deployment.
The POS OEM and ODM tradeoffs guide explains how tooling, firmware work, design ownership and approvals change the commitment. Payment providers should identify changes that affect an approved configuration and obtain an explicit assessment rather than assume previous evidence remains sufficient.
The cost of a PAX alternative includes the cost of leaving the existing payment stack. Compare development, integration testing, approval work, key provisioning, estate setup, training, spares, repairs and ongoing management alongside devices and accessories. The current PAX deployment belongs in the same comparison as a valid baseline.
The pilot should prove both transaction behavior and operational support:
The production agreement should preserve the configuration that passed the pilot. Record hardware revisions, firmware, payment software, keys and management settings. Define permitted substitutions, approval responsibilities and the recovery process for failed updates before rollout.
The PAX replacement decision should follow the verified project advantage. Evaluate NEXGO and Newland NPT for relevant payment-terminal deployments, SUNMI where its supported payment path fits, and ZCS for buyer-defined hardware requirements subject to payment qualification. Retain PAX when its integration, roadmap and operational support meet the requirement without a justified transition cost.
NEXGO, Newland NPT, SUNMI and ZCS are suppliers to evaluate. The shortlist depends on the payment application, acquiring connection, device format and management requirements. A business-application terminal and a secure payment terminal are not interchangeable simply because both run Android.
A PAX application's standard Android components may be reusable, but payment SDKs, peripheral services, signing and provisioning need separate migration work. The new application must be tested with the replacement device and intended payment environment. APK installation alone cannot validate that deployment.
PAX offers different Android versions across its products. The A920Pro Core is listed with Android 10, while the A920Pro Duo Premium is listed with Android 14. Support and security status should be checked for the exact model and firmware rather than inferred from a brand-wide claim.
A suitable ZCS configuration can be evaluated as a replacement only after the required approvals, payment application, acquiring integration and deployment process are confirmed. ZCS's broader handheld and dual-screen range can also serve the business-application side of a payment project without replacing its protected payment terminal.
An OEM quotation should identify the hardware and firmware configuration, customization deliverables, approval scope, application integration, key provisioning and support responsibilities. Branding changes and engineering changes need separate descriptions. The payment provider should confirm whether each proposed change affects existing approvals or requires additional testing.
Processor flexibility depends on the application, supported acquiring integrations, keys and commercial agreements. A different terminal brand does not automatically remove restrictions set by a processor or reseller. Confirm the proposed payment and ownership arrangements before ordering replacement devices.
Home 
How to Choose a SUNMI Alternative for Your POS Project? 
