Основная информация

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

Компанией ABG CardTechnology разработан програмно-аппаратный комплекс, выполняющий авторизацию и последующий процессинг международных и национальных кредитных карточек. Данный комплекс в течение ряда лет обеспечивает работу Компании Объединенных Кредитных Карточек - UCS  - не путать с названием нашей компании -Универсальные Комплексные Системы!

С целью обеспечения взаимодействия между сетями терминальных устройств (ТУ) и процессинговым центром была разработана программная система – авторизационный сервер (АС). В общем случае сеть ТУ может быть представлена любым набором клиентских оконечных устройств (в нашем случае терминальные устройства (ТУ) - кассы R-Keeper как терминал + сервер R-Keeper как ПО), обладающих возможностью формировать данные о совершаемых сделках между предприятием сервиса и держателями карт: кассовые аппараты (ККМ), терминалы самообслуживания, автоматизированные рабочие места и пр. 

АС может предоставлять четыре типа услуг: 

  1. собственно авторизация
  2. работа с внутренним архивом транзакций АС
  3. генерация MDC файла (файла финансовых транзакций)
  4. обеспечение файлового обмена между АС и процессинговым центром (ПЦ).

Для обеспечения простоты, надежности и взаимной независимости АС и программного обеспечения ТУ, обмен информацией между ТУ и АС происходит через общее файловое пространство посредством файлов запросов и ответов. Под общим файловым пространством, с точки зрения ПО R-Keeper, мы подразумеваем общую с АС директорию обмена, которую предоставляет владелец АС. 

Таким образом, для настройки авторизации кредитных карт в ресторане, отеле и.т.д мы используем директорию обмена, доступную в местной локальной сети и предоставленную банком эмитентом (банком, с которым работает данный объект). 

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

Настройка Менеджерской RK6 (E_Rest32)

В  менеджерском приложении "Редактор" необходимо в свойствах кредитной карты (или карт) на закладке "Кредитная ката" указать опцию "Авторизация" и по-желанию опцию "Автораспознавание", при этом выбрав в списке соответсвующий тип кредитной карты (см. Рис.1). Автораспознавание позволяет автоматически распознавать кредитную карту при прокатке в режиме оплаты, без необходимости ручного выбора из списка кредитных карт.

Также в редакторе необходимо установить опцию "Авторизация кредитных карт" в меню "Списки" - "Общие настройки" (см. Рис.2) - без этой настройки авторизация кредитных карт на кассовой станции происходить не будет!

Настройка кассы (Dos-rkclient)

Интерфейс взаимодействия Rkeeper-АС реализован в библиотеке AUABG16.DLL (для кассового DOS-сервера) и AUABG32.DLL (для кассового NT-сервера). 

Библиотека записывается в корень текущего каталога сервера R-Keeper и имеет следующие настройки в файле RKEEPER6.INI: 

  • CredCardDLL=<имя используемой библиотеки>. Например,  CredCardDLL=AUABG16.DLL или CredCardDLL=AUABG16.DLL. Есть реализация библиотеки авторизации для других стран (например, для Литвы AULIT*.DLL) 
  • AsServerPath=<директория обмена>. Может быть указан как локальный путь, так и сетевой ресурс, подключенный как локальный диск. Например D:\Bank\ 
  • AUMode = 0 - протокол обмена (отличия есть только при удалении чека). Возможные значения: 0 - ABG оригинальный; 1 - Мастер Банк 
  • AULog = 2 - уровень логгирования операций: 0 - не вести LOG (пишутся только ошибки); 1 - редкие события; 2 - обмен с сервером авторизации 
  • AUWaitForCheck = 20 - время ожидания (в минутах) закрытия чека после успешной авторизации 
  • AU_UNIT01 = <номер терминала для кассы UNIT01>. По умолчанию равен номеру кассы (001) 
  • .......
  • AU_UNIT99 = <номер терминала для кассы UNIT99>

При закрытии дня формируется файл(-ы) финансовых транзакций, его название делается по маске: 

  • raYYMMDD.TRM

- где:

  • YY MM DD - логическая дата 
  • TRM - номер терминала 001..999 

Основные правила

Ниже описаны основные правила совместной работы терминального устройства (ТУ) и авторизационного сервера (АС):

  • Все ТУ (или интерфейсные модули(ИМ) ) и АС имеют доступ к одному общему для всех рабочему каталогу (директория обмена). Этот каталог используется для всех рассматриваемых далее файлов. И ТУ и АС должны иметь права чтения, записи, создания, поиска и удаления файлов в данном каталоге. 
  • Каждому ТУ в сети присваивается уникальный номер (поле f15 в файле обмена - TrmN) в пределах 001 - 999. Этот номер используется в файлах обмена между ТУ/ИМ и авторизационным сервером . Запрос от ТУ/ИМ записывается в файл с именем “$int__i$.NNN” , где NNN = “001” - “999”. Ответ от АС записывается в файл с именем “$int__o$.NNN”. Номер ТУ, в частности, определяет валюту, в которой производятся транзакции. При необходимости принимать в одном ТУ несколько валют, ТУ присваивается несколько номеров. 
  • ТУ/ИМ формирует файлы запросов с расширением, строго соответствующим его уникальному номеру TrmN. ТУ/ИМ обрабатывает файлы ответов строго по своему уникальному номеру TrmN. С одним авторизационным сервером не допускается работа нескольких ТУ/ИМ с одинаковым TrmN. 
  • На время записи запроса или ответа файл должен быть заблокирован для чтения или открыт в эксклюзивном режиме. 
  • После прочтения файла авторизационного запроса или ответа он должен быть удален считывающей стороной, что свидетельствует о его прочтении. 
  • Для ТУ/ИМ должен быть предусмотрен конфигурируемый параметр, определяющий фиксированное минимальное время ожидания ответа от АС. До истечения этого времени ТУ/ИМ не должны прерывать процесс ожидания ответа на запрос. 
  • Выполнение авторизационных запросов строго последовательное. ТУ/ИМ могут формировать очередной файл запроса от данного ТУ только после обработки и удаления файла ответа на предыдущий запрос. Создавая новый запрос, ТУ/ИМ не должны затирать предыдущий, если он не был считан АС. В свою очередь АС затирает ответ, еще не обработанный ТУ/ИМ. 
  • При старте ТУ/ИМ должны проверять наличие и безусловно удалять старые файлы и запросов и ответов, если они есть. При невозможности удалить какой-либо из файлов, работа с АС блокируется. 
  • На запросы, обнаруженные при старте, АС с версиями 4.10 и выше формирует отрицательный ответ с сообщением “INVALID TRANS” . Штатная обработка начинается только после успешного старта программы.

Примечание: В прикрепленном файле полное описание протокола ABG, предоставленное Компанией Объединенных Кредитных Карточек - UCS .

ВложениеРазмер
formats5.rar524.57 КБ