Карточный процессинг относится к числу наиболее критичных направлений банковских информационных технологий. Любая операция по банковской карте сопровождается обменом структурированными сообщениями между терминальным оборудованием, процессинговой системой, банковскими системами и другими участниками обработки. Для такого обмена традиционно применяются протоколы, основанные на ISO 8583, где данные представлены в виде типа сообщения, битовой карты и набора полей фиксированной или переменной длины.

В современных банковских системах все чаще используются сервисные архитектуры, очереди сообщений, API-шлюзы и микросервисы. Для таких решений JSON является более удобным форматом, поскольку он человекочитаем, хорошо поддерживается инструментами разработки и легко валидируется с помощью схем. Поэтому возникает задача не просто разобрать ISO 8583-сообщение, а представить его смысл в форме, пригодной для обмена между современными компонентами банковской инфраструктуры.

В рамках рассматриваемой работы предполагается разработка отдельного CBA-модуля для интеграции с CBA TCI. Особенность решения состоит в том, что модуль не должен передавать классическое ISO 8583-сообщение как набор полей и bitmap. Вместо этого он должен формировать JSON-сообщение, в котором сохраняются назначение операции, обязательные реквизиты, идентификаторы транзакции, сумма, валюта, сведения о терминале и результат обработки.

Такой подход не означает отказа от логики исходного протокола. Напротив, при переходе к JSON необходимо сохранить бизнес-семантику сообщений: тип операции, направление обмена, состав обязательных данных, правила ответа и связь между запросом и ответом. Иначе JSON станет только произвольным транспортным объектом и потеряет совместимость с процессинговой логикой.

Основная сложность заключается в том, что ISO 8583 не является самоописательным форматом. Номер поля сам по себе не раскрывает его бизнес-смысл без профиля обмена. Например, код обработки, сумма операции, системный номер аудита, ссылочный номер и код ответа имеют определенное назначение и используются по правилам карточного процессинга. При проектировании JSON-модели эти значения должны получить понятные имена и однозначные типы данных.

Для CBA-модуля целесообразно строить JSON-сообщение вокруг нескольких логических блоков: protocol, transaction, card, terminal, account и result. В protocol фиксируются тип сообщения, версия представления и направление обмена. В transaction помещаются код операции, сумма, валюта и идентификаторы транзакции. В terminal указываются данные устройства или точки обслуживания. В result передаются признаки результата обработки и код ответа.

В классическом ISO 8583 наличие полей определяется битовой картой. В JSON такая карта обычно не нужна, поскольку наличие данных определяется самой структурой объекта. Однако обязательность полей должна сохраняться. Для этого используется схема сообщения, которая определяет, какие атрибуты обязательны для запроса, какие возвращаются в ответе, какие являются условными и какие не должны попадать в журналирование.

Рассмотрим условный пример авторизационного запроса. В классическом сообщении ISO 8583 он мог бы содержать тип сообщения, код обработки, сумму, валюту, системный номер аудита, ссылочный номер и данные терминала. В JSON-формате эти же данные могут быть представлены как объект с осмысленными атрибутами. Это делает сообщение более удобным для CBA-модуля и связанных с ним сервисов.

Таблица 1

Пример сопоставления элементов ISO 8583 с JSON-моделью

Пример JSON-сообщения для CBA-модуля может выглядеть таким образом:

{

"protocol": {

"name": "CBA_TCI",

"format": "JSON",

"messageType": "0100"

},

"transaction": {

"type": "authorization",

"processingCode": "000000",

"amount": {

"value": 1500,

"currency": "643"

},

"stan": "123456", "rrn": "617012123456"

},

"terminal": {

"id": "TERM0001"

}

}

В данном примере JSON не копирует физическую структуру протокола ISO 8583, но сохраняет смысл ключевых элементов сообщения. Наличие bitmap заменяется описанной JSON-схемой и правилами обязательности атрибутов.

При проектировании такой модели важно разделять транспортный формат и бизнес-семантику. Формат определяет способ представления данных, но не должен менять смысл операции. Если исходное сообщение является авторизационным запросом, JSON-объект также должен однозначно отражать, что это запрос на авторизацию транзакции. Если формируется ответ, он должен сохранять связь с исходным запросом через идентификаторы транзакции.

Отдельное внимание нужно уделить суммам и датам. В ISO 8583 сумма часто передается как числовая строка с ведущими нулями, а масштаб определяется контекстом валюты. В JSON не следует терять эту информацию. Практичным подходом является передача суммы в минорных единицах вместе с кодом валюты и, при необходимости, отображаемым значением.

Для обработки ответов в CBA-модуле необходимо предусмотреть единый объект результата. Он может содержать код ответа, текстовое описание, технический статус и признак успешности операции. Такой объект позволяет отделить бизнес-отказ, например недостаточность средств, от технических ошибок, например невозможности обработать сообщение или недоступности внешнего компонента.

Обработка ошибок также должна быть формализована. Если сообщение не соответствует ожидаемой JSON-схеме, авторизатор должен вернуть понятный технический отказ. Если отсутствует обязательный атрибут, ошибка должна указывать на конкретное поле. Если ошибка возникает на этапе бизнес-обработки, она должна отражаться в результате операции, а не смешиваться с ошибками формата.

Безопасность является обязательным требованием. JSON-сообщения легче логировать и анализировать, поэтому возрастает риск случайного попадания чувствительных карточных данных в журналы или тестовые среды. Полное числовое значение карты не должен сохраняться в обычных логах, вместо него следует использовать маску или токен. Также необходимо ограничивать доступ к диагностическим данным и контролировать состав сообщений, попадающих в мониторинг.

Тестирование CBA-модуля должно проверять не только синтаксис JSON, но и корректность сохранения процессинговой логики. Для каждого сценария следует подготовить исходные данные, ожидаемое JSON-сообщение, ожидаемый ответ и негативные случаи: отсутствие обязательных полей, неверный формат суммы, ошибочный код валюты, повторную отправку сообщения и техническую недоступность компонента.

Таким образом, преобразование сообщений ISO 8583 в JSON-формат следует рассматривать как проектирование нового представления для CBA-модуля, а не как простую замену одного текста другим. Правильно спроектированная JSON-модель позволяет сохранить процессинговую семантику, упростить интеграцию с современными сервисами и повысить удобство сопровождения системы.

Литература:

1. ISO 8583–1:2003. Financial transaction card originated messages — Interchange message specifications.
2. Bray T. The JavaScript Object Notation (JSON) Data Interchange Format. RFC 8259, 2017.
3. PCI Security Standards Council. Payment Card Industry Data Security Standard: Requirements and Testing Procedures.