Интеграция Android-приложения с фискальным принтером и кардридером

Всем привет! Сегодня мы хотим поделиться нашим опытом работы с периферийными устройствами на платформе Android.

Вы пришли в горнолыжный прокат за лыжами и вам нужно рассчитаться картой и получить договор-оферту об оказании услуги и чек. Казалось бы, что может быть проще?

1. Делаем раз. Выбрали инвентарь (лыжи, палки, ботинки, шлем и маску).
2. Сотрудник ловко достает смартфон и сканирует им баркоды на инвентаре.
3. Тут же достает считыватель пластиковых карт, снимает денежные средства и замораживает залог.
4. А вот чек и договор-оферта, которые напечатал принтер, прикрепленный на пояс.

В реальности все куда дольше, и вы сами прекрасно знаете почему.

В одном месте вы выбираете инвентарь, потом идете в кассу, куда стекаются все со всех стоек проката, там оплачиваете, возвращаетесь к прокатчику, получаете у него инвентарь и, наконец-то готовы ко встрече с горой!

А в часы пиковых нагрузок эта история неминуемо превращается в сущий ад.

1. Отстояли длиннющую очередь к прокатчику, выбрали инвентарь.
2. Теперь постоим в общей очереди на кассу.
3. Потом вернемся к прокатчику за законно оплаченным. И снова отстоим очередь. Вам ведь только спросить (забрать)? Да кого это волнует.

Вот так скорость обслуживания из полутора минут растянулась на все 20, а в это время утренний вельвет снежного склона уже кто-то режет лыжами!

Почему бы прокату не обустроить каждую стойку кассой? Да потому, что такая проблема не постоянна. Пиковые нагрузки случаются регулярно, но по большому счету не так часто – утро выходных и праздников, и это только если погода катальная. Поэтому инвестировать в кассовое оборудование с точки зрения владельцев явно затраты не супер оправданные. Эту задачу решает появление дополнительного мобильного сотрудника который раз, два, и помог очереди рассосаться.

В кейсе с горнолыжкой достаточно было бы купить коробочное решение для интеграции смартфона с кассовым принтером и картридером, коих на рынке хватает. Ими пользуются и курьеры, которые доставляют заказы, и девушки, которые продают билеты на аэроэкспресс.

Мы бы тоже могли ввести сумму и получить оплату, но у нас не прокат инвентаря!

В системе заказчика с которой работали мы, буква закона требовала выдачи клиенту не просто чека на энную сумму, но еще и квитанции с подробным описанием услуги и уникальным присвоенным ей номером. То есть мы должны провести оплату, зарегистрировать это на сервере, получить уникальный номер транзакции, и затем распечатать чек, в котором отображается этот номер, полное описание услуги и баркод с закодированной информацией.

Задача поставлена, переходим к реализации.

Реализация

Для начала определились, что надо использовать комплекс со смартфоном, который позволяет пользователю настраивать параметры услуги и взаимодействовать с сервером. Вопрос о выборе смартфонов для системы решился сам собой. Заказчик выбрал «рабочих лошадок» — смартфоны на базе Android. Ими оказались Huawei Honor 5C. Удобные недорогие устройства от китайского производителя. Главное, что Bluetooth есть и работает. А вот дальше надо было решить задачи посложнее. Чтобы все операции с продажей услуг проводились законно, нам был нужен фискальный регистратор. Это принтер с памятью, в которую записывается история операций по проведенным продажам.

Мобильные фискальные принтеры (а мы помним, что наше решение должно быть мобильным!) выпускаются рядом российских компаний «Атол», «Инкотекс», «Счетмаш», «Штрих-М». Мы изучили их предложения, но в нашем решении принтер должен был печатать на широкой ленте (3” вместо 2”), поскольку нам нужно было разместить на чеке подробные данные об оказанной услуге. Широкая лента нашлась только у одного включенного в государственный реестр мобильного фискального принтера ШТРИХ-MOBILE-ПТК.

С клиентов нам необходимо брать не только наличные платежи, но и списывать деньги с карты. А значит нужны картридер и провайдер такого решения, чтобы проводить оплаты и учитывать все проводимые таким способом средства. И таких решений на нашем рынке достаточно. Различаются они, пожалуй, типами моделей устройств для считывания, процентом комиссии за проведение эквайринга и… интеграциями с фискальными принтерами! Тут-то нам и попалось решение от iBox Pro, использующее картридер модели chip-n-pin с клавиатурой, а также, по счастью, интегрированное с мобильным фискальным регистратором ШТРИХ-MOBILE-ПТК.

