для кредитных организаций

г. Екатеринбург
СОГЛАШЕНИЕ
об информационно-технологическом взаимодействии
№ ИТВ-02.13 (ХХ)
« __ »________ 2013 года
ООО «ЕРЦ – Финансовая логистика», именуемое в дальнейшем «Клиент», в лице директора Зайкова
Алексея
Юрьевича,
действующего
на
основании
Устава,
с
одной
стороны,
и
_________________________________________, именуемое в дальнейшем «Банк», в лице
___________________________, действующего на основании __________________________________, с
другой стороны, далее именуемые «Стороны», заключили настоящее соглашение (далее Соглашение»)
о нижеследующем:
1. Термины и определения
1.1. Плательщик – физическое лицо, по поручению которого Банк осуществляет перевод
денежных средств в пользу Клиента.
1.2. Система «ФРИСБИ» - автоматизированная система Клиента, обеспечивающая
информационно-технологическое взаимодействие между Клиентом и Банком.
1.3. Вознаграждение - сумма, выплачиваемая Клиентом Банку за информационнотехнологическое взаимодействие в порядке и сроки, предусмотренные настоящим Соглашением.
1.4. Перевод денежных средств (перевод) - действия Банка в рамках применяемых форм
безналичных расчетов по предоставлению получателю средств денежных средств плательщика.
1.5. Обеспечительный взнос (далее «Обеспечение») – средство обеспечения Банком своих
обязательств по Соглашению. Сумма Обеспечения учитывается на текущем счете Банка в Системе
«ФРИСБИ».
1.6. Текущий счет Банка – аналитический счет в Системе «ФРИСБИ», на котором учитывается
списание и пополнение денежных средств Банка.
2. Предмет Соглашения
2.1. Банк осуществляет информационно-технологическое взаимодействие между Плательщиком
и Клиентом в отношении принятых от Плательщиков переводов денежных средств в пользу Клиента за
услуги, предоставляемые организациями, указанными в Приложении № 1 Соглашения.
2.2. Клиент выплачивает Банку Вознаграждение за информационно-технологическое
взаимодействие.
3. Права и обязанности Сторон
3.1. Банк обязан:
3.1.1. В момент осуществления перевода по распоряжению Плательщика передавать данные о
совершенной операции в Систему «ФРИСБИ» с использованием собственных каналов передачи
информации.
3.1.2. В течение 3 (Трех) рабочих дней с момента подписания Соглашения внести на расчетный
счет Клиента, указанный в п. 13.1. Соглашения, Обеспечение, необходимое для исполнения своих
обязательств по Соглашению. Размер Обеспечения указан в Приложении № 2 Соглашения.
3.1.3. Обеспечить прием от Плательщика информации о наименовании организации,
наименовании товара (работы, услуги), за который (которые) исполняются денежные обязательства
физического лица перед организацией, о размере вносимых Банку денежных средств, а также иной
информации.
3.1.4. Письменно направлять Клиенту предложения о включении в Систему «ФРИСБИ» новых
мест приема переводов. Клиент должен направить в адрес Банка письменное согласие, либо отказ по
данному предложению.
3.1.5. В течение 3 (Трех) рабочих дней до фактического момента передислокации места приема
переводов уведомлять Клиента об изменении его местонахождения.
3.1.6. Не вступать в какие-либо договорные отношения с третьими лицами по организации приема
переводов от физических лиц в пользу Клиента без письменного согласования с Клиентом.
3.2. Банк имеет право:
3.2.1. Взимать с Плательщика дополнительную плату за совершение действий, связанных с
осуществлением перевода, в соответствии с Приложением №1 Соглашения. Дополнительная плата
полностью поступает в распоряжение Банка и не включается в расчеты для выплаты Вознаграждения
за информационно-технологическое взаимодействие, при этом Банк самостоятельно несет
ответственность за неуплату всех налогов и сборов с суммы вознаграждения, поступившей в
распоряжение Банка.
3.2.2. По согласованию с Клиентом оформить места приема переводов рекламноинформационными материалами.
3.2.3. Осуществлять перечисление денежных средств, полученных за календарный день в виде
переводов от Плательщиков, на следующий рабочий день единым платежным поручением по
реквизитам Клиента, указанных в п. 13.1. Соглашения.
3.3. Клиент обязан:
3.3.1. Отказать Банку в обработке предоставленной информации в случае возникновения
технических неполадок у Клиента.
3.3.2. Выплачивать Банку Вознаграждение, в соответствии с п. 5.1. Соглашения.
3.3.3. Предпринимать все возможные и необходимые действия в рамках своей компетенции,
включая регулярную проверку качества работы Системы «ФРИСБИ» для того, чтобы обеспечить
нормальное предоставление Банку возможности информационного обмена с Клиентом, кроме времени,
затрачиваемого на профилактические и ремонтные работы.
3.4. Клиент имеет право:
3.4.1. Проверять в любое время ход исполнения Банком обязательств, связанных с исполнением
Соглашения, не вмешиваясь в его хозяйственную деятельность.
3.4.2. Вносить изменения в условия Соглашения, направляя Банку соответствующие предложения
не менее чем за 4 (четыре) рабочих дня до момента изменения условий. Банк обязуется в течение 3
(трех) рабочих дней с момента получения соответствующего предложения либо принять изменение
условий, либо предоставить Клиенту письменный отказ. В случае не предоставления ответа об отказе
принять предложение, предложение об изменении условий Соглашения считается акцептованным
Банком. В случае несогласия Банка с изменениями - Клиент имеет право расторгнуть Соглашение в
течение 5 (пяти) рабочих дней с момента получения несогласия Банка, уведомив об этом последнего в
письменной форме.
3.4.3. В случае неисполнения (ненадлежащего исполнения) Банком какого-либо из обязательств,
предусмотренного
Соглашением,
Клиент
вправе
без
предварительного
уведомления
отключить/блокировать информационно-технологическое взаимодействие с Банком в Системе
«ФРИСБИ» и в письменной форме потребовать немедленного устранения нарушений, а также
возмещения убытков. В случае если требования об устранении нарушения не были выполнены Банком
в течение 3 (Трех) календарных дней, Клиент вправе отказаться от исполнения Соглашения в
одностороннем порядке.
4. Порядок расчетов
4.1. После заключения Соглашения и регистрации в Системе «ФРИСБИ» Банк вносит
Обеспечение на расчетный счет Клиента, указанный в п. 13.1. Соглашения, при этом Банк согласен с
тем, что:
 передача информации с Точек перевода денежных средств Банка в Системе «ФРИСБИ»
становится возможной только после поступления Обеспечения на расчетный счет Клиента, указанный
в п. 13.1. Соглашения.
 расчет суммы Обеспечения устанавливается по согласованию сторон в соответствии с
Приложением № 2 Соглашения.
 на сумму денежных средств Обеспечения никакие проценты не начисляются и не
