Як підключити POS-термінал до мобільного застосунку?
Підключення мобільного застосунку до POS-термінала — це не просто «надіслати суму на термінал». Це інтеграція із закритими протоколами обладнання, які у кожного виробника свої, плюс обробка всіх можливих збоїв зв'язку в момент фінансової операції. Ми в компанії маємо 7+ років досвіду в мобільній розробці та реалізували понад 20 інтеграцій з POS-терміналами для різних еквайєрів. Наш підхід — повне покриття всіх edge-кейсів, щоб кожна транзакція була завершена коректно.
Типова ситуація: касир у супермаркеті проводить оплату через мобільний застосунок, термінал авторизує картку, але зв'язок обривається. Що робити? Наше рішення включає автоматичний запит статусу останньої транзакції та механізм повторного підключення з 5 спробами, що дає 99% успішного визначення статусу. Замовте інтеграцію під ключ — ми беремо на себе всі етапи: від аналізу протоколів до тестування на реальному обладнанні. Оцінимо ваш проект протягом двох робочих днів.
Протоколи та виробники
Більшість POS-терміналів у торговельному ритейлі спілкуються за одним із стандартних інтерфейсних протоколів:
- ECR-протокол (Electronic Cash Register) — набір команд для передачі суми з касового застосунку на термінал. У кожного банку-еквайєра або виробника — своя реалізація. Ощадбанк, ПриватБанк, Ingenico, Verifone — у всіх відрізняється синтаксис команд і поля відповіді.
- OPI (Open Payment Initiative) / OPOS (OLE for POS) — більш стандартизовані протоколи, популярні в Європі.
- Proprietary SDK: PAX A-серія, Sunmi V2, Newland — мають власні Android SDK (термінал сам працює на Android, викликаємо AIDL-інтерфейс або Intent).
Перед початком розробки уточнюємо у клієнта: який конкретний термінал, який банк-еквайєр, який протокол підтримується. Це не технічний вибір розробника — це факти про встановлене обладнання.
| Протокол | Виробники | Складність | Швидкість | Стандартизація |
|---|---|---|---|---|
| ECR | Ощадбанк, ПриватБанк, Альфа-Банк | Середня | Висока | Ні, своя реалізація |
| OPI/OPOS | Ingenico, Verifone | Висока | Середня | Є |
| Proprietary SDK | PAX, Sunmi, Newland | Низька | Висока | Ні |
Які інтерфейси використовуються?
Bluetooth (BLE + Classic). Термінал виступає GATT-сервером (BLE) або classic Bluetooth serial device. На iOS: CoreBluetooth для BLE, classic Bluetooth — тільки через ExternalAccessory framework з MFi-сертифікацією. Це важливе обмеження: більшість POS-терміналів використовують classic Bluetooth SPP-профіль, а iOS без MFi-сертифіката виробника термінала не зможе підключитися через classic BT. На Android обмежень немає — BluetoothSocket + RFCOMM.
USB. Android: UsbManager, UsbDeviceConnection. iOS: Lightning/USB-C аксесуар — знову потрібен MFi. На практиці USB-підключення зустрічається рідше, ніж Bluetooth.
TCP/IP (Wi-Fi / LAN). Термінал у локальній мережі, застосунок підключається по IP:Port і надсилає команди в текстовому або бінарному форматі. URLSession / OkHttp для HTTP-команд або CFStream / Java Socket для raw TCP. Найбільш передбачуваний інтерфейс з точки зору iOS.
Флоу платіжної операції
- Застосунок формує команду «продаж» із сумою та додатковими параметрами.
- Надсилає на термінал.
- Термінал показує користувачеві екран оплати, приймає картку.
- Повертає відповідь: статус (
approved/declined/error), код авторизації, RRN, маскований PAN. - Застосунок обробляє відповідь та продовжує бізнес-флоу (закриває чек, оновлює замовлення).
Кроки 2–4 можуть зайняти до 60–90 секунд при повільному еквайрингу. На цей період показуємо spinner з повідомленням «Очікування відповіді термінала» та кнопку «Скасувати» (яка надсилає команду скасування на термінал, а не просто закриває екран).
Що робити при обриві зв'язку під час транзакції?
Найнеприємніший кейс: транзакція пішла на термінал, зв'язок перервався — застосунок не знає, чи пройшов платіж. Термінал авторизував картку, але відповідь не дійшла.
Правильна схема: при втраті зв'язку — пробуємо отримати статус останньої транзакції (команда «запит останньої операції»). Якщо термінал відповідає — беремо статус звідти. Якщо ні — показуємо оператору «Статус невідомий, перевірте термінал» і зберігаємо транзакцію в PENDING статусі. Автоматичне списання при невідомому статусі — неприпустимо.
Reconnect logic: при обриві Bluetooth — автоматичне перепідключення з 5 спробами, exponential backoff. Стан з'єднання — завжди видно в UI (іконка статусу).
Повернення та скасування
Скасування транзакції (reversal) — до закриття фінансового дня. Повернення (refund) — після. Обидва вимагають окремих команд на термінал з RRN вихідної транзакції. Реалізуємо обидва сценарії — оператор повинен мати можливість виправити помилку.
Порівняння платформ: Android vs iOS
| Аспект | Android | iOS |
|---|---|---|
| Classic BT (SPP) | Нативно, BluetoothSocket |
Тільки MFi-пристрої |
| BLE | BluetoothGatt |
CoreBluetooth |
| USB | UsbManager |
Тільки MFi |
| TCP/IP | Socket / OkHttp |
CFStream / URLSession |
Якщо замовник вимагає iOS і термінал працює тільки по classic Bluetooth без MFi — єдиний шлях: TCP/IP через проміжний адаптер або перехід на термінал з BLE/TCP підтримкою.
До речі, протокол BLE зазвичай забезпечує нижчу затримку (до 50 мс) порівняно з classic Bluetooth (100–200 мс), що прискорює транзакцію в 2–4 рази. Це важливо для сценаріїв з високою пропускною здатністю. Більше деталей в документації Apple по CoreBluetooth.
Типові помилки при інтеграції
- Неврахування MFi-сертифікації для iOS на classic Bluetooth — призводить до неможливості підключення.
- Відсутність retry logic при обриві — втрачені транзакції.
- Використання непідходящого протоколу (наприклад, ECR для термінала, який підтримує тільки OPI).
- Неправильний парсинг відповіді термінала (різні коди помилок у різних виробників).
Що входить в роботу
- Аналіз обладнання та протоколів еквайєра.
- Реалізація транспортного шару (Bluetooth/USB/TCP).
- Розробка протоколу команд (продаж, скасування, повернення, запит статусу).
- Обробка edge-кейсів (обрив зв'язку, таймаут, невідомий статус).
- Тестування на реальному терміналі в тестовому режимі еквайєра.
- Документація з інтеграції для підтримки клієнта.
- Гарантія на транспортний шар: 6 місяців безкоштовної підтримки.
Вартість інтеграції фіксується на етапі ТЗ, а окупність досягається за рахунок автоматизації ручного введення даних. Отримайте консультацію щодо вашого проекту — оцінимо складність та терміни.
Процес роботи
З'ясування моделі термінала та протоколу → вивчення документації еквайєра → реалізація транспортного шару (BT/USB/TCP) → протокол команд (продаж, скасування, повернення, запит статусу) → обробка edge-cases (обрив зв'язку, таймаут) → тестування на реальному терміналі в тестовому режимі еквайєра → бойове тестування → експлуатація.
Орієнтири за термінами
Базова інтеграція (продаж + відповідь) за конкретним протоколом з одним інтерфейсом: 3–5 днів. Повний набір операцій (продаж, скасування, повернення, запит статусу) + retry/reconnect logic + кілька інтерфейсів: 2–3 тижні.
Наша команда — мобільні розробники з 7+ років досвіду в iOS (Swift, SwiftUI, CoreBluetooth) та Android (Kotlin, Jetpack Compose, BluetoothSocket). Ми працювали з терміналами PAX, Ingenico, Verifone, Sunmi. Ми гарантуємо якість інтеграції та прозорість кожного етапу.
Замовте інтеграцію POS-термінала — і ми забезпечимо стабільну роботу платіжного модуля у вашому застосунку.