Topic starter
18/08/2026 2:22 pm
TL;DR: SoftPOS is set to reach more than 34.5 million merchants by 2027, and Guardsquare argues that moving card-present payments onto smartphones shifts the security burden from dedicated terminals to app integrity, API protection, and runtime hardening. The governing problem is no longer just PCI compliance, but whether the app itself can resist tampering, reverse engineering, and fraud at scale.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “Why SoftPOS Raises the Stakes for Mobile App Security”.
By the numbers:
- By 2027, more than 34.5 million merchants are expected to accept payments through SoftPOS technology.
Key questions
Q: How should teams secure SoftPOS apps against tampering and reverse engineering?
A: Teams should treat the payment app as a high-value target and harden both code and runtime.
Q: Why do mobile payment apps create a higher fraud risk than many teams expect?
A: Mobile payment apps concentrate sensitive credentials, card data, and customer trust in a device that attackers can tamper with, clone, or instrument.
Q: What are the signs that a SoftPOS environment is no longer trustworthy?
A: Rooted devices, emulator use, code injection, overlays, abnormal API behaviour, and failed integrity checks are all warning signs.
Practitioner guidance
- Implement device integrity gates Block SoftPOS payment functions on rooted devices, emulators, and known tampered environments, and make the checks policy-driven rather than advisory.
- Harden the payment app against reverse engineering Use code obfuscation, anti-debugging, and tamper resistance around the payment workflow so attackers cannot easily inspect or alter logic.
- Protect payment APIs and embedded credentials Move API keys and secrets out of the mobile code path where possible, and enforce attestation before sensitive payment calls are accepted.
Bottom line: SoftPOS shifts the payment security boundary into the mobile app, where runtime conditions and device posture become part of the trust model.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:14 pm
SoftPOS creates a payment application trust problem, not just a mobile deployment problem. Once card-present acceptance moves into the app layer, the security model has to account for device integrity, runtime behaviour, and API abuse together. PCI controls remain necessary, but they no longer describe the full risk boundary. Practitioners should treat the mobile app as a privileged payment control, not as a thin presentation layer.
A question worth separating out:
Q: When should organisations prioritise runtime protection over PCI compliance alone?
A: Immediately, if the payment experience lives inside a mobile app rather than a dedicated terminal. PCI helps validate the payment kernel, but runtime protection is what limits tampering, replay, and malicious tooling in the app layer. The two are complementary, not interchangeable.
👉 Read our full editorial: SoftPOS shifts payment risk from terminals to mobile app controls