SPoC, CPoC and MPoC under PCI DSS: scope, cost and SAQ

Does PCI DSS mobile payments acceptance need its own assessment path?

A merchant that takes cards on a commercial off-the-shelf phone or tablet can validate with SAQ SPoC, provided the payment software and card reader form a SPoC Solution that appears on the PCI SSC's list of validated SPoC Solutions. Other mobile setups follow different PCI SSC standards or require a full assessment, so the first task is confirming which of those situations applies. Start by checking the solution's listing status against the PCI SSC's published list, then ask your acquirer which validation it expects you to complete. Acquirers set the validation requirement for their merchants, so their answer governs your path.

The answer depends on four facts. The first is whether the solution is listed and its listing matches your exact combination of app, reader and firmware versions. The second is device ownership, because the merchant's own phone or tablet is handled differently from a consumer's device. The third is whether the setup is a P2PE solution, since SPoC, CPoC and MPoC solutions cannot qualify for P2PE approval. The fourth is whether any of your own systems store, process or transmit account data. Any system that does is part of the cardholder data environment and must be covered by the assessment, whatever questionnaire you complete.

Before you buy hardware or sign a contract, ask the solution provider for its current listing reference and the responsibility matrix for the SPoC Solution, and ask your assessor to confirm in writing which SAQ or report applies to your configuration. Cost and effort depend on that decision, so request a quote that separates the validation work, device management, and any QSA time. Confirm the expected effort and fees directly with your acquirer and assessor, because neither the standard nor this page sets them.

What a PCI DSS mobile acceptance assessment costs and who gets paid

This table lists each cost component of a mobile acceptance assessment, who is paid for it, whether it recurs, and what moves it up or down. No supplied source gives a price, so use the table to structure requests for written quotes and questions to your acquirer.

Cost component	Who is paid	One-time or recurring, and drivers
Qualified Security Assessor fees for a ROC	Independent QSA firm	Recurring annually if a ROC is required. Drivers: number of payment flows, number of merchant locations, and whether the acquirer requires a ROC at your level.
Self-assessment effort for SAQ SPoC	Your internal staff, or a paid advisor you choose	Recurring annually. Drivers: how many devices and apps are in use, how well the SPoC Solution is documented, and how many policies you must write.
SPoC, CPoC or MPoC solution fees	Solution provider or listed product vendor	Usually recurring (licensing, support, updates). Confirm whether the solution is on the PCI SSC list and what the vendor's contract covers.
Implementation partner work on configuration and evidence	Implementation partner, under a written fixed scope	Mostly one-time for setup and evidence preparation, with recurring retainer options. Drivers: how many app and device configurations must be documented.
Scanning and logging tools	Tool vendor or cloud provider	Often recurring. Drivers: number of endpoints, log retention period, and whether scans are performed by an Approved Scanning Vendor where applicable.
Internal staff time	Your own payroll	Recurring. Drivers: device fleet changes, staff turnover, and how often the mobile app or device firmware is updated.
Acquirer validation requirements	Your acquirer (no fee from the standard itself)	Ask the acquirer which SAQ or ROC they require, which dates apply, and whether any reporting fees exist.

What makes mobile acceptance more or less expensive

Mobile acceptance costs are set less by the phone itself than by who owns it, how many devices and sites run the solution, and how much evidence already exists. Each driver below is one lever the merchant can pull before a scope is agreed, and each one changes both the assessment effort and the recurring work after validation.

Merchant-owned or personal devices

Company-owned phones and tablets are managed endpoints, so the merchant controls their configuration, updates and access. Personal devices used for work introduce a separate question about who controls the operating system and the payment app. Before quoting, confirm with the solution provider and your assessor whether any device will be a personal one, and whether a mobile device management policy can enforce the settings the solution depends on. Requirement 9.5.1 treatment of commercial off-the-shelf devices should also be confirmed for your device type with your assessor.

Number of devices and locations

Each additional phone, tablet or site adds inventory entries, physical handling checks, configuration evidence and staff training records. A small number of devices at one site is far easier to document than dozens spread across events, delivery routes and branches. Ask for a device inventory template and a per-location procedure before agreeing scope, and find out whether devices can be retired or redeployed without re-assessment work.

