Реалізація 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-відповідей
• EMVCo contactless test cases — набір 48 сценаріїв для сертифікації

Без проходження тест-кейсів EMVCo отримати допуск до реальних терміналів Visa/Mastercard не вийде. Це окремий етап проекту. Стандарт EMV Book C-2 налічує 48 тест-сценаріїв; їх проходження займає від 5 до 10 робочих днів. Завдяки нашому досвіду ми скорочуємо цей час на 30%.

Порівняння підходів до тестування HCE

Процес і терміни роботи

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

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

Наша команда має 10+ років досвіду в мобільній розробці та більше 5 років — у NFC-рішеннях. Ми допомогли 15+ компаніям впровадити HCE-оплату. Затримка відповіді HCE-сервісу не повинна перевищувати 300–500 мс за ISO/IEC 14443-4, а розмір APDU-відповіді — не більше 256 байт. Вартість визначається після аналізу вашого проекту: базовий PoC — від $1500, повна інтеграція з сертифікацією — від $12000.

Що входить в роботу

• Документація APDU-діалогу та архітектури HCE-сервісу.
• Вихідний код сервісу з коментарями.
• Тестовий стенд з ACR122U та скриптами.
• Інструкція з проходження сертифікації EMVCo.
• Підтримка на етапі сертифікації (доопрацювання за зауваженнями).
• Гарантія якості: ми несемо відповідальність за проходження сертифікації.

Орієнтовні терміни та вартість

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

Android HostApduService documentation та EMVCo Contactless Specification Book C-2

Замовте консультацію — оцінимо ваш проект та запропонуємо оптимальне рішення. Ми сертифіковані партнери EMVCo та гарантуємо якість.