Доверенность выдана без права передоверия сроком на 1 (один) год.

Генеральный директор

ООО «ДЕЛЬТА ТЕЛЕКОМ» Трейстер Е.А.

 

 

Приложение № 9

К Правилам приема платежей

Описание процедуры регистрации платежа

 

Порядок информационного обмена

 

1.1. Запросы от ПЦ Оператора по приему платежей передаются путем передачи данных на веб-сервер Поставщика по протоколу HTTPS (с использованием 128 разрядного шифрования), с использованием аутентификации клиента одним или несколькими выбранными способами (“Basic” аутентификация запроса с указанием логина и пароля Оператора по приему платежей, аутентификация по клиентскому сертификату, аутентификация по логину и паролю Оператора по приему платежей, переданными в строке GET запроса).

1.2. Веб-сервер Поставщика обеспечивает авторизацию запросов Оператора по приему платежей по сетевому адресу передающей стороны со стороны Оператора по приему платежей и данным аутентификации.

1.3. Запросы могут поступать параллельно, т. е. очередной запрос может быть направлен до получения ответа на предыдущий запрос. Длительность таймаута до получения ответа не превышает 30 секунд.

1.4. Веб-сервер Поставщика возвращает результат обработки запроса (ответ) Оператора по приему платежей, в виде XML-документа.

1.5. Запросы Оператора по приему платежей передаются с использованием метода передачи параметров запроса GET, с использованием, в случае необходимости, URL кодирования.

1.6. Запросы Оператора по приему платежей и ответы от веб-сервера Поставщика кодируются с использованием кодировки Windows-1251.

1.7. Все запросы Оператора по приему платежей производятся по одному адресу (URL) указанному Поставщиком.

1.8. Порядок произведения операции регистрации платежа Оператором по приему платежей следующий:

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

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

1.9. Поставщик гарантирует, что при получении положительного ответа на запрос на проверку возможности регистрации платежа, запрос на регистрацию платежа будет выполнен успешно, в любом случае.

1.10. Ежедневный итоговый реестр:

1.10.1. Оператор по приему платежей ежедневно, в установленное по согласованию с Поставщиком время, передает Поставщику итоговый реестр принятых платежей за прошедшие полные сутки (с 00:00:00 часов до 00:00:00 часов следующего дня). Поставщик при получении от Оператора по приему платежей итогового реестра формирует список платежей на эту же дату и производит сравнение с итоговым реестром Оператора по приему платежей.

1.10.2. В случае обнаружения Поставщиком расхождений с итоговым реестром Оператора по приему платежей, Поставщик связывается с представителями Оператора по приему платежей для выяснения причин расхождений и их устранения.

 

 

Форматы запросов и ответов веб-сервера Поставщика

 

2.1. Запросы должны содержать только те параметры, которые являются необходимыми и достаточными для конкретного типа запроса.

2.2. Используемые в запросах параметры:

 

Название	Назначение	Тип	Размер	Комментарии
LOGIN	Логин Оператора по приему платежей	Строка	Не более 20
PASS	Пароль Оператора по приему платежей	Строка	Не более 20
TYPE	Тип запроса	Число		Допустимые значения: 1 – запрос на проверку возможности регистрации платежа; 2 - запрос на регистрацию платежа.
CODE1	Идентификатор 1 получателя платежа	Строка	Не более 255
CODE2	Идентификатор 2 получателя платежа	Строка	Не более 255
CODE3	Идентификатор 3 получателя платежа	Строка	Не более 255
AMOUNT	Сумма платежа в копейках	Число	Не более 9
PAYTYPE	Тип или назначение платежа	Число	Не более 3
PAYID	Номер платежа в системе Оператора по приему платежей	Число	Не более 20
DATE	Дата платежа в системе Оператора по приему платежей	Строка		В формате: YYYYMMDDHHMMSS

 

2.3. Используемые поля в ответах:

 