Use of a listed solution

Using a SPoC, CPoC or MPoC solution from the PCI SSC's published list shifts much of the validation work to the solution's validated state, and it determines which self-assessment path applies. An unlisted or custom app brings the work back into the merchant's own assessment. Check the current listing status of any product, confirm the version in use matches the validated version, and ask the vendor how updates are handled.

Back-end systems receiving transaction data

Transaction data from a mobile reader usually flows to a payment gateway, a POS back office or a custom database. Every system that stores, processes or transmits account data, or could affect its security, falls into scope, which can widen the assessment well beyond the phone. Map each receiving system early, decide whether any of them can be replaced with a tokenized or outsourced flow, and confirm with the assessor where the boundary sits.

Number of third parties

Each solution provider, gateway, device manager, integrator and hosting provider holds part of the chain. Their responsibilities must be documented in a responsibility matrix and, where they affect the cardholder data environment, their own compliance status should be confirmed. Fewer parties with clear contractual duties usually mean less coordination and less evidence to collect. Ask each provider for its current validation status and written responsibility split before signing.

Maturity of existing evidence

Merchants that already keep current network diagrams, data-flow maps, policies, access reviews and vulnerability scan records need far less new work than those starting from nothing. Gaps in these records often cost more than the mobile-specific controls themselves. Before requesting quotes, inventory what exists, note its last review date, and mark which items will need to be created. A readiness review can show this gap in writing before fixed-scope work begins.

Which validation path fits a mobile acceptance setup

This table compares the validation paths open to a merchant taking cards on a phone or tablet, from SAQ SPoC for listed solutions to a ROC when the setup falls outside SAQ eligibility. Read each row against your actual device, back end and card reader, then confirm the required path with your acquirer before you commit.

Option	When it fits	What the organization still owns	What the assessor will ask for
SAQ SPoC	Merchant uses a SPoC Solution on the PCI SSC list of validated SPoC Solutions, on a commercial off-the-shelf phone or tablet with a secure card reader	Deploying and managing devices, keeping the solution current, physical custody of readers, staff use policies, and the merchant environment around the device	Evidence the solution is listed and unchanged, device inventory, reader handling records, and the completed SAQ SPoC with its AOC
Other SAQ	The solution, back end or environment falls outside SPoC eligibility, but the card data flow still qualifies for a simpler self-assessment questionnaire	Confirming which SAQ matches the flow, completing every applicable requirement, and keeping the environment within that SAQ's boundaries	Network and data-flow diagrams, responses for each applicable requirement, and an AOC matching the chosen SAQ
ROC by a QSA	The setup is complex, custom, or includes systems that no SAQ covers, or the acquirer requires a full assessment	Full scoping of the cardholder data environment, remediation of gaps, and paying an independent QSA for the assessment	A Report on Compliance produced by a Qualified Security Assessor, plus evidence for each in-scope requirement and an AOC
P2PE path	The payment device is a validated P2PE solution rather than a COTS device, and the merchant uses it within the solution's terms	Using the P2PE solution as listed, managing devices and keys within the solution's responsibilities, and avoiding changes that break the approval	Confirmation of the P2PE solution listing, device custody records, and the P2PE SAQ with its AOC
Mobile solution vs. P2PE device	SPoC, CPoC and MPoC solutions cannot qualify for P2PE approval, so a phone-based solution is never validated as P2PE	Choosing the correct standard for the device type at the start of the project	Clear documentation of which PCI SSC standard the solution is listed under, not a P2PE listing
Acquirer decision	Always, because the payment brands delegate validation requirements to acquirers and payment processors	Asking the acquirer in writing which validation type, SAQ or ROC, and which deadline applies to your merchant level	A written acquirer requirement, which becomes the baseline for the validation scope

Why SPoC, CPoC and MPoC fall outside P2PE approval

