Android Host Card Emulation lets your app become a contactless payment card. The phone's NFC controller routes APDUs straight to your HostApduService instead of a hardware secure element — which means any Android 8+ device can run a tap-to-pay wallet. The tradeoff: you own the EMV transaction flow, the key management, and the tokenization lifecycle yourself. This hub maps the five skill areas you need to ship one.
Five bands — the core HCE framework, hardware-backed key security, token provisioning, South African payments reality, and scheme compliance. Each card maps to a leaf in tech/android-hce/*. The HCE Framework explainer is live; the rest land as the tree grows.
Visa Ready and Mastercard lab certification processes, compliance checklists, test card profiles, terminal simulators, and the difference between functional approval and production go-live. The gate between a working prototype and a wallet real people can use at a POS.
Whether you are building a Visa, Mastercard, or private-label wallet, the NFC transaction is always the same EMV dialogue between terminal and phone. The terminal drives the conversation; your HostApduService responds. Learn this flow once and it applies to every card in the hub.
When a phone touches a POS terminal, the NFC controller wakes your service and the terminal sends four commands in sequence. Each command is a raw APDU byte array; your service parses the command, builds the response, and appends SW 9000 (success) to every reply.
// Terminal → Phone: the four-command EMV dialogue 1. SELECT // Terminal sends the AID (Application Identifier) → 00 A4 04 00 07 A0000000031010 // e.g. Visa AID ← FCI template + SW 9000 2. GPO // GET PROCESSING OPTIONS — terminal sends PDOL data → 80 A8 00 00 ... ← AIP + AFL (tells terminal which records to read) + SW 9000 3. READ RECORD // Terminal reads card data (DPAN, expiry, etc.) → 00 B2 01 0C 00 ← EMV record TLVs + SW 9000 4. GENERATE AC // Terminal requests the transaction cryptogram → 80 AE 80 00 ... ← ARQC (online auth) or TC (offline) + SW 9000
The cryptogram in step 4 is the entire security model. It is computed from the LUK (limited-use key), the transaction amount, a terminal-supplied unpredictable number, and a transaction counter. Even if someone intercepts the full NFC exchange, the cryptogram is single-use — it cannot authorise a second transaction. This is why HCE without a hardware secure element is still considered safe enough for contactless payments.
HCE sits in tech/ because the core work is Android systems programming. But the payment rails touch business operations — ERP systems reconcile settlement files — and the token provisioning backend typically runs on edge infrastructure like Cloudflare Workers for low-latency API calls to VTS/MDES.