Терминал > Критическая ошибка в терминале!
-
ZiZ
- Сообщения: 36
- Зарегистрирован: 19 ноя 2019, 15:32
- Благодарил (а): 6 раз
- Поблагодарили: 2 раза
Критическая ошибка в терминале!
Добрый день!
Мы знаем, что для торговли роботами должен быть всегда подгружен сертификат.
Несколько раз был свидетелем того, как терминал (последняя версия) на какие-то секунды терял связь и сертификат автоматически отключался (красный ключик), потом связь также резко восстанавливалась, НО сертификат уже сам не подгружался.
Это является критической недопустимой ошибкой!
Нужно добавить такую опцию, чтобы терминал ежесекундно проверял загрузку сертификата (зелёный ключик) и автоматически подгружал его после каких-либо ошибок.
Иначе торговля роботами полностью теряет смысл.
Спасибо.
-
ensh
- Сообщения: 215
- Зарегистрирован: 28 июн 2017, 13:56
- Благодарил (а): 4 раза
- Поблагодарили: 38 раз
Re: Критическая ошибка в терминале!
Непрочитанное сообщение ensh » 19 июн 2020, 13:05
Проверьте в настройках, что установлен флажок — Загружать сертификат при соединении.
По-умолчанию, он не ставиться кажется.
-
ZiZ
- Сообщения: 36
- Зарегистрирован: 19 ноя 2019, 15:32
- Благодарил (а): 6 раз
- Поблагодарили: 2 раза
Re: Критическая ошибка в терминале!
Непрочитанное сообщение ZiZ » 19 июн 2020, 13:41
Да, установлен и не помогает.
Провёл эксперимент сейчас. Вручную отключал и включал разные вайфай-роутеры от разных провайдеров. Имитировал разрыв соединения и подключение к запасному варианту. Каждый раз терминал без нареканий восстанавливал соединения со всеми серверами, НО сертификат подгружался через раз, приходилось иногда вручную кликать на красный ключик.
Отсюда вывод, нужно добавить функционал «тикового» опроса статуса подключения сертификата на ВСЁ время работы терминала. Как только терминал обнаруживает отключение сертификата, он тут же должен инициировать его подключение.
Иначе торговля роботами на малых таймфреймах лишена всякого смысла, потому что при разрыве-восстановлении соединения может просто не подгрузиться сертификат.
-
ZiZ
- Сообщения: 36
- Зарегистрирован: 19 ноя 2019, 15:32
- Благодарил (а): 6 раз
- Поблагодарили: 2 раза
Re: Критическая ошибка в терминале!
Непрочитанное сообщение ZiZ » 19 июн 2020, 14:27
Саппорт мне написал, что при подаче заявки терминал сперва проверяет статус загрузки сертификата и подгружает его при необходимости. Это должно помочь, просто у меня после разрыва-восстановления соединения сделки не совершались. 
-
ensh
- Сообщения: 215
- Зарегистрирован: 28 июн 2017, 13:56
- Благодарил (а): 4 раза
- Поблагодарили: 38 раз
Re: Критическая ошибка в терминале!
Непрочитанное сообщение ensh » 19 июн 2020, 17:12
Там есть какой то таймаут на отсылку сертификатов на сервере, сервер считает, что у клиента сертификат есть, а клиент ждет сертификата с сервера , чтобы соединиться. А может чето и сломали
В любом случае, высокочастотная торговля и надежность это не про Альфа Директ, так что проблема с сертификатом еще не самое большое зло
Вернуться в «Терминал»
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей
11.03.2016 года в 20:15, являясь клиентом МКБ, я позвонил в горячую линию узнать о партнерах банка, так как нахожусь не в Москве, а в городе Саранске по бизнесу. Мне ответили, что Альфа-банк является их партнером по внесению средств на карту и не взимает комиссии.
Приехал в Альфа-банк и через терминал начал вносить энную сумму в размере 26500 т.р., внес сумму, нажал продолжить, терминал мне выдал ошибку о том, что невозможно зачислить средства, и выдал только карту, а чек, как обычно и случается, не предоставил.
Так как само отделение уже не работало, я позвонил в МКБ, чтобы уточнить поступили ли средства на счет, на что мне сотрудник говорит, что зачисления средств на счет не было. Я позвонил в горячую линию Альфа-банка, оформил претензию, номер мне выслали в смс сообщении.
Прошло 2 дня и сегодня собираюсь ехать к ним. В этот же день я вызвал сотрудников полиции и оформил заявление о факте мошенничества Альфа-банка, так как все четыре терминала работали, соответственно, так же как и тот, в который я вносил деньги. 13 марта у меня платеж по кредиту и соответственно мне уже начислен штраф в размере 10% от суммы кредита. Надеюсь, ситуация разрешится мирно!
Альфа-Банк
2016-03-14 11:17:13
Добрый день.
Спасибо за отзыв. Для проведения проверки сообщите, пожалуйста, на почтовый адрес expert@alfabank.ru (в теме письма «Народный рейтинг», а в тексте ссылка на отзыв):
— Ваше ФИО и номер телефона;
— номер обращения, оформленного в Телефонном центре нашего Банка.
С уважением к Вам, Альфа-Банк.
Хороший банк
Оценка
5
Проверяется
Отличная Кешбек-система, удобный вывод на картув рублях а не бонусах и трать куда хочешь!
Бесплатное обслуживание….
Читать полностью
12.02.2023
Отличный банк
Оценка
5
Проверяется
Очень удобная техническая поддержка через онлайн-чат. Также была в офисе — подбирают компетентных сотрудников.
Благодаря Альфа- банку смогла рефинансировать свой кредит и взять…
Читать полностью
12.02.2023
Лучший банк!
Оценка
5
Проверяется
Пользуюсь этим банком сравнительно немного времени, но уже стало понятно, что условия пользования картами и вкладами намного удобней чем в других банках, так же очень радует, что…
Читать полностью
12.02.2023
Так держать
Оценка
5
Проверяется
За полтора месяца все устраивает на 5+. Своевременная доставка карты.на дом, хорошая работа представителя банка, отличная программа Кешбэка для новых клиентов, особо порадовал…
Читать полностью
12.02.2023
Отличная бонусная кампания и сервис.
Оценка
5
Проверяется
Увидел в интернете рекламу карты «Альфа Банка», бонус 1000р. за оформление карты по ссылке, оформил карту в начале января, доставка была удобной, из-за моего прокола пришлось…
Читать полностью
12.02.2023
Альфа-банк супер
Оценка
5
Проверяется
Очень нравится, так как в трудные моменты всегда помогут. В банке сразу ответят на все вопросы и объяснять, как пользоваться продуктом.В приложении все просто и удобно, его можно…
Читать полностью
12.02.2023
Очень достойный банк
Оценка
5
Проверяется
стала клиентом благодаря карте перекрёстка. Пользовалась кредитной картой и дебетовой. Когда неожиданно списали деньги за страховку по кредитке- быстро вернули через чат поддержки…
Читать полностью
12.02.2023
Коды ответов
Результатом выполнения и критерием успешности любой операции является Код ответа (Responce Code (RC)). В рамках протокола ISO 8583 он передается в поле 39 ответного сообщения. Формат RC зависит от версии ISO 8583: в версии ISO 8583:1987 он двузначный, в версии ISO 8583:1993 — трехзначный. Главным образом будем рассматривать обмен в рамках версии 1987 г., по причине ее большей распространенности. При этом заметим, что каждый конкретный разработчик ПЦ использует различные подходы к обеспечению совместимости между версиями: какие-то хосты передают в рамках P2H три символа RC, при этом, в случае если обмен выполняется в рамках версии 1987 г., заполняя лидирующий символ (первый слева) нулем. В других случаях ПЦ выполняет конвертацию трехзначного RC версии 1993 г. — в его двузначный эквивалент версии ISO 8583:1987 и в таком виде отправляет его на POS.
Коды ответов можно разделить на успешные и негативные. Негативным является любой ответ, кроме явного ответа «Одобрено» либо его семантического эквивалента. При этом причиной может быть как техническая ошибка, так и отказ эмитента в выполнении той или иной операции.
Ниже приведем наиболее распространенные RC, разбив их на две условные группы — Технические и Сервисные.
Технические RC
В это группу включим основные коды ответов, полученные в результате тех или иных технических сбоев, либо ошибок при заполнении сообщения. Заметим, что вариативность причин возникновения любого их описанных ниже RC более или менее широка, и в рамках материала дана исключительно в целях примера.
00 — Approved (Одобрено). Транзакция завершена успешно.
12 — Invalid Transaction (Неверная транзакция). Неверны какие-либо параметры транзакции. Допустим, поля сообщения заполнены таким образом, что из них следует, что операция Выдача наличных выполняется в торговом POS-терминале. Что, в общем случае, недопустимо.
13 — Invalid Amount (Неверная сумма). Поле 4 (Сумма) заполнено неверным значением. Данный RC может возникнуть в случае срабатывания какого-либо лимита, либо в рамках операций, подразумевающих предварительную авторизацию с ее последующим завершением (например, предварительное бронирование услуг с последующим расчетом).
14 — Invalid Card Number(Неверный номер карты). Неверно заполнено поле 2 (Номер карты), либо имеет место быть попытка выполнить транзакцию по карте, отсутствующей в базе данных эмитента.
15 — Invalid Issuer (Неверный эмитент). Такой RC обычно отправляется авторизационной платформой ПС и говорит о том, что маршрут отправки операции эмитенту не найден (в большинстве случаев, по причине неверного БИНа карты).
30 — Format Error (Ошибка формата данных). Возникает в результате тех или иных ошибок при заполнении сообщения в рамках определенного диалекта. Например, какое-либо поле превышает допустимое количество символов, либо вообще отсутствует, либо заполняется в неверном формате и/или кодировке. При этом ряд ПС, в случае отправки данного RC, направляет в ответном сообщении дополнительное поле с конкретным указанием на ошибочный элемент входящего сообщения.
88 и 89 — Cryptographic Failure (Криптографическая ошибка). Транзакция отклонена по причине ошибок криптографии. К примеру, таких как, ошибка шифрования пинблока, ошибка проверки цифровой подписи и других.
96 — System Error (Системная ошибка). В общем случае ошибка свидетельствует о том, что произошел сбой на каком-либо из этапов обмена. Как правило, в рамках ПЦ эквайрера, однако нам известны случаи, когда данный RC передавался и в рамках H2H.
Сервисные RC
К сервисным RC можно отнести коды ответов по операциям в рамках которых отсутствовали технические ошибки, а отказ был получен по причине ограничений доступа к тому или иному сервису со стороны эмитента или ПС, либо других условий, не связанных с техническими проблемами.
00 — Approved (Одобрено). Транзакция завершена успешно.
01 — Refer to Call Issuer (Позвоните эмитенту). Для завершения транзакции необходимо связаться с эмитентом.
04 — Capture Card (Изъять карту). Эмитент или ПС направил команду на изъятие карты.
05 — Do Not Honor (Не оплачивать). Отказ без объяснения причины. В подавляющем большинстве случаев такой RC отправляется эмитентом. Причины также следует уточнять у эмитента.
41 — Lost Card (Карта утеряна). Попытка выполнить операцию по карте, помеченной в БД эмитента или ПС как утерянная.
43 — Stolen Card (Карта украдена). Попытка выполнить операцию по карте, помеченной в БД эмитента или ПС как украденная.
51 — Not Sufficient Funds (Недостаточно средств). Сумма операции превышает сумму доступных средств на карточном счете.
52 и 53 — No Checking/Saving Account. Попытка выполнить операцию с неверным карточным счетом.
54 — Expired Card (Карта просрочена). Попытка выполнить операцию по карте с истекшим сроком действия.
55 — Incorrect PIN (Неверен пин). При выполнении операции с онлайн-пинкодом он был введен некорректно.
57 — Transaction Not Permitted to Issuer/Cardholder (Транзакция не разрешена для Эмитента/Держателя карты). Попытка выполнить операцию, не разрешенную для конкретного эмитента или держателя карты.
58 — Transaction Not Permitted to Acquier/Terminal (Транзакция не разрешена для Эквайрера/Терминала). Попытка выполнить операцию, не разрешенную для конкретного эквайрера или терминала.
Таков список наиболее часто встречающихся кодов ответа, имеющих одинаковые значения для всех ведущих ПС. Заметим, что их число несколько шире и варьируется в зависимости от конкретного диалекта ПС. Например в рамках спецификации Visa могут присутствовать RC, отсутствующие у Mastercard, и наоборот.
Оффлайновые коды ответов
В общих чертах следует коснутся и оффлайновых RC. К ним относятся коды, сгенерированные программным обеспечением POS-терминала. Поскольку в данном случае обмен выполняется не в рамках ISO 8583, а условия возникновения таких RC наступают в процессе т.н. EMV Transaction Flow, ограничимся общим описанием (Вопросы APDU/EMV-обмена будут подробно освещены в будущих материалах).
Z1 — OFFLINE DECLINED (Отклонено оффлайн). Было принято решение отклонить транзакцию, не отправляя онлайн-сообщение.
Z3 — NO ONLINE, DECLINED (Нет связи, отклонено оффлайн). POS-терминал предпринял попытку отправить онлайн-запрос, которая закончилась неудачно по причине отсутствия связи. В оффлайне транзакция отклонена.
Y1 — OFFLINE APPROVED (Одобрено оффлайн). Транзакция одобрена без онлайн-обращения к эмитенту. Справедливо для терминалов, поддерживающих оффлайн-транзакции.
Y3 — NO ONLINE, APPROVED (Нет связи, одобрено оффлайн). POS-терминал предпринял попытку отправить онлайн-запрос, которая закончилась неудачно по причине отсутствия связи. В оффлайне транзакция была одобрена. Справедливо для терминалов, поддерживающих оффлайн-транзакции.
SMS-информирование
Достаточно популярная ныне услуга SMS-информирования используется многими держателями карт. Помимо очевидного удобства, являясь в ряде случаев причиной споров, а иногда и скандалов между мерчантом и кардхолдером. Рассмотрим наиболее типичный случай:
- Клиент расплачивается картой.
- Получает SMS о списании суммы услуги/покупки.
- Терминал не печатает чек/зависает/перезагружается.
- Мерчант не имеет на руках успешного чека по операции.
- Клиент утверждает, что операция успешна, при этом ссылается на SMS.
Дальнейший сценарий развития событий зависит от опытности персонала ТСП и многих других факторов.
Первое и самое важное, что следует принимать во внимание в такой ситуации: критерием успешности операции по карте является чек (либо, если речь идет об одобренных ПС терминалах, не оснащенных чековым принтером — его электронный эквивалент), содержащий успешный код ответа и/или его расшифровку. Никакие SMS, полученные клиентом, критерием успешности операции не являются. Ни один диспутный цикл ни по одной претензии не будет рассматривать полученное кардхолдером SMS в качестве аргумента. Основная причина состоит в том, что такая услуга как SMS-информирование никак не специфицирована со стороны ПС. То есть, технические инструменты, в том числе и протоколы/формат обмена, которыми она достигается, зависят от каждого конкретного эмитента. В том числе, может быть реализована и с помощью различных самописных решений. В общем случае, некий условный «SMS-сервер» анализирует запросы к карточному контракту и фиксирует изменения его доступного остатка. Помимо этого, в большинстве случаев могут анализироваться поля 41 (Идентификатор Терминала (Terminal ID)), 42 (Идентификатор Мерчанта (Merchant ID)) и 43 (Имя и местонахождение мерчанта (Card Acceptor Name/Location)) из входящего запроса от эквайрера. Затем эти данные вносятся в «тело» SMS-сообщения и отправляются на номер телефона, который кардхолдер указал при выпуске карты. На выходе получается SMS-сообщение примерно такого формата: «КАРТА, ДАТА/ВРЕМЯ, Тип операции, Сумма, НАИМЕНОВАНИЕ ТСП, ДОСТУПНЫЙ ОСТАТОК».
Подчеркнем ряд важных моментов: фактически, принцип функционирования SMS-сервера базируется на срабатывании триггеров. При этом он может быть настроен на срабатывание при выполнении операции Оплата, но не срабатывать на операцию Отмена оплаты; далее, SMS-сервер ничего «не знает» про состояние каналов связи в момент выполнения операции. Соответственно, не способен «понять», был ли ответ на авторизацию успешно доставлен на POS-терминал. Сумма и комбинации всех этих факторов, а также отсутствие регламентов со стороны ПС, делают SMS-инфо крайне ненадежным источником. Этот факт необходимо учитывать как мерчантам, так и кардхолдерам. Безусловно, качество предоставления такой услуги, как SMS-информирование в последние годы существенно возросло. Однако это не отменяет сказанного выше.