SoftPOS Architecture: Contactless EMV on Commodity Phones, PCI MPoC and Attestation

A traditional payment terminal is a small fortress. It has a tamper-responsive enclosure, a certified secure processor, a hardware keypad that never touches an operating system, and keys injected in a controlled facility. A phone has none of that. It runs an operating system that the user can root, apps that can draw overlays on top of each other, and a screen that any malware with the right permission can record. Yet in 2026 millions of merchants take card payments on exactly that device.

That is the central puzzle of SoftPOS architecture: how do you move the trust boundary from a sealed box to a general-purpose computer? The answer is not one trick. It is a layered system in which a contactless kernel reads the card, an SDK encrypts the data in a hardened app, a backend continuously judges whether the phone is fit to transact, and key release is gated on that judgment. This post walks through each layer, the PCI standards that govern them, how Apple and Android differ, and where the design breaks.

What this covers: the reference architecture for tap to pay on phone, the EMV kernel and cryptography, attestation and monitoring, PIN-on-glass, key management, the acquirer path, the threat model, platform specifics, and failure modes.

Non-advisory notice: this article describes systems architecture and published standards for educational purposes. It is not legal, compliance, security-certification or financial advice. Verify current requirements with PCI SSC, EMVCo, your acquirer and your assessor.

Context and Background

Card acceptance on consumer devices evolved in three phases. First came mobile point of sale (mPOS): a phone or tablet paired with a small external dongle that did the actual card reading and PIN capture. The dongle carried the certified hardware, so the phone was merely a display and a network pipe. This is the model most of the industry used for roughly a decade.

The second phase removed the dongle. SoftPOS, also marketed as Tap to Phone, Tap to Pay or contactless-only acceptance on COTS (commercial off-the-shelf) devices, uses the phone’s own NFC antenna to read the card. Because there is no certified hardware in the loop, the security has to come from software, from the platform’s secure hardware where it exists, and from a remote monitoring service.

The third phase is the standards consolidation. PCI SSC (the PCI Security Standards Council) originally published two separate standards: SPoC (Software-based PIN Entry on COTS), which let a phone accept PIN entry together with a certified external reader, and CPoC (Contactless Payments on COTS), which covered contactless-only acceptance on the phone. Their successor is MPoC, Mobile Payments on COTS. According to the PCI SSC MPoC page, MPoC combines many aspects of SPoC and CPoC, is modular and objective-based, and supports PIN and contactless acceptance on the same COTS device. Version 1.1 was announced on 26 November 2024.

The transition has dates. A PCI SSC bulletin states that a sunset period for SPoC and CPoC began on 1 May 2026 and ends on 31 October 2026, after which PCI SSC stops accepting new SPoC and CPoC submissions. Existing listings are not withdrawn by the sunset; they remain valid through their normal lifecycle and expiry dates. As of this writing (9 November 2026), new solutions are therefore evaluated against MPoC, while older CPoC-listed solutions, including some in production on phones today, continue to run until their listings lapse.

Two related posts cover adjacent ground. The card tokenization and PCI DSS vault architecture post describes what happens to a card number after it reaches the back end, and the network tokenization architecture post covers the wallet side: why a tapped Apple Pay or Google Pay credential arrives as a device token and a cryptogram, not as a raw card number. This article sits in front of both. It is about the first centimetre of the journey, from the card’s antenna to the first encrypted byte leaving the phone.

The thesis: attestation is the new tamper switch

Most explainers present SoftPOS as “an app plus an SDK.” The more useful framing is that SoftPOS replaces a physical security property with a continuous, remote one. A terminal’s tamper switch erases keys the instant a case is opened. A phone has no such switch, so the architecture substitutes a loop: the device repeatedly proves its state to a backend, the backend decides, and the keys that make card data useful are released only while the proof is fresh and acceptable. The security of the whole system is therefore bounded by two things: the quality of the evidence the platform can give, and the discipline of the policy that reads it. Everything else in this post hangs off that idea.

