The MPoC Guidance Document addresses a common issue: an SDK passes validation, your application integrates it, but the lab flags dependencies or listing mismatches during assessment. This document complements the MPoC Standard v1.1 and the MPoC Program Guide v1.1, and answers frequently asked questions from feedback channels, technical working groups, and industry sessions.
This checklist translates the guidance into a pre-integration validation protocol. Use it before committing to an SDK vendor and again before submitting for assessment.
Purpose of This Checklist
You're evaluating an MPoC SDK for integration into your payment application on a commercial off-the-shelf Android or iOS device. This checklist ensures:
- The SDK you select is eligible under the MPoC framework.
- Your integration approach aligns with listing and dependency requirements.
- You've documented the relationships the lab will verify during your assessment.
This isn't a substitute for reading the MPoC Standard v1.1 or the MPoC Program Guide v1.1. It's a structured tool to flag integration issues before you write code.
Prerequisites
Before using this checklist:
- Confirm your solution falls under one of the three MPoC product categories: MPoC SDK, MPoC Application, or MPoC Integrated Solution.
- Identify whether your application will be listed independently or as part of a vendor-provided integrated solution.
- Obtain access to the PCI SSC Document Library to cross-reference the MPoC Guidance Document, Technical FAQs v1.8, and current SDK listings.
If you're building a custom payment application without an SDK, this checklist doesn't apply. Validate the application itself under the MPoC Standard.
The Checklist
SDK Eligibility and Listing Verification
- Confirm the SDK appears on the current PCI SSC MPoC Listings page.
- Record the SDK version number and listing date.
- Verify the SDK listing status is "Active" (not "Expired" or "Under Review").
- Document the SDK vendor's name exactly as it appears in the listing.
- Confirm the SDK supports your target OS version (Android/iOS).
- Identify whether the SDK is listed as a standalone MPoC SDK or as part of an integrated solution.
Why this matters: An unlisted or expired SDK can't be used in a compliant MPoC deployment. Labs will reject your application during assessment if the SDK dependency is invalid.
Product Type and Relationship Mapping
- Determine your product type: MPoC SDK, MPoC Application, or MPoC Integrated Solution.
- If you're building an MPoC Application, confirm whether you're integrating a listed MPoC SDK or building payment logic directly.
- If you're using an MPoC Integrated Solution, confirm the vendor has listed the complete solution (SDK + application) as a single entity.
- Document the dependency chain: your application → SDK → cryptographic libraries → OS-level security features.
- Identify any third-party libraries your application introduces outside the SDK boundary.
Why this matters: The MPoC Guidance Document clarifies how product types interact. Misclassifying your product type can lead to a failed listing application.
Integration Report Requirements
- Confirm whether the SDK vendor provides an Integration Report as part of their listing.
- If an Integration Report is required, request a copy from the vendor before integration begins.
- Review the Integration Report for mandatory integration steps, prohibited modifications, and supported configuration parameters.
- Document any deviations from the Integration Report your implementation requires.
- Confirm whether your integration approach requires a separate assessment or falls under the SDK's existing validation.
Why this matters: The Integration Report defines the validated security boundary. Modifying SDK behavior outside the report's scope creates an untested configuration that won't pass assessment.
Dependency and Update Tracking
- List all SDK dependencies (cryptographic libraries, OS frameworks, third-party components).
- Confirm each dependency is explicitly covered in the SDK's validation report.
- Document the SDK's update policy: How will you be notified of security patches or version updates?
- Establish a process for re-validation if the SDK updates to a new major version.
- Confirm whether your application's listing must be updated if the SDK version changes.
Why this matters: SDK updates can invalidate your application's listing if the new version wasn't part of your original assessment. The MPoC Guidance Document clarifies when re-listing is required.
Vendor Verification and Support
- Confirm the SDK vendor provides technical support during your assessment process.
- Request a statement from the vendor confirming your integration approach is supported.
- Document the vendor's escalation path for integration questions during lab testing.
- Verify the vendor will provide updated documentation if the MPoC Standard or Guidance Document changes.
- Confirm the vendor's listing includes your target deployment region (if region-specific restrictions apply).
Why this matters: Labs expect vendors to verify that your integration aligns with their validated configuration. If the vendor can't or won't confirm support, the lab may require additional evidence.
Customizing the Checklist
Adjust this checklist based on your product type:
If you're building an MPoC Application integrating a third-party SDK: Add a section documenting how your application handles cardholder data outside the SDK boundary. If your app displays PAN, stores transaction logs, or transmits data independently, those flows need separate validation.
If you're a vendor listing an MPoC SDK: Expand the Integration Report section to include sample code, prohibited API calls, and configuration parameters your customers must follow. The more specific your Integration Report, the fewer assessment failures your customers will face.
If you're deploying an MPoC Integrated Solution: Replace the SDK Eligibility section with a section confirming the solution vendor has listed the entire stack. You don't need to verify individual SDK listings if the vendor has listed the integrated solution as a single product.
Validation Steps
After completing the checklist:
Cross-reference the MPoC Listings page. Confirm every SDK and dependency you documented appears in the current listings. If you find discrepancies, contact the vendor before proceeding.
Review the MPoC Technical FAQs v1.8. The September 2025 FAQ document addresses edge cases not covered in the Guidance Document. If your integration involves custom cryptography, non-standard OS configurations, or multi-vendor dependencies, check the FAQs for clarification.
Submit a pre-assessment inquiry to your lab. Before committing to development, send the completed checklist to your assessment lab. Ask them to confirm your integration approach aligns with current MPoC requirements. This step catches listing mismatches before you build.
Document your validation in your assessment package. When you submit for assessment, include this completed checklist and any vendor correspondence. Labs expect you to demonstrate due diligence during SDK selection.
If you identify gaps during validation, don't proceed with integration. An SDK that doesn't meet listing requirements or lacks vendor support will fail assessment, and retrofitting compliance into a deployed application is expensive.
The MPoC Guidance Document clarifies what the standard requires. This checklist ensures you've verified those requirements before you write the first line of integration code.
