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

События пишутся в \\IP кассы\storage\crystal-cash\logs\bank.log

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

Уровень логирования можно повысить до TRACE в файле \\IP кассы\storage\crystal-cash\modules\loader\log4j.xml

для логера

    <logger name="ru.crystals.pos.bank">
        <level value="trace"/>
        <appender-ref ref="file-bank"/>
    </logger>

и аппендера

    <appender name="file-bank" class="org.apache.log4j.RollingFileAppender">
        <param name="Threshold" value="trace"/>
        <param name="file" value="logs/bank.log"/>
        <param name="MaxFileSize" value="1000KB"/>
        <param name="MaxBackupIndex" value="4"/>
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d{dd.MM HH:mm:ss} %-5p [%c{1}] %m%n"/>
        </layout>

Все операции обмена между кассой и банковским ПО действуют по алгоритму запрос-ответ.

Кассовая программа выполняет запрос к терминалу используя банковское ПО, установленное на кассе. И спустя таймаут, сопоставимый с данным запросом, кассовая программа ожидает ответ от терминала.

Далее касса ожидает ответ  Response code/file

При этом код ответа может содержать положительные и отрицательные ответы. 

Рассмотрим на примерах

Аналогично операции возврата

Достаточно распространенная ситуация, когда долго обрабатывается запрос от кассы на сервере авторизации и спустя установленный таймаут кассовая программа прерывает операцию оплаты по банку. В данном случае может произойти ситуация, когда транзакция на банковском сервере авторизации прошла, но ответ о ее статусе не успел в таймаут вернуться на кассу. Покупатель оказывается в неприятной ситуации - деньги банк списал, а касса ("торговая точка") не зарегистрировала эту операцию.

Как эта ситуация выглядит в логе:

из лога видно, что команда об оплате выполнена в 26.02 16:20:22 , ответ не был получен своевременно и спустя 1,5 минуты в 26.02 16:21:52 касса отменила запрос с ошибкой.

Как решить: для магазинов с неудовлетворительном каналом связи рекомендуется увеличить таймаут для выполнения банковских операций. Для этого:

1. В файле \\IP кассы\storage\crystal-cash\config\plugins\bank-sberbank-config.xml (файл для процессинга Сбербанк) 

<property key="responseTimeout" value="90000"/> -- настройка задается в милисекундах.По-умолчанию 90000

3. Сохранить файл и перезагрузить кассу

Неверная настройка конфигурационного файла банковского ПО

Данный случай распространен для процессинга Аркус (Арком). Согласно порядку настройки в статье SetRetail10 ▪️ Касса ◾️ АРКОМ (Аркус) (Ingenico) ВТБ в пункте

в файле ops.ini или ops_spdh.ini - файл ресурсов для редактора настроек сотрудники банка могут допустить ошибку в сопоставлении команд. Таким образом происходит сбои, когда касса посылает команду оплата, а в файле ops.ini или ops_spdh.ini она вызывает совершенно другую команду.

Рассмотрим на примере:

В файле ops.ini или ops_spdh.ini для кода 1 указано выполнение команды 1=0,166,ТЕСТ СВЯЗИ, хотя по факту должна выполняться команда оплаты 1=0,128,ОПЛАТА

В результате происходит ошибка при попытке оплаты.

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