SoftPOS Reference Architecture

At a high level, SoftPOS architecture has five cooperating parts: the contactless reader and kernel on the phone, the MPoC application and SDK that wrap it, an attestation and monitoring (A&M) backend, a key-management service, and the acquirer or payment service provider (PSP) gateway that turns the encrypted payload into an authorization message. Card data is protected from the first moment it is read; the merchant’s own app is deliberately kept outside the trust boundary.

Figure 1: Reference SoftPOS architecture. Card data flows left to right and is encrypted before it leaves the phone; the attestation backend decides whether keys are released.

The diagram shows two parallel flows. The data path runs from the card through the phone’s NFC controller and contactless kernel into the MPoC software, then out as an encrypted payload to the PSP and onward to the card network and issuer. The control path runs between the MPoC software and the attestation and monitoring backend, and it ends in a decision about whether the PSP can decrypt what it received. Keeping those two paths distinct is the key to understanding why a compromised phone cannot simply be used to harvest cards.

The contactless reader and kernel

The first component is the reader function. The phone’s NFC controller exchanges ISO/IEC 14443 frames with the card or a wallet’s emulated card. On top of that sits the EMV contactless stack, which EMVCo publishes as a family of books. According to the EMVCo contactless pages, EMV Contactless refers to Book A, Book B and Book C-X. Book B is the Entry Point specification, and each payment system publishes its own kernel specification as a Book C-X. EMVCo itself publishes Book C-8, designed as a kernel specification that can be licensed directly from EMVCo. At the time of writing, EMVCo lists Book B at version 2.12 and Book C-8 at version 1.2, both dated 6 July 2026.

The division of labour matters. Entry Point is the traffic cop: it builds the candidate list of applications on the card, matches them against what the reader supports, and selects the kernel that will run the transaction. A kernel then owns the rest of the card conversation: it requests and parses card data, performs offline data authentication where applicable, applies terminal risk rules and cardholder verification logic, and requests a cryptogram from the card. The common mapping, which is general industry knowledge rather than something stated on the page above, is that C-2 is Mastercard, C-3 Visa, C-4 American Express, C-5 JCB, C-6 Discover and C-7 UnionPay.

The MPoC application and SDK

The second component is the software that exposes the kernel to a merchant. The security properties of MPoC come from the fact that this software is evaluated, not the merchant’s point-of-sale app. In Visa’s Tap to Phone documentation for Android, for example, the MPoC application (a separate “Tap to Pay Ready” app) does the payment processing, while the merchant’s own POS app starts each transaction and hands off to it, so changes to the evaluated components need no change in the merchant app. That is a representative pattern: the payment-handling code is a small, hardened, separately versioned unit.

An alternative is the embedded SDK pattern, where the evaluated library is linked into the merchant’s app. This is more convenient for the merchant but enlarges the attack surface, because the host app’s code now shares a process with the payment logic. MPoC v1.1 explicitly acknowledges a variant here: it permits non-isolating SDKs so that the MPoC application can manage secure channels, and it allows one MPoC SDK to integrate another.

Attestation, monitoring and the key gate

The third component is the A&M backend. A Keysight overview of MPoC describes the logic well: because COTS devices lack hardware-backed guarantees, attestation and monitoring continuously judge whether a device is fit to transact. The exact mechanics are the subject of a later section. For now, hold on to the shape: the phone sends evidence, the backend returns a verdict, and a separate key service uses that verdict to decide whether to let the PSP decrypt.

The PSP and acquirer gateway

The final component is the gateway that receives the opaque payload. In a certified SoftPOS solution the merchant never holds card data in clear form, and the PSP typically requests decryption material from the solution provider. The PSP then builds an ISO 8583 or equivalent authorization message and sends it to the acquirer’s switch. The ISO 8583 vs ISO 20022 card messaging post describes that downstream message format.