SPoC, CPoC and MPoC are separate PCI SSC standards for accepting payments on commercial off-the-shelf devices, and a solution built to any of them cannot qualify for P2PE solution approval. The Council's FAQ on these standards and P2PE states this directly, so a merchant should never assume that a phone-based acceptance product is covered by a P2PE listing because it encrypts card data at the point of entry. Each standard has its own requirements, its own validation path and its own list of approved solutions, so the three names are not interchangeable. A product validated to SPoC does not carry the same assurance as one validated to CPoC or MPoC, and the merchant should confirm which standard a specific solution was validated against before relying on it. Read the FAQ on MPoC, SPoC, CPoC and P2PE before you compare vendor claims.

Because these devices sit outside P2PE, a merchant can run mobile acceptance alongside P2PE terminals in the same business. The two environments may share a merchant network or location, but they are still separate payment acceptance paths with separate scope. The merchant should inventory each device type, record which standard and listing applies to each, and document the flows that connect them, including any point where card data could move from one environment into the other. An assessor will expect to see that boundary written down and tested, not inferred from the fact that both systems use encryption.

The practical effect shows up in the SAQ choice and the paperwork. A merchant using a listed SPoC solution may be eligible for the SAQ SPoC questionnaire, but that eligibility depends on the solution and its listing, not on the merchant's own encryption choices. A merchant that cannot meet those conditions will need a different SAQ or a ROC, and running P2PE devices alongside does not change which questionnaire applies to the mobile path. Confirm with your acquirer which SAQ it accepts for your setup, keep the solution's listing details and attestations on file, and record in your scope documentation which devices are P2PE and which are not.

How a mobile acceptance assessment runs from scoping to attestation

The sequence moves from the acquirer's validation requirement through inventory, solution listing, scoping and evidence gathering to a signed Attestation of Compliance that the organization submits. Each step produces a named artifact, and the organization owns the outcome throughout.

Confirm the acquirer's validation requirement
Start by asking your acquirer or payment service provider which validation type applies to your business, which SAQ or ROC form they expect, and when they need the Attestation of Compliance. The organization owns this conversation because the payment brands and acquirers, not the PCI SSC, decide who must validate and how. The output is a written note from the acquirer stating the validation type, the form and the submission route. Do not begin scoping until that note exists.
Inventory phones, tablets, readers and back-end systems
Build a complete inventory of every commercial off-the-shelf phone or tablet used for acceptance, each secure card reader, the payment app versions installed, and the back-end systems that receive, route or store transaction data. Record who owns each device, whether the merchant or a staff member controls it, and how it is managed. The output is a versioned asset inventory that the assessor will later check against the solution listing and your data flow diagram.
Verify the solution is listed by the PCI SSC
Confirm that the SPoC, CPoC or MPoC solution, including the app, the card reader and the back-end components, appears on the PCI SSC's list of validated solutions for the relevant standard, and that the exact versions you deploy match the listing. The output is a saved copy of the listing entry with its version details, attached to your evidence file. Mobile solutions cannot qualify for P2PE approval, so a P2PE listing does not substitute for this check.
Scope the environment and document data flows
Map where cardholder data is captured, how it moves from the reader to the phone and onward to the processor, and which systems in your network could affect that path. Confirm whether any clear-text output leaves the device and, if so, how it is encrypted. The output is a current network diagram and data flow diagram, plus a scope statement that names included and excluded systems with reasons. Your assessor will test this scope, so it must reflect what actually runs.
Select the SAQ or engage a QSA for the ROC
Using the acquirer's requirement and your scope, choose the SAQ SPoC or, where your acquirer requires a full assessment, plan a Report on Compliance. A Qualified Security Assessor completes a ROC on the official PCI SSC template, and only that independent QSA can issue it. The output is a signed engagement letter for a ROC or a confirmed SAQ selection with the reasoning recorded. Ask any consultant you hire to keep their preparation work separate from the assessor's testing.
Gather evidence for each applicable requirement
Work through each requirement that applies to your SAQ or ROC and collect dated evidence that shows the control operates. For Requirement 9.5, the SAQ D notes state that 9.5.1 does not apply to commercial off-the-shelf devices such as merchant-owned smartphones or tablets, and is only recommended for manual key-entry components such as keyboards, so record how your devices are handled and why. Evidence typically includes configuration records, access reviews, patch records, and reader tamper-inspection logs. The output is an evidence index that maps each requirement to the file that supports it.
Complete the assessment and sign the AOC
Complete the SAQ or ROC with answers that match your evidence index, then have an authorized officer sign the Attestation of Compliance. Where a QSA produces the ROC, the QSA issues the associated Attestation of Compliance after its own review. Note that PCI DSS certificates are not recognized as validation, so the signed AOC is the document that counts. The output is a finalized, signed AOC and, where applicable, a ROC issued by the QSA.
Submit the attestation to the acquirer
Send the signed AOC through the route your acquirer specified in the first step, and keep a copy with the evidence index and the ROC if one was issued. Confirm receipt in writing and record the date your acquirer accepted it. The output is an accepted submission on file and a list of open items, if any, that your acquirer has raised. Tell the reader that DeployOpen prepares systems and evidence for this process but does not issue the AOC or the ROC, which remain the responsibility of the organization and its independent assessor.