Название	Назначение	Тип	Размер	Комментарии
RESULTCODE	Код результата выполнения запроса	Не отрицательное число	Не более 4	0 - считается положительным результатом выполнения запроса, все остальные значения - кодом ошибки
RESULTMESSAGE	Описание результата выполнения запроса	Строка	Не более 255
DATE	Дата и время выполнения запроса на стороне Поставщика	Строка		В формате: YYYYMMDDHHMMSS
PAYID	Номер платежа в системе Поставщика	Число	Не более 20
ADDINFO	Дополнительная информация передаваемая Поставщиком Оператору по приему платежей в рамках платежа	Строка	Не более 255	Может, к примеру, содержать ФИО получателя платежа, задолженность получателя платежа, и т.п.

 

 

2.4. Проверка возможности регистрации платежа

2.4.1. Запрос

 

https://<serviceUrl>?[ LOGIN = value & PASS = value &] TYPE =1&[ PAYTYPE = value&]CODE1 = value [& CODE2 = value [& CODE3 = value ]]& AMOUNT = value

 

2.4.2. Ответ

 

<?xml version="1.0" encoding="windows-1251"?> <RESPONSE> < RESULTCODE > value </ RESULTCODE > < RESULTMESSAGE > value </ RESULTMESSAGE > < DATE > value </ DATE > < ADDINFO > value </ ADDINFO ></RESPONSE>

 

2.5. Регистрация платежа

2.5.1. Запрос

 

https://<serviceUrl>?[ LOGIN = value & PASS = value &] TYPE =2&[ PAYTYPE = value&]CODE1 = value [& CODE2 = value [& CODE3 = value ]]& AMOUNT = value & PAYID = value & DATE = value

 

2.5.2. Ответ

 

Положительный:

 

<?xml version="1.0" encoding="windows-1251"?> <RESPONSE> < RESULTCODE > 0 </ RESULTCODE > < RESULTMESSAGE > value </ RESULTMESSAGE > < DATE > value </ DATE > < PAYID > value </ PAYID ></RESPONSE>

 

Отрицательный:

 

<?xml version="1.0" encoding="windows-1251"?> <RESPONSE> < RESULTCODE > value </ RESULTCODE > < RESULTMESSAGE > value </ RESULTMESSAGE > < DATE > value </ DATE > </RESPONSE>

Требования к итоговому реестру принятых платежей

 

3.1. Итоговый реестр принятых платежей – текстовый файл, содержащий список платежей, зарегистрированных Поставщиком, по запросам Оператора по приему платежей, за отчетную дату.

3.2. В итоговом реестре должны содержаться все успешно зарегистрированные платежи за один календарный день в период времени с 00:00:00 часов по 00:00:00 часов следующего дня часов.

3.3. Файлы с итоговыми реестрами принятых платежей опционально защищаются (шифруются и/или подписываются) посредством PGP и передаются по электронной почте Поставщику.

3.4. Имя файла должно содержать дату и название Оператора по приему платежей в формате <YYYYMMDD><PaySystemName>.pgp

3.5. Файл содержит данные в кодировке Windows-1251.

3.6. Файл состоит из строк, разделенных символами “перевод строки”, “возврат каретки”.

3.7. Все строки в файле содержат одинаковое количество полей разделенных между собой символом “точка с запятой”.

3.8. Строка имеет следующую структуру:

 

[PAYTYPE;]CODE1[CODE2;[CODE3;]];AMOUNT;PAYIDA;PAYIDOP;DATE

 

,где:

PAYTYPE - тип или назначение платежа;

CODE1 - идентификатор 1 получателя платежа;

CODE2 - идентификатор 2 получателя платежа;

CODE3 - идентификатор 3 получателя платежа;

AMOUNT – сумма платежа в копейках;

PAYIDA – номер платежа в системе Оператора по приему платежей;

PAYIDOP – номер платежа в системе Поставщика;

DATE – дата платежа в системе Оператора по приему платежей;