Техническое описание приёма платежей в торговых сетях
· Введение
Документ описывает техническое предложение для торговых сетей для организации приёма платежей через платёжную систему Pinpay express.
Основное назначение документа дать представление о том, с помощью каких технических средств реализован приём платежей с кассовых точек торговой сети и механизмах передачи данных в платёжную систему Pinpay express.
· Сокращения
ПС – Платёжная Система
САП – Сервер Авторизации Платежей
ККМ – Контрольно-Кассовая Машина
· Верхне уровневое описание
· Основные компоненты
· Модуль ККМ
Модуль для кассового аппарата (KKM) является частью рабочего места кассира, осуществляющего прием платежа на кассовом аппарате супермаркета.
В рамках текущего решения поддерживаются следующее программное обеспечение, устанавливаемое на ККМ:
Frontol Win32, производитель АТОЛ
ККМ с модулем Cyberplat
Взаимодействие ККМ с модулем сервера авторизации платежей осуществляется с помощью обмена файлами.
В рамках платежной системы существует два типа запросов:
· получение разрешения на платеж
· платеж
Перед приемом наличных средств ККМ должна убедиться в том, что реквизиты платежа верны и в данный момент оплата возможна. Для этого применяется первый запрос – “получение разрешения на платеж”. На данном этапе не происходит реального зачисления средств на лицевой счет абонента. Этот этап должен происходить в режиме реального времени. Сумма на этом шаге может быть больше реальной суммы платежа. В случае положительного ответа, возможен прием средств.
После этого осуществляется подтверждение платежа, посредством отправки второго запроса к системе – “платеж”.
· Сервер Авторизации Платежей
Сервер авторизации платежей (САП) предоставляется для обеспечения взаимодействия одного или нескольких интеллектуальных кассовых аппаратов (ККМ) с центральным сервером платежной системы.
Взаимодействие с центральным сервером платежной системы “Pinpay express” осуществляется по каналам сети общего пользования Internet посредством протоколов HTTPS/TCP/IP. Защита информации обеспечивается путем шифрования данных на транспортном уровне (SSL) и использования электронно-цифровых подписей (MD5/RSA).
Сервер авторизации платежей представляет собой доработанное приложение Cyberplat ATMPAY.
· Сервер платёжной системы
· Внедрение
Внедрение системы в существующую торговую сеть заключается в установке и настройке следующих модулей:
· Установка на стороне торговой сети сервера авторизации платежей
· Настройка сервера авторизации платежей на работу с ПС Pinpay express
· Настройка кассовых точек на работу с сервером авторизации платежей
· Технические требования
· Требования к модулю сервера авторизации платежей
Сервер авторизации платежей устанавливается на компьютер с предустановленной операционной системой Windows (XP/2000/Vista).
Рекомендуемая конфигурация:
Дополнительные требования:
Компьютер должен иметь подключение к внутренней сети торговой сети для организации файлового обмена с модулями кассовых аппаратов.
Компьютер должен иметь подключение к сети Internet для взаимодействия с сервером ПС Pinpay express по каналам сети общего пользования Internet посредством протоколов HTTPS/TCP/IP.
· Требования к модулю кассового аппарата
На ККМ должно быть установлено ПО с возможностью отправки платежей через выбранную платёжную систему.
В случае использования на ККМ программного обеспечения компании АТОЛ (Frontol Win32) в выбранной редакции Frontol должен быть модуль работы с платёжными системами.
Настройка ПО Frontol заключается в
· Выбор ПС Cyberplat в качестве платёжной системы.
Данный выбор определяет лишь протокол, который будет использоваться при отправке платежей. Отсылкой платежей в ПС Pinpay express занимается сервер авторизации платежей.
· Настройка адреса расшаренной сетевой папки для организации файлового обмена между ККМ и сервером авторизации платежей.
· Логика работы сервера авторизации платежей
САП осуществляет постоянный мониторинг директории обмена в локальной или удаленной файловой системе. После обнаружения файла в данной директории или одной из поддиректорий с подходящим именем и длиной происходит его считывание. Такой файл считается файлом запроса. Файл должен иметь имя “$int__i$.NNN”, где NNN номер терминала. Номер терминала может содержать латинские буквы и цифры. Файл запроса должен иметь длину в 200 байт. После успешного считывания производится его унарное переименование в той же директории. Файлу присваивается имя “$int__p$.NNN”, где NNN номер терминала. После отправки запроса и получения ответа из платежной системы САП формирует файл ответа с именем “$int__o$.NNN”. Затем удаляется блокировочный файл “$int__p$.NNN”.
Для обработки каждого нового файла запроса запускается новый процесс.
Ответ на второй запрос (платеж) формируется сразу, без отправки в платежную систему, т. к. он помещается в очередь. За обработку очереди отвечает отдельный процесс - сканер. Отправка содержимого очереди производится синхронно (последовательно), т. к. эта процедура не требует высокой скорости. После помещения запроса в очередь САП гарантирует его доставку (при условии, что был получен положительный ответ на первом этапе и платежная система работоспособна).
Если запрос не удалось поместить в очередь – будет выдан отрицательный ответ.
При нормальной работе ответ на второй запрос (платеж) будет всегда положительным.
Поэтому возможно отключения формирования ответа на втором этапе. Это достигается изменением параметра в конфигурационном файле.
В таком режиме работы ККМ должна убедиться в том, что она смогла сформировать файл запроса и в том, что он исчез (считан САП).
Очередь состоит из набора файлов в специальной директории. Каждый файл содержит один платеж. Сканер работает по принципу конечного автомата, оперируя файлами в очереди.
Фалы очереди могут иметь следующие расширения:
· “req” – новый запрос на платеж;
· “chk” – запрос прошел предварительную проверку;
· “unk” – состояние платежа не определено;
· “bad” – платеж не может быть проведен (обработка платежа оканчивается).
Изначально в очередь помещаются “req”-файлы. После чтения такого файла сканер производит еще одно получение разрешения на платеж уже на реальную сумму. Если произошла транспортная ошибка, то файл будет обработан позднее. При отрицательном ответе файлу назначается расширение “bad”. Этого не должно происходить при соблюдении протокола обмена с САП и при нормальной работе платежной системы. Такие платежи требуют детального анализа и могут быть проведены позднее путем ручного присвоения файлу расширения “req”. При положительном ответе файлу назначается расширение “chk”.
При обнаружении “chk”-файла сканер производит отправку платежа. Если произошла транспортная ошибка, то файлу назначается расширение “unk”. При положительном ответе файл удаляется. При этом деньги начисляются на лицевой счет абонента. При отрицательном ответе файлу назначается расширение “bad” (на этом обработка оканчивается, требуется детальное изучение ситуации).
При обнаружении “unk”-файла сканер производит проверку состояния платежа в платежной системе. Если платеж проведен, то файл удаляется. Если платежа не было, то файл заново помещается в очередь с расширением “req” или “chk” в зависимости от состояния.
· Правила обмена
Все ККМ и САП имеют доступ к одной общей для всех директории обмена, определяемой в конфигурационном файле. Эта директория (или ее поддиректории) используется для всех рассматриваемых далее файлов. И ККМ и САП должны иметь права чтения, записи, создания, поиска и удаления файлов в данной директории.
Каждой ККМ в сети присваивается уникальный номер NNN в пределах от “001” до “ZZZ”. Номер ККМ может содержать цифры и латинские буквы. При использовании букв считается, что регистр не важен, т. е. символ ‘Z’ полностью соответствует символу ‘z’.
ККМ присваивает каждому запросу к САП свой уникальный в течение суток цифровой номер.
Обработка следующего запроса САП со стороны одной ККМ производится только по завершении обработки текущего запроса (формирования файла ответа).
Перед отправкой нового запроса ККМ должна убедиться в том, что САП не занят в данный момент обработкой предыдущего запроса. Для этого ККМ проверяет наличие в директории обмена файла ”$int__p$.NNN”, где NNN – номер ККМ. Если файл существует, то выкладывать новый файл запроса запрещено (отказ в обслуживании).
ККМ пишет запрос во временный файл в директории обмена. Желательно давать ему имя ”~int__i$.NNN”, где NNN – номер ККМ. После записи, файл унарно переименовывается в файл запроса в той же директории. Имя файла запроса должно быть следующим - ”$int__i$.NNN”, где NNN – номер ККМ.
После успешного чтения файла запроса САП сразу удаляет предыдущий файл ответа с соответствующим именем для того, что бы ККМ не отреагировала на ложный файл ответа. Затем САП удаляет файл запроса унарным переименованием в ”$int__p$.NNN”, где NNN – номер ККМ.
ККМ ждет в течение оговариваемого времени T1 исчезновения, сформированного ей файла запроса. Если файл запроса не удален, ККМ сама его уничтожает и выдает оператору сообщение о недоступности сервера.
После исчезновения файла запроса ККМ ждет в течение оговариваемого времени T2 появления файла ответа. Файл именуется следующим образом: ”$int__o$.NNN”, где NNN – номер ККМ. Файл появляется в той же директории что и файл запроса. Номер ККМ соответствует номеру в имени файла запроса. Если файл ответа не появился, ККМ выдает оператору сообщение о недоступности сервера. В противном случае ККМ считывает и удаляет файл ответа. После считывания ответа ККМ должна осуществлять проверку номера ответа и номера ККМ. Если эти поля не совпадают с соответствующими полями в файле запроса, то ККМ считает что это ответ на предыдущий запрос или для другой ККМ. ККМ удаляет этот ответ и ожидает появления корректного файла ответа.
САП пишет ответ во временный файл в директории обмена. Файл именуется следующим образом: ”~int__o$.NNN”, где NNN – номер ККМ. После записи, файл унарно переименовывается в файл ответа в той же директории. Имя файла ответа будет следующим: ”$int__o$.NNN”, где NNN – номер ККМ. Если файл ответа не готов в течение времени T2, то САП его не формирует, т. к. ККМ уже не ждет ответа. Затем удаляется файл ”$int__p$.NNN”, где NNN – номер ККМ.
САП может не формировать файл ответа на втором шаге (платеж). Это достигается путем изменения конфигурации.
Для проверки файла на наличие ККМ должна производить чтение директории, а не файла.
· Последовательность взаимодействия
Описание ведется на примере кассира, осуществляющего прием платежа на кассовом аппарате супермаркета. Для терминала самообслуживания алгоритм работы аналогичен.
· Кассир начинает обслуживание покупателя, желающего осуществить платеж сотовому оператору.
· Покупатель называет кассиру сумму платежа.
· Кассир, убедившись в платежеспособности клиента, вводит заявленную сумму в строку ввода и нажимает спец. клавишу, далее кассир вводит остальные реквизиты платежа в ККМ (например, оператор услуг, номер телефона). В одном чеке можно оформить только один платёж за телефон. Если клиент желает совершить сразу несколько оплат – каждая должна идти отдельным чеком (для каждого платежа процедура повторяется с пункта 1.1).
· ККМ помещает в директорию обмена файл запроса на проверку реквизитов платежа (получение разрешения на платеж) и переходит в режим ожидания приёма запроса сервером. Сумма на этом шаге может быть больше реальной суммы платежа.
· Сервер платежей удаляет файл запроса и начинает его обработку – именно факт удаления запроса позволяет кассе перейти в режим ожидания ответа. Если сервер не заберёт (не удалит) запрос в течение настраиваемого времени T1, то касса удаляет свой запрос, считает, что сервер не принимает запросы и отказывает в осуществлении платежа клиенту.
· В случае «приёма» запроса сервер платежей посылает запрос на проверку реквизитов платежа в платежную систему и переходит в режим ожидания ответа.
· После получения ответа от платежной системы сервер платежей формирует ответ на запрос для кассы в директории обмена.
· В течение настраиваемого оговоренного времени T2, с момента перехода в режим ожидания ответа, ККМ ожидает появления файла ответа.
· Если файл ответа появился, то ККМ считывает его, удаляет и визуализирует результаты проверки реквизитов на экране.
· В случае отрицательного ответа (или ответа нет) кассир прерывает исполнение платежа.
· В случае положительного результата ККМ на принтере чеков распечатывает два слипа (копия клиента и копия магазина – см. Приложение 2), а на дисплее кассира появляется диалог «Попросите клиента подписать счёт и нажмите ДА, если подпись получена, НЕТ, чтобы отказать в авторизации».
· После получения необходимой подписи кассир нажимает ДА происходит автоматическая печать обычного чека продажи (в качестве наименования товара и артикула используется информация из соответствующего конфигурационного файла) и печатается подитог, но чек не закрывается.
· С этого момента считается, что оплата услуг подготовлена (оформлена в виде подписанных счетов), но не авторизированна. Кассир нажимает на кнопку РАСЧ и происходит формирование файла подтверждения оплаты.
· ККМ помещает в директорию обмена файл запроса на платеж.
· ККМ переходит в режим ожидания приёма запроса сервером.
· Сервер платежей удаляет файл запроса и начинает его обработку – именно факт удаления запроса позволяет кассе перейти в режим ожидания ответа. Если сервер не заберёт (не удалит) запрос в течение настраиваемого времени T1, то касса удаляет свой запрос, считает, что сервер не принимает запросы и отказывает в осуществлении платежа клиенту.
· В случае «приёма» запроса сервер платежей формирует ответ на запрос для кассы в директории обмена.
· В течение настраиваемого оговоренного времени T2, с момента перехода в режим ожидания ответа, ККМ ожидает появления файла ответа.
· В случае отрицательного ответа (или ответа нет) кассир прерывает исполнение платежа.
· Если файл ответа появился, то ККМ считывает его, удаляет и визуализирует результаты платежа на экране.
· Чек закрывается (печатается фискальная надпечатка).
ВНИМАНИЕ!!! В случае использования кассовых аппаратов на этапе подтверждения платежа (п. п. 1.14 –1.21) рекомендуется пропуск пунктов 1.15 – 1.20. Такой сценарий работы САП определяется настройками
