В продолжении статьи (часть 1) поговорим о том, как мы интегрировали и сопровождали работу стационарных терминалов.
Напомню, что мы занимались интеграцией различных типов платежных терминалов для Aptito — известного в США сервиса управления ресторанами.
В этой статье расскажем о дополнительных проблемах терминалов на стадии приема платежей от посетителей, и как мы их решили.
Прием платежей делится на несколько этапов:
- В POS-приложении Aptito официант выбирает гостя, от которого он хочет принять оплату, POS отправляет запрос на прием платежа на необходимую сумму. В результате на терминале отображается необходимая сумма оплаты.
- Далее посетитель или официант прикладывает банковскую карту (Apple Watch, телефон и так далее) к терминалу для совершения оплаты.
- После этого терминал выдает ответ об успешности операции.
Проблемы ресторанов, использовавших данные терминалы
Распространенная проблема: люди, занимающиеся установкой всего оборудования, не позаботились о выделении минимальной ширины канала для коммуникации приложений и оборудования. Часто рестораны испытывали сложности в скорости работы терминала. Посетителям приходилось долго ждать связи терминала с банком, операции по несколько раз могли проходить неуспешно. Но что хуже всего, некоторые платежи вообще терялись. Мы стали разбираться, почему такая картина повторяется у ряда заведений на примере одного ресторана. В ходе целого детективного расследования оказалось, что ресторан подключил все свое оборудование к одному-единственному Wi-Fi роутеру, который был еще и публичен. Чем и воспользовались сотрудники из соседнего тайского ресторана для скачивания торрентов.
Для решения данной проблемы нами был разработан модуль, который автоматически проверял статус уже инициализированных транзакций сразу после окончания операции при разрыве соединения или раз в N минут, если терминал был не доступен по какой-то причине. Тем самым мы находили такие потерянные транзакции, либо давали возможность их отменить, если поиск был неуспешен. Ну и, конечно, после этого рестораны стали устанавливать независимый роутер, который использовался только для обеспечения работоспособности Aptito.
Если в вышеописанной истории проблема во многом была в недостаточных знаниях сотрудников ресторанов, то другая неприятность заключалась уже в самом программном обеспечении терминала. Изначально мы интегрировали терминал с системой Aptito с помощью высокоуровневого API. Это было сделано достаточно быстро. Но через какое-то время мы обнаружили, что стала теряться одна из двух-трех сотен транзакций. То есть, деньги были списаны, транзакция была в терминале, ответа от терминала об успешности транзакции не пришло. При попытке проверить статус этой транзакции терминал по какой-то причине отвечал, что такой транзакции не существует.
Пообщавшись с разработчиками ПО терминалов, мы не смогли получить конкретного ответа. Решали вопрос путем рефакторинга интеграции, также не помогло. В итоге с коллегами из Aptito было принято решение, что будем переходить на низкоуровневое общение с терминалом на основе TCP протокола.
Мы разработали модуль коммуникации для передачи команд от Aptito на терминал и получения ответов от терминала. После перехода на низкоуровневое API проблема была решена + система получила дополнительный функционал: возможность отмены уже инициализированной транзакции в приложениях Aptito до момента оплаты. Ранее ее можно было отменить только на терминале, и к сожалению, не все работники ресторанов умели это делать (эта тема заслуживает отдельной статьи). В итоге от всех клиентов Aptito мы получили положительный отклик так как: транзакции перестали теряться, терминал стал быстрее работать, стало удобнее отменять транзакции прямо из Aptito POS и других приложений.
Какие выводы из всего этого сделали мы? В случае работы с платежными системами необходимо продумывать дублирующие механизмы, даже если они предусмотрены изначально терминалами или другим ПО, с которым идёт интеграция. Необходимо закладывать максимальное количество логов (информации о каждом действии ПО), для быстрого поиска момента и причины появления ошибок.