выплачиваются.
Сумма Обеспечения может быть самостоятельно увеличена Банком путем перечисления
соответствующей суммы на расчетный счет Клиента, указанный в п. 13.1. Соглашения, с указанием в
реквизитах платежа «Сумма Обеспечения по Соглашению № ИТВ-02.13 (ХХ) от « » _________ 2013
года, НДС не облагается».
Информация о пополнении Обеспечения Банком становится доступной Банку в 09:30; 12:00;
15:00; 17:00 местного времени.
Пополнение счета Банка в Системе «ФРИСБИ» производится после фактического получения
средств Клиентом.
Обработка информации (переводов денежных средств) в Системе «ФРИСБИ» осуществляется
в рамках календарной даты переведенных денежных средств, включая выходные и праздничные дни (с
00:00 часов до 24:00 часов текущей даты).
4.2. В течение 5 (Пяти) рабочих дней по окончании каждого календарного месяца Стороны
производят окончательную сверку проведенных операций. По результатам данной сверки Банк
направляет в адрес Клиента Акт выполненных работ, подписанный последним числом отчетного
календарного месяца (Приложение № 3). Акт выполненных работ передается уполномоченному лицу
Клиента не позднее 10 (Десятого) числа месяца, следующего за отчетным по адресу: г. Екатеринбург,
ул. Репина, 103. Надлежащим фактом предоставления Банком указанных документов в срок является
направление данной документации заказным письмом с уведомлением либо курьером с отметкой о
вручении Клиенту.
4.3. В случае если данные, включенные Банком в Акт выполненных работ, не совпадают с
данными Клиента, то последний формирует и направляет в Банк не позднее 5 (Пяти) рабочих дней со
дня его представления протокол разногласий, в котором указываются данные, с которыми не согласен
Клиент.
4.4. Банк в срок не позднее 5 (Пяти) рабочих дней со дня получения от Клиента протокола
разногласий либо подписывает его, либо предоставляет Клиенту полный и мотивированный ответ по
имеющимся расхождениям. В случае невозможности определить причину расхождений по переданной
информации, эталонными считаются данные, принятые и обработанные Клиентом за отчетный месяц.
5. Вознаграждение
5.1. За оказанные услуги Клиент уплачивает Банку Вознаграждение в размере и порядке,
предусмотренные в Приложении № 1 Соглашения.
5.2. Сумма Вознаграждения исчисляется в процентах от сумм переведенных по распоряжению
Плательщика Клиенту денежных средств за отчетный период и включает в себя НДС – 18%. Отчетным
периодом является календарный месяц. В случае изменения установленной действующим
законодательством ставки НДС, ставка вознаграждения изменяется соразмерно без дополнительного
согласования Сторонами. В случае если Банк не является плательщиком НДС – начисленная сумма
вознаграждения уменьшается на сумму НДС.
5.3. Вознаграждение Банка за оказанные услуги начисляется Клиентом ежемесячно. Расчет
осуществляется по итогам каждого месяца в течение 10 рабочих дней после подписания Сторонами
Акта выполненных работ.
5.4. Размер Вознаграждения Банка может быть изменен Клиентом в одностороннем порядке,
исходя из объема данных, принятых и переданных Банком за предыдущий месяц, а также иных
факторов. Клиент вправе направить на адрес электронной почты ___________________ ответственного
сотрудника Банка информацию об изменении Вознаграждения, с последующим направлением для
подписания дополнительного соглашения. Изменение размера Вознаграждения Банка наступает с
даты, указанной в письме, отправленном Клиентом. При смене ответственного сотрудника по
дополнительному соглашению со стороны Банка, последний обязуется письменно уведомить Клиента.
6. Регистрация Банка в Системе «ФРИСБИ»
6.1. Банк передает Клиенту заявку на регистрацию в Системе «ФРИСБИ» в соответствии с
Приложением № 4 Соглашения.
6.2. Клиент в течение 5 (Пяти) рабочих дней с момента получения заявки предоставляет Банку
возможность доступа к Системе «ФРИСБИ» для организации информационно-технологического
взаимодействия в соответствии с Приложением № 5 Соглашения.
6.3. При возникновении необходимости блокирования/отключения в Системе «ФРИСБИ» самого
Банка или мест приема переводов, Банк передает Клиенту заявку на блокирование.
7. Прочие условия
7.1. Клиент не несет ответственности по спорам и разногласиям, возникшим между Банком и
Плательщиками, в отношении передачи Банком некорректной информации или оформления
некорректного перевода в адрес Клиента, а также во всех случаях, когда подобные споры и
разногласия не относятся к предмету Соглашения.
7.2. Клиент не несет ответственности за прямые или косвенные убытки Банка, в том числе
упущенную выгоду, понесенную сторонами по вине Клиента, включая временное снижение качества
связи и (или) отказ оборудования сети.
7.3. Банк несет ответственность за передаваемую Клиенту информацию в рамках Соглашения.
8. Возврат Обеспечения
8.1. По Соглашению возможен полный или частичный возврат Обеспечения как в связи с
расторжением Соглашения, так и без расторжения Соглашения.
8.2. Возврат Обеспечения по Соглашению осуществляется в течение 10 (Десяти) рабочих дней с
момента получения заявления от Банка, или с момента расторжения Соглашения, в соответствии с
реквизитами, указанными в п. 13.2. Соглашения.
8.3. Если Обеспечения на счете Банка недостаточно для покрытия издержек, связанных с
перечислением средств, и финансовых обязательств Банка по Соглашению, Клиент отказывает Банку в
проведении операции по возврату Обеспечения.
9. Форс-мажорные обстоятельства
9.1. Сторона освобождается от ответственности за частичное или полное
неисполнение обязательств по Соглашению, если это неисполнение явилось следствием обстоятельств
непреодолимой силы, возникших после заключения Соглашения в результате обстоятельств
чрезвычайного характера, которые Сторона не могла ни предвидеть, ни предотвратить разумными
мерами. К таким обстоятельствам относятся: телекоммуникационные сбои всеобщего характера,
наводнение, пожар, землетрясение и иные явления природы, а также война, военные действия, акты
или действия государственных органов и др.
9.2. При наступлении указанных в п. 9.1. Соглашения обстоятельств Сторона,
исполнению обязательств которой они препятствуют, должна не позднее 3 (Трех) рабочих дней
известить о них в письменном виде другую Сторону. Извещение должно содержать данные о
характере обстоятельств, что должно быть подтверждено компетентной государственной или иной
организацией, а также, по возможности, оценку их влияния на возможность исполнения Стороной
обязательств по Соглашению и срок исполнения обязательств.
9.3. В случае если обстоятельства, указанные в п. 9.1. Соглашения,
продлятся более 30 (Тридцати) календарных дней, Клиент имеет право расторгнуть Соглашение в
одностороннем внесудебном порядке, при этом Стороны должны провести взаиморасчеты по
возникшим при исполнении Соглашения финансовым обязательствам.
10.
Конфиденциальность
10.1. Стороны заверяют, что обладают законными полномочиями заключить
настоящее Соглашение; лица, подписавшие настоящее Соглашение, имели все права совершить
указанные действия.
10.2. Стороны принимают на себя обязательства не разглашать полученные в ходе исполнения
Соглашения сведения, являющиеся конфиденциальными для каждой из Сторон. Под
конфиденциальной информацией в Соглашении понимаются не являющиеся общедоступными
сведения, разглашение которых может привести к возникновению убытков и/или повлиять на деловую
репутацию любой из Сторон, в том числе:
- информация о Плательщиках, переводах, остатках на счетах, объемах операций;
- информация о выплачиваемом вознаграждении.
10.3. Стороны обязуются не разглашать информацию, указанную в п. 10.2.
Соглашения третьим лицам, за исключением согласованного предоставления конфиденциальной
информации третьим лицам в целях исполнения Соглашения и иных соглашений между Клиентом и
Банком.
10.4. Информация, указанная в п. 10.2. Соглашения, может быть выдана только в порядке,
установленном законодательством Российской Федерации.
10.5. В случае прекращения действия Соглашения, Стороны обязуются также не разглашать
и не использовать в своих интересах и/или интересах третьих лиц информацию, указанную в п. 10.2
Соглашения в течение 2 (двух) лет с момента расторжения Соглашения.
10.6. Клиент не несет ответственности в случае несанкционированного доступа к
информации о текущем счете Банка в Системе «ФРИСБИ» со стороны третьих лиц, возникшего по
вине Банка.
11. Вступление в силу, срок действия и порядок расторжения Соглашения
11.1. Соглашение считается заключенным с момента его подписания Сторонами и действует
до 31 декабря 2013 года (включительно).
11.2. Соглашение считается пролонгированным на каждый последующий год, если не менее
чем за 30 (Тридцать) дней до окончания срока действия Соглашения ни одна из Сторон письменно не
уведомила другую Сторону о своем желании прекратить действие Соглашения.
11.3. Стороны выполняют свои обязательства в полном объеме до момента прекращения
действия Соглашения.
11.4. Стороны имеют право в одностороннем внесудебном порядке расторгнуть Соглашение,
письменно уведомив об этом другую Сторону за 30 (тридцать) дней до предполагаемой даты
расторжения соглашения, произведя при этом все взаиморасчеты по возникшим при исполнении
Соглашения финансовым обязательствам.
11.5. Стороны имеют право расторгнуть Соглашение в одностороннем порядке и по другим
основаниям, предусмотренным настоящим Соглашением.
11.6. С даты расторжения данного Соглашения прекращаются полномочия Банка по
использованию Системы «ФРИСБИ».
11.7. Денежные обязательства Сторон, а также обязательства, определяющие
ответственность Сторон за нарушение Соглашение, сохраняются до момента их полного исполнения и
не зависят от окончания срока действия Соглашения.
11.8. Соглашение составлено в двух экземплярах, по одному для каждой из Сторон. Оба
экземпляра идентичны и имеют равную юридическую силу.
12. Приложения
12.1. К Соглашению прилагаются следующие Приложения, которые являются неотъемлемой
частью Соглашения:
12.1.1. Приложение №1 «Тарифы вознаграждения, выплачиваемые Клиентом Банку, и условия
передачи извещений Клиенту»;
12.1.2. Приложение №2 «Размер Обеспечения»;
12.1.3. Приложение №3 «Акт выполненных работ»;
12.1.4. Приложение №4 «Форма заявки на регистрацию Банка в Системе «ФРИСБИ»;
12.1.5. Приложение №5 «Протокол обмена данными».
Приложение №1
к Соглашению об информационно-технологическом взаимодействии
№ ИТВ-02.13 (ХХ) от «___» ____________ 2013 года
Тарифы вознаграждения, выплачиваемые Клиентом Банку, и условия передачи извещений
Клиенту
№
п/п
Наименование организации
Взимание
дополнительного
вознаграждения,
уплачиваемого
Плательщиком
Банку
Вознаграждение
Банка, без НДС, %
Прочие условия
ЖКУ, в том числе г. Екатеринбург
Электроэнергия, в том числе:
Телефонная связь, в том числе:
Мобильная связь, в том числе:
Кабельное телевидение, в том
числе:
Интернет, в том числе:
Прочие организации, в том числе:
Клиент
Банк
_________________/Зайков А.Ю./
_____________/
М.П.
М.П.
/
Приложение №2
к Соглашению об информационно-технологическом взаимодействии
№ ИТВ-02.13 (ХХ) от «___» ____________ 2013 года
Размер Обеспечения
Размер Обеспечения Банка на момент подписания Соглашения составляет 100 000 (Сто тысяч) рублей
(НДС не предусмотрен).
Клиент
Банк
_______________/А.Ю. Зайков/
____________/_____________/
М.П.
М.П.
Приложение № 3
к Соглашению об информационно-технологическом взаимодействии
№ ИТВ-02.13 (ХХ) от «___» ____________ 2013 года
Акт выполненных работ
г.Екатеринбург
«____»____________2013 года
ООО «ЕРЦ – Финансовая логистика», именуемое в дальнейшем «Клиент», в лице директора Зайкова
Алексея
Юрьевича,
действующего
на
основании
Устава,
с
одной
стороны,
и
_________________________________________, именуемое в дальнейшем «Банк», в лице
_________________________________________,
действующего
на
основании
_______________________________________, с другой стороны, далее именуемые «Стороны»,
составили настоящий акт о нижеследующем: согласно Соглашения об информационнотехнологическом взаимодействии №________ от «____» _________ 2013 года, за период с «____»
__________ 2013 года по «____» ___________2013 года сумма Вознаграждения Банка составила:
№
п/п
Наименование
организации
Информация о суммах
переведенных по поручению
Плательщика Клиенту денежных
средств
Вознаграждение
Банка
%
руб.
1
2
Итого:
Итого
к
оплате:
________________________________________(в
________________________________________________________________
т.ч.
НДС/без
НДС)
Претензий к качеству оказанных услуг нет.
Настоящий Акт выполненных работ составлен в двух экземплярах, имеющих одинаковую
юридическую силу, по одному для каждой стороны.
Клиент
Банк
_________________/Зайков А.Ю./
_____________/
М.П.
М.П.
/
Приложение № 4
к Соглашению об информационно-технологическом взаимодействии
№ ИТВ-02.13 (ХХ) от «___» ____________ 2013 года
Форма заявки на регистрацию Банка в Системе «ФРИСБИ»
г. Екатеринбург
«____»_____________2013 года
Для регистрации в Системе «ФРИСБИ» Банку необходимо предоставить следующую информацию:
1.
2.
3.
4.
5.
№ п/п
Наименование Организации;
Дата и номер Соглашения;
Контактное лицо – Ф.И.О., номер мобильного телефона, электронная почта;
Номер мобильного телефона для SMS-уведомлений;
Сведения о месте приема переводов:
Наименование
торгового объекта
Адрес места приема
переводов
Технические характеристики места приема
переводов*
1.
2.
*Необходимо указать:
1.
2.
3.
4.
5.
6.
Персональный Компьютер (объем ОЗУ и ЖД, частота работы процессора);
Способ подключения к сети Интернет;
Фискальный регистратор – марка, версия, интерфейс;
Купюроприемник – марка, протокол, интерфейс;
Сканер штрихкода – марка, интерфейс;
Картридер – марка, интерфейс.
Прошу осуществить регистрацию места (мест) приема переводов в Системе «ФРИСБИ».
Банк
__________/
М.П.
/
Приложение № 5
к Соглашению об информационно-технологическом взаимодействии
№ ИТВ-02.13 (ХХ) от «___» ____________ 2013 года
Протокол обмена данными
eKassir v3 Protocol Версия: 3.0.1
Общее описание
Протокол eKassirV3 предназначен для приема платежей с терминалов, точек с кассиром, других точек
приема платежей.
Особенности:
1. В качестве транспортного протокола используется HTTP/HTTPS.
2. Запросы и ответы представляют собой xml-сообщения, формируемые на основе xsd-схем.
3. Протокол не использует пакетный режим. Один запрос – одна операция. В ответе приходит
результат выполнения операции.
4. В протоколе используется аутентификация точки по паролю или по ЭЦП (см следующий раздел).
Транспортный уровень
Общие сведения
Все запросы передаются по протоколу http (версия 1.1, RFC 2616) методом POST. В случае
использования другого метода возвращается ошибка 405 (Methodnotallowed). Сообщение протокола
eKassirV3 передается в теле запроса. В запросе должен быть заголовок eKassir-Version, значение
которого всегда 3 (три) – номер версии протокола.
В протоколе eKassir используются следующие способы аутентификации:
1. ЭЦП и идентификатор точки в заголовке http,
2. По идентификатору точки и паролю.
В случае, если не прошла аутентификация, возвращается ошибка 401 (Unauthorized), а в теле ответа
текстовое описание ошибки.
Протокол eKassirV3 не поддерживает разделенные (chunked) данные. В случае получения запроса с
разделенными данными или с длиной запроса 0 байт возвращаетсяошибка415 (Unsupportedmediatype).
При обработке запроса может возникнуть внутренняя ошибка сервера. В этом случае
возвращаетсяошибка500 (Internalservererror), а в теле ответа содержится информация об ошибке
сервера. По протоколу eKassirV3 длина запроса на сервер ограничена. По умолчанию ограничение —
10000 байт. Это значение может быть изменено администратором eKassir. В случае превышения
ограничения возвращаетсяошибка413 (Requestentitytoolarge).
Кодировка
Сообщения протокола могут быть переданы на сервер в любой кодировке на усмотрение разработчика.
Название кодировки, в которой представлено сообщение, передается в заголовке Content-Type. Также в
этом заголовке передается media-type, который по протоколу eKassir должен быть text/xml.
Например, значение заголовка для кодировки utf-8 будет таким:
text/xml; charset=utf-8
В случае отсутствия кодировки в запросе или неверного названия кодировки (например, utg-8 вместо
utf-8) будет использоваться кодировка по умолчанию. Необходимо уточнить ее у администратора
сервера.
Ответ сервера передается в кодировке запроса.
Аутентификация по идентификатору точки и ЭЦП
Для аутентификации этим способом на сервер в каждом запросе должны быть переданы
идентификатор точки в eKassir и подпись передаваемого сообщения. Также может передаваться тип
хеш-функции, которая используется для вычисления подписи сообщения. Идентификатор, подпись и
тип хеш-функции передаются в следующих заголовках http:
eKassir-PointID
eKassirSignature
eKassirHashType
Идентификатор точки в eKassir. Целое положительное число. Выдается клиенту при
подключении к системе.
Подпись сообщения по алгоритму RSA.
Использованная при вычислении подписи хеш-функция:
- MD5
- SHA1
Заголовок необязательный. По умолчанию MD5.
Подпись формируется по следующему алгоритму:
1. Вычисляется хеш MD5 (или SHA1) сообщения
2. Полученный хеш подписывается секретным ключом RSA
3. Результат обрабатывается по алгоритму Base64
Подпись вычисляется перед сжатием сообщения.
Для разработчиков, использующих php или другой язык, не имеющий строгой типизации
данных:
Хеш вычисляется после того, как сформированная строка сообщения преобразована в массив
байт в выбранной кодировке.
Аутентификация по идентификатору точки и паролю
Для аутентификации этим способом на сервер eKassir в каждом запросе должны быть переданы
идентификатор точки в eKassir и MD5 хеш пароля.
Идентификатор точки и хеш передаются в следующих заголовках http:
Идентификатор точки в eKassir
eKassir-PointID
eKassir-Password MD5 хеш пароля
Хеш пароля вычисляется следующим образом:
1. Строка с паролем конвертируется в массив байт в кодировке utf-8
2. Из полученного массива вычисляется хеш MD5
3. Полученный хеш обрабатывается по алгоритму Base64
Сжатие запросов и ответов
Перед отправкой сообщения по сети клиент может сжать данные по алгоритму gzip или deflate. Сжатие
делается после формирования ЭЦП. Для того чтобы сообщить серверу о методе сжатия запроса,
необходимо добавить заголовок Content-Encoding в http-запрос со значением gzip или deflate
соответственно. Если серверу не удается произвести декомпрессию принятых данных или указано
неверное значение заголовка Content-Encoding, сервер ответит ошибкой 415 (Unsupportedmediatype).
Для уменьшения трафика клиент также может управлять сжатием ответов сервера. Для этого
используется заголовок Accept-Encoding. В заголовке указывается способ сжатия ответа сервера gzip
или deflate (может использоваться перечисление через ','(запятую), тогда сервер сам выберет способ
сжатия). Если в запросе указан способ, который не поддерживается, сервер отвечает ошибкой 406
(Notacceptable). В заголовке ответа Content-Encoding сервер указывает способ, которым сжат ответ.
Управление временем обработки запроса
Клиентское приложение может сообщать Серверу, какое время отводится на ожидание ответа. Это
позволяет Серверу не тратить больше времени на обработку, чем это необходимо, а клиентское
приложение может получать информацию о том, что Сервер запрос не обрабатывал вообще. Для этого
используется заголовок http-запроса eKassir-ExpectedTimeout. Его значение – таймаут в
миллисекундах, который дается на обработку запроса. Рекомендуется устанавливать его равным
половине времени ожидания ответа сервера в запросе. Например, таймаут запроса по сети 30 секунд,
тогда значение заголовка 30 * 1000 / 2 = 15000 миллисекунд. В случае, если сервер не начал
обрабатывать запрос, то клиент получит ошибку 503 (Service Unavailable).
Справочник ошибок транспортного уровня
В таблице ниже приведен полный перечень ошибок транспортного уровня.
Код Название
Описание
401
Unauthorized
Ошибка аутентификации. Текст с описанием ошибки передается в теле
ответа. При разработке необходимо убедиться в том, что все заголовки
переданы корректно, что использованы правильные ключи (или пароль).
После передачи в эксплуатацию этот код ответа означает, что
пользователи указали аутентификационные данные в настройках
клиентской части.
405
Methodnotallowed
Разработчик использовал неверный метод запроса. По протоколу eKassir
должен использовать метод POST.
406
Not acceptable
413
Request entity too
large
В заголовке Accept-Encoding запроса передан способ сжатия, который не
поддерживается сервером.
Длина запроса превышает максимально разрешенную. Обратитесь к
администратору сервера, чтобы увеличить максимальную длину запроса.
415
Unsupportedmediatype
Данная ошибка может возникнуть по следующим причинам:
1. Запрос нулевой длины,
2. Запрос с разделенными данными (chunked). По протоколу такие
запросы не поддерживаются.
3. В запросе передано неверное значение заголовка Content-Encoding.
500
Internal server error
Произошла внутренняя ошибка сервера. В теле ответа передаются
данные об ошибке, которые следует передать разработчикам серверной
части. При получении этой ошибки следует повторить запрос через 5
минут.
503
Service unavailable
Ошибка может возникнуть в случае, если сервер перегружен. Эта
ошибка означает, что сервер вообще не обработал запрос.
Сценарии взаимодействия
В этом разделе описаны сценарии приема платежа с участием плательщика. При описании
взаимодействия используются следующие термины:
Плательщик лицо, осуществляющее платеж
Приложение, обеспечивающее взаимодействие с Плательщиком
Клиент
Сервер
Серверное приложение, обслуживающее запросы Клиента
Основной сценарий при приеме платежа
1. Плательщик выбирает услугу.
2. Клиент предлагает плательщику заполнить параметры платежа.
3. Плательщик заполняет параметры платежа.
4. Клиент подтверждает, что параметры платежа корректны, и отправляет заявку проверки параметров
платежа на Сервер.
5. Сервер ставит заявку в очередь и отвечает, через какое время заявка будет обработана.
6. Клиент ждет отведенное время и отправляет запрос результатов проверки номера на Сервер.
7. Сервер подтверждает, что параметры платежа корректны.
8. Клиент предлагает Плательщику оплатить услугу.
9. Плательщик оплачивает услугу.
10. Клиент отправляет платеж на сервер.
11. Сервер принимает платеж и ставит его в очередь обработки.
Расширения:
4а. Параметры платежа некорректны: 4а1. Клиент предлагает Плательщику исправить некорректные
данные.
4б. Услуга не поддерживает проверку параметров платежа: 4б1. Клиент переходит к шагу 8.
4в.6а. Не удалось отправить запрос проверки на Сервер (или запрос получения результатов проверки),
а проверка параметров платежа по услуге обязательна: 4в1, 6а1. Клиент сообщает плательщику, что
проверка параметров платежа временно недоступна, предлагает попробовать позднее.
4г. 6б. Не удалось отправить запрос проверки на Сервер (или запрос получения результатов проверки),
а проверка параметров платежа по услуге возможна, но необязательна: 4г1. 6б1. Клиент сообщает
плательщику, что проверка параметров платежа временно невозможна и переходит к шагу 8.
7а. Сервер сообщает, что параметры платежа некорректны: 7а1. Клиент сообщает плательщику, что
параметры платежа некорректны и предлагает исправить некорректные данные.
7б. Сервер сообщает, что проверка параметров платежа невозможна по техническим причинам, а
проверка параметров платежа по услуге обязательна:
7б1. Клиент сообщает плательщику, что проверка параметров платежа временно недоступна,
предлагает попробовать позднее.
7в. Сервер сообщает, что проверка параметров платежа невозможна по техническим причинам, а
проверка параметров платежа по услуге возможна, но необязательна: 7в1. Клиент сообщает
плательщику, что проверка параметров платежа временно невозможна и переходит к шагу 8.
9а. Плательщик отказался от оплаты: 9а1. Сценарий прекращается.
10а. Не удалось отправить платеж на Сервер: 10а1. Клиент сохраняет платеж, чтобы отправить его
позже.
Команды протокола
Общее описание
Все типы протокола обмена описаны в схеме eKassirV3Protocol.xsd.
В протоколе все запросы имеют общий базовый тип Request.
Подобно запросам все ответы также имеют общий базовый тип Response. Ответы на все запросы
наследуют базовому типу. Базовый тип не содержит никаких параметров.
Ответ ErrorResponse
В протоколе определен тип ответа ErrorResponse, с помощью которого сервер сообщает об ошибке
обработки запроса. Данный тип ответа может приходить на любой ответ. Коды ошибок который
приходят
Пример ответа с ошибкой:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="ErrorResponse"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Error Number="11" Description="Cancel unavailable. Payment has been rejected already." IsFatal="false" xmlns=""
/>
</Response>
Проверка параметров платежа
Проверка параметров платежа происходит асинхронно в два этапа. На первом этапе производится
регистрация заявки на возврат платежа (RegisterCheckRequest). Признаком успешной регистрации
является ответ (RegisterCheckResponse), в котором указан таймаут, через который рекомендуется
проверить статус заявки при помощи запроса результатов проверки параметров
платежа(GetCheckResultRequest).В ответе на данный запрос (GetCheckResultResponse) сервер
возвращает текущий статус обработки. Если статус заявки не является конечным, клиенту следует
повторно запросить получение результатов через рекомендуемый в ответе таймаут.
Взаимодействие
Схема вызовов:
Запрос RegisterCheckRequest
Этот запрос используется клиентом для проверки параметров платежа. Сервер в ответе предоставляет
информацию о том, когда заявка будет обработана системой. Для того чтобы получить результаты
проверки, клиент должен отправить запрос результатов проверки параметров платежа.
Пример запроса, который содержит один параметр платежа (номер телефона):
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="RegisterCheckRequest" Id="e8e1ebdb-420e-4ed5-808123902d48c383" Service="4" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<PaymentParameters xmlns="">
<Parameter Name="account" Value="9999999999" />
</PaymentParameters>
</Request>
Ответ RegisterCheckResponse
В ответ на запрос RegisterCheckRequest сервер возвращает ответ, в котором сообщает через какое
время клиенту рекомендуется запросить статус обработки запроса проверки параметров платежа.
Пример успешного ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="RegisterCheckResponse"
GetCheckResultTimeout="PT5.217S" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Запрос GetCheckResultRequest
Запрос предназначен для получения результатов проверки параметров платежа. Для выполнения этого
запроса предварительно необходимо отправить запрос RegisterCheckRequest.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetCheckResultRequest" Id="e8e1ebdb-420e-4ed5-808123902d48c383" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ GetCheckResultResponse
В ответе на запрос GetCheckResultRequest сервер возвращает результат проверки параметров платежа.
В случае успешной проверки сервер возвращает параметры, которые были высланы в запросе
регистрации заявки на проверку, а также параметры, которые вернул поставщик услуги, чтобы
показать их плательщику. Заявка на проверку параметров еще может находиться не в
конечном статусе, в этом случае, клиенту следует повторить запрос GetCheckResultRequest через
рекомендуемый в ответе таймаут.
Статусы проверки параметров платежа:
Статус Категория
Описание
0
1
Конечный
Конечный
Параметры платежа корректны
2
3
Конечный
Проверка параметров платежа невозможна.
Промежуточный Проверка параметров еще не выполнена. Запросите результаты позже
Параметры платежа не корректны
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetCheckResultResponse" State="0"
Description="Аккаунт существует" GetCheckResultTimeout="PT0S" MaxPaymentSumm="1000.00"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<PaymentParameters xmlns="">
<Parameter Name="account" Value="9999999999" />
<Parameter Name="documentnumber" Value="123456" />
</PaymentParameters>
</Response>
Проведение платежа
Сервер платежей производить обработку платежа асинхронно. Для проведения платежа клиенту
необходимо зарегистрировать платеж на сервере с помощью запроса (SendPaymentRequest).После
получения данного запроса сервер производит первичную проверку платежа и в случае успеха
отвечает клиенту о том, что запрос был поставлен в очередь обработки(SendPaymentResponse). Если
платеж не пройдет первичную проверку сервер возвращает клиенту ответ(ErrorResponse), в котором
содержится описание ошибки. После успешной регистрации платежа в системе, в виду его
асинхронной отправки поставщику услуги, при необходимости клиент должен воспользоваться
запросом статуса платежа через рекомендуемый в ответе на регистрацию
платежа(SendPaymentResponse) таймаут.
Схема взаимодействия:
Запрос SendPaymentRequest
Запрос предназначен для отправки платежа на Сервер. Сервер ставит платеж в очередь обработки и
формирует ответ в случае успешной первичной проверки.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="SendPaymentRequest" Id="593b2bc2-4cd7-40d2-9f0c4d610d39e5f9" Service="4" Ticket="212506755" Number="16366833241247828975" Time="2012-0126T16:38:21.1449243+04:00" EncashmentNumber="142" Value="100" Commission="0" Currency="RUB"
PaymentTool="5" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<PaymentParameters xmlns="">
<Parameter Name="account" Value="9999999999" />
</PaymentParameters>
<Cheques xmlns="" />
<FiscalData FRNumber="2242" EKLZNumber="105" DocumentNumber="3743" OperationDate="2012-0126T15:49:47.4419243+04:00" ShiftNumber="25" SaleAmountByCash="12" SaleAmountByCard="14"
OperationNumber="39" INN="666666666666" xmlns="">
<Parameters>
<Parameter Name="12" Value="12" />
</Parameters>
<Extension agent="gwtest" />
</FiscalData>
</Request>
Ответ SendPaymentResponse
Данный ответ возвращается, только если платеж успешно поставлен в очередь обработки. Если платеж
не принят сервером будет возвращен ответ ErrorResponse.
Пример успешного ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="SendPaymentResponse" PaymentId="1810629"
PaymentTime="2012-01-26T16:38:21.2+04:00" OperatorId="1" ContractId="1" CheckStateTimeout="PT0.22S"
AvailableBalance="-2259447181.50" CurrentBalance="-2259447281.50" Currency="RUR" NeedBlock="false"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Отмена платежа
Отмена платежа используется для того, чтобы отменить завершенный платеж или платеж, который
еще не был отправлен поставщику услуги. Отмена платежа поддерживается не всеми поставщиками
услуг, также платеж можно отозвать только в течение тех же суток, когда он был отправлен на сервер.
Для регистрации заявки на отмену платежа клиент посылает запрос на отмену платежа
(CancelPaymentRequest),сервер производит проверку возможности отзыва платежа и возвращает ответ
о том что платеж поставлен в очередь на отмену . Если платеж не пройдет проверку сервер возвращает
клиенту ответ(ErrorResponse), в котором содержится описание ошибки. После успешной регистрации
отмены платежа в системе, в виду асинхронности отмены платежа у поставщика услуги, при
необходимости клиент должен воспользоваться запросом статуса платежа через рекомендуемый в
ответе на регистрацию отмены платежа(CancelPaymentResponse) таймаут.
Схема взаимодействия:
Запрос CancelPaymentRequest
Запрос отмены платежа используется для того, чтобы попытается поставить платёж очередь на отмену
у поставщика, если он завершен на сервере или отменить платеж, который еще не был отправлен
поставщику. Запрос отмены платежа может посылать только та точка, которая произвела его
регистрацию на сервере.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CancelPaymentRequest" Id="593b2bc2-4cd7-40d2-9f0c4d610d39e5f9" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ CancelPaymentResponse
Если в ответе сервера нет ошибки, то запрос принят к обработке. После успешной операции
регистрации отмены необходимо проверять статус платежа, используя запрос проверки статуса
платежа.
Пример успешного ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CancelPaymentResponse" CheckStateTimeout="PT0S"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Проверка статуса платежа
Так как проведение или отмена платежа производятся сервером асинхронно, то платеж в результате
обработки изменяет свой статус во времени независимо от клиента. Для того чтобы конечному клиенту
получить статус платежа в платёжной системе, ему необходимо воспользоваться запросом статуса
платежа. После получения такого запроса сервер произведет поиск запрашиваемого платежа, и в
случае если запрашиваемый платеж будет найден, и его регистрация производилась данной платежной
точкой, сервер вернет ответ, содержащий текущий статус платежа и дополнительные параметры,
которые образовались в платеж в результате его обработки. В противном случае сервер вернет ответ с
описание ошибкой о том, что платеж не найден. Статусы платежа делятся на две группы конечные и
промежуточные. При получении клиентом промежуточного статуса, клиент обязан повторять запрос
CheckStatusRequest через таймаут, рекомендованный в ответе.
Статусы платежа:
Статус Категория
Описание
0
1
Промежуточный Принят сервером к обработке, но еще не обрабатывался
Конечный
Отвергнут, так как его параметры некорректны (не существуют у
поставщика услуги),
2
Конечный
3
Промежуточный Отправлен поставщику услуги, но результат обработки еще не получен
4
5
Промежуточный Отложен, так как невозможно отправить поставщику
Конечный
Завершен.
Отвергнут по другим причинам (см. описание статуса),
6
7
Промежуточный Отзывается у поставщика услуги
Конечный
Отменен
8
Конечный
Возвращен плательщику
Запрос CheckStatusRequest
Запрос используется для проверки результата обработки платежа. Данный запрос
предназначен для получения текущего статуса платежа, после запросов SendPaymentRequest
или CancelPaymentRequest.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CheckStatusRequest" Id="593b2bc2-4cd7-40d2-9f0c4d610d39e5f9" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ CheckStatusResponse
Данный ответ возвращается на запрос CheckStatusRequest. В ответе содержится информация о платеже
и статус платежа. Пример ответа, в котором платеж находится в промежуточном статусе:
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CheckStatusResponse"
PaymentId="1810629" StateTime="2012-01-26T16:51:42.61+04:00" State="4"
StateComment="Отложен, так как невозможно отправить поставщику”
OperatorId="1" ContractId="1" NextCheckStateTimeOut="PT1M30S"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<PaymentParameters xmlns="">
<Parameter Name="account" Value="9999999999" />
</PaymentParameters>
</Response>
Пример ответа, в котором платеж успешно зачислен получателю:
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CheckStatusResponse" PaymentId="1810629"
StateTime="2012-01-26T16:51:42.61+04:00" State="5" StateComment="Завершен" OperatorId="1" ContractId="1"
NextCheckStateTimeOut="PT0S" xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<PaymentParameters xmlns="">
<Parameter Name="account" Value="9999999999" />
</PaymentParameters>
</Response>
Пример ответа, в котором платеж успешно отменен:
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CheckStatusResponse" PaymentId="1810629"
StateTime="2012-01-26T16:51:42.61+04:00" State="7" StateComment="Отвергнут, отозван" OperatorId="1"
ContractId="1" NextCheckStateTimeOut="PT0S"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<PaymentParameters xmlns="">
<Parameter Name="account" Value="9999999999" />
</PaymentParameters>
</Response>
Справочники
Запрос GetDirectoryRequest
Запрос справочника используется для получения информации об услугах, оплата которых возможна на
Сервере для этого клиента, точке приема платежей, счете и пр.
Клиент может запросить справочник с разной детализацией. От уровня детализации зависит размер
справочника. В каждой услуге есть номер ее версии. Номер версии меняется, если изменилась
информация об услуге. В протоколе также предусмотрен запрос полной информации об одной услуге
или группе услуг. Все это позволяет использовать различные стратегии по работе со справочниками в
зависимости от типа приложения. Примеры:
Тип
приложения
Стратегия
Сервер
Так как сервер использует каналы с высокой пропускной способностью, размер
передаваемых данных для него не имеет большого значения, поэтому можно всегда
использовать запрос полного справочника.
Как правило, мобильный клиент использует GPRS, в котором ограничена
пропускная способность, кроме того на нем нет необходимости печатать чеки с
информацией об участниках.
Приложение может загружать короткий или средний справочник, а затем
запрашивать информацию об услугах, оплата которых необходима. Таким образом,
можно существенно сэкономить трафик.
Мобильный
клиент
Пример запроса
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetDirectoryRequest" ServicesDetalization="4"
IncludeRegions="true" IncludeServiceTypes="true" IncludeContracts="true" IncludeOperators="true"
IncludeCurrencies="true" IncludeNominals="true"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ GetDirectoryRequest
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetDirectoryResponse"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Client Id="1" Name="1" Blocked="false" xmlns="">
<Requisites LegalName="1" LegalAddress="1" PostAddress="1" TaxpayerIdNumber="1" RRCode="1"
ContactPhoneNumber="1" />
</Client>
<Point Id="1" PointId="7d198045-cf94-4e0b-8764-d3c3a408f572" Blocked="false" Address="" Name="1-1"
CreationDate="2010-09-09" xmlns="" />
<Account Id="7" Name="p 1-1" AllowedBalance="-100.00" CurrentBalance="-2259447281.50" AvailableBalance="2259447181.50" Currency="RUR" xmlns="" />
<Contracts xmlns="">
<Contract Id="1" Number="11111" Date="2010-09-09" />
</Contracts>
<Operators xmlns="">
<Operator Id="1" Name="1" ContractId="1">
<Requisites LegalName="Unknown" LegalAddress="Unknown" PostAddress="Unknown"
TaxpayerIdNumber="000000000000" RRCode="000000" ContactPhoneNumber="" />
</Operator>
<Operator Id="2" Name="2" ContractId="3">
<Requisites LegalName="" LegalAddress="" PostAddress="" TaxpayerIdNumber="" RRCode=""
ContactPhoneNumber="" />
</Operator>
</Operators>
<Regions xmlns="">
<Region Id="1" Name="Test" />
</Regions>
<ServiceTypes xmlns="">
<ServiceType Id="1" Name="" />
</ServiceTypes>
<FullServices xmlns="">
<Service Id="6" Version="19" ExternalId="" Name="asda" TypeId="0" RegionId="0" Logo="" Alias="asd"
DefaultOperatorId="1" MinValue="0.00" MaxValue="0.00" Currency="RUR" CheckNecessity="2"
CheckTimeout="30">
<Parameters>
<Parameter Name="test" Value="<[[D/>null" />
<Parameter Name="TEST33" Value="null" />
</Parameters>
<Requisites LegalName="" LegalAddress="" PostAddress="" TaxpayerIdNumber="" RRCode=""
ContactPhoneNumber="" />
<PaymentParameters>
<Parameter Name="account" DisplayName="account" Description="account" Mask="" Regexp=""
DefaultValue="" SendAt="3" Direction="1" IsRequired="true" AvailableValuesReference="" />
</PaymentParameters>
<CommissionLimitations />
</Service>
<Service Id="8" Version="37" ExternalId="" Name="Мегафон" TypeId="1" RegionId="1" Logo="" Alias="1"
DefaultOperatorId="1" MinValue="0.00" MaxValue="30000.00" Currency="RUR" CheckNecessity="2"
CheckTimeout="30">
<Parameters>
<Parameter Name="test" Value="<[[D/>null" />
<Parameter Name="TEST33" Value="null" />
</Parameters>
<Requisites LegalName="" LegalAddress="" PostAddress="" TaxpayerIdNumber="" RRCode=""
ContactPhoneNumber="" />
<PaymentParameters>
<Parameter Name="account" DisplayName="123" Description="123" Mask="" Regexp="" DefaultValue=""
SendAt="3" Direction="3" IsRequired="true" AvailableValuesReference="" />
<Parameter Name="1" DisplayName="test" Description="1" Mask="" Regexp="" DefaultValue="" SendAt="3"
Direction="3" IsRequired="true" AvailableValuesReference="123" />
</PaymentParameters>
<CommissionLimitations>
<CommissionLimitation StartDate="2011-09-24" Type="4" MinRate="0.000" MaxRate="100.000"
MinAmount="0.00" MaxAmount="12.00" CommissionType="1" />
</CommissionLimitations>
</Service>
</FullServices>
<Nominals xmlns="">
<Nominal NominalId="1" CurrencyCode="810" Value="10.00" Type="1" />
<Nominal NominalId="2" CurrencyCode="643" Value="50.00" Type="2" />
</Nominals>
<Currencies xmlns="">
<Currency CurrencyCode="643" AlfabticCode="RUB" Description="RUB" />
<Currency CurrencyCode="810" AlfabticCode="RUR" Description="RUR" />
<Currency CurrencyCode="840" AlfabticCode="USD" Description="USD" />
</Currencies>
<LastEncashment PointId="7d198045-cf94-4e0b-8764-d3c3a408f572" EncashmentId="142" InputeDate="0001-0101T00:00:00.0000000+04:00" StartDate="2012-01-26T15:35:07.7400000+04:00" EndDate="0001-0101T00:00:00.0000000+04:00" State="1" xmlns="" />
</Response>
Параметры платежа
Часто возникает необходимость передать на сервер не только номер лицевого счета (как account), но и
дополнительные параметры. Так, например, при приеме коммунальных платежей бывает необходимо
вбить показания счетчиков учета воды, электричества и пр. Также бывает необходимость передать в
ответе сервера на запрос проверки номера фамилию, имя, отчество или другие данные о плательщике и
его лицевом счете.
Для этих целей в справочнике передаются описания дополнительных атрибутов платежа.
Дополнительные атрибуты платежа могут передаваться в запросе на сервер, в ответе сервера и на
разных этапах обработки платежа. Справочник позволяет автоматически сформировать меню для
пользователя в клиентском приложении.
Формат маски
Маска параметра платежа предназначена для ввода значения пользователем. В маске могут
использоваться следующие символы:
[] – внутри квадратных скобок может содержаться любое количество символов «0», «9», «А», «а» и
«_». Символ «0» означает обязательную цифру. Количество указанных в маске символов «0»
соответствует количеству обязательных цифр для ввода. Например, маска [000] требует у оператора
ввода текста длиной три символа. В поле ввода значения нули будут заменены символом «*».
Например, маска [000] заполнит поле ввода строкой «***».
Символ «9» означает необязательную цифру. Например, маска [00099] требует ввода строки длинной
от 3-х до 5-и цифр.
Символ «А» означает обязательную букву. Например, маска [AAA] требует ввода строки длинной трех
букв.
Символ «а» означает необязательную букву. Например, маска [АААааа] требует ввода строки длинной
от 3-х до 5-и букв.
Символ «_» означает обязательный символ (букву или цифру).
Любые символы, не заключенные в квадратные скобки, будут выведены в поле ввода значения
атрибута. Например, маска +7([000]) [000]-[0000] в поле ввода значения выведет +7(***) ***-****.
Символы за пределами квадратных скобок не включаются в значение, введенное оператором.
{}- символ, включенный в фигурные скобки, будет отображаться в поле ввода значения атрибутов так
же, как если бы он был за пределами квадратных скобок. Но символы внутри фигурных скобок
включаются в веденное значение. Например, маски [00]-[00] и [00]{-}[00] выведут в поле ввода
одинаковый текст: **-**. Если оператор введет строку «1234», то в первом случае значением атрибута
будет «1234», а во втором «12-34».
{}- символ, включенный в фигурные скобки, будет отображаться в поле ввода значения атрибутов так
же, как если бы он был за пределами квадратных скобок. Но символы внутри фигурных скобок
включаются в веденное значение. Например, маски *00+-*00+ и *00+,--*00+ выведут в поле ввода
одинаковый текст: **-**. Если оператор введет строку «1234», то в первом случае значением атрибута
будет «1234», а во втором «12-34».
Запрос GetServiceRequest
Запрос предназначен для получения полной информации по одной услуге.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetServiceRequest" Id="2"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ GetServiceResponse
В ответе высылается полное описание услуги, если она разрешена клиенту. Параметры услуги
смотрите выше.
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetServiceResponse"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Service Id="2" Version="32" ExternalId="" Name="2" TypeId="1" RegionId="1" Logo="" Alias="2"
DefaultOperatorId="1" MinValue="0.00" MaxValue="30000.00" Currency="RUR" CheckNecessity="2"
CheckTimeout="31" xmlns="">
<Parameters>
<Parameter Name="test" Value="<[[D/>null" />
<Parameter Name="TEST33" Value="null" />
</Parameters>
<Requisites LegalName="" LegalAddress="" PostAddress="" TaxpayerIdNumber="" RRCode=""
ContactPhoneNumber="" />
<PaymentParameters>
<Parameter Name="account" DisplayName="account" Description="" Mask="" Regexp="" DefaultValue=""
SendAt="3" Direction="1" IsRequired="true" AvailableValuesReference="" />
</PaymentParameters>
<CommissionLimitations>
<CommissionLimitation StartDate="2011-09-24" Type="4" MinRate="0.000" MaxRate="100.000"
MinAmount="0.00" MaxAmount="12.00" CommissionType="1" />
</CommissionLimitations>
</Service>
</Response>
Запрос GetServicesRequest
Запрос предназначен для получения полной информации по нескольким услугам.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetServicesRequest"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<IdCollection xmlns="">
<Id>6</Id>
<Id>3</Id>
<Id>1</Id>
</IdCollection>
</Request>
Ответ GetServicesResponse
В ответе высылается полное описание услуг, если они разрешены клиенту. Параметры услуги
смотрите выше.
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetServicesResponse"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Services xmlns="">
<Service Id="6" Version="19" ExternalId="" Name="asda" TypeId="0" RegionId="0" Logo="" Alias="asd"
DefaultOperatorId="1" MinValue="0.00" MaxValue="0.00" Currency="RUR" CheckNecessity="2"
CheckTimeout="30">
<Parameters>
<Parameter Name="test" Value="<[[D/>null" />
<Parameter Name="TEST33" Value="null" />
</Parameters>
<Requisites LegalName="" LegalAddress="" PostAddress="" TaxpayerIdNumber="" RRCode=""
ContactPhoneNumber="" />
<PaymentParameters>
<Parameter Name="account" DisplayName="account" Description="account" Mask="" Regexp=""
DefaultValue="" SendAt="3" Direction="1" IsRequired="true" AvailableValuesReference="" />
</PaymentParameters>
<CommissionLimitations />
</Service>
<Service Id="1" Version="45" ExternalId="x76" Name="1" TypeId="1" RegionId="1" Logo="" Alias="1-1"
DefaultOperatorId="1" MinValue="10.00" MaxValue="30000.00" Currency="RUR" CheckNecessity="2"
CheckTimeout="30">
<Parameters>
<Parameter Name="test" Value="<[[D/>null" />
<Parameter Name="TEST33" Value="null" />
</Parameters>
<Requisites LegalName="" LegalAddress="" PostAddress="" TaxpayerIdNumber="" RRCode=""
ContactPhoneNumber="" />
<PaymentParameters>
<Parameter Name="account" DisplayName="account" Description="Аккаунт" Mask="" Regexp=""
DefaultValue="" SendAt="3" Direction="1" IsRequired="true" AvailableValuesReference="" />
<Parameter Name="Date" DisplayName="Дата создания" Description="Дата создания реестра" Mask=""
Regexp="" DefaultValue="" SendAt="3" Direction="3" IsRequired="true" AvailableValuesReference="">
<AllowedValue DisplayName="Первое" Value="1" />
<AllowedValue DisplayName="Второе" Value="2" />
</Parameter>
<Parameter Name="attr" DisplayName="attr" Description="ХЗ" Mask="" Regexp="" DefaultValue="" SendAt="1"
Direction="2" IsRequired="false" AvailableValuesReference="" />
<Parameter Name="attr2" DisplayName="attr2" Description="" Mask="" Regexp="" DefaultValue="" SendAt="2"
Direction="2" IsRequired="false" AvailableValuesReference="" />
<Parameter Name="Chech1" DisplayName="Chech1" Description="" Mask="" Regexp="" DefaultValue=""
SendAt="1" Direction="1" IsRequired="false" AvailableValuesReference="" />
<Parameter Name="Send1" DisplayName="Send1" Description="" Mask="" Regexp="" DefaultValue=""
SendAt="2" Direction="1" IsRequired="false" AvailableValuesReference="" />
<Parameter Name="ChechAndSend1" DisplayName="ChechAndSend1" Description="" Mask="" Regexp=""
DefaultValue="" SendAt="3" Direction="1" IsRequired="false" AvailableValuesReference="" />
</PaymentParameters>
<CommissionLimitations>
<CommissionLimitation StartDate="2011-09-24" Type="4" MinRate="0.000" MaxRate="100.000"
MinAmount="0.00" MaxAmount="12.00" CommissionType="1" />
</CommissionLimitations>
</Service>
</Services>
</Response>
Получение сдачи
Запрос сдачи по номеру чека (20изначный штрих-код на чеке терминала). Этим запросом терминал
получает сдачу, и сервер ее блокирует на таймаут заданный администратором, чтобы исключить
повторное использование.
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetBalanceRequest" Number="16366833241796027811"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ GetBalanceResponse
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="GetBalanceResponse" Balance="10.00" SourseState="0"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Команда передачи внутреннего протокола
Ekassir может служить транспортом для другого протокола. Для этой цели служит запрос
ExtendedRequest. В нем можно передать данные вложенного протокола. Таким образом, возможно,
сделать обмен между терминалом и сервером получателя через сервер eKassir по любому протоколу.
Взаимодействие
Схема вызовов:
Клиент, например терминал, передает запрос PaySystemServer, который далее транслирует вложенные
в запрос данные шлюзу. Шлюз формирует запрос поставщику слуги, получает ответ. Ответ передается
обратно по цепочке. Если запрос не поддерживается шлюзом, то клиент получит ответ ErrorResponse
«Запрос не поддерживается».
Запрос ExtendedRequest
Пример запроса
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="ExtendedRequest" Service="4"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">RestData</Request>
Ответ ExtendedResponse
Пример ответа
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="ExtendedResponse"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">RestData</Response>
Запрос создания инвентаризации
Данная функциональность используется платежными терминалами, на которых производиться работа
с фискальными регистраторами. Запрос предназначен для отправки данных инвентаризации на Сервер.
Сервер добавляет инвентаризацию в БД и формирует ответ.
Запрос AddInventoryRequest
Запрос регистрации инвентаризации
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddInventoryRequest" ExternalId="1763516746"
Date="2012-01-26T13:27:25.7986634+04:00" ShiftNumber="1" Amount="3" XReportAmount="3"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ AddInventoryResponse
Ответ на запрос регистрации инвентаризации
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddInventoryResponse" Id="114"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Запрос создания фискальной операции
Данная функциональность используется платежными терминалами, на которых производиться работа
с фискальными регистраторами. Запрос предназначен для отправки данных фискальной операции
произведенной на фискальном регистраторе на Сервер. Сервер добавляет фискальную операцию в БД
и формирует ответ.
Запрос AddFiscalOperationRequest
Запрос регистрации фискальной операции
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddFiscalOperationRequest" FRNumber="3982"
EKLZNumber="4070" DocumentNumber="80" OperationDate="2012-01-26T13:27:44.8885722+04:00"
ShiftNumber="48" OperationType="1" StartAmount="36" Amount="66" Number="77" Reason="2" InventoryId="21"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Extension param1="value1" xmlns="" />
</Request>
Ответ AddFiscalOperationResponse
Ответ на запрос регистрации фискальной операции
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddFiscalOperationResponse" Id="59"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Запрос создания Z отчёта
Данная функциональность используется платежными терминалами, на которых производиться работа
с фискальными регистраторами. Запрос предназначен для отправки данных Z отчёта на Сервер. Сервер
добавляет Z отчёт в БД и формирует ответ.
Запрос AddZReportRequest
Запрос регистрации Z-отчета
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddZReportRequest" FRNumber="9747"
EKLZNumber="3367" OperationNumber="0" KPKNumber="3955" OperationDate="2012-0126T13:28:11.5772408+04:00" ShiftNumber="70" SaleAmount="10" SaleCount="44" SaleAmountByCash="18"
SaleAmountByCard="73" PayOutAmount="25" PayOutCount="91" PayInAmount="94" PayInCount="86"
CashDeskAmount="23" TotalSaleAmount="59" ShiftStartDate="2012-01-26T13:28:09.6750506+04:00"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Extension att1="value1" xmlns="" />
</Request>
Ответ AddZReportResponse
Ответ на запрос регистрации Z-отчета
Параметры ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddZReportResponse" Id="38"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Пример ответа:
Система работы через заявки
Некоторая функциональность системы работает через механизм заявок. Данный механизм
предназначен для возможности выполнения транзакционных операций. При работе клиент посылает
заявку на определённую операцию, сервер при этом проверяет возможность регистрации заявки и при
успехе возвращает клиенту идентификатор зарегистрированной заявки с секретным кодом активации
(в некоторых случаях север блокирует ресурсы для возможности выполнения запрашиваемой
операции). После чего клиент производит определённые действия на своей стороне, и в зависимости
результатов выполнения операции на своей стороне, посылает на сервер запрос подтверждения или
отмены заявки. При получении запроса подтверждения заявки сервер выполнят операцию, которая
связана с текущей заявкой и освобождает заблокированные ресурсы. В противном случает при
получении запроса отмены заявки, сервер, не выполняя операцию, которая связана с данной заявкой,
производит возврат данных в исходное состояние (снимает блокировку с ресурсов). Для возможности
работы в распределенной среде, механизм заявок предоставляет функциональность автоматического
выполнения действия по заявке по истечению заданного клиентом таймаута, таких как авто
исполнение, авто отмена. Данная функциональность управляется клиентом путем задания параметров
в запросе на регистрацию заявки любого типа.
Возврат платежа
Для возможности расчета с клиентами по отвергнутым платежам в платежной системе предусмотрена
процедура возврата платежей. Для возврата платежа необходимо чтобы соблюдались следующие
условия:
1) платеж клиента должен быть отменен
2) возврат производился на точке того же агента который проводил возвращаемый платеж (любая
точка агента).
3)Если платеж имеет цепочку переотправки на сервер, все платежи в этой цепочке должны быть
отменены
4)На платеже не присутствует глобальная блокировка, связанная с операциями редактирования или
переотправки.
Основной сценарий возврата платежа
1. Плательщик приходит в кассу агента, через которого был произведён платеж и предоставляет чек.
2. Кассир на основании чека производит регистрацию заявки на возврат платежа и посылает его на
сервер.
3. Сервер производит поиск платежа по критериям поиска заданным в заявке на возврат.
4. В случае если платеж найден, проверяются условия возврата.
5. В случае успешности проверки условий возврата, сервер накладывает на платеж глобальную
блокировку
6. В случае успешности получения глобальной блокировки на платеж сервер регистрирует заявку в
системе и посылает ответ на регистрацию заявки, в котором содержится информация по
возвращаемому платежу и сумма к возврату.
7. При получении успешного ответа на регистрацию заявки касса выполняет действия связанные с
возвратом определённые регламентом агента (операции в кассовом по, возврат денег клиенту и т.д.).
8. В случае успеха оформление возврата на кассе, касса посылает запрос на подтверждения заявки на
возврат на сервер.
9. Сервер при получении подтверждения заявки производит возврат платежа на сервере (отмечает
платеж как возвращённый ,если у платежа была цепочка переотправки, то все платежи в этой цепочки
принимают статус «возвращен первичный платеж», и снимает блокировку платежу)
10. В случае успеха возврата платежа на сервере сервер переводит статус заявки в исполнено и
возвращает статус заявки клиенту.
11. Касса получает ответ на подтверждение заявки, проверяет статус заявки из ответа
12. В случае получения статуса заявки как исполненной. Касса считает что отзыв завершён успешно.
Сценарий прекращается
Расширения:
8.а В случае не успеха оформление возврата на кассе (клиент отказался, нет денег, ошибка в кассовом
ПО и. т. д.), касса посылает на сервер запрос отмены заявки на возврат платежа.
9.а Сервер при получении отмены заявки производит снятие глобальной блокировки с платежа.
10.а В случае успеха возврата платежа на сервере сервер переводит статус заявки в отменена и
возвращает статус заявки клиенту.
11.а Касса получает ответ на отмену заявки, проверяет статус заявки из ответа
12.а В случае получения статуса заявки как отмененной касса считает, что платеж вернулся в исходное
состояние на сервере. Сценарий прекращается
Запрос RegisterRefundPaymentQueryRequest
Запрос регистрации заявки на возврат платежа
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="RegisterRefundPaymentQueryRequest"
OnlyCheck="false" ActivityTime="0001-01-01T00:00:00" ActivityType="0" PaymentIdOnPoint="56d8bdd0-c0c0-4ffda136-f4975a3999c7" PaymentId="1810631" PointId="0" PointGuidId="00000000-0000-0000-0000-000000000000"
PaymentDate="0001-01-01T00:00:00" Ticket="0"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ RegisterRefundPaymentQueryResponse
Ответ на запрос регистрации заявки на возврат платежа
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="RegisterRefundPaymentQueryResponse" QueryId="113"
ActivationCode="8df60b79-0e88-430d-98be-74790a932eb2" Amount="10.00" State="0"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Payment PaymentState="7" Id="56d8bdd0-c0c0-4ffd-a136-f4975a3999c7" Ticket="479467456"
Number="1636683324760442998" ClientTime="2012-02-02T16:11:29.36" ServerTime="2012-02-02T16:11:29.41"
EncashmentNumber="143" Value="10.00" Commission="0.00" Amount="10.00" FromBalance="0.00">
<PayParameters xmlns="">
<Parameter Name="account" Value="9993333333" />
</PayParameters>
<Service Id="4" Version="49" ExternalId="" Name="Test" TypeId="1" RegionId="0" Logo="" Alias="mtsall"
DefaultOperatorId="1">
<Parameters xmlns="">
<Parameter Name="test" Value="<[[D/>null" />
<Parameter Name="TEST33" Value="null" />
</Parameters>
</Service>
<Point Id="1" PointId="7d198045-cf94-4e0b-8764-d3c3a408f572" Blocked="false" Address="" Name="1-1"
CreationDate="2010-09-09" />
<Client Id="1" Name="1" Blocked="false">
<Requisites LegalName="1" LegalAddress="1" PostAddress="1" TaxpayerIdNumber="1" RRCode="1"
ContactPhoneNumber="1" xmlns="" />
</Client>
<Contract Id="1" Number="11111" Date="2010-09-09" />
<Operator Id="1" Name="1" ContractId="1">
<Requisites LegalName="Unknown" LegalAddress="Unknown" PostAddress="Unknown"
TaxpayerIdNumber="000000000000" RRCode="000000" ContactPhoneNumber="" xmlns="" />
</Operator>
<Serial>1810631</Serial>
</Payment>
</Response>
Запрос отмены заявки.
Запрос предназначен для отмены любой заявки.
Запрос CancelQueryRequest
Запрос отмены заявки
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CancelQueryRequest" QueryId="114"
ActivationCode="2a446ba2-5be4-49d8-814e-bb979235d081"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ CancelQueryResponse
Ответ на запрос отмены заявки
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CancelQueryResponse" QueryId="114" Result="true"
TextResult="Заявка 114 на возврат платежа успешно отменена."
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Запрос подтверждения заявки.
Запрос предназначен для подтверждения любой заявки.
Запрос CommitQueryRequest
Запрос подтверждения заявки
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CommitQueryRequest" QueryId="113"
ActivationCode="8df60b79-0e88-430d-98be-74790a932eb2"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Ответ CommitQueryResponse
Ответ на запрос подтверждения заявки
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="CommitQueryResponse" QueryId="113" Result="true"
TextResult="Заявка 113 на возврат платежа успешно обработана. Платеж Serial = 1810631 возвращен."
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
Инкассация.
Для возможности учета денежных средств на платежных точках в системе предусмотрена возможность
передачи информации по инкассации. В системе используется понятие инкассационного периода.
Инкассационный период – временной интервал от одной инкассаций платежной точки до другой,
имеющий порядковый номер в рамках платежной точки. При проведении инкассации платежной
точки, платежная точка имеет возможность сообщить данные о загруженных и извлеченных наличных
средствах при инкассации, а также оборотах денежных средств в рамкам инкассируемого периода. Эти
данные могут, используются системой для проведения сверок инкассаций и платежей проведенной
точкой в данном периоде. Для этого ПО платежной точки должно отправлять запрос регистрации
инкассации , указывая номер текущего периода и данные инкассации. После успешного получения
ответа, точка может считать, что инкассация зарегистрирована на сервере и открывать новый
Инкассационный период. Для возможности сверки платежей в ПО платежной точки любой запрос на
регистрацию платежа должен содержать номер текущего инкассационного периода
Запрос AddEncashmentRequest
Запрос регистрации инкассации
Пример запроса:
<?xml version="1.0" encoding="utf-8"?>
<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddEncashmentRequest"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol">
<Encashment PointId="7d198045-cf94-4e0b-8764-d3c3a408f572" EncashmentId="141" Collector="collector"
InputeDate="2012-01-26T13:30:44.9355751+04:00" StartDate="2012-01-26T12:27:02.7133911+04:00"
EndDate="2012-01-26T13:30:44.9355751+04:00" State="0" xmlns="">
<NominalInfoInput>
<NominalInfo Count="100" NominalValue="10.00" CurrencyId="810" Type="1" />
<NominalInfo Count="100" NominalValue="50.00" CurrencyId="643" Type="2" />
</NominalInfoInput>
<NominalInfoOutput>
<NominalInfo Count="100" NominalValue="10.00" CurrencyId="810" Type="1" />
<NominalInfo Count="100" NominalValue="50.00" CurrencyId="643" Type="2" />
</NominalInfoOutput>
<CurrencyEncashment>
<CurrencyEncashmentTotal CurrencyCode="810" TotalCashOutForAllSystem="0" TotalCashInForAllSystem="0"
TotalCashOutForMainSystem="0" TotalCashInForMainSystem="0" StartTotalCashOutput="1678800.00"
EndTotalCashOutput="1678800.00" StartTotalCashInput="1678800.00" />
<CurrencyEncashmentTotal CurrencyCode="643" TotalCashOutForAllSystem="0" TotalCashInForAllSystem="0"
TotalCashOutForMainSystem="0" TotalCashInForMainSystem="0" StartTotalCashOutput="3339800.00"
EndTotalCashOutput="3339800.00" StartTotalCashInput="3339800.00" />
</CurrencyEncashment>
</Encashment>
</Request>
Ответ AddEncashmentResponse
Ответ на запрос регистрации инкассации
Пример ответа:
<?xml version="1.0" encoding="utf-8"?>
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="AddEncashmentResponse" Serial="53286"
xmlns="http://ekassir.com/eKassir/PaySystem/Server/eKassirV3Protocol" />
13. Реквизиты и подписи Сторон
13.1. Клиент:
ООО «ЕРЦ – Финансовая логистика»
Почтовый адрес: 620043, г. Екатеринбург, ул. Репина,103
Юридический адрес: 620043, г. Екатеринбург, ул. Репина, 103
ИНН 6658376074, КПП 665801001
ОГРН 1116658001074
р/с 40702810300261003212 в Филиал «Газпромбанк» в г. Екатеринбурге
к/сч 30101810800000000945 БИК 046568945
Адрес электронной почты: money@erc.ur.ru
Тел. (343) 287-10-06, факс (343) 287-10-03
13.2. Банк:
Почтовый адрес:
ИНН
, КПП _________________
ОГРН __________________
р/с _____________________________
к/сч ____________________ БИК _________________
Адрес электронной почты: _______________________
Тел. __________________________________________
Клиент
Банк
_______________/Зайков А.Ю./
____________/
М.П.
М.П.
/