Компания предоставила нам тестовые устройства, и мы принялись за работу.

С платежной системой iBox Pro мобильное приложение можно интегрировать простым (через intent-вызов) и сложным способом (через SDK). Мы выбрали сложный путь, но вовсе не потому, что нам нравится преодолевать трудности. А по другой важной причине. Тут понадобится лирическое отступление.

В случае intent-вызова алгоритм такой:

Наш алгоритм выглядит иначе. Мы не можем просто взять, вбить сумму за услугу и распечатать чек. Нам нужно отправить данные на сервер, получить стоимость услуги, затем получить оплату от клиента, и после этого обратиться к серверу и получить уникальный код и затем обязательно отразить этот код в чеке.

Поэтому мы разработали такой алгоритм:

В итоге с помощью SDK iBox (свежую версию их эволюционирующего SDK можно скачать с GitHUB) мы встроили вызовы к iBox в наше мобильное приложение. Бонусом получили более удобный для пользователя единый интерфейс – на этапе оплаты человеку не приходится переключаться на сторонний интерфейс iBox, все процессы происходят только в рамках нашего мобильного приложения.

После фиксации факта продажи необходимо выдать клиенту чек, а иногда и дополнительные документы – договор-оферту, бланк заказа или гарантийное письмо. Вопрос “на чем будем печатать?” — если у пользователя на поясе висит мобильный принтер — пусть печатается на нём. Поэтому, мы заставили принтер печатать помимо фискальных чеков и другие документы.

С принтером можно работать через официальную библиотеку от Штрих-М с документацией, которую они создали для удобства работы с JPOS, а также с помощью небольшой библиотечки-примера от энтузиастов.

При печати документов на мобильном принтере мы столкнулись с двумя случаями, когда матрица давала сбой:

В сочетании с некоторыми смартфонами, которые мы использовали для тестирования, скорость работы принтера падала катастрофически. Нас это очень тревожило, так как по стандарту обслуживания заказчик требовал от нас уложиться в 1,5 минуты со всем процессом от оформления услуги до выдачи чека. По счастью, целевой девайс печатал по Bluetooth без проблем, и эту загадку мы решили оставить неразгаданной.

• Ещё одна странная проблема всплыла при работе с iBox. При работе с нашими смартфонами устройство могло войти в спящий режим и не выходило из него. Проявлялось только с Huawei и вылечилось с помощью установки последней версии прошивки картридера.

По умолчанию фискальный принтер выдает чек от платежной системы с минимумом информации. Нас это не устроило. Во-первых, нам нужен был красиво оформленный чек, который выглядел бы аналогично чекам, утвержденным в других системах заказчика. Во-вторых, нам нужно было совместить чек с квитанцией об оказании услуги и подробной информацией о ней. Итого – с помощью SDK принтера мы сделали красивый документ чек-квитанцию. А потом долго и мучительно на тестировании один за другим печатали чеки, меняя параметры, пока, наконец, реальная бумажка не стала выглядеть на всех принтерах одинаково и так, как нужно.

Конечно, мало просто сделать интеграцию в системе, важно сделать эту систему надежной. Для нас важно было обеспечить механизмы отката назад с любого этапа. Например, платежный сервис подтвердил приложению снятие денег, приложение запросило у сервиса бронирования услуг уникальный номер услуги, и тут пропала связь с сервером. И вот на этом этапе нужно сделать Fallback-механизм, который позволит повторить запрос на сервер или вернуть деньги на карту.

Вариантов подобных ошибок оказалось множество: при снятии денег рано вытащили карту, неправильно ввели пин-код, при попытке распечатать чек закончилась кассовая лента, принтер разрядился и так далее. Границы необходимой отказоустойчивости на каждом этапе мы определяли в ходе тест-сессий с участием опытных кассиров. В результате для каждой ошибки были разработаны необходимые Fallback-механизмы.

Итого:

• Сделали отказоустойчивую интеграцию смартфон + картридер + фискальный принтер.
• Протестировали в боевых условиях и наладили еще раз все Fallback-механизмы.
• Решение внедрено, работает и радует пользователей приложения и их клиентов.

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