Trust boundaries in one sentence each

The card and issuer are trusted by the network. The kernel and SDK are trusted to the extent that they were evaluated and are verified at runtime. The operating system is treated as hostile but observable. The merchant app is treated as untrusted. The backend is trusted and runs under PCI DSS-grade controls. This stance, hostile host and trusted backend, is what separates SoftPOS from an ordinary mobile app handling a card number in a text field.

Deeper Analysis: From Tap to Authorization

The transaction path has three stages that matter for architecture: the contactless EMV exchange between phone and card, the sealing of the result into a payload only the PSP can open, and the attestation loop that gates that opening. Each stage adds a constraint the dedicated terminal never had to think about, because on a terminal all three happened inside one certified boundary.

The contactless EMV exchange

When the cardholder taps, the reader first powers the card’s field, then selects the Proximity Payment System Environment (PPSE) to list the payment applications present. Entry Point matches those against the reader’s configuration and chooses a kernel. The kernel issues a GET PROCESSING OPTIONS command, reads the records it needs, and then asks the card to generate an application cryptogram. For an online authorization, the card returns an ARQC (authorization request cryptogram) that only the issuer can verify with a key derived from its issuer master key.

Two details shape the architecture. First, contactless EMV is built around speed: the specifications aim at a tap that completes in a fraction of a second, so the phone must keep the NFC session stable while the kernel runs. Phones that dim or throttle the NFC controller under power saving, or that place the antenna where cases interfere, fail here, and the failure shows up as “tap again” friction, not as a security event. Second, the data the kernel returns is exactly what a card-present authorization message needs: the PAN or token, expiry, cryptogram, application transaction counter, and the terminal verification results. A wallet tap (Apple Pay or Google Pay) returns a device-specific token and a dynamic cryptogram, so the merchant’s side never sees the underlying PAN; see the network tokenization post for how the token is resolved.

Sealing the data: encrypt in the trusted component, decrypt in the PSP

The central protection is that card data is encrypted as early as the platform allows and stays encrypted until it reaches the PSP’s decryption service. Apple’s Platform Security guide describes this clearly for Tap to Pay on iPhone: the Secure Element hosts the payment applets and kernel configurations, the SE takes control of the NFC controller during a read so card data moves only between the card and the SE, and after the tap the SE encrypts and signs the card data. It stays encrypted and authenticated until it reaches the PSP, and the PSP must request a decryption key from the Tap to Pay server. The server releases the key only after validating the data’s integrity and authenticity and confirming the read happened within 60 seconds of the request, and only the PSP that initiated the read can decrypt it.

Figure 2: Tap to pay on phone sequence. The merchant app only ever handles an opaque payload; the PSP obtains a decryption key from the key service, which checks freshness first.

The sequence reads naturally in plain language. The merchant app starts a read with an amount. The reader session runs the kernel and returns an opaque encrypted payload. The app forwards that payload to its PSP backend. The PSP asks the key service for the decryption key, the key service checks that the payload is authentic and recent, and only then does the PSP decrypt and construct the authorization request. The merchant’s app is a courier carrying a sealed envelope.

This pattern is the same, in spirit, as the field-level and envelope encryption described in the envelope encryption and KMS/HSM key management post. The difference is where the encryption key lives. In a classic terminal it lives in a tamper-responsive device. In SoftPOS it lives either in the phone’s secure element (Apple), in a trusted execution environment or protected storage, or, in the weakest platform case, in software protected by white-box cryptography and obfuscation. The Keysight overview lists cryptography and key management, including key generation, injection, storage, rotation and white-box implementations, as one of the evaluated areas, which tells you the standard expects implementers to defend keys even where hardware roots are thin.

Store and forward and its consequences

