SoftPOS in 2026: opportunities and certification realities

SoftPOS — accepting contactless card payments directly on an NFC-enabled Android phone or tablet, without any dedicated card reader hardware — has moved from novelty to mainstream deployment faster than almost any other acceptance technology in the last five years. For field sales teams, market traders and SMEs who cannot justify dedicated terminal fleets, that is a genuine unlock. It is also, technically and operationally, one of the most demanding acceptance channels to certify correctly.

What actually makes SoftPOS work

Under the hood, SoftPOS relies on the device's secure execution environment — Android's StrongBox or a comparable hardware-backed keystore — combined with software-based PIN entry directly on the device screen, commonly referred to as PIN-on-glass. The scheme kernels (the certified logic that reads and validates card data during a contactless tap) run inside an attested, monitored software environment rather than dedicated secure hardware, which is precisely why certification requirements are so much stricter than for traditional terminals.

Attestation is not optional

Every transaction needs proof that the device has not been rooted, tampered with, or run through an unauthorised OS modification. This attestation check happens before, during and sometimes after the tap, and a failed attestation must fail safely — falling back to a manual entry flow or simply declining the transaction, never silently proceeding on unverified hardware.

Certification realities that shape delivery

Scheme certification for SoftPOS — under frameworks such as the PCI Mobile Payments on COTS (MPoC) standard — covers the full chain: the kernel, the attestation library, the backend monitoring service, and the device management approach. None of these can be certified in isolation; the certifying lab assesses the whole solution as deployed.

This has a direct consequence for delivery timelines: you cannot simply integrate a SoftPOS SDK and ship. Certification cycles typically run several months, require a fixed device allow-list (not "any Android phone"), and demand evidence of ongoing security monitoring — not just a one-time audit at launch.

Delivery programme essentials

• A managed device allow-list, since certification is tied to specific hardware and OS combinations.
• A remote key injection and rotation strategy that does not require physical device handling.
• A monitoring service that can detect and respond to compromised devices in near real time.
• A clearly designed fallback UX for attestation failures — never a silent retry loop.
• A device lifecycle process covering enrolment, decommissioning and lost-device revocation.

Sequencing SoftPOS correctly

We consistently advise clients to sequence SoftPOS after a stable online acquiring core is already in production, rather than launching it as a first acceptance channel. The reasoning is straightforward: SoftPOS certification effort compounds on top of an existing, certified acquiring relationship far more efficiently than it does as a standalone first launch, where every certification question has to be answered from zero.

Teams that treat SoftPOS as "just another SDK drop-in" typically discover the gap only when a scheme mandate update requires a kernel recertification, and the engineering team has no established relationship with the certifying lab or a repeatable certification process to fall back on.

Operational considerations beyond certification

Beyond the certification programme itself, operations teams need runbooks for merchant device support — a very different support profile from a traditional terminal fleet, where a faulty device can simply be swapped. With SoftPOS, "device support" often means diagnosing OS-level issues, permission conflicts, or a merchant's own IT policy interfering with attestation.

SoftPOS success is measured in certification renewals survived, not demos delivered.

Planning for kernel and OS version churn

Android OS updates and device manufacturer changes are a continuous background risk to SoftPOS programmes in a way that traditional terminal fleets rarely face, because you do not control the device manufacturer's release cadence. A security patch that changes how the secure keystore behaves, or a manufacturer that discontinues a certified device model, can force an unplanned recertification cycle.

Mature programmes maintain an ongoing relationship with their certification lab and kernel provider specifically to track upcoming OS changes and manufacturer roadmaps, so recertification work can be scheduled proactively rather than triggered reactively by a device that suddenly falls out of the allow-list. Budgeting a standing certification maintenance capacity, rather than treating certification as a one-off project cost, is what separates programmes that scale smoothly from ones that stall every time Android ships a major release.

It is also worth maintaining a documented fallback acceptance method for merchants whose enrolled device temporarily falls out of the allow-list mid-recertification, so a single device model transition never fully blocks a merchant's ability to take payment while the underlying kernel work catches up.

Key takeaways

• SoftPOS depends on hardware-backed attestation and PIN-on-glass, not just an NFC read.
• Certification (including PCI MPoC) assesses the whole chain — kernel, attestation, monitoring, device management.
• A managed device allow-list and remote key rotation are prerequisites, not nice-to-haves.
• Sequence SoftPOS after a stable acquiring core so certification effort compounds rather than fragments.
• Plan operational support for OS-level device issues, which differ entirely from terminal hardware faults.