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.
At a glance
What this is: SoftPOS is moving card-present payments into mobile apps, and the article’s core finding is that security now depends on app integrity, API protection, and runtime controls rather than terminal hardware.
Why it matters: IAM, application security, and payment teams need to treat the mobile app as part of the trust boundary because device compromise, tampering, and credential abuse now sit closer to the payment flow.
By the numbers:
- By 2027, more than 34.5 million merchants are expected to accept payments through SoftPOS technology.
Context
SoftPOS moves card-present payment acceptance from dedicated terminals into a mobile application running on general-purpose devices. That changes the security boundary: the app, its APIs, and the surrounding runtime become part of the payment control plane, not just the user interface.
The governance gap is that traditional payment assurance focused heavily on terminal controls and payment kernel compliance. In a mobile-first checkout model, the app itself becomes a privileged payment component, so tampering, reverse engineering, and device compromise can directly affect merchant trust and transaction integrity.
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. That means obfuscation, anti-debugging, tamper detection, attestation, and environment checks that can disable payment functions when the device no longer meets policy. PCI validation is not enough on its own because it does not secure the surrounding app logic.
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. If controls are weak, stolen credentials, app tampering, and malware can expose transactions or keys. The operational risk is not just theft. Breach fallout can include fines, customer churn, and long-term brand damage.
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. If the app cannot prove the device and runtime are in a known-good state, the payment workflow should be treated as compromised or at least untrusted.
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.
Technical breakdown
Why mobile app integrity becomes part of the payment trust boundary
SoftPOS turns a smartphone into a payment endpoint, which means the security model has to assume hostile local conditions. The app must verify device posture, detect rooting or emulator use, and resist modification of its code or user interface. In practical terms, the trust boundary expands from the payment kernel to the entire runtime environment. If that boundary is weak, attackers do not need to break the terminal, they only need to alter the app path that carries the payment intent.
Practical implication: Treat device integrity and app integrity as payment controls, not optional security extras.
How API abuse and reverse engineering create fraud paths
When payments are mediated by app logic and service calls, attackers can target the seams between the user interface, local logic, and backend APIs. Reverse engineering can expose cryptographic flows, app logic, or hidden validation paths, while malicious tooling can replay calls, inject requests, or abuse exposed credentials. This is a classic mobile security problem, but SoftPOS raises its impact because the app is handling payment acceptance. Hardening, obfuscation, and anti-tamper controls are what make these abuse paths materially harder.
Practical implication: Protect payment APIs and embedded logic as high-value attack surfaces, not ordinary app backends.
Why runtime protection matters more than compliance alone
PCI requirements help validate the payment kernel, but they do not automatically protect the surrounding app code, secrets, or runtime behaviour. That gap matters because attackers often succeed at the application layer rather than at the payment module itself. Runtime application self-protection, anti-debugging, overlay detection, and policy-driven attestation shift detection earlier in the attack path. The technical point is simple: compliance confirms a control exists, but runtime protection helps prove the app is operating inside the expected security conditions.
Practical implication: Add runtime enforcement so payment acceptance fails closed when the app or device no longer meets policy.
Threat narrative
Attacker objective: To manipulate mobile payment acceptance at scale by abusing the app layer instead of attacking dedicated terminal hardware.
- Entry occurs through a rooted, emulated, or otherwise tampered mobile device running a SoftPOS-enabled payment app.
- Credential access and abuse follow when attackers clone the app, reverse engineer cryptographic logic, or steal merchant credentials and API flows.
- Escalation happens when malicious tooling injects requests, bypasses environment checks, or manipulates the application at runtime to enable fraudulent payment activity.
- Impact is fraudulent card-present payment processing, loss of merchant trust, and exposure of sensitive payment flows and credentials.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
App-level hardening becomes the deciding control plane for mobile payments. Reverse engineering, tampering, overlay abuse, and malicious tooling all target the logic around the payment kernel because that is where fraud can be scaled. This shifts the discipline from terminal assurance to software assurance for payment pathways. The practical conclusion is that integrity checks, anti-tamper controls, and attestation are now core governance issues.
SoftPOS also exposes an NHI-adjacent control problem in the form of exposed API credentials and machine-to-machine trust. Payment apps that embed keys, tokens, or predictable API flows create non-human identity risk even when the payment UX looks consumer simple. That means identity governance has to extend into mobile application secrets, backend authorization, and runtime policy. Security teams should govern the app as an identity-bearing workload.
SoftPOS will widen the gap between compliant and resilient payment apps. Teams that rely on certification alone will miss the practical question of whether the app still behaves securely under root access, emulation, or runtime manipulation. The market signal is clear: payment security is moving toward continuous verification of application state. Practitioners should re-evaluate whether their current controls can still prove trust at transaction time.
Mobile payment security now depends on proving the app is operating in an expected environment. That is a narrower and stricter requirement than general mobile app security, because a payment workflow can be valid only when device state, application state, and API trust all align. Teams should make runtime attestation part of payment governance, not a separate mobile concern.
What this signals
SoftPOS creates a control problem at the point where mobile convenience meets payment trust. For practitioners, that means security design has to move from terminal-centric assurance to application-centric assurance, with device posture and runtime checks enforced before payment logic executes.
Mobile app hardening now has direct governance value for payment programmes. If the app can be rooted, instrumented, or reverse engineered, the payment model inherits that weakness. Teams should align mobile security, application security, and payment governance around the same trust boundary instead of treating them as separate workstreams.
For practitioners
- 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.
- Add runtime application self-protection Monitor for overlays, hooking, injection, and malicious tooling during execution, then fail closed when the app is no longer trustworthy.
- Test SoftPOS controls under real attacker conditions Validate the payment app against rooted, instrumented, and malware-augmented test environments so protections are proven before merchant rollout.
Key takeaways
- SoftPOS shifts the payment security boundary into the mobile app, where runtime conditions and device posture become part of the trust model.
- The practical risk is not only compliance failure but also tampering, reverse engineering, API abuse, and malware-assisted fraud.
- Payment teams need controls that prove the app is operating in a trusted state at transaction time, not just controls that certify the payment kernel.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | SoftPOS app APIs and credential flows are a primary abuse path in the article. |
| Recommendation — Strengthen API authentication and attestation for payment calls before they reach backend services. | ||
| OWASP ASVS | V13 — Configuration | The article emphasises runtime integrity, rooting checks, and hostile-device conditions. |
| Recommendation — Use configuration controls to fail SoftPOS functions on rooted, tampered, or emulated devices. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-transit is protected | SoftPOS payment flows depend on protected transport and trusted exchange paths. |
| Recommendation — Protect payment data in transit and verify that mobile payment flows cannot be altered in transit. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article focuses on securing the payment app itself against tampering and abuse. |
| Recommendation — Embed security testing and hardening into the mobile payment application lifecycle. | ||
| MITRE ATT&CK | TA0006; TA0004; TA0008 — Credential Access; Privilege Escalation; Lateral Movement | The described abuse path involves credential theft, runtime manipulation, and movement into payment flows. |
| Recommendation — Map SoftPOS fraud paths to credential access and privilege escalation techniques to guide detection and testing. | ||
Key terms
- Softpos: SoftPOS is a model that lets a smartphone or tablet accept card-present payments through software instead of dedicated payment hardware. It expands flexibility but also moves trust into the device, operating system, and app runtime, where tampering, malware, and exposed credentials become direct payment risks.
- Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
- Application Hardening: The process of reducing an application’s attack surface by tightening configuration, authentication, dependencies, runtime behaviour, and monitoring. In mature programmes, hardening is continuous and linked to identity and secrets governance, not a one-time release activity.
- Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security decisions that protect modern applications and services.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org