Реализация NFC-оплаты (HCE) через Android-приложение

Отметим: когда POS-терминал отправляет команду SELECT AID, а HCE-сервис не отвечает корректным FCI — транзакция отклоняется без пояснений. Мы знаем, как этого избежать. Реализация NFC-оплаты через HCE в Android-приложение надёжнее и гибче аппаратного SE — не нужен дополнительный чип, а логика платёжного диалога полностью под вашим контролем. Host-based Card Emulation (HCE) позволяет Android-приложению эмулировать бесконтактную карту без физического Secure Element, но требует точной реализации ISO/IEC 7816-4 поверх NFC. Мы реализуем такой сервис под ключ, с поддержкой APDU-диалога, управлением жизненным циклом и прохождением сертификации EMVCo. Свяжитесь с нами для оценки вашего проекта.

Какие проблемы решает HCE-сервис?

Главная сложность — корректный APDU-диалог с терминалом. Когда POS «видит» телефон, он отправляет серию APDU-команд. Стандартный сценарий EMV Contactless начинается с SELECT PPSE. Приложение должно ответить корректным FCI с именем AID. Дальше терминал выбирает конкретное приложение (SELECT AID), запрашивает параметры транзакции (GET PROCESSING OPTIONS), читает записи (READ RECORD). Каждый ответ — строго по EMV Book 3 и Book C-2. Ошибка в одном байте TLV-структуры — терминал выдаёт «Карта не принята» без подробностей в логах. Отлаживать приходится через NFC-снифер (ACR122U + libnfc + Wireshark) или аппаратный анализатор.

Как избежать конфликтов AID на устройстве

Каждое HCE-приложение регистрирует AID в AndroidManifest.xml через <host-apdu-service>. Если на устройстве несколько приложений с одним AID — Android показывает disambiguation dialog. Для проприетарных AID (диапазон F0xx) это управляемо. Для стандартных (Visa A0000000031010, Mastercard A0000000041010) возникает конфликт с банковскими приложениями — пользователю придётся выбирать каждый раз. Решение — регистрировать собственный проприетарный AID, согласовывать его с процессором и настраивать терминальную сторону на приём. Либо использовать HCE_PAYMENT category с предустановленным AID и корректно обрабатывать конфликты через CardEmulation.setPreferredService().

Как мы реализуем HCE-сервис: архитектура и стек

HostApduService — это Service, который Android запускает при появлении NFC-поля. Главный метод — processCommandApdu(), который вызывается в основном потоке. Блокировать его нельзя: если ответ не придёт за ~500 мс, терминал разрывает соединение.

Типичная структура:

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 или DEACTIVATION_DESELECTED } } 

ApduProcessor — конечный автомат, который держит состояние транзакции: выбран ли PPSE, выбран ли AID, в каком состоянии GPO. Состояние сбрасывается в onDeactivated. Это критично: если не сбросить после DEACTIVATION_LINK_LOSS, следующая транзакция начнётся с неправильного состояния.

Почему тестирование на эмуляторе недостаточно?

Эмулятор Android не симулирует NFC-поле и APDU-диалог полноценно. Для разработки и CI используем:

• ACR122U + PC/SC — USB NFC-ридер, эмулирует терминал на ПК, можно скриптовать APDU-последовательности
• Mastercard PayPass Test Tool — официальный инструмент для валидации EMV-ответов
• EMV-Co contactless test cases — набор сценариев для сертификации

Без прохождения тест-кейсов EMV-Co получить допуск к реальным терминалам Visa/Mastercard не получится. Это отдельный этап проекта. Стандарт EMV Book C-2 насчитывает 48 тест-сценариев; их прохождение занимает от 5 до 10 рабочих дней.

Сравнение подходов к тестированию HCE

Процесс и сроки работы

Работа разбивается на несколько фаз:

1. Анализ требований процессинга и схемы токенизации.
2. Проектирование APDU-диалога под конкретный процессинг.
3. Реализация HCE-сервиса на Kotlin с использованием Jetpack.
4. Интеграция с бэкендом токенизации (защищённая выдача токенов).
5. Тестирование на ACR122U и эмуляторе.
6. Прохождение EMV-Co тестов и сертификация.
7. Подготовка документации и инструкций.

Наша команда имеет 10+ лет опыта в мобильной разработке и более 5 лет — в NFC-решениях. Мы помогли 15+ компаниям внедрить HCE-оплату. Задержка ответа HCE-сервиса не должна превышать 300–500 мс по ISO/IEC 14443-4, а размер APDU-ответа — не более 256 байт. Ориентировочная стоимость: PoC с кастомным AID — от 100 000 ₽, полный цикл с EMV-Co сертификацией — от 400 000 ₽.

Что входит в работу

• Документация APDU-диалога и архитектуры HCE-сервиса.
• Исходный код сервиса с комментариями.
• Тестовый стенд с ACR122U и скриптами.
• Инструкция по прохождению сертификации EMVCo.
• Поддержка на этапе сертификации (доработка по замечаниям).

Ориентировочные сроки

HCE на Android превосходит эмуляцию на iOS по гибкости: на Android можно реализовать любое EMV-приложение, тогда как iOS ограничена Apple Pay. Это даёт в 3 раза больше возможностей для кастомных платёжных систем.

Android HostApduService documentation и EMVCo Contactless Specification Book C-2

Закажите консультацию — оценим ваш проект и предложим оптимальное решение.