Purpose of This Checklist
Preparing a mobile payment solution for MPoC assessment involves submitting your SDK or application to a laboratory for evaluation against the MPoC Standard v1.1. Before scheduling this lab engagement, your internal audit team must ensure you've met integration requirements, vendor eligibility criteria, and listing dependencies that assessors will examine.
This checklist guides you through the vendor verification steps clarified in the PCI Security Standards Council's new MPoC Guidance Document. Use it to identify gaps before your lab does, especially around SDK relationships, integration reports, and product listing requirements. Each section corresponds to specific areas the guidance document expands upon: MPoC product types, SDK and application relationships, listing requirements, and vendor verification eligibility.
Prerequisites
Before using this checklist, confirm:
- You've reviewed MPoC Standard v1.1 and know which product category applies to your solution (MPoC SDK, MPoC Application, or MPoC Solution).
- You have access to the MPoC Program Guide v1.1 and the MPoC Technical FAQs (v1.8, September 2025).
- Your development team can provide documentation on third-party SDK dependencies and integration points.
- You know which payment brands and acquirers will deploy your solution.
If you're unsure about your product category, stop here. The guidance document defines three MPoC product types and their interactions. Misclassifying your solution can cause significant issues during assessment.
The Checklist
Product Type Classification
Confirm your product category. Are you submitting an MPoC SDK, an MPoC Application, or an MPoC Solution? Document which category applies and why.
Identify all integration points. If you're an SDK provider, list every application that will integrate your SDK. If you're an application provider, list every SDK you've integrated. These relationships determine your listing requirements.
Map dependencies to listed products. Check the PCI SSC MPoC Listings to verify that any SDK you integrate is currently listed and approved. An unlisted or expired SDK invalidates your application's eligibility.
SDK and Application Relationship Verification
Document SDK version control. If your SDK will be integrated by multiple applications, define how you'll notify integrators of security updates. The guidance document addresses how SDK updates affect downstream applications.
Verify integration report completeness. If you're submitting an application that uses a third-party MPoC SDK, prepare an Integration Report that demonstrates how your application implements the SDK's security controls. This report must show you haven't introduced vulnerabilities through your integration.
Test for integration weaknesses. Run penetration tests targeting the boundary between your application code and the integrated SDK. Common failures include insecure data passing, improper error handling, and credential exposure at integration points.
Confirm SDK eligibility for your use case. Not every listed MPoC SDK is eligible for every deployment scenario. Verify that the SDK you're integrating supports your target device types, operating system versions, and transaction flows.
Listing Requirements Audit
Review listing expiration dates. MPoC listings aren't permanent. Check when your dependencies' listings expire and plan reassessment timing accordingly. If a dependency's listing lapses, your solution falls out of compliance.
Understand update triggers. The guidance document clarifies when product updates require relisting. Document what changes (SDK version updates, OS compatibility additions, cryptographic library changes) will trigger reassessment.
Prepare for multi-party coordination. If your solution depends on multiple listed components, coordinate timing with those vendors. A single expired dependency invalidates your entire solution's listing.
Verify listing visibility requirements. Confirm whether your solution will appear in public MPoC listings or remain under a private arrangement with specific payment brands. This affects your documentation obligations.
Vendor Verification Evidence
Compile SDK eligibility documentation. If you're an SDK provider, gather evidence that your SDK meets the program's eligibility criteria. The guidance document addresses SDK eligibility questions that laboratories frequently raise.
Prepare integration evidence. For application providers, document every security-relevant decision made during SDK integration. Assessors will ask why you implemented specific controls and how you validated their effectiveness.
Document cryptographic implementations. List every cryptographic operation your solution performs, the libraries you use, and how you protect key material. Cross-reference these implementations against MPoC Standard requirements.
Test transaction flow isolation. Verify that your solution properly isolates payment transactions from other device functions. This is a common assessment failure point, especially for applications running on shared Commercial Off-The-Shelf devices.
Customizing This Checklist
Your solution's complexity determines how you'll adapt this checklist:
If you're an SDK provider: Expand the SDK relationship section to include every known integration scenario. Add specific version control procedures and security update notification protocols.
If you're an application provider: Focus on the integration report requirements. Add detailed testing procedures for each SDK integration point and document your validation methodology.
If you're submitting a bundled solution: Address both SDK and application requirements. Split this checklist into two parallel tracks and assign clear ownership for each component.
Add your organization's internal control requirements to each section. If you have existing secure development lifecycle gates, map them to the relevant checklist items. For example, if you require threat modeling for all external integrations, add that step under "SDK and Application Relationship Verification."
Validation Steps
After completing the checklist:
Run a pre-assessment review with your laboratory. Most MPoC assessment labs offer pre-engagement consultations. Share your completed checklist and ask them to identify gaps before formal testing begins.
Cross-reference against MPoC Technical FAQs v1.8. The September 2025 FAQ update addresses common interpretation questions. If your checklist responses conflict with FAQ guidance, revise your approach.
Test your integration report against assessment criteria. If you're submitting an application with an integrated SDK, have a security architect who wasn't involved in development review your Integration Report. They should be able to understand your security decisions from the documentation alone.
Verify all dependencies are currently listed. Check the PCI SSC Document Library the week before your lab submission. Listings change, and you don't want to discover an expired dependency during assessment.
Document your rationale for classification decisions. If an assessor questions your product category or integration approach, you'll need to explain your reasoning with reference to the guidance document's definitions.
The MPoC Guidance Document reflects extensive collaboration with global stakeholders through the Council's Mobile Working Group and Technology Guidance Group. That collaborative process means the guidance addresses real implementation challenges that solution providers and laboratories have encountered. Use it as your reference when questions arise during this checklist process.
Your goal isn't just to pass assessment. It's to demonstrate that your solution maintains payment security on devices you don't control, in environments you can't monitor, with users you can't train. That's the MPoC challenge. This checklist helps you prove you've addressed it.