Some deployments, for example market stalls or events with poor connectivity, need offline acceptance. Apple documents a Store and Forward mode: encrypted card data is stored temporarily on the iPhone, the PSP can request the decryption key for up to 14 days after the read, SE encryption protects the data while stored, and PIN entry is not supported in this mode. The architectural point is that offline acceptance converts a real-time authorization into a deferred one. The merchant is shipping an unauthorized claim, and the issuer may decline when it finally arrives. That is a business risk the acquirer must price, with floor limits and velocity controls, and a fraud-detection pipeline like the one in the real-time fraud detection architecture post must treat late-arriving data differently.

Attestation and Monitoring: Replacing the Tamper Switch

Attestation and monitoring is the mechanism that gives a general-purpose phone something like a terminal’s tamper response. The phone repeatedly submits signed evidence about its own state, the backend evaluates that evidence against policy, and key release, transaction limits or the ability to use PIN entry all depend on the verdict. It is a feedback loop, not a one-time check at install.

Figure 3: Attestation pipeline. Evidence about the device, app and runtime is bound to a fresh nonce, scored by a policy engine, and mapped to one of three outcomes.

What the evidence looks like on Android

On Android, a common building block is Google’s Play Integrity API, although MPoC solution providers may combine it with their own checks. The Play Integrity verdict documentation describes a JSON verdict with request details, account details, app integrity, device integrity and optional environment details. The server is told to verify the request details first (package name, request hash or nonce, timestamp) so a token cannot be replayed for a different request.

The device label is tiered. MEETS_DEVICE_INTEGRITY indicates a genuine, certified Android device; on Android 13 and later this implies a locked bootloader and a certified manufacturer image. MEETS_STRONG_INTEGRITY additionally requires security updates within the last year for the OS and vendor partitions on Android 13 and later. MEETS_BASIC_INTEGRITY is weaker and may pass on a device with an unlocked bootloader. Optional environment signals include an app-access-risk verdict, which lists other apps that could capture the screen, control the device or draw overlays, and a Play Protect verdict. Google’s own guidance is to avoid relying on a single label and to treat unevaluated or missing fields as a risk signal, not a pass.

That tiering maps neatly onto payments. A processor can require the strong label for PIN-capable acceptance, accept the device label for contactless-only low-value taps, and refuse basic-only devices. Stripe’s help page for Tap to Pay on Android is a concrete example of one provider’s rule: the device must have received a security patch within the last 12 months, and a device with an older patch is blocked with an error until it is updated or replaced. This is a vendor policy rather than a universal MPoC requirement, but it shows how a verdict becomes a business rule.

Why attestation is necessary but never sufficient

The honest limitation is that attestation tells you about a snapshot. A verdict says the device looked healthy when the token was minted. An attacker who compromises the device a second later, or who uses a legitimately attested device with a remote-control app that is not flagged, can still abuse the session. That is why MPoC treats monitoring as continuous and why the standard expects detection and response for compromised platforms; MPoC v1.1 includes clarified requirements in exactly that area.

Four design rules follow:

Bind everything to a nonce. Evidence must be tied to a specific transaction or session so it cannot be replayed.
Keep verdicts short-lived. A long-lived “trusted” flag is a standing vulnerability. Release keys per session or per transaction and expire them quickly.
Degrade, don’t just block. A device that fails only a soft check can be restricted to lower amounts, contactless-only, or no PIN, which limits revenue loss from false positives.
Feed the verdicts into fraud scoring. A cluster of transactions from a device that just flipped from healthy to degraded is a strong risk feature.

The Apple approach: hardware roots instead of a verdict API

Apple’s design leans on hardware. Per Apple’s documentation, the Tap to Pay servers manage provisioning of payment kernels and monitor device security in a manner compatible with the PCI MPoC standard. On first use the server checks eligibility, including the device model, iOS version and whether a passcode is set. Applets and kernel configurations are downloaded and installed on the Secure Element over a secure channel, and the SE validates their integrity and authenticity first. Apple’s page does not use the word “attestation” for this, so this article describes it as eligibility checking plus integrity validation. The developer framework is ProximityReader: it requires coordination with a participating PSP that is Level 3 certified and an Apple-granted entitlement, and the documentation notes that Tap to Pay on iPhone follows the PCI CPoC standard, using Level 2 certified payment kernels. That note is itself a good illustration of the sunset transition: the documentation as fetched still refers to CPoC even as PCI SSC steers new evaluations toward MPoC.

