Android
AuraScore 83/100

Android Host Card Emulation and Contactless Payment Readiness Checklist

Audit and validate Host Card Emulation (HCE), APDU protocol routing, and contactless EMV payment flows on Android.

Use this checklist when engineering, testing, or certifying an Android contactless payment solution utilizing Host Card Emulation. It covers AID table management, APDU dispatch performance, token lifecycle, and PCI-CPoC compliance.

Template

Role: Senior Android Payments Specialist with expertise in Host Card Emulation (HCE), EMVCo specifications, and tokenized payment kernel engineering.

Context

  • Target Payment Application / SDK: {{app_name}}
  • Supported Card Networks and Schemes: {{payment_scheme}}
  • Application Identifier (AID) Configuration: {{aid_configuration}}
  • Token Service Provider Gateway: {{token_service_provider}}
  • APDU Command Handling Architecture: {{apdu_handling_strategy}}
  • Contactless Payment Security Standard: {{pci_compliance_standard}}

Task

Produce an in-depth, engineering-grade Host Card Emulation (HCE) certification checklist to validate that {{app_name}} correctly executes contactless transactions, handles APDU exchanges within latency thresholds, and secures payment tokens in compliance with {{pci_compliance_standard}}.

Method

  1. Inspect Android manifest declarations, evaluating HostApduService definitions, AID groups, and dynamic AID registration protocols configured for {{payment_scheme}}.
  2. Review the APDU processing pipeline against {{apdu_handling_strategy}}, auditing command parsing for SELECT AID, GET PROCESSING OPTIONS (GPO), and READ RECORD.
  3. Validate lifecycle synchronization between {{app_name}} and {{token_service_provider}}, ensuring single-use replenishment, limited-use keys (LUK), and active token invalidation.
  4. Establish latency profiling criteria to ensure APDU exchange completion remains strictly under terminal timeout constraints (e.g., sub-400ms end-to-end).
  5. Formulate security validation tests for transaction counter verification, cryptogram generation (ARQC/TC), and offline data authentication (ODA) handling.
  6. Detail foreground dispatch and payment conflict resolution checks when competing contactless wallet applications are registered on the host device.
  7. Create verification procedures for out-of-band Consumer Device Cardholder Verification Method (CDCVM) using device credentials or biometric confirmation.
  8. Formulate failure mode diagnostics covering field collision, premature terminal removal (torn transactions), and fallback authentication.

Constraints

  • Checklist items MUST include specific APDU status words (e.g., 0x9000, 0x6A82, 0x6985) for each relevant test scenario.
  • You MUST enforce strict token obfuscation and memory sanitization rules in alignment with {{pci_compliance_standard}}.
  • You MUST NOT permit blocking operations or thread sleep calls on the Android HCE main execution thread.
  • All test assertions must state the expected behavior across both screen-locked and device-unlocked operational states.

Output format

  • HCE Architecture Readiness Summary (max 150 words)
  • Five thematic audit sections: 1. Service Declaration & AID Routing, 2. APDU Exchange & Latency, 3. Token & Cryptogram Lifecycle, 4. CDCVM & Screen State, 5. Torn Transactions & Error Handling
  • Each section must present 4-5 checklist items formatted as: [ ] Test ID | Objective | ISO/IEC 7816-4 APDU Scenario | Expected SW / Output | Pass Criteria
  • Pre-Certification Sign-off Matrix

Self-review

  1. Does the checklist cover dynamic AID conflict handling when multiple payment apps are present on Android?
  2. Are all parameters ({{app_name}}, {{payment_scheme}}, {{aid_configuration}}, {{token_service_provider}}, {{apdu_handling_strategy}}, {{pci_compliance_standard}}) deeply contextualized?
  3. Are torn transaction and tear-recovery routines explicitly accounted for in the validation steps?
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-android
financial-services
android
payments
nfc