PCI-DSS Compliance Checklist for Android Apps

  

In modern mobile payment ecosystems, Android applications are no longer “thin clients.” They participate actively in data capture, encryption, authentication, and transaction orchestration. As a result, an Android app can significantly expand or reduce PCI-DSS scope depending on how it is architected.

This checklist is aligned with PCI DSS v4.0.1, the active standard as of 2025, and focuses on practical, Android-specific controls that help meet compliance while reducing real-world risk.

1. Scope Control: The Most Important Design Decision

The fastest way to reduce PCI exposure is scope minimization.

Recommended architectural principles

• Avoid handling Primary Account Number (PAN) inside the Android app wherever possible.
• Prefer hosted payment pages, redirect-based flows, or payment provider SDKs that ensure card data never traverses app memory or backend services.

If PAN entry is unavoidable, ensure:

• PAN is transmitted directly to the payment gateway
• Backend services receive tokens only, never raw card data
• Sensitive Authentication Data (SAD) such as CVV, PIN blocks, or track data must never be stored post-authorization.

Outcome: A well-designed Android app can remain out of the Cardholder Data Environment (CDE).

2. Data Flow Mapping (Non-Negotiable)

Before controls are applied, data movement must be understood.

Maintain a living inventory of:

• Screens where PAN or tokens may appear
• Data paths: UI → memory → network → SDK → backend

Secondary channels:

• logs
• analytics
• crash reporting
• screenshots
• clipboard
• autofill and accessibility services

This document becomes core PCI evidence and is critical during audits.

3. Protect Stored Account Data (PCI Requirement 3)

The strongest control is non-storage. When storage cannot be avoided, Android must enforce cryptographic isolation.

Android storage rules

Never store PAN in:

• SharedPreferences / DataStore
• SQLite / Room
• files, cache, screenshots, logs
• Store provider tokens only, never real card numbers
• All sensitive material must be encrypted using keys protected by Android Keystore

Example: AES key generation using Android Keystore

val keyGenerator = KeyGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_AES,
    "AndroidKeyStore"
)

val keySpec = KeyGenParameterSpec.Builder(
    "pci_aes_key",
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
    .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .setUserAuthenticationRequired(false)
    .setKeySize(256)
    .build()
keyGenerator.init(keySpec)
keyGenerator.generateKey()

Additional hardening

• Use hardware-backed keystore where available
• Disable automatic backups:

<application
    android:allowBackup="false"
    android:fullBackupContent="false">
</application>

• Prevent screenshots on sensitive screens:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

4. Encrypt Data in Transit (PCI Requirement 4)

All card-related traffic must be encrypted using strong cryptography.

Android network controls

• Enforce TLS 1.2+ (prefer TLS 1.3)
• Block cleartext traffic at OS level
• Harden WebView traffic
• Apply certificate pinning for payment and authentication endpoints

Example: Network Security Config

<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

Certificate pinning (OkHttp example)

val certificatePinner = CertificatePinner.Builder()
    .add("api.payment.com", "sha256/AAAAAAAAAAAAAAAAAAAA...")
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Important: Always maintain a pin rotation strategy to avoid production lockouts.

5. Secure Development Lifecycle (PCI Requirement 6)

PCI DSS v4.x places strong emphasis on secure software development.

Mandatory practices

• Threat modeling for all payment flows
• Secure coding aligned with modern mobile security baselines

Dependency governance:

• version pinning
• removal of abandoned libraries
• SBOM generation

Secrets management:

• no API keys inside APK
• use short-lived backend-issued tokens
• Release hardening:
• R8 / ProGuard enabled
• debug logs stripped
• debuggable flag disabled

6. Vulnerability Management & Testing (PCI Requirements 6 & 11)

Required testing layers

• Static analysis for Kotlin/Java
• Dependency vulnerability scanning

Mobile penetration testing:

• runtime instrumentation
• MITM attempts
• rooted/emulator environments
• Continuous patching discipline with defined SLAs

Runtime abuse detection (example signal)

val isDebuggerAttached = Debug.isDebuggerConnected()
if (isDebuggerAttached) {
    // Raise risk signal, do not rely on this as sole control
}

Client-side signals are risk indicators, not enforcement mechanisms.

7. Access Control & Authentication (PCI Requirements 7 & 8)

Android-specific expectations

• Device identity ≠ user identity
• Use OAuth2 / OIDC patterns with short-lived access tokens
• Secure refresh token storage via Keystore

Step-up authentication for:

• adding cards
• refunds
• payout changes
• Enforce session expiry and inactivity timeouts

8. Logging, Monitoring & Log Hygiene (PCI Requirement 10)

Non-negotiable rules

• Never log PAN or SAD (even masked incorrectly)

Sanitize:

• network logs
• analytics events
• crash reports
• Use correlation IDs instead of payload duplication

Example: Safe logging

Log.i("PaymentEvent", "Transaction started, id=$transactionId")

Never log request or response bodies that may contain payment data.

9. Third-Party SDK & Payment Software Responsibility

• PA-DSS is retired; payment software now falls under Secure Software and Secure Software Lifecycle standards.
• Clearly document:
• what the Android app is responsible for
• what the payment SDK/provider secures
• Treat third-party SDKs as extensions of your attack surface

10. Audit-Ready Evidence Checklist

Maintain the following artifacts:

• PCI scope definition & data-flow diagrams
• Proof of non-storage of PAN/SAD
• Keystore usage documentation
• TLS and pinning configuration
• Secure SDLC records
• Penetration test reports with remediation tracking

These artifacts convert compliance from a last-minute scramble into a predictable process.

Closing Note

PCI-DSS compliance for Android applications is not a checkbox exercise and not something that can be “patched in” before an audit. It is the outcome of intentional architectural decisions, strict data-handling discipline, and continuous security validation.

Well-designed Android apps:

• aggressively minimize PCI scope
• avoid storing sensitive card data entirely
• treat runtime security as a layered risk model
• align engineering practices with evolving PCI standards

When compliance is embedded into design, it stops being a blocker — and becomes a competitive reliability signal for payment platforms operating at scale.

---

PCI-DSS Compliance Checklist for Android Apps was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.