PIN-on-Glass, Key Management and the Acquirer Path

Contactless-only acceptance covers most small-ticket payments, but PIN is unavoidable in several situations: a card may demand cardholder verification above the contactless CVM limit, an issuer may request a PIN after too many consecutive taps, and some markets require PIN for higher values. SoftPOS therefore needs a PIN-on-glass capability, meaning the cardholder types the PIN on the same touchscreen the merchant is holding.

Why PIN on a touchscreen is the hardest problem

A hardware PIN pad is physically tamper-resistant, and its keypad lines feed a secure processor directly. A touchscreen is shared with the operating system. Any malware with accessibility permissions, an overlay or a screen-recording capability could observe taps, and a malicious app could place an invisible layer that records coordinates. The mitigations are layered. The PIN entry UI is drawn by the evaluated component, not the merchant app, and it randomizes or otherwise protects the keypad layout in ways the standard evaluates. The device is checked for overlay and capture risks before PIN is allowed. And the PIN is encrypted into a PIN block immediately, using a key the merchant cannot access.

Apple’s design shows one concrete implementation. According to its security guide, the PIN prompt can appear right after the tap, or the PSP can trigger it with a signed token valid for one transaction. The Secure Element captures the PIN digits and creates an encrypted PIN block, and the PSP needs a separate server-issued key to decrypt it. Apple says it does not decrypt or store PINs, the merchant cannot access them, and the feature is designed to block photos, videos, screenshots and screen recordings during entry. An optional Screen Lock setting locks the merchant device during PIN entry, requiring Face ID, Touch ID or passcode to resume. MPoC v1.1 also updated PIN entry requirements, including accessible PIN entry and PIN entry on external devices, which signals that the standard accommodates a split model where a certified external reader (SCRP-style devices in the earlier SPoC world) handles PIN for higher assurance.

Key hierarchy

Payment key management is conservative, and SoftPOS keeps the same hierarchy with an adaptation at the leaf. In classic terminals, a DUKPT (Derived Unique Key Per Transaction) scheme derives a unique key for each transaction from a base derivation key held in the acquirer’s HSM and an initial key injected into the terminal. SoftPOS cannot inject a key in a secure facility, so keys must be provisioned remotely. That is only acceptable if the provisioning channel is itself authenticated and the receiving environment has been attested at that moment. This is why the provisioning step and the attestation step are bound together in practice, and why the standard treats key generation, injection, storage and rotation as a single evaluated area.

A practical hierarchy has four tiers:

Root and wrapping keys in an HSM. These live in the solution provider’s or PSP’s hardware security module. MPoC v1.1 notes that FIPS 140-2 Level 2 HSMs are permitted if used in controlled environments, so the exact HSM level is part of the compliance conversation.
Per-device or per-session keys. Derived or issued after attestation, scoped to one device installation, and rotated on a schedule or on suspicion.
Per-transaction data keys. Used to encrypt the payload so one compromised transaction does not expose others.
PIN keys. Kept separate from data keys so a data-key compromise does not leak PINs.

The general key-management patterns are covered in the envelope encryption and KMS/HSM article; the SoftPOS-specific twist is the gate. A key service that releases a decryption key only when evidence is fresh turns a stolen payload into a worthless blob.

The acquirer and processor flow

After decryption, the PSP assembles an authorization message. The flow is conventional from this point:

