|
|
Home
Протокол приема платежей "Delta Key SA-1"Обеспечение целостности данных запросов и ответов Запрос на проведение платежа Запрос на проверку статуса платежа Общая информация о порядке информационного обменаПлатежная система взаимодействует с поставщиком услуг по протоколу HTTP или HTTPS, передавая запросы используя метод GET либо метод POST. Для использования протокола "Delta Key SA-1" необходимо быть оператором, зарегистрированном в системе в качестве Поставщика услуг. (см. Регистрация в системе в качестве поставщика услуг). Получить статус поставщика услуг можно автоматически, скачав и установив программу "Система управления транзакциями" и зарегистрировавшись в системе в качестве Поставщика услуг (Пункт "Меню", далее "Регистрация", далее "Поставщик услуг".) Параметры подключения к серверу поставщика услуг сообщаются поставщиком услуг при регистрации платежной формы, в том числе URL-адреса скриптов проверки возможности платежа, проведения платежа и запрос статуса платежа. (см. Регистрация платежных форм) Передача запроса осуществляется после поступления в платежную систему запроса на проведение платежа от плательщика. Прием платежей в терминалах моментальной оплаты работает в двух режимах: ON-LINE и OFF-LINE. ON-LINE режим позволяет провести предварительный запрос на возможность проведения платежа. В этом случае сначала следует запрос на возможность проведения платежа, а затем, в случае положительного ответа оператора - запрос на сам платеж. OFF-LINE режим не позволяет это сделать, так как он работает в режиме накопления, и лишь затем передает пакеты на сервер. Помимо этого, даже терминалы, работающие в режиме ON-LINE, в целях сокращения очередей у автомата, могут переключиться на работу с платежами без отправки предварительного запроса. Протокол "Delta Key SA-1" работает с терминалами моментальной оплаты и дилерскими точками как в режиме "С предварительным запросом". (Режим ON-LINE), так и в режиме "Без предварительного запроса", напрямую обеспечивая проведение платежа. (Режим OFF-LINE). Однако поставщик услуг при настройке протокола может запретить использование режима "OFF-LINE", если считает недопустимым его использование в случае приема платежей в свой адрес. При регистрации платежной формы необходимо в качестве протокола обмена данными указать "Дельта Кей SA-1". Передача запросов, получение ответовПлатежная система взаимодействует с поставщиком услуг по протоколу HTTP или HTTPS, передавая запросы, используя метод GET либо метод POST. Интерфейс поставщика услуг должен принимать запросы со следующих IP-адресов: 188.120.246.108 188.120.239.25 Обеспечение целостности данных запросов и ответовПротокол Delta Key SA-1 в качестве способа авторизации использует электронную подпись по алгоритму MD5 HMAC (RFC 2104). При необходимости Вы можете выбрать другой протокол с другим методом авторизации, например, Delta Key + OSMP использует авторизацию по электронному цифровому сертификату. Параметры запросовЗапрос на проверку возможности проведения платежаЗапрос системы содержит несколько обязательных параметров, а также дополнительные данные, указанные при регистрации платежной формы. Обязательные параметры перечислены в таблице 1. Таблица 1. Параметры запроса на возможность проведения платежа
Также в сообщении передаются дополнительные параметры, заданные при регистрации формы. Дополнительные параметры передаются в формате <Параметр=Значение , Параметр представляет собой код дополнительного параметра, а Значение указывается плательщиком при выполнении
платежа.Сигнатура сообщения вычисляется путем склейки значений обязательных и дополнительных параметров и вычисления хеша полученной строки методом hmac, который в качестве ключа использует секретный параметр, также заданный при регистрации платежной формы. Строка для вычисления секретного ключа получается путем склейки следующих параметров: command + transact + form + sum + дополнительные_параметры Если дополнительных полей несколько, то очень важно при вычислении сигнатуры соблюсти правильный порядок следования полей. Рассмотрим пример: На шлюз поступает следующий запрос: command=check&transact=18661485&form=5100&summ=1.00&2534=112&2510=testtrest&sign=3b33a7ef6b338a8fd7fd9c47fc845503 В форме транзакции 5100 определен следующий порядок следования полей: 1. Поле номер 2534 (логин пользователя) 2. Поле номер 2510 (контрольный код) Таким образом при использовании ключа wceO9d6Mb6FnNLCvuNxaClUCPYEvy9wLhikh сигнатура будет следующей:
3b33a7ef6b338a8fd7fd9c47fc845503 , так как подписывается строка check1866148551001.00112testtrest Однако, если порядок следования полей изменен, то может быть допущена следующая ошибка: подписываемая строка - check1866148551001.00testtrest112 , соответственно ее сигнатура - 1cd49d3d1523eae8afc0fa71e32476e6 .Ответ присылается в формате XML и должен быть следующего вида:
<?xml version="1.0" encoding="UTF-8"?>
Параметр transact_number должен содержать номер транзакции, посланной в запросе. Параметр result_code содержит код
результата проверки (см. таблицу 3). Параметр comment содержит комментарий, характеризующий текстовой строкой возможность
проведения платежа.Кодировка результирующей XML может быть UTF-8, windows-1251 или любой другой, при этом в заголовке документа должна быть верно указана кодировка. Запрос на проведение платежа.Запрос системы содержит несколько обязательных параметров, а также дополнительные данные, указанные при регистрации платежной формы. Обязательные параметры перечислены в таблице 2. Таблица 2. Параметры запроса на возможность проведения платежа
Также в сообщении передаются дополнительные параметры, заданные при регистрации формы. Дополнительные параметры передаются в формате <Параметр=Значение> , Параметр представляет собой код дополнительного параметра, а Значение
указывается плательщиком при выполнении платежа. Сигнатура сообщения вычисляется путем склейки значений обязательных и дополнительных параметров и вычисления хеша полученной строки методом hmac, который в качестве ключа использует секретный параметр, также заданный при регистрации платежной формы. Строка для вычисления секретного ключа получается путем склейки следующих параметров: command + transact + form + out_date + sum + дополнительные_параметры Ответ присылается в формате XML и должен быть следующего вида: <?xml version="1.0" encoding="UTF-8"?> <response> <transact>transact_number</transact> <summ>summ</summ> <result>result_code</result> <comment>comment</comment> </response> Параметр transact_number должен содержать номер транзакции, посланной в запросе. В случае, если по какой-либо причине поставщик услуг
получал ранее запрос с данным номером транзакции (т.е. платеж дублируется сервером), поставщику услуг надлежит повторить ответ, данный на
предыдущий запрос. Например, если поставщик услуг получает запрос с транзакцией 101, а такой платеж был уже успешно зачислен на счет абонента,
то поставщик услуг должен вернуть серверу успешный результат проведения платежа.Параметр summ содержит сумму платежа, также присланную в запросе на проводку, где разделитель целой и дробной части -
символ точки. Параметр result_code содержит код результата проверки (см. таблицу 3). Параметр comment содержит комментарий,
характеризующий текстовой строкой возможность проведения платежа.Кодировка результирующей XML может быть UTF-8, windows-1251 или любой другой, при этом в заголовке документа должна быть верно указана кодировка. Запрос на проверку статуса платежаЗапрос на проверку статуса платежа посылается в случае, если ответ на проведение платежа был некорректным, не был получен, либо ответ не подлежал корректной расшифровке. В этом случае посылается запрос на проверку статуса. В ответ на запрос о статусе присылается результат, с которым была обработана операция, т.е. если платеж успешно до этого прошел, то необходимо прислать 0 в поле результата, если прошел с ошибкой, то возвращается код ошибки. Если платеж не проходил, то в поле результата необходимо прислать 66, в этом случае система повторит запрос на платеж еще раз. Формат запроса на проверку статуса платежа и формат ответа на данный запрос в точности соответствует запросу на проведение платежа с единственным отличием в поле command. В случае запроса статуса этот параметр будет иметь значение "status" . Коды результатов ответаТаблица 3. Коды результатов
Успешным считается ответ 0. При результате 73 запрос будет повторен. При результате 66 будет заново выполнена команда проведения платежа. Обратите внимание, что результат 66 присылается только в ответ на команду проверки статуса платежа (в случае, если платеж не обнаружен в базе данных поставщика услуг). Электронная цифровая подписьЭлектронная цифровая подпись формируется путем склейки обязательных и дополнительных параметров запроса и хеширует их методом hmac с использованием секретной фразы, генерируемой при регистрации формы. Описание метода HMAC Пример вычисления подписи и полной реализации протокола на языке Perl см. ниже. Контрольный примерПредположим, поставщик услуг зарегистрировал платежную форму "Оплата связи". Системой данной платежной форме был присвоен номер 3993. В настройке уведомления были заданы следующие параметры: В качестве параметров были заполнены следующие: В данном случае дополнительными параметрами будут 18,36 и 35. В случае выбора метода POST запрос на проверку возможности проведения платежа может быть таким: <input type="hidden" name="command" value="check"> <input type="hidden" name="transact" value="999999999"> <input type="hidden" name="form" value="3993"> <input type="hidden" name="summ" value="100.00"> <input type="hidden" name="18" value="Андрей Иванов"> <input type="hidden" name="36" [email protected]> <input type="hidden" name="35" value="3356"> <input type="hidden" name="sign" value="f45ad15ed2bf7cb8250658098cab41e1"> Данный запрос будет отправлен на адрес http://test.ru/check.php Тот же запрос при выбранном методе GET будет выглядеть следующим образом: http://test.ru/check.php?command=check&transact=999999999&form=3993&summ=100.00&18=Андрей+Иванов[email protected] &35=3356&sign=f45ad15ed2bf7cb8250658098cab41e1 Ответ на данный запрос может быть таким: <?xml version="1.0" encoding="UTF-8"?> <response> <transact>999999999</transact> <result>0</result> <comment>Платеж может быть проведен</comment> </response> или <?xml version="1.0" encoding="UTF-8"?> <response> <transact>1234567</transact> <result>18</result> <comment>Прием платежа в адрес данного абонента запрещен</comment> </response> В первом случае оператор разрешает проведение платежа, во втором - нет. Запрос на проведение платежа для метода POST выглядит следующим образом: <input type="hidden" name="command" value="pay"> <input type="hidden" name="transact" value="999999999"> <input type="hidden" name="form" value="3993"> <input type="hidden" name="out_date" value="20070613110006"> <input type="hidden" name="summ" value="100.00"> <input type="hidden" name="18" value="Андрей Иванов"> <input type="hidden" name="36" [email protected]> <input type="hidden" name="35" value="3356"> <input type="hidden" name="sign" value="f45ad15ed2bf7cb8250658098cab41e1"> Данный запрос будет отправлен на адрес http://test.ru/pay.php Тот же запрос при выбранном методе GET будет выглядеть следующим образом: http://test.ru/check.php?command=pay&transact=999999999&form=3993&out_date=20070613110006&summ=100.00 &18=Андрей+Иванов[email protected]&35=3356&sign=f45ad15ed2bf7cb8250658098cab41e1
Ответ на данный запрос может быть таким: <?xml version="1.0" encoding="UTF-8"?> <response> <transact>999999999</transact> <sum>110.15</sum> <result>0</result> <comment>Платеж успешно проведен</comment> </response> или <?xml version="1.0" encoding="UTF-8"?> <response> <transact>1234567</transact> <sum>110.15</sum> <result>18</result> <comment>Прием платежа в адрес данного абонента запрещен</comment> </response> Запрос на статус платежа для метода POST выглядит следующим образом: <input type="hidden" name="command" value="status"> <input type="hidden" name="transact" value="999999999"> <input type="hidden" name="form" value="3993"> <input type="hidden" name="out_date" value="20070613110006"> <input type="hidden" name="summ" value="100.00"> <input type="hidden" name="18" value="Андрей Иванов"> <input type="hidden" name="36" [email protected]> <input type="hidden" name="35" value="3356"> <input type="hidden" name="sign" value="f45ad15ed2bf7cb8250658098cab41e1"> Данный запрос будет отправлен на адрес http://test.ru/status.php Тот же запрос при выбранном методе GET будет выглядеть следующим образом: http://test.ru/check.php?command=status&transact=999999999&form=3993&out_date=20070613110006&summ=100.00 &18=Андрей+Иванов[email protected]&35=3356&sign=f45ad15ed2bf7cb8250658098cab41e1
Ответ на данный запрос может быть таким: <?xml version="1.0" encoding="UTF-8"?> <response> <transact>999999999</transact> <sum>110.15</sum> <result>0</result> <comment>Платеж успешно проведен </response> или <?xml version="1.0" encoding="UTF-8"?> <response> <transact>1234567</transact> <sum>110.15</sum> <result>18</result> <comment>Прием платежа в адрес данного абонента запрещен</comment> </response> Пример реализации протокола на языке PerlРеализация протокола включает в себя следующие файлы, расположенные в одном каталоге: create_tables.sql - дамп базы данных MySQLdelta-key.conf - конфигурационный файлdelta-key.cgi - скрипт протоколаdelta-key.log - файл логовЛистинг 3-1. create_tables.sql
Листинг 3-2. delta-key.conf
Листинг 3-3. delta-key.cgi
|
© 2005-2013. «Delta Key» Все права защищены. |
Правовые нормы | Раскрытие информации | Контактная информация | Дизайн — Алексей Попов © 2023 |