SPoC and CPoC Sunset on October 31, 2026: A SoftPOS Procurement Action Plan

Key Takeaways

• ● PCI SSC stops accepting new SPoC and CPoC submissions after October 31, 2026; existing listings retain their normal lifecycle.
• ● SPoC and CPoC listings remain subject to annual checkpoints and applicable maintenance requirements throughout their active listing periods.
• ● PCI SSC encourages future development planning around applicable standards, including MPoC where appropriate; the bulletin sets no universal hardware replacement deadline.

The SPoC and CPoC sunset closes a submission route, while existing listed solutions follow their individual lifecycle dates. According to the PCI SSC sunset bulletin, published in May 2026, the transition runs from May 1 through October 31, 2026. After the transition, PCI SSC will stop accepting new submissions under both programs.

SoftPOS procurement teams should turn the deadline into a documented project decision. Payment service providers, independent software vendors, integrators and enterprise buyers need to establish which solution is being supplied, how long the provider will maintain the deployment and whether an MPoC migration changes the supported device environment. The procurement recommendations below translate those questions into evidence requests; the recommendations are not additional requirements announced in the bulletin.

1. What Changes After October 31, 2026?

The bulletin preserves existing listing lifecycles. Listed SPoC and CPoC solutions retain their established expiration or reevaluation dates, remain eligible for annual checkpoints and applicable change submissions, and remain subject to maintenance requirements during their active listing periods.

The distinction between submission closure and listing expiration is the central rule.

The SPoC and CPoC sunset ends new submissions after October 31, 2026. Existing PCI-listed solutions continue through their normal listing lifecycle, subject to established expiration or reevaluation dates and maintenance requirements. The deadline therefore does not create a single expiration date for every deployed SoftPOS solution.

For procurement teams, the next useful date is the one attached to the proposed solution and support contract.

SoftPOS remains a deployment model rather than the name of one PCI validation program. SPoC, CPoC and MPoC describe different security frameworks used within mobile acceptance. The SoftPOS and Tap to Pay guide explains the underlying category; the immediate buying question is which framework and exact solution apply to the proposed deployment.

2. New Projects and Existing Deployments Need Different Decisions

Project status determines the next action. A team choosing its first payment partner has different options from a merchant operating an existing listed solution or an ISV already completing an evaluation. Treating all three situations as one replacement campaign creates unnecessary cost and can miss the actual approval dependency.

An evaluation underway is not the same as a submission accepted or a solution listed. The buyer should ask the provider to identify the current milestone and the party responsible for completing the next step. A sales statement that certification is “almost finished” does not establish a production release date.

The sunset announcement does not itself impose a blanket ban on new merchant deployments using every existing listed solution. That is an interpretation of the bulletin's limited scope, not a promise that a particular rollout is permitted. The proposed solution, provider, acquirer and applicable payment-brand rules still need to support the project.

A maintenance claim should also identify the deployment being maintained. A provider may support one application version, operating-system range or commercial territory without supporting another. Procurement teams should capture those boundaries before signing a rollout schedule.

3. Verify the Exact Solution Listing

Listing verification should start with the provider's legal name and the exact product or solution. A brand logo, certificate image or reference to an upstream SDK can be useful background, but the evidence needs to connect the listed item to the application and service being purchased.

PCI SSC provides a practical starting point for that verification. Its MPoC products and solutions listing is accessible through the official listings service, which may present terms before displaying entries. Buyers should record the reference, status, versions and lifecycle information shown for the relevant entry, then resolve any missing deployment details with the provider.

The procurement record should answer eight questions:

1. 1. What legal entity supplies and maintains the solution?
2. 2. What exact product, component or solution is listed?
3. 3. Which reference number identifies the entry?
4. 4. Which application, SDK and service versions will the buyer receive?
5. 5. What expiration or reevaluation date applies?
6. 6. Who owns annual checkpoints and applicable changes?
7. 7. How does the final integration relate to the listed scope?
8. 8. Which acquirer and payment-brand conditions apply to production use?

A listed component and a deployed solution are different procurement objects. An ISV integrating an MPoC SDK should ask the provider and laboratory which integration evidence and validation steps apply to the finished offering. The SDK's listing should not be interpreted as approval for every application, backend, device or operating arrangement built around it.

Payment certifications also address different layers. Hardware security, contactless communication, payment software and deployment acceptance can involve separate evidence and owners. The POS terminal certifications guide explains those boundaries; a supplier should identify which layer each document actually covers.

4. Get a Written Maintenance and MPoC Roadmap

The provider's maintenance commitment should cover the buyer's operating horizon. A listing date answers one question; a contract covering security fixes, incident response, supported devices and migration assistance answers another. Both belong in the purchasing decision.

The provider should distinguish a development plan from an achieved milestone. “MPoC planned,” “under evaluation,” “submitted” and “listed” describe materially different states. A buyer can accept a future milestone as a commercial dependency, but the milestone should have an owner, expected date and fallback arrangement.