The PSP builds an ISO 8583 style authorization request (or its API equivalent) containing the PAN or token, EMV data elements including the cryptogram, the POS entry mode indicating contactless chip, the amount and merchant identifiers.
The acquirer’s switch routes it to the card network, which routes it to the issuer. The card authorization switch and issuer processing post covers the issuer side of this hop.
The issuer validates the ARQC with its derived key, runs its risk rules and returns approve or decline, possibly with an ARPC for the card to verify.
The response returns through the same path to the merchant app within the expected latency budget.

The commercial structure around that path is its own topic. Many SoftPOS merchants onboard through a payment facilitator rather than directly with an acquirer; the PayFac vs ISO vs merchant of record comparison explains how liability and settlement differ. Interchange for contactless card-present tends to be lower than for card-not-present, which is part of the economic case, though the specific rates depend on region and scheme and are not covered here.

Device Threat Model and Defences

A security architecture is only as credible as its threat model. For SoftPOS the adversaries are the merchant themselves (collusion or fraud), malware on the merchant’s phone, a remote attacker abusing the backend, a malicious customer, and an attacker who steals a phone. Each maps to a specific control.

Figure 4: Threat-to-control map for contactless acceptance on commodity phones. Each defence is partial, and the layers are meant to overlap.

Rooted, hooked or instrumented devices

A rooted device lets an attacker read process memory, hook functions at runtime and patch the app. The defences are runtime application self-protection, obfuscation and anti-tampering in the SDK, plus attestation that refuses devices that fail integrity checks. The Keysight overview says evaluators test mobile apps and SDKs for tamper resistance, obfuscation, runtime protection and resistance to rooting, hooking and instrumentation. These are evaluated, but no software defence is absolute; the intent is to raise the cost of attack and to detect it quickly.

Screen capture, overlays and accessibility abuse

For PIN entry, overlays and screen capture are the headline risks. Android’s environment verdict can list apps that could capture the screen, control the device or draw overlays, and a SoftPOS provider can refuse PIN entry when such apps are detected. The standard approach is “fail closed for PIN, fail soft for contactless-only”: a risk signal that blocks PIN entry should not necessarily block a low-value tap.

Relay and skimming attacks

Contactless transactions can be targeted by relay attacks, in which a fraudster forwards the NFC conversation between a victim’s card and a distant reader. Kernel-level timing checks and issuer-side velocity and amount limits are the standard controls; neither is specific to SoftPOS, but a phone reader adds a twist because the “merchant” can be a compromised device acting as a relay. The backend therefore monitors for implausible patterns such as many distinct cards in a short window on one device, which is where the verdict feed into fraud scoring pays off.

Backend abuse and insider risk

The backend is the crown jewel, because the keys live there. Controls include HSM-protected key hierarchies, segregation of duties, per-PSP key scoping (Apple states that only the PSP that initiated the read can decrypt it), and PCI DSS compliance for the infrastructure; Apple states its Tap to Pay servers are PCI DSS compliant. A rotating-key, short-window design limits blast radius even if a payload is exfiltrated. The same pattern appears in IoT fleets, where a device proves its state before it receives secrets; the TPM 2.0 remote attestation post shows the hardware-rooted version of the loop that SoftPOS approximates in software.

Platform Specifics: iPhone, Android and Everything Else

The two mainstream platforms make different trade-offs, and an architect choosing a provider should understand them.

iPhone

The iPhone path is vertically integrated. Apple controls the NFC controller, Secure Element, kernels and the server that provisions and monitors them. As covered, card data stays inside the SE, the key is released by an Apple server to the initiating PSP, and merchant developers use the ProximityReader framework with an entitlement and a Level 3 certified PSP. The upside is a strong, uniform security posture across a small number of device models. The downsides are that integration depends on Apple’s roadmap and region availability (check Apple’s current country list, which this article does not enumerate), that developers have less visibility into the monitoring decisions, and that the sunset notes above make the compliance wording in some documents trail the standards.

Android

