NFC Payment (HCE) Implementation via Android Application
Host-based Card Emulation — technology allowing Android app to masquerade as contactless card without physical SE (Secure Element). Sounds simple. Actually — implementation of ISO/IEC 7816-4 over NFC with APDU commands, service lifecycle management, AID registration and payment system certification. Most commands like SELECT AID and GET PROCESSING OPTIONS must be implemented manually.
Main Challenge: APDU Dialog with Terminal
When POS terminal "sees" phone, it sends series of APDU commands. Standard EMV Contactless scenario starts with:
00 A4 04 00 07 A0 00 00 00 03 10 10 — SELECT PPSE
App must respond with correct FCI containing AID name. Then terminal selects specific app (SELECT AID), requests transaction parameters via GET PROCESSING OPTIONS, reads records via READ RECORD. Each response — strictly per EMV Book 3 and Book C-2.
One byte error in TLV structure — terminal returns "Card not accepted" with no details in app logs. Debugging requires NFC sniffer (e.g., ACR122U + libnfc + Wireshark) or hardware protocol analyzer.
AID Registration and Conflicts
Each HCE app registers AID in AndroidManifest.xml via <host-apdu-service>. Multiple apps with one AID — Android shows disambiguation dialog. For proprietary AIDs manageable. For standard ones (Visa: A0000000031010, Mastercard: A0000000041010) conflict with banking apps — user must choose every time.
Solution — register proprietary AID in range F0xx..., coordinate with processor, configure terminal to accept. Or use HCE_PAYMENT category with preinstalled AID and properly handle conflicts via CardEmulation.setPreferredService().
HCE Service Architecture
HostApduService — a Service Android launches when NFC field appears. Main method — processCommandApdu(), called on main thread. Blocking it forbidden: if response doesn't arrive within ~500 ms, terminal disconnects.
Typical structure:
class PaymentHceService : HostApduService() {
private val apduProcessor = ApduProcessor()
override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
return apduProcessor.process(commandApdu)
}
override fun onDeactivated(reason: Int) {
apduProcessor.reset()
// reason: DEACTIVATION_LINK_LOSS or DEACTIVATION_DESELECTED
}
}
ApduProcessor — state machine holding current transaction state: PPSE selected, AID selected, GPO state. State resets in onDeactivated. Critical: not resetting after DEACTIVATION_LINK_LOSS — next transaction starts with wrong state.
Token Security
Cannot store real PAN data in app. Modern scheme — dynamic tokens: server issues single-use cryptogram for each transaction. App requests token early (when opening payment screen), stores encrypted in EncryptedSharedPreferences or Android Keystore, transmits to terminal in READ RECORD response.
Token lifetime — usually 30–60 minutes or one transaction. On expiry — app requests new before next transaction, not during processCommandApdu (no time for network request).
Testing Without Real POS Terminal
For development and CI:
- ACR122U + PC/SC — USB NFC reader, emulates terminal on PC, can script APDU sequences
- Mastercard PayPass Test Tool — official EMV response validation
- EMV-Co contactless test cases — certification scenario set
Without passing EMV-Co test cases, can't get access to real Visa/Mastercard terminals. Separate project phase.
Process and Timeframes
Work divided into phases: design APDU dialog for specific processor → implement HCE service → integrate with backend tokenization → test on real terminals → prepare certification documentation.
Minimum PoC with custom AID — 2–3 weeks. Full integration with EMV certification — from 2 months. Exact timeframes after processor requirements and tokenization scheme study.