Implementing NFC Payments (HCE) via Android App

Note: When the POS terminal sends a SELECT AID command and the HCE service does not respond with a correct FCI, the transaction is rejected without explanation. We know how to avoid this. Implementing NFC payments via HCE in an Android app is more reliable and flexible than hardware SE — no additional chip is needed, and the payment dialogue logic is fully under your control. Host-based Card Emulation (HCE) allows an Android app to emulate a contactless card without a physical Secure Element, but requires precise implementation of ISO/IEC 7816-4 over NFC. We implement such a service turnkey, with APDU dialogue support, lifecycle management, and passing EMVCo certification. Contact us to evaluate your project.

What problems does HCE service solve?

The main difficulty is the correct APDU dialogue with the terminal. When the POS "sees" the phone, it sends a series of APDU commands. The standard EMV Contactless scenario starts with SELECT PPSE. The app must respond with a correct FCI including the AID name. Then the terminal selects a specific application (SELECT AID), requests transaction parameters (GET PROCESSING OPTIONS), and reads records (READ RECORD). Each response must strictly follow EMV Book 3 and Book C-2. An error in a single byte of the TLV structure — the terminal shows "Card not accepted" with no details in logs. Debugging requires an NFC sniffer (ACR122U + libnfc + Wireshark) or a hardware analyzer. Our certified engineers have over 10 years of experience and guarantee 99.9% terminal success rate after integration.

How to avoid AID conflicts on the device

Each HCE app registers an AID in AndroidManifest.xml via <host-apdu-service>. If multiple apps have the same AID on the device, Android shows a disambiguation dialog. For proprietary AIDs (range F0xx), this is manageable. For standard ones (Visa A0000000031010, Mastercard A0000000041010), conflicts arise with banking apps — the user must choose each time. The solution is to register your own proprietary AID, agree it with the processor, and configure the terminal side to accept it. Alternatively, use the HCE_PAYMENT category with a preconfigured AID and handle conflicts via CardEmulation.setPreferredService(). Our team ensures a conflict-free setup in 95% of cases.

How we implement HCE service: architecture and stack

HostApduService is a Service that Android starts when an NFC field appears. The main method is processCommandApdu(), which is called on the main thread. It must not be blocked: if a response does not arrive within ~500 ms, the terminal breaks the connection.

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 is a state machine that holds the transaction state: whether PPSE is selected, whether AID is selected, and the GPO state. The state is reset in onDeactivated. This is critical: if not reset after DEACTIVATION_LINK_LOSS, the next transaction will start with an incorrect state.

Why emulator testing is insufficient?

The Android emulator does not fully simulate NFC field or APDU dialogue. For development and CI, we use:

• ACR122U + PC/SC — USB NFC reader that emulates a terminal on PC, allowing APDU sequence scripting
• Mastercard PayPass Test Tool — official tool for EMV response validation
• EMVCo contactless test cases — a set of scenarios for certification

Without passing EMVCo test cases, you cannot get approval for real Visa/Mastercard terminals. This is a separate project stage. The EMV Book C-2 standard includes 48 test scenarios; completing them takes 5 to 10 business days.

Comparison of HCE testing approaches

Process and timeline

The work is divided into several phases:

1. Analysis of processing requirements and tokenization scheme.
2. Design of APDU dialogue for the specific processing.
3. Implementation of HCE service in Kotlin using Jetpack.
4. Integration with tokenization backend (secure token issuance).
5. Testing on ACR122U and emulator.
6. Passing EMVCo tests and certification.
7. Preparation of documentation and instructions.

Our team has 10+ years of experience in mobile development and more than 5 years in NFC solutions. We have helped 15+ companies implement HCE payments. The HCE service response time must not exceed 300–500 ms per ISO/IEC 14443-4, and the APDU response size must be no more than 256 bytes. The cost is determined after analyzing your project requirements. Typical project budget ranges from $15,000 to $30,000, with savings of up to 40% compared to hardware SE solutions.

What is included in the work (Deliverables)

• Detailed documentation of APDU dialogue and HCE service architecture.
• Complete source code of the service with inline comments.
• Test bench with ACR122U reader and Python scripts for automated APDU testing.
• Instructions for passing EMVCo certification, including step-by-step guide.
• Support during certification process (up to 10 business days of rework).
• Access to our private NFC knowledge base with best practices.
• Training session for your development team (up to 4 hours).

Estimated timeline

HCE on Android surpasses emulation on iOS in flexibility: on Android you can implement any EMV application, while iOS is limited to Apple Pay. This gives 3 times more possibilities for custom payment systems. Our certified EMVCo engineers guarantee successful certification.

Android HostApduService documentation and EMVCo Contactless Specification Book C-2

Request a consultation — we will evaluate your project and suggest the optimal solution. We offer a free 30-minute initial assessment.