Android is a heterogeneous ecosystem: thousands of device models, different NFC chipsets, different update cadences and different hardware-backed key stores. The SoftPOS provider therefore carries more of the burden. It must maintain a device compatibility list (providers publish device requirements, as Visa’s Android compatibility page and Stripe’s patch policy illustrate), integrate Play Integrity or an equivalent, rely on hardware-backed key storage where present, and fall back to software protection where it is not. Result: more variance in assurance and a larger policy surface, but far greater device reach, which matters in markets where the iPhone is a minority.

Wallet and ecosystem effects

A tap from a wallet carries a token and a dynamic cryptogram, and the phone-to-phone case adds a wrinkle: the same device model can be both the customer’s wallet and the merchant’s reader. The reader function and the card emulation function use the same NFC controller but not at the same time, and providers generally prevent a phone from being its own cardholder through policy and routing checks. For the broader ecosystem of NFC credentials beyond payments, such as digital keys, the Aliro digital key standard post gives a useful contrast: the same radio, but a different trust model.

Where 3-D Secure fits (and does not)

SoftPOS is a card-present channel, so 3-D Secure, which authenticates card-not-present e-commerce, is not part of this flow. The distinction is worth stating because readers sometimes conflate “tap” with “authentication.” In card-present contactless, the authentication is the card’s cryptogram plus any PIN or device CVM; in e-commerce it is the issuer’s 3DS challenge, described in the 3-D Secure 2 and SCA flow article.

Trade-offs, Gotchas, and What Goes Wrong

False positives are a revenue problem. Every attestation rule that blocks a device also blocks a merchant. A strict patch-age rule, like the 12-month policy described above, will lock out legitimate users on budget phones whose manufacturers stopped issuing updates. Providers therefore publish compatibility lists and tolerate some degradation modes. Treat the false-positive rate as a product metric, not just a security one.

Verdict fatigue and outages. If the attestation service or the platform’s integrity API is unavailable, the system must decide whether to fail open or fail closed. Failing closed stops all sales for every merchant; failing open silently removes the control. A bounded offline grace window, with lower limits and no PIN, is the usual compromise, but it must be designed and tested, not discovered in an incident.

Staleness in store-and-forward. Apple’s 14-day key window and 60-second online freshness check illustrate the tension. Longer windows help merchants in poor coverage areas but widen the exposure and the decline risk. Document the window to the merchant, and monitor the decline rate on deferred batches separately.

Kernel and configuration drift. Schemes update kernel specifications and CAPKs (certification authority public keys) periodically. EMVCo’s own page shows revision activity, including a Book B update and a C-8 update in July 2026, and a scheme bulletin for C-4. A SoftPOS provider must push configuration updates to a fleet of phones, which is a deployment problem in its own right. A device that missed an update can fail to read newer cards or, worse, accept a card against stale risk parameters.

Compliance is not a switch you flip. Using a certified SDK does not make the merchant’s whole system compliant. The PCI SSC page notes that payment brands manage compliance programs, so whether a merchant must use a listed solution is a question for the brands and the acquirer. PCI SSC encourages merchants and acquirers to select a PCI-listed MPoC solution, and a component listing (an SDK, say) does not by itself permit live deployment according to the Keysight overview. Check the listing’s scope: which platforms, which versions, which regions, which CVM options.

The phone is still a phone. Battery saver, NFC toggles, cases, screen protectors with metal, OS updates that change NFC behaviour and background process limits all produce real-world tap failures. These rarely show in lab certification but dominate support tickets. Instrument tap-to-authorization latency and failure reasons from day one.

Anti-pattern: treating the merchant app as trusted. Any design that lets the merchant’s own code see the PAN or PIN has missed the point of the architecture. Equally, an app that logs raw payloads or sends them to an analytics SDK can leak what the architecture protects. Audit logging pipelines for opaque payloads as strictly as for card data.

Anti-pattern: one-time attestation at login. A single check when the app opens does not protect a session that runs for hours. Bind attestation to each transaction or short session.

