Contact card issuer ошибка 1с

Обновлено: 05.07.2024

В рамках материала рассмотрим ситуации с которыми сталкивается, пожалуй, любой мерчант/эквайрер/кардхолдер, а именно - технические сбои и негативные ответы при использовании карт. Кроме того, коснемся вопросов работы SMS-информирования и автоматических отмен.

Терминология

Авторизация — процесс обмена данными между участниками операции по банковской карте или другому платежному средству (например, мобильному кошельку и т.д.). Стандартная цепочка обмена выглядит следующим образом: Эквайрер (см. ниже) отправляет авторизационный запрос в ПС, ПС - эмитенту. Эмитент выполняет все необходимые проверки, такие как проверки безопасности, проверки доступности средств на карточном счете и другие, на основании которых отправляется ответ (положительный или отрицательный) на авторизационный запрос. Ответ на авторизационный запрос отправляется обратным маршрутом. То есть, сначала в ПС а затем эквайреру.

POS-терминал (POS - Point Of Service) — устройство, обеспечивающее техническую возможность обслуживания карт и других платежных средств.

Эмитент — финансовый институт (банк или иная финансовая организация), выпустивший (эмитировавший) карту.

Эквайрер — финансовый институт (банк или иная финансовая организация), обеспечивающий обслуживание карт мерчантом.

Мерчант — торгово-сервисное предприятие (далее ТСП), имеющее техническую возможность принимать карты.

Кардхолдер — держатель карты, имеющий право выполнять по ней набор операций, разрешенных эмитентом.

Процессинговый центр (ПЦ) — программно-аппаратный комплекс, обеспечивающий технологическую возможность информационного обмена между внутренними и внешними участниками расчетов в рамках того или иного сервиса (в нашем случае - эквайринга).

Другое относительно распространенное наименование ПЦ — «Банковский хост», или просто «хост» (от англ. Host - букв. «хозяин»). То есть узел, играющий роль сервера в рамках классической клиент-серверной архитектуры. Далее по тексту мы будем использовать как аббревиатуру ПЦ, так и термин «хост» с его производными.

Эквайринг бесконтактные платежи

Ниже приведем наиболее распространенные RC, разбив их на две условные группы — Технические и Сервисные.

Технические RC

00 - Approved (Одобрено). Транзакция завершена успешно.

13 - Invalid Amount (Неверная сумма). Поле 4 (Сумма) заполнено неверным значением. Данный RC может возникнуть в случае срабатывания какого-либо лимита, либо в рамках операций, подразумевающих предварительную авторизацию с ее последующим завершением (например, предварительное бронирование услуг с последующим расчетом).

14 - Invalid Card Number(Неверный номер карты). Неверно заполнено поле 2 (Номер карты), либо имеет место быть попытка выполнить транзакцию по карте, отсутствующей в базе данных эмитента.

15 - Invalid Issuer (Неверный эмитент). Такой RC обычно отправляется авторизационной платформой ПС и говорит о том, что маршрут отправки операции эмитенту не найден (в большинстве случаев, по причине неверного БИНа карты).

88 и 89 - Cryptographic Failure (Криптографическая ошибка). Транзакция отклонена по причине ошибок криптографии. К примеру, таких как, ошибка шифрования пинблока, ошибка проверки цифровой подписи и других.

96 - System Error (Системная ошибка). В общем случае ошибка свидетельствует о том, что произошел сбой на каком-либо из этапов обмена. Как правило, в рамках ПЦ эквайрера, однако нам известны случаи, когда данный RC передавался и в рамках H2H.

Сервисные 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-обмена будут подробно освещены в будущих материалах).

Y1 - OFFLINE APPROVED (Одобрено оффлайн). Транзакция одобрена без онлайн-обращения к эмитенту. Справедливо для терминалов, поддерживающих оффлайн-транзакции.

SMS-информирование

Достаточно популярная ныне услуга SMS-информирования используется многими держателями карт. Помимо очевидного удобства, являясь в ряде случаев причиной споров, а иногда и скандалов между мерчантом и кардхолдером. Рассмотрим наиболее типичный случай:

  • Клиент расплачивается картой.
  • Получает SMS о списании суммы услуги/покупки.
  • Терминал не печатает чек/зависает/перезагружается.
  • Мерчант не имеет на руках успешного чека по операции.
  • Клиент утверждает, что операция успешна, при этом ссылается на SMS.

Дальнейший сценарий развития событий зависит от опытности персонала ТСП и многих других факторов.

Подчеркнем ряд важных моментов: фактически, принцип функционирования SMS-сервера базируется на срабатывании триггеров. При этом он может быть настроен на срабатывание при выполнении операции Оплата, но не срабатывать на операцию Отмена оплаты; далее, SMS-сервер ничего «не знает» про состояние каналов связи в момент выполнения операции. Соответственно, не способен «понять», был ли ответ на авторизацию успешно доставлен на POS-терминал. Сумма и комбинации всех этих факторов, а также отсутствие регламентов со стороны ПС, делают SMS-инфо крайне ненадежным источником. Этот факт необходимо учитывать как мерчантам, так и кардхолдерам. Безусловно, качество предоставления такой услуги, как SMS-информирование в последние годы существенно возросло. Однако это не отменяет сказанного выше.

Читайте также: