Интеграция POS-терминала в мобильное приложение: полный цикл работ

Как подключить 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).

Перед началом разработки уточняем у клиента: какой конкретный терминал, какой банк-эквайер, какой протокол поддерживается. Это не технический выбор разработчика — это факты об установленном оборудовании.

Какие интерфейсы используются?

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.

Флоу платёжной операции

1. Приложение формирует команду «продажа» с суммой и дополнительными параметрами.
2. Отправляет на терминал.
3. Терминал показывает пользователю экран оплаты, принимает карту.
4. Возвращает ответ: статус (approved/declined/error), код авторизации, RRN, маскированный PAN.
5. Приложение обрабатывает ответ и продолжает бизнес-флоу (закрывает чек, обновляет заказ).

Шаги 2–4 могут занять до 60–90 секунд при медленном эквайринге. На этот период показываем spinner с сообщением «Ожидание ответа терминала» и кнопку «Отмена» (которая отправляет команду отмены на терминал, не просто закрывает экран).

Что делать при обрыве связи во время транзакции?

Самый неприятный кейс: транзакция ушла на терминал, связь прервалась — приложение не знает, прошёл платёж или нет. Терминал авторизовал карту, но ответ не дошёл.

Правильная схема: при потере связи — пробуем получить статус последней транзакции (команда «запрос последней операции»). Если терминал отвечает — берём статус оттуда. Если нет — показываем оператору «Статус неизвестен, проверьте терминал» и сохраняем транзакцию в PENDING статусе. Автоматическое списание при неизвестном статусе — недопустимо.

Reconnect logic: при обрыве Bluetooth — автоматическое переподключение с 5 попытками, exponential backoff. Состояние соединения — всегда видно в UI (иконка статуса).

Возврат и отмена

Отмена транзакции (reversal) — до закрытия финансового дня. Возврат (refund) — после. Оба требуют отдельных команд на терминал с RRN исходной транзакции. Реализуем оба сценария — оператор должен иметь возможность исправить ошибку.

Сравнение платформ: Android vs iOS

Если заказчик требует 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-терминала — и мы обеспечим стабильную работу платёжного модуля в вашем приложении.