Отложенная авторизация приема наличных¶
Авторизация отложенных операций приема наличных¶
Регулярные и непрогнозируемые перебои со связью негативно отражаются на коэффициенте доступности УС при авторизации операций в режиме онлайн по протоколу NDC. В ПроАТМ реализован набор расширений стандартных стейтов и функций для протокола NDC (согласно его описанию), позволяющих осуществить прием наличных при разорванном соединении с их последующим (отложенным) зачислением после восстановления связи с хостом.
Набор расширений включается в реестре параметром CASHIN_OFFLINE_MODE.
Отложенными являются:
принятые, но не авторизованные в силу отсутствия связи операции;
принятые операции, отклоненные NDC-хостом (подробнее, IgnoreHostFailedReplyForCashin);
операции, которые были прерваны до авторизации в силу сбоя сценария, оборудования, ПО и пр.
Рисунок 85. Схема авторизации отложенных операций¶
Хранение файла транзакций и регистрация операции¶
Вся информация о транзакциях хранится в файле БД TransactAuth.db, расположенном в директории размещения главного исполняемого файла ogre.exe (например, C:\FS365\Application).
БД включает в себя информацию о денежных операциях, внесенных денежных средствах, транзакционных запросах, буферах NDC, операционных циклах и номере карты (в замаскированным виде).
Каждой транзакции присваивается свой ID. После отправки транзакционного запроса операции присваивается статус: ожидание авторизации, неавторизованно, авторизовано. Каждому статусу соответствует свой код. В случае, когда транзакционный запрос был отправлен, но ответа от ПЦ получено не было, транзакции присваивается статус «неавторизованно», и в базе данных транзакция отмечается как незавершенная.
Работа механизма отправки отложенных сообщений¶
Авторизация отложенных операций запускается по событию «Завершен сценарий обслуживания» и выполняется в фоновом режиме (см. особенности реализации стейтов I и J при включенном механизме отложенной авторизации). Предусмотрена возможность ограничения выполнения авторизации операций, проведенных в offline-режиме по картам, номера которых не совпадают с текущей. УС на время проведения фоновой авторизации самостоятельно переходит в состояние OutOfService и держит карту клиента внутри ридера, пока не завершится операция в фоновом режиме. В ходе фоновой авторизации выполняются транзакционные запросы со значениями Opcode Buffer, Buffer B, Buffer C и счетчиками принятых банкнот неавторизованных операций, ранее сохраненными в БД, и PAN-, PIN- и EMV-данными текущей карты, которая находится в устройстве, и используются текущие параметры макирования.
Критерием успешности авторизации отдельно взятой отложенной операции служит наличие функции Deposit And Print в ответе хоста (такие операции помечаются в БД как успешно авторизованные). Если во время авторизации отложенной операции не удалось установить соединение с хостом, то процесс фоновой авторизации прекращается. Устройство переходит в режим обслуживания клиентов, и до восстановления связи все последующие операции будут производиться в режиме offline. Авторизация PIN-кода при offline операции идет по ветке таймаута сценария обслуживания. Рекомендуется по таймауту авторизации PIN-кода предоставлять клиенту возможность выбора продолжения с отложенным зачислением или прекращения выполнения операции.
В процессе фоновой авторизации отложенных операций приема наличных блокируется переход в РОП: команды на переход в РОП выполняются отложено (только после завершения процедуры авторизации). На дисплее показывается служебный экран «C03» (Supervisor mode) или, при его отсутсвии, «С02» (Out-of-Service mode).
Примечание
Во избежание возникновения отложенных операций, которые были проведены по заведомо недействительным картам, рекомендуется использовать фильтрацию по FIT-таблице.
Защита целостности базы данных отложенных транзакций¶
Хранение записей об отложенных операциях осуществляется в БД транзакций. Предусмотрен механизм подписывания БД: каждая запись подписывается, что позволяет исключить возможность редактирования отдельных полей, а также исключается возможность удалить или вставить отдельно подписанные записи в таблице незавершенных операций за счет использования механизма сбора подписи по конкатенации подписей отдельных записей. Подпись хранится в отдельных полях таблицы БД.
Предусмотрена защита от восстановления среза локальной БД путем копирования файлов или восстановления разделов жесткого диска (защита от многократного зачисления пакета отложенных операций).
Подпись транзакций выполняется после добавления каждой новой неавторизованной транзакции, но перед тем как сделать эту подпись, выполняется проверка, что уже существующие транзакции не искажены (проверяется текущая подпись) и, если искажений нет, переподписываются уже все транзакции, включая новую.
Отложенные операции с нарушенной подписью дальнейшей авторизации не подлежат и позже числятся в реестре незавершенных операций с соответствующей пометкой («ошибка проверки целостности») в чеке операционного цикла. Предполагается дальнейший разбор инцидента вручную.
В случае нарушения целостности функционирования механизма подписывания БД, отложенная авторизации приема наличных деактивируется до устранения проблемы. В журнал и перечень проблемных ситуаций помещается соответствующее сообщение.
Особенности закрытия операционного цикла¶
В момент закрытия операционного цикла БД транзакций может содержать ненулевое число незавершенных операций приема наличных, которые по ряду причин авторизованы не были (операция отложена либо нарушена целостность записи в БД). Данная ситуация не является препятствием для закрытия операционного цикла. В чеке закрытия операционного цикла отражается:
итоговая сумма принятых наличных;
сумма успешно авторизованных операций;
реестр незавершенных операций, сумма которых подлежит ручному зачислению по итогам пересчета банкнот в расчетном центре банка;
отложенные операции, не прошедшие проверку.