What must be in place before the assessor reviews the mobile setup

A mobile acceptance assessment tests whether the devices, apps, data flows and records match what the merchant claims. The six items below are the ones assessors ask for first, and each one can be checked internally before the assessor arrives.

Current device inventory

List every phone and tablet that touches card data, with make, model, serial number, owner (merchant or solution provider), location and the person responsible for it. Compare the list against the solution's configuration to find devices that were added without approval or retired devices still enrolled. Ask the provider to confirm which devices are covered by the validated solution and which are merchant-owned. Missing or stale entries are the most common reason an inventory fails review.

Solution listed on the PCI SSC

Confirm that the card reader, the software and the exact version in use all appear on the PCI SSC list of validated solutions, and that the merchant's deployment matches the listed components. A listing for one reader model or software release does not cover another. Keep a dated copy of the listing entry in the evidence folder. This check decides which self-assessment questionnaire applies, so verify it before anything else.

Documented card data flows

Draw how card data moves from the customer's card through the reader, the phone, any cloud back end and the acquirer, and mark every point where data is entered, stored, transmitted or logged. Confirm that the diagram matches what the app and back end actually do, not only the vendor's architecture document. Check that no card data appears in logs, screenshots, crash reports or support tickets. Assessors compare this diagram with the traffic they observe.

Configuration standards for devices and back ends

Write a configuration standard for the phones and the server or cloud components, covering operating system version, required patches, disabled features, screen lock, app permissions and network settings. Also cover the back-end hosts, databases and APIs. Check each system against the standard and keep the results. Ask the solution provider which settings they control and which the merchant must set, and record that split in writing.

Tamper checks and device management

Define how merchant-owned phones are kept under control: enrollment in a mobile device management tool, a schedule for checking the card reader for tampering or substitution, and a rule for what staff do when a device is lost, damaged or behaves oddly. Test the process once with a sample device so the team can show it works. The standard treats merchant-owned phones and tablets as commercial off-the-shelf devices, so the controls here are the merchant's responsibility to design and evidence.

Evidence folder mapped to requirements

Build one folder that maps each applicable requirement to the document, log, screenshot or record that supports it, with an owner and a review date for each item. Include the inventory, listing evidence, data flow diagrams, configuration results, tamper check logs and training records. Ask the assessor early which evidence formats they accept and whether they want samples or full populations. Missing links between a requirement and its evidence slow the review more than missing controls do.

Who owns what in a mobile payment validation

The merchant owns the payment environment, its controls and the Attestation of Compliance (AOC). That ownership cannot be handed to a vendor or consultant. The merchant decides which SPoC, CPoC or MPoC solution it uses, which devices its staff carry, who may install apps, and how the business responds when a control drifts. Internally, the merchant usually needs a named owner for payment devices, someone who keeps the device and solution inventory current, and a person who signs off the SAQ or confirms the validation requirements set by its acquirer.

Solution selection: Confirm the phone or tablet, card reader and payment application appear together on the PCI SSC's list of validated SPoC Solutions before you deploy anything.
Device inventory: Record every merchant-owned phone or tablet, its user, its location and its application version.
Staff procedures: Train staff to report lost or tampered readers and to refuse unexpected device swaps.
Attestation: Your organization signs the SAQ SPoC AOC, so the signatory must understand each answer.
Acquirer contact: Ask your acquirer which validation level and reporting path applies to your volume.

Before signing, check that every answer matches the environment you actually operate, because the AOC is your statement of compliance.

How to choose an assessor or consultant for mobile acceptance

Mobile acceptance projects involve a solution provider, a merchant, a consultant and an assessor, and each owns different evidence. The checks below help you confirm who does what before you commit to a written scope. None of them replaces reading the assessor's and consultant's own engagement terms.

Confirm the QSA listing

If your validation requires a Report on Compliance, the assessor must be a Qualified Security Assessor listed by the PCI SSC. Ask for the firm's and the named individual's listing status and check it on the PCI SSC site yourself rather than relying on a copy of a certificate. A Self-Assessment Questionnaire does not require a QSA, so ask the provider which path your acquirer expects before you request quotes. Confirm this in writing before work starts.

Separate consultant and assessor roles

The organization that prepares your mobile acceptance environment and evidence should not also be the assessor that validates it, unless the relationship is documented and permitted. Ask each firm to state in writing what it will build, configure or document, and what it will only review. Where one firm does both, ask how it manages independence and who signs the assessment.

Ask for listed solution experience

Mobile acceptance depends on the specific listed SPoC, CPoC or MPoC solution, the card reader, the phone or tablet model and the merchant's app. Ask for examples of work in environments that use the same listed solution and reader family, described without client names. Ask which parts of the deployment the firm has handled before, such as device management, key injection checks and merchant-owned device rules.

Split fixed scope from retained work

Fixed-scope work covers defined deliverables, such as a scope statement, a data-flow diagram or a configuration review, with agreed dates and outputs. Retained work covers ongoing tasks such as quarterly reviews, device onboarding or change support. Ask which items the quote fixes and which it bills by time, and what triggers a change request when a new device model or solution version enters the environment.

Ask who owns the evidence

Ask the partner which evidence it will prepare, such as configuration exports, device inventories, access reviews and policy drafts, and how it will hand that evidence to you and to the assessor. The organization owns its controls and its attestation. Confirm who keeps the source files, how versions are recorded and whether the assessor can rely on the partner's work or must re-test it.

Ask what the quote excludes

Ask for a written list of exclusions before comparing prices. Common exclusions include the assessor's own fee, the acquirer or brand validation process, remediation of findings, replacement hardware, penetration testing and work on other channels. Ask how the partner will price any remediation it discovers and whether it can guarantee a validation outcome. A credible partner will not promise a result, because the assessor decides it.

Questions buyers ask about PCI DSS mobile acceptance

Does a phone app that takes card payments need a full ROC?

Usually not. A merchant taking cards on a commercial off-the-shelf phone or tablet may be able to validate with a Self-Assessment Questionnaire rather than a Report on Compliance, but only when the solution is on the PCI SSC's list of validated SPoC Solutions and the merchant uses it as listed. The SAQ SPoC questionnaire was released in September 2023 for this case. Any merchant that uses a different architecture, a custom app or an unlisted reader may fall back to a larger questionnaire or a ROC. Confirm the validation type with your acquirer, because the acquirer and the payment brands decide which validation each merchant must complete.

Does SAQ SPoC apply to every phone?

No. SAQ SPoC applies only when the phone or tablet, the card reader and the software together form a SPoC Solution that is on the PCI SSC's list of validated solutions. The validation covers the specific combination, so a different phone model, a different reader or an app version outside the listed configuration can fall outside it. Ask the solution provider for the listing reference and the exact components it covers, then check that your deployment matches. Mobile Payments on COTS (MPoC) and Contactless Payments on COTS (CPoC) are separate PCI SSC standards with their own listed solutions, so a listing under one standard does not carry over to the others.

Is a consumer app on a customer's own phone in the merchant's PCI DSS scope?