PCI MPoC provides the relevant direction for evaluating future mobile acceptance designs. The PCI SSC MPoC overview describes a modular security program building on SPoC and CPoC, including PIN and contactless acceptance on the same COTS device. PCI SSC also states that payment-brand compliance programs govern questions about required validation and use of listed products.

An MPoC roadmap should identify the commercial deployment as well as the technical product. A provider can have a listed offering without supporting every country, acquirer, device family or PIN flow the buyer needs. The project plan should state the intended markets and acceptance relationships explicitly.

5. Select the Payment Solution Before Ordering Android Hardware

Hardware procurement should follow the chosen payment solution's supported environment. The recommended order is payment partner and acquiring path, supported device configuration, sample validation, then volume purchasing. This sequence prevents a hardware order from committing the project to an environment the payment provider cannot support.

A generic “SoftPOS-ready” description leaves important compatibility questions unanswered. Procurement teams need the exact device model, Android build, security patch policy, application version and relevant integrity or attestation dependencies. GMS availability and NFC capability can matter to a particular implementation, but neither independently establishes payment-solution eligibility.

The hardware evidence should be specific enough to survive a replacement shipment. A matching model name can conceal a changed board, NFC component, firmware build or update policy. The purchase specification should record the configuration the payment provider has accepted and require review of changes that can affect that acceptance.

The existing hardware guide covers the detailed device checks. Buyers can use the enterprise SoftPOS hardware requirements checklist once the payment route is selected. For this transition, the purchasing gate is written confirmation that the quoted configuration fits the intended solution and support period.

6. Treat MPoC Migration as a Solution Change

MPoC migration should be reviewed across the application, security services, device environment and merchant operation. A provider may preserve much of an existing deployment or require substantial changes. The migration estimate should therefore list affected components instead of assuming either a simple app update or complete hardware replacement.

The device decision follows from that component review.

MPoC migration concerns the payment solution, including software integration, security monitoring and supported device conditions. Existing Android hardware may remain usable when the target solution supports the configuration and validation succeeds. Hardware replacement becomes necessary when compatibility, security support or operational requirements cannot be met with the existing devices.

That approach gives buyers a testable basis for retaining or replacing equipment.

A migration pilot should exercise failure paths as well as successful payments. Recommended cases include interrupted enrollment, a failed integrity check, unavailable monitoring services, a network timeout, an application update and device replacement. The payment provider should define the permitted behavior and recovery action for each case.

Rollback needs provider approval and a clear operating boundary. Returning to an earlier application does not automatically restore valid enrollment, compatible services or an acceptable security state. The migration plan should specify when rollback is permitted and when merchants must use another supported acceptance method.

Fleet management makes the migration repeatable. The SoftPOS hardware platform guide covers the broader relationship between device support and deployment operations. Buyers should ask how the provider will identify affected devices, stage releases, record results and stop a rollout when acceptance conditions fail.

7. Use a Procurement Evidence Pack Before Signing

The procurement evidence pack should connect the contract to one identifiable production configuration. The following is a recommended buyer control, not a new PCI SSC form or an exhaustive compliance checklist.

The contract should distinguish committed support from future capability. A useful schedule records the current supported offering, expected migration work, exclusions, notification periods and consequences of a missed dependency. Buyer acceptance should depend on evidence delivered for the actual configuration rather than a presentation describing the provider's product family.

The immediate action is to assign owners before the submission window closes. An evaluation underway needs a provider and laboratory discussion; an existing deployment needs a lifecycle and maintenance review; a new procurement needs a supported payment route before volume hardware is ordered. Those decisions remain useful after October 31 because each project carries its own support and release schedule.

8. Frequently Asked Questions

Q1. Do all SPoC and CPoC solutions expire on October 31, 2026?

Existing SPoC and CPoC listings do not share a universal October 31 expiration date. Buyers should check the individual lifecycle dates and continuing maintenance obligations attached to the selected listing.

Q2. Can an existing listed SPoC or CPoC solution still be maintained?

An active listed solution remains eligible for annual checkpoints and applicable change submissions during its listing period. The provider should confirm the maintenance responsibilities and commercial support terms for the buyer's deployment.

Q3. Does the sunset bulletin prohibit every new merchant deployment?

The bulletin does not announce a blanket prohibition on all new deployments of existing listed solutions. A particular rollout still needs confirmation of supported scope, provider availability and applicable acquiring or payment-brand requirements.

Q4. Must merchants replace Android devices to migrate to MPoC?

Device replacement depends on the target MPoC solution and the existing device configuration. Buyers should retain equipment only after the provider confirms support and the migration tests satisfy the agreed acceptance criteria.

Q5. Does a listed MPoC SDK automatically validate the final solution?

An SDK listing does not establish that every resulting integration is validated. The ISV should obtain confirmation of the final solution's scope, applicable integration process and production responsibilities from the provider and laboratory.

Q6. What should a SoftPOS buyer request before signing a hardware order?

A SoftPOS buyer should request listing evidence, a supported configuration, maintenance terms, acquiring confirmation and a migration plan where needed. Volume purchasing should follow sample validation against the chosen payment solution.