Practical Recommendations

If you are evaluating or building contactless acceptance on commodity phones, start from the assumption that your assurance is the product of three layers: the platform’s hardware roots, the evaluated software, and your backend’s policy. Weakness in any layer must be compensated by another, and the compensation should be explicit in your design documents.

Choose a listed MPoC solution where you can, and read the listing for scope. Prefer an architecture in which the merchant app is a courier for opaque payloads. Keep the key-release decision in a service you control or can audit, with a short key window. Treat attestation verdicts as graded inputs, not binary gates, and connect them to transaction limits and fraud scoring. Design the offline and outage behaviour on purpose.

Because SPoC and CPoC stopped accepting new submissions after 31 October 2026, plan new evaluations against MPoC and track the expiry dates of any existing CPoC or SPoC listings you depend on. Where a vendor’s documentation still cites CPoC, ask for their MPoC roadmap in writing.

A short checklist:

Confirm the solution’s PCI listing type (solution vs component) and its scope.
Verify that card data and PIN are encrypted inside the evaluated component, and that the merchant app never handles clear data.
Define the attestation policy tiers: which verdicts allow PIN, which allow contactless-only, which block.
Bind attestation evidence to a nonce and keep key release windows short.
Specify behaviour during attestation-service outages and for offline or store-and-forward modes.
Monitor tap success rate, authorization latency, decline rate and device-health transitions per device model.
Maintain a process for kernel, CAPK and configuration updates across the fleet.
Review log and analytics pipelines for payload leakage.

Frequently Asked Questions

What is SoftPOS?

SoftPOS is software-based point of sale: a merchant accepts contactless card or wallet payments by tapping the card on a smartphone or tablet, with no external terminal. The device’s NFC antenna reads the card, an evaluated app and SDK encrypt the data, and a backend monitors the device’s integrity. Marketing names include Tap to Pay, Tap to Phone and contactless acceptance on COTS devices.

What is PCI MPoC and how is it different from SPoC and CPoC?

MPoC (Mobile Payments on COTS) is the PCI SSC standard for accepting PIN and contactless payments on commercial off-the-shelf devices. It builds on SPoC (PIN entry) and CPoC (contactless) and is modular and objective-based. According to a PCI SSC bulletin, SPoC and CPoC stopped taking new submissions after a sunset period ending 31 October 2026, while existing listings remain valid until their normal expiry.

How does a phone keep card data secure without a hardware terminal?

It layers protections: the card is read through a certified kernel, the data is encrypted in an evaluated component (a Secure Element on iPhone, protected storage elsewhere), and the decryption key is released to the payment processor only after the backend validates fresh evidence of device integrity. The merchant’s app handles only an opaque encrypted payload, never the card number or PIN.

Is Tap to Pay on iPhone the same as Tap to Pay on Android?

No. Both let a phone accept contactless payments, but they differ in implementation. On iPhone, Apple controls the Secure Element, kernels and server, and developers use the ProximityReader framework with an entitlement and a certified PSP. On Android, the provider integrates its own MPoC SDK, device compatibility policy and integrity checks such as Play Integrity, so assurance varies more with the device.

Can SoftPOS accept PIN entry?

Yes, where the solution supports it. PIN-on-glass lets the cardholder type the PIN on the phone’s touchscreen, and the PIN is encrypted into a PIN block inside the protected component. Apple documents this for Tap to Pay on iPhone, including capture-blocking and an optional Screen Lock. Support depends on the provider, country and device; offline store-and-forward on iPhone does not support PIN entry.

What happens if the attestation service says the device is compromised?

The solution can degrade or block. Typical responses are refusing PIN entry, lowering transaction limits, requiring a fresh attestation, withholding decryption keys so any captured payload is useless, and alerting the provider. The exact policy is set by the solution provider and its acquirer; there is no universal rule beyond the standard’s expectation that compromised platforms are detected and responded to.