Для завершения платежа вам может прийти sms сообщение следуйте инструкциям для оплаты

Коды ответов

Результатом выполнения и критерием успешности любой операции является Код ответа (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-информирование в последние годы существенно возросло. Однако это не отменяет сказанного выше.