Архив - Авторизация кредитных карт по протоколу ABG в системе R-Keeper v6
Основная информация
В документе описаны основные положения и настройки авторизации кредитных карт с помощью протокола ABG.
Компанией ABG CardTechnology разработан программно-аппаратный комплекс, выполняющий авторизацию и последующий процессинг международных и национальных кредитных карточек. Данный комплекс в течение ряда лет обеспечивает работу Компании Объединенных Кредитных Карточек - UCS - не путать с названием нашей компании -Универсальные Комплексные Системы!
С целью обеспечения взаимодействия между сетями терминальных устройств (ТУ) и процессинговым центром была разработана программная система – авторизационный сервер (АС). В общем случае сеть ТУ может быть представлена любым набором клиентских оконечных устройств (в нашем случае терминальные устройства (ТУ) - кассы R-Keeper как терминал + сервер R-Keeper как ПО), обладающих возможностью формировать данные о совершаемых сделках между предприятием сервиса и держателями карт: кассовые аппараты (ККМ), терминалы самообслуживания, автоматизированные рабочие места и пр.
АС может предоставлять четыре типа услуг:
- собственно авторизация
- работа с внутренним архивом транзакций АС
- генерация MDC файла (файла финансовых транзакций)
- обеспечение файлового обмена между АС и процессинговым центром (ПЦ).
Для обеспечения простоты, надежности и взаимной независимости АС и программного обеспечения ТУ, обмен информацией между ТУ и АС происходит через общее файловое пространство посредством файлов запросов и ответов. Под общим файловым пространством, с точки зрения ПО R-Keeper, мы подразумеваем общую с АС директорию обмена, которую предоставляет владелец АС.
Таким образом, для настройки авторизации кредитных карт в ресторане, отеле и.т.д мы используем директорию обмена, доступную в местной локальной сети и предоставленную банком эмитентом (банком, с которым работает данный объект).
Важно! ТУ использует АС только для авторизации (нефинансовая транзакция) и передачи итогового файла финансового отчета. При этом задача генерации файла финансового отчета ложится на ТУ предприятия, как обладающих всей полнотой информации. Одновременно с ТУ снимается требование обязательного проведения всех транзакций, в том числе отмен и голосовых авторизаций, через АС, исключая случаи, когда отмену требуется провести в он-лайн режиме.
Настройка Менеджерской RK6 (E_Rest32)
В менеджерском приложении "Редактор" необходимо в свойствах кредитной карты (или карт) на закладке "Кредитная ката" указать опцию "Авторизация" и по-желанию опцию "Автораспознавание", при этом выбрав в списке соответствующий тип кредитной карты Автораспознавание позволяет автоматически распознавать кредитную карту при прокатке в режиме оплаты, без необходимости ручного выбора из списка кредитных карт.
Также в редакторе необходимо установить опцию "Авторизация кредитных карт" в меню "Списки" - "Общие настройки" - без этой настройки авторизация кредитных карт на кассовой станции происходить не будет!
Настройка кассы (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 .