Как мы помогали ресторанам платежи принимать. Часть 2
How we helped restaurants accept payments. Part 2
В продолжении статьи (часть 1) поговорим о том, как мы интегрировали и сопровождали работу стационарных терминалов.
Напомню, что мы занимались интеграцией различных типов платежных терминалов для Aptito — известного в США сервиса управления ресторанами.
В этой статье расскажем о дополнительных проблемах терминалов на стадии приема платежей от посетителей и как мы их решили.
Прием платежей делится на несколько этапов
- В POS приложении Aptito официант выбирает гостя от которого он хочет принять оплату, POS отправляет запрос на прием платежа на необходимую сумму. В результате на терминале отображалась необходимая сумма оплаты.
- Далее посетитель или официант прикладывают банковскую карту (applewatch, телефон и тд) к терминалу для совершения оплаты.
- После чего терминал выдает ответ об успешности операции.
Проблемы ресторанов, использовавших данные терминалы
Распространенная проблема: люди, занимающиеся установкой всего оборудования, не позаботились о выделении минимальной ширины канала для коммуникации приложений и оборудования. Часто рестораны испытывали сложности в скорости работы терминала, посетителям приходилось долго ждать связи терминала с банком, операции по несколько раз могли проходить неуспешно. Но что хуже всего, некоторые платежи вообще терялись. Мы стали разбираться, в чем дело, почему такая картина повторяется у ряда заведений на примере одного ресторана. В ходе целого детективного расследования оказалось, что ресторан подключил все свое оборудование к одному-единственному Wi-Fi роутеру, который был еще и публичен. Чем и воспользовались сотрудники из соседнего тайского ресторана для скачивания торрентов.
Для решения данной проблемы нами был разработан модуль, который автоматически проверял статус уже инициализированных транзакций сразу после окончания операции при разрыве соединения или раз в N минут, если терминал был не доступен по какой-то причине. Тем самым мы находили такие потерянные транзакции, либо давали возможность их отменить, если поиск был неуспешен. Ну и конечно, после этого рестораны стали устанавливать независимый роутер, который использовался только для обеспечения работоспособности Aptito.
Если в вышеописанной истории проблема во многом была в недостаточных знаниях сотрудников ресторанов, то другая неприятность заключалась уже в самом программном обеспечении терминала. Изначально мы интегрировали терминал с системой Aptito с помощью высокоуровневого API, это было сделано достаточно быстро. Но через какое-то время мы обнаружили, что стала теряться одна из двух-трех сотен транзакций. То есть, деньги были списаны, транзакция была в терминале, ответа от терминала об успешности транзакции не пришло. При попытке проверить статус этой транзакции терминал так же по какой-то причине отвечал, что такой транзакции не существует.
Пообщавшись с разработчиками ПО терминалов — ничего конкретного мы не смогли от них получить. Решали вопрос путем рефакторинга интеграции, так же не помогло. В итоге с коллегами из Aptito было принято решение, что будем переходить на низкоуровневое общение с терминалом на основе TCP протокола.
Мы разработали модуль коммуникации для передачи команд от Aptito на терминал и получения ответов от терминала. После перехода на низкоуровневое API проблема была решена + система получила дополнительный функционал: возможность отмены уже инициализированной транзакции в приложениях Aptito до момента оплаты. Ранее ее можно было отменить только на терминале, и к сожалению не все работники официантов умели делать (эта тема заслуживает отдельной статьи). В итоге от всех клиентов Aptito мы получили положительный отклик так как: транзакции перестали теряться, терминал стал быстрее работать, стало удобнее отменять транзакции прямо из Aptito POS и других приложений.
Какие выводы из всего этого сделали мы. В случае работы с платежными системами необходимо продумывать дублирующие механизмы, даже если они предусмотрены изначально терминалами или другим ПО, с которым вы интегрируетесь. Необходимо закладывать максимальное количество логов (информации о каждом действии ПО), для быстрого поиска момента и причины появления ошибок.
Напомню, что мы занимались интеграцией различных типов платежных терминалов для Aptito — известного в США сервиса управления ресторанами.
In the continuation of the article (part 1) we will talk about how we integrated and accompanied the work of stationary terminals.
Let me remind you that we integrated various types of payment terminals for Aptito, a well-known US restaurant management service.
In this article we will tell you about additional problems of terminals at the stage of accepting payments from visitors and how we solved them.
Payment acceptance is divided into several logical steps:
- In the Aptito POS application, the waiter chooses the guest from whom he wants to accept the payment, the POS sends a request to accept the payment for the required amount. As a result, the necessary amount of payment is displayed on the terminal.
- Then the visitor or the waiter appends a bank card (applewatch, phone, etc.) to the terminal to make the payment.
- After that terminal gives the answer about success of the operation.
What problems were faced by the restaurants that used these terminals
A common problem: people who install all the equipment did not take care to allocate a minimum channel width for communication between applications and equipment. Restaurants often experienced difficulties in the speed of the terminal, visitors had to wait a long time for the terminal to communicate with the bank, operations could fail several times. But worst of all, some payments were lost at all. We began to understand what the matter is, why such a picture is repeated in a number of institutions on the example of one restaurant. During the whole detective investigation it turned out that the restaurant connected all its equipment to a single Wi-Fi router, which was also public. Employees from a nearby Thai restaurant used it to download torrents.
To solve this problem, we developed a module that automatically checked the status of already initialized transactions immediately after the end of the operation when the connection is broken or once in N minutes if the terminal was not available for some reason. In this way we found such lost transactions or allowed to cancel them if the search was unsuccessful. And of course, after that the restaurants started installing an independent router that was only used to ensure that Aptito would work.
While the problem with the above story was largely due to the lack of knowledge on the part of the restaurants' staff, the other problem was already in the terminal software itself. Initially, we integrated the terminal with the Aptito system using a high-level API, it was done fairly quickly. But after a while we found out that one of two or three hundred transactions started to be lost. That is, the money was written off, the transaction was in the terminal, there was no response from the terminal about the success of the transaction. When trying to check the status of this transaction, the terminal also answered that there was no such transaction for some reason.
Having talked to the developers of terminal software - we couldn't get anything concrete from them. We solved the issue by refactoring the integration, and it didn't help either. As a result, it was decided with our colleagues from Aptito that we would switch to low-level communication with the terminal based on the TCP protocol.
We developed a communication module to transmit commands from Aptito to the terminal and receive responses from the terminal. After switching to a low-level API problem was solved + the system received additional functionality: the ability to cancel the already initialized transaction in the Aptito applications before payment. Previously, it could be canceled only in the terminal, and unfortunately not all waiters could do (this topic deserves a separate article). As a result, we received a positive response from all Aptito clients as: transactions stopped being lost, the terminal became faster, it became more convenient to cancel transactions directly from Aptito POS and other applications.
What conclusions have we drawn from all this. In case of work with payment systems, you need to think about duplicate mechanisms, even if they are originally provided by terminals or other software with which you integrate. It is necessary to lay down the maximum number of logs (information about each action of the software) to quickly find the moment and cause of errors.
Let me remind you that we were engaged in integration of different types of payment terminals for Aptito - known in the USA restaurant management service.
