Реалізація підключення до POS-терміналу з мобільної програми
Підключення мобільної програми до POS-терміналу—це не просто «відправити суму на термінал». Це інтеграція з закритими протоколами обладнання, у кожного виробника свої, плюс обробка всіх можливих збоїв комунікації в момент фінансової операції.
Протоколи та виробники
Більшість 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).
Перед початком розробки—уточнюємо у клієнта: який конкретний термінал, який банк-еквайрер, який протокол підтримується. Це не технічний вибір розробника—це факти про встановлене обладнання.
Інтерфейси підключення
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—автоматичне переподключення з 3–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 підтримкою.
Процес
Виявлення моделі терміналу та протоколу → вивчення документації еквайреа → реалізація транспортного шару (BT/USB/TCP) → протокол команд (продаж, скасування, повернення, запит статусу) → обробка edge-cases (обрив комунікації, timeout) → тестування на реальному терміналі в тестовому режимі еквайреа → боєве тестування → експлуатація.
Орієнтири за часом
Базова інтеграція (продаж + відповідь) по конкретному протоколу з одним інтерфейсом: 3–5 днів. Повний набір операцій (продаж, скасування, повернення, запит статусу) + retry/reconnect logic + кілька інтерфейсів: 2–3 тижні.