PCI 3DS SDK, CPoC and SPoC Sunset on 31 October: What Tap to Pay and Checkout Teams Need on File

Three PCI standards reach the end of their sunset period on 31 October 2026, a little over three weeks from today. The PCI Security Standards Council set a window from 1 May to 31 October 2026 for the PCI 3-D Secure (3DS) Software Development Kit Standard, the PCI Contactless Payments on COTS (CPoC) Standard and the PCI Software-based PIN Entry on COTS (SPoC) Standard. COTS means commercial off the shelf devices, in practice ordinary phones and tablets. None of this changes PCI DSS v4.0.1 itself, which remains the baseline for merchants and service providers. What changes is the set of programmes that vendors point to when they say the payment software inside their product has been independently validated, and that claim ends up in a lot of security questionnaires and vendor files.

The successors are already in place. For phone based card acceptance, the Mobile Payments on COTS (MPoC) Standard builds on both SPoC and CPoC, so a single MPoC solution can cover contactless acceptance and PIN entry on a phone rather than needing two separate validations. Version 1.1 of MPoC was published in November 2024, and among other changes it allows one MPoC SDK to integrate another, which matters for platforms that build on a payment provider SDK. For 3DS, the Council published version 2.0 of the PCI Secure Software Standard in January 2026 and described it as an alternate path for assessing 3DS SDKs, intended over time to replace the dedicated 3DS SDK Standard. In short, phone acceptance moves to MPoC and 3DS SDKs move under Secure Software.

Who should care? Three groups. First, vendors that sell Tap to Pay or SoftPOS style acceptance on Android or iOS, and any fintech that white labels one. If your product listing still says CPoC or SPoC validated, you need an MPoC plan you can describe to customers with dates attached. Second, app teams that embed a 3DS SDK for card authentication in a mobile checkout, which covers a large share of ecommerce and subscription apps. Third, merchants and their assessors, who are the ones that will see a retired programme name in a vendor attestation and have to decide what it means for their own PCI DSS scope. The Council material we found does not spell out, in one place, how existing listings are treated after 31 October, so ask your lab or payment provider directly rather than assuming.

For merchants, the practical question is evidence. When your QSA or internal assessor reviews a phone acceptance solution, they rely on the vendor validation to reduce the work in your own assessment. If that validation sits under a standard that has finished its sunset, expect more questions, and possibly a request for the vendor MPoC status or roadmap. Update your vendor register now rather than in the middle of fieldwork. For each payment application and SDK, record the PCI programme it is validated under, the listing reference, the expiry date and the named successor programme. If you run a compliance platform such as Vanta, Drata, Secureframe or Sprinto, add these as tracked vendor documents with renewal dates so the reminder fires before your next assessment, not after it.

For vendors, the work is a transition plan and a clear customer message. Map each validated product to its successor: SPoC and CPoC solutions to MPoC, 3DS SDKs to the Secure Software Standard v2.0 module. Book lab time early, because every vendor in the same position is booking the same small pool of recognised labs this quarter. Then write one short statement for your trust centre that says which programme each product is validated under today, which programme it is moving to, and the expected date. Sales and security teams will be asked this question in questionnaires through the rest of 2026, and a single written answer avoids five different improvised ones. If you are pursuing SOC 2 or ISO 27001 alongside PCI, the same statement supports supplier management controls in both.

There is an AI angle too, and it is the one most teams will miss. A lot of new mobile checkouts are now generated or heavily edited with AI coding tools such as Cursor, Claude Code, Bolt, v0 and Lovable. These tools happily pull in a payment or 3DS SDK, pick a version from training data or a quick search, and wire it up. They do not check which PCI programme that SDK is validated under, whether that programme is in sunset, or whether a newer validated version exists. We made the same point about client side scripts in AI generated checkouts under PCI DSS requirements 6.4.3 and 11.6.1. Whoever owns the payment flow, not the model, has to confirm the SDK and version against the official listing, and that check belongs in code review for any change touching payments.

For ISO 27001, treat this as a supplier relationship and change management item. Annex A controls on supplier agreements and on monitoring supplier services expect you to notice when a supplier assurance basis changes, and a retired validation programme is exactly that. For SOC 2, the vendor management criteria under CC9.2 ask how you assess and monitor vendors that matter to your commitments, so record the change and your follow up. If you are building an AI governance programme under ISO 42001, note any AI system that can modify payment code and make human review of payment SDK changes a stated control. Our PCI DSS, ISO 27001 and SOC 2 guides cover how these controls fit together, and the compliance readiness checklist lists the supplier evidence most assessors ask for.

A short list for this week. Inventory every payment application and SDK in your products and your merchant environment, including mobile 3DS SDKs. For each one, record the PCI programme, the listing reference and the expiry date. Flag anything still resting on 3DS SDK, CPoC or SPoC validation and ask the vendor, in writing, for their MPoC or Secure Software status and dates. Ask your QSA how they will treat those listings in your next assessment. Add a review rule so any pull request that changes a payment SDK version, including one written by an AI coding tool, needs a named human approver who has checked the listing. None of this is hard, but doing it before 31 October costs a few hours and doing it during an assessment costs a lot more.