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

Платежи в мобильных приложениях: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

В каждом нашем проекте по монетизации приложения мы балансируем между политиками App Store и Google Play, требованиями PCI DSS и логикой верификации покупок на бэкенде. Неправильно сделанная система платежей — это не просто баг, это финансовые потери и возможный бан приложения. За 7 лет мы разобрали более 50 кейсов интеграции платёжных SDK — от простой Stripe-формы до распределённого биллинга с собственными серверными вебхуками.

In-App Purchase: две платформы, два разных API

Если приложение продаёт цифровой контент или подписки — Apple и Google требуют использовать их платёжные системы. Обойти это нельзя: нарушение правил 3.1.1 App Store или Google Play Developer Policy приводит к удалению приложения. Физические товары и сервисы, оказываемые офлайн, — другая история.

StoreKit 2 (iOS 15+)

StoreKit 2 — полная переработка исходного StoreKit с async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читаемо и предсказуемо по сравнению с очередью транзакций через SKPaymentTransactionObserver.

Самое важное изменение: транзакции в StoreKit 2 подписаны JWS (JSON Web Signature) и верифицируются локально без серверного roundtrip. Transaction.verificationResult возвращает .verified(Transaction) или .unverified(Transaction, VerificationError). Это не значит, что сервер не нужен — он нужен для хранения статуса подписки, но локальная верификация убирает задержку при старте.

StoreKit.AppTransaction — верификация самого факта загрузки приложения из App Store. Нужна для приложений с платным скачиванием или бессрочными покупками, не подписками.

Сложное место в StoreKit 2 — обработка renewalState для подписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Состояние inGracePeriod означает, что Apple пытается возобновить оплату (до 16 дней) — в это время нужно продолжать давать доступ. Не обработаешь — потеряешь лояльных пользователей, у которых временно не прошла карта. По опыту, около 5% подписок попадают в billing retry, и автоматическое восстановление доступа возвращает до 80% из них.

Google Play Billing Library (v6+)

Google Billing — сложнее StoreKit по количеству сценариев. BillingClient с PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обязательно вызывать при каждом старте приложения, не полагаться на PurchasesUpdatedListener как единственный источник правды.

Подтверждение покупки: acknowledgePurchase() для non-consumables и подписок, consumePurchase() для consumables. Если не вызвать acknowledge в течение 3 дней — Google автоматически сделает возврат. Это гарантированная потеря денег, если забыть про acknowledge на бэкенде после верификации.

ProductDetails с SubscriptionOfferDetails — в Billing v5+ структура оферт усложнилась: один продукт может иметь несколько basePlanId и offerId (пробный период, скидка для новых пользователей, retention-оффер). BillingFlowParams.SubscriptionUpdateParams для апгрейда/даунгрейда подписки с prorationMode.

Почему серверная верификация обязательна?

Никогда не доверяйте только клиентскому коду при разблокировке платного контента. Клиентская верификация обходится модификацией приложения.

Для IAP минимальная схема: приложение получает receiptData (iOS) или purchaseToken (Android), отправляет на бэкенд, бэкенд верифицирует через Apple App Store Server API / Google Play Developer API, сохраняет статус в БД, отдаёт ответ клиенту. RevenueCat делает это за вас — но если у вас кастомный бэкенд, нужно реализовать самостоятельно.

Webhook-и важнее, чем кажется. Пользователь может отменить подписку через настройки телефона, не через приложение — приложение не получит об этом событие в реальном времени. Только webhook от Apple/Google (или RevenueCat) позволяет своевременно обновить статус. Мы используем проверку подписи входящих запросов через Apple's signedPayload и Google's DeveloperNotification.

Как RevenueCat упрощает интеграцию?

Поддерживать StoreKit 2 и Google Billing одновременно, с учётом промо-кодов, оферт, восстановления покупок и серверной верификации — это несколько месяцев разработки. RevenueCat закрывает большую часть этого слоя.

RevenueCat — не просто SDK для платежей. Это:

• Единый API для iOS и Android (и Stripe для веба)
• Серверная верификация и хранение статусов подписок
• Webhooks на события (покупка, возобновление, отмена, billing issue)
• Аналитика по когортам, MRR, churn
• A/B тестирование оферт через Experiments

Purchases.configure(withAPIKey:) при старте, Purchases.shared.getCustomerInfo() для получения текущих entitlements — минимальный интегрируемый слой. Purchases.shared.purchase(package:) вместо прямого вызова StoreKit/Billing.

В документации RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Ограничения RevenueCat: платный (бесплатно до $2.5k MRR, дальше процент от дохода), не подходит для очень сложных flow с несколькими storefront-ами или кастомными bundle-ами. Однако для типового SaaS-приложения экономия на собственной разработке составляет $15–30 тыс. — интеграция окупается за 2 месяца.

Stripe в мобильных приложениях

Stripe — для оплаты физических товаров, услуг, B2B-платежей где IAP не требуется политикой платформы.

Stripe iOS SDK и Android SDK — PaymentSheet для готового UI оплаты, PaymentSheetFlowController для кастомного UI с сохранёнными картами. Payment Intent создаётся на сервере, client secret передаётся в приложение — карточные данные никогда не проходят через ваш сервер, только через Stripe.

Apple Pay и Google Pay через Stripe: PKPaymentRequest (iOS) и GooglePayLauncher (Android) уже интегрированы в Stripe SDK. Конверсия у Apple Pay даёт в 1.3–2 раза выше результат, чем формы с ручным вводом карты — это цифры, которые мы подтвердили на десятке проектов.

Сохранённые карты через SetupIntent + Customer API — пользователь платит в один тап при повторном визите. Compliance: PCI DSS SAQ A — самый лёгкий уровень compliance, потому что Stripe Tokenization убирает нужду хранить карточные данные на своей стороне. Согласно PCI DSS, передача токенов освобождает от необходимости сертификации уровня 1.

3DS2 (Strong Customer Authentication) — обязателен для платежей в ЕС по PSD2. Stripe обрабатывает автоматически через PaymentIntent.confirmPayment, но нужно корректно обработать .requiresAction статус и вернуть пользователя в нужный экран после аутентификации.

Что входит в работу (deliverables)

Процесс и сроки

Начинаем с прояснения бизнес-модели: подписки, разовые покупки, consumables, freemium. От этого зависит архитектура. Тестирование IAP требует Sandbox-аккаунтов (Apple) и License Testers (Google) — это отдельная настройка окружения.

Sandbox Apple ведёт себя не так, как production: подписки возобновляются каждые 5 минут вместо месяца, inGracePeriod работает по-другому. Обязательно тестировать сценарии: истечение триала, отмена, billing retry, refund.

Стоимость рассчитывается индивидуально исходя из набора инструментов и сложности серверной логики. В среднем мы укладываемся в бюджет $5k–15k на типовую интеграцию, но экономия от предотвращения ошибок и churn окупает эти вложения за 2–3 месяца.

Получите консультацию по вашему проекту — свяжитесь с нами. Мы поможем выбрать оптимальную архитектуру платежей, которая пройдёт ревью сторов и не сломается при пиковых нагрузках.