Generally not, when the consumer uses the software on their own device to enter only their own card data. The PCI SSC treats that device like the cardholder's card, so it is outside the merchant's PCI DSS scope. The organization that develops the software is still in scope for development duties, such as the secure development expectations in Requirement 6. If the developer stores, processes or transmits account data, PCI DSS applies to the developer's environment as well. Confirm the exact data flows with your assessor, because a merchant app that also receives, logs or forwards card data changes the answer.

Does Requirement 9.5 apply to phones the merchant owns?

The SAQ D notes state that Requirement 9.5.1 does not apply to commercial off-the-shelf devices such as merchant-owned smartphones or tablets. The same notes say the requirement is recommended for manual key-entry components such as keyboards. Requirement 9.5 concerns protecting point-of-interaction devices from tampering and substitution, and the merchant still has to manage the card reader and the solution through the other requirements that apply. Because the answer depends on the validation type and the device role, confirm with your assessor how the requirement applies to your specific deployment.

What does the effort for mobile acceptance depend on?

Effort depends mostly on how much of the payment flow the merchant controls. The main drivers are whether a listed solution exists for the exact hardware and software, how many devices and locations are deployed, whether the merchant runs its own app or uses a provider's app, how card data is handled after the transaction, and whether the merchant has to integrate with a point-of-sale or back-office system. Ongoing work includes device management, app updates, staff training, and keeping the inventory and attestation current. Ask any provider to itemize the one-time setup tasks separately from the recurring tasks, and ask for the validation evidence that each task relies on.

Can our organization complete the SAQ itself?

Often yes, for a merchant with a simple, listed solution and clear ownership of the devices. The merchant completes the questionnaire and its Attestation of Compliance, and the acquirer decides whether that validation is acceptable for the merchant's level. The work still requires someone who can read each requirement, collect evidence, and explain how the controls work in practice. If the environment includes custom code, integrations or shared networks, the scope analysis becomes harder and outside help is more likely to pay off. Confirm with your acquirer which validation it requires before you start.

What does a partner deliver, and what does the assessor deliver?

A partner prepares the systems and the evidence. Typical partner work includes setting up devices, documenting the data flows, configuring management and logging, hardening the systems the merchant owns, and assembling the evidence packet. DeployOpen prepares systems, controls and evidence for compliance assessments and works under a written, fixed scope. Only an independent Qualified Security Assessor or the merchant's own questionnaire process produces the validation, and DeployOpen does not issue reports, attestations or certificates. Ask a partner to state in writing which deliverables are preparation and which are validation, and confirm with your acquirer who must sign the Attestation of Compliance.

Which parts of mobile acceptance should we confirm with our acquirer first?

Start with the validation type, the level, and the exact solution listing your acquirer will accept. Ask whether the acquirer requires a particular SAQ, whether a ROC is needed at your volume, and whether any quarterly scanning or other external testing applies. Also ask how it treats merchant-owned phones and consumer apps in your flow, and whether it needs a specific version of the solution. Get those answers in writing before you buy devices or commission a partner, because the acquirer and the payment brands decide which requirements each merchant must meet.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the systems, controls and evidence that a mobile acceptance assessment will examine. We do not issue reports or attestations, and the assessor and your acquirer decide which validation applies to your deployment.

How we scope

We confirm which payment flow, SPoC, CPoC or MPoC solution, and merchant devices apply before any work starts.
The written scope lists systems, devices, data flows and responsibilities that DeployOpen will cover, agreed in advance.
We map which requirements sit with your organization, the solution provider and the assessor, so gaps are visible early.

How we build

We configure the self-hosted back-end and management components inside your cloud accounts, data centers or air-gapped networks.
We harden systems, enforce access controls and logging, and check that device management settings match the validated solution's instructions.
We test the configuration against the requirements in scope, including security testing where the written scope includes it.

How we hand over

We deliver configuration records, network and data-flow diagrams, device inventories and the policy and procedure documents named in scope.
We document each control with the evidence an assessor would ask to see, mapped to the in-scope requirement.
We walk your team through operation so your staff can produce the recurring evidence without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer when your deployment needs them.
Retainers can cover updates to the solution, device fleet changes and recurring evidence collection, as agreed in writing.
Questions about validation scope, validation type or assessor selection should go to your acquirer and your independent assessor.