MPoC is the PCI standard that lets an ordinary smartphone accept cards — contactless and PIN — with no dongle. It folded the older CPoC and SPoC standards into one modular programme and, crucially, made a live back-end attestation-and-monitoring engine mandatory. This is the standard behind SoftPOS.
A COTS phone is an untrusted, uncontrolled environment — any app, any OS version, any state of patching. MPoC’s entire design answers one question: how do you accept card data safely on a device you do not control?
PCI MPoC — Mobile Payments on COTS (Commercial Off-The-Shelf, i.e. a normal phone or tablet) — is the PCI SSC standard and programme for solutions that turn an unmodified smartphone into a payment-acceptance device. No external reader, no dongle: the phone’s own NFC accepts the contactless tap, and the touchscreen can capture the PIN.
It was published in November 2022; the current version is MPoC v1.1 (November 2024), which added flexibility for offline transactions, multiple cardholder verification methods, manual card entry and more. MPoC is the standard the market calls SoftPOS or tap-to-pay-on-phone.
| Standard | Card capture | PIN | Limitation it had |
|---|---|---|---|
| SPoC | Separate approved hardware reader | On the phone glass | Still needed dedicated hardware. |
| CPoC | Phone’s built-in NFC | None | No PIN → low-value contactless only. |
| MPoC | Phone NFC (contactless) | On the phone glass (PIN-on-glass) | Combines both — full contactless + PIN, no dongle. |
MPoC consolidated two earlier standards. SPoC (Software-based PIN entry on COTS) covered entering a PIN on the phone’s glass — but required a separate approved hardware reader (SCRP) for the card. CPoC (Contactless Payments on COTS) covered tapping a card to the phone’s own NFC — but had no PIN, capping it at low-value transactions. Each was half a solution.
Before/while a transaction runs, the solution checks the device and app state — OS integrity, rooting/jailbreak, debugger attachment, app tampering, known-bad conditions. A failed attestation can block the transaction.
A back-end (Domain 3 in the standard) continuously ingests telemetry from deployed devices, interprets it, and responds to anomalies and emerging threats across the whole fleet — not just one device.
This is the philosophical break from classic PCI. Security is an operational, live capability the solution provider must run, not a certificate on a wall.
The A&M environment is itself in scope and assessed. Whoever runs it carries that responsibility — often the SDK/solution vendor, sometimes a specialised provider.
The defining feature of MPoC — and what separates it from a static PCI assessment — is the Attestation & Monitoring (A&M) system. Because the phone is untrusted, security cannot be proven once at certification. It must be continuously verified at runtime, transaction by transaction.
MPoC does not replace your PCI DSS obligations as a merchant/acquirer; it governs the acceptance solution. The systems behind the phone still sit in their own DSS scope. MPoC is a layer on top, not a substitute.
Because A&M is mandatory and live, an MPoC solution is a subscription to a running back-end. If the provider’s monitoring lapses or they exit the market, your acceptance stops being compliant. Vendor durability is a real risk.
New phones, OS updates and rooting techniques appear constantly. The attestation logic must keep pace or it either blocks good devices (lost sales) or misses compromised ones (loss).
High-value transactions need a PIN/CVM; the schemes and local acquirers set contactless and PIN-on-glass limits. MPoC enables PIN-on-glass but does not override scheme rules or local floor limits.
Visa Tap to Phone and Mastercard Tap on Phone each layer their own brand requirements over MPoC. Certifying to MPoC is necessary but not always sufficient for a given market or scheme.
Almost nobody should certify a full MPoC solution from scratch — the A&M obligation alone is a standing engineering and operations commitment. The modular structure exists precisely so you do not have to.
Embed a validated MPoC SDK and consume a validated A&M service rather than building both. Your differentiation is onboarding, pricing and merchant UX — not re-solving runtime attestation.
Buy a packaged SoftPOS product from your acquirer or a SoftPOS vendor. Confirm it is MPoC-listed and carries the relevant scheme programme approval for your market.
If you need very high transaction values, deep offline operation, or you cannot rely on attestable modern phones in the field, a certified mPOS reader (PCI PTS device) may be more robust than SoftPOS. SoftPOS shines for low-cost, fast merchant onboarding.
SoftPOS is compelling in markets where terminal hardware cost and distribution are the barrier to merchant acceptance — much of sub-Saharan Africa. The phone the merchant already owns becomes the terminal. That is the unlock; MPoC is what makes it safe enough for the schemes to allow.
Shipping a SoftPOS app that is not MPoC-validated (or whose A&M is hollow) means you are accepting cards on untrusted devices with no real runtime defence — an open door to fleet-wide compromise and scheme sanction.