Типовой договор на прием платежей физических лиц

Договор об осуществлении деятельности
по приему платежей физических лиц № СА-______________ (ДПП)
г. Екатеринбург
«
» ___________ 2013 года
Общество с ограниченной ответственностью «ЕРЦ – Финансовая логистика» (ООО
«ЕРЦ – Финансовая логистика»), именуемое в дальнейшем «Оператор», в лице Директора
Зайкова Алексея Юрьевича, действующего на основании Устава, с одной стороны, и
_________________________________________, именуемое в дальнейшем «Субагент», в лице
_________________________________________,
действующего
на
основании
_______________________________________, с
другой
стороны,
далее
именуемые
«Стороны», заключили настоящий договор (далее «Договор») о нижеследующем:
1. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
1.1. Поставщик – юридическое лицо, или индивидуальный предприниматель,
получающий денежные средства Плательщика за реализуемые товары (выполняемые работы,
оказываемые услуги), а так же юридическое лицо или индивидуальный предприниматель,
которому вносится плата за жилое помещение и коммунальные услуги в соответствии с
Жилищным кодексом РФ.
1.2. Плательщик – физическое лицо, осуществляющее внесение Субагенту денежных
средств в целях исполнения денежных обязательств физического лица перед Поставщиком.
1.3. Абонентский договор – Договор на предоставление услуг, заключенный между
Поставщиком и Плательщиком.
1.4. Лицевой счет Плательщика – аналитический счет или иной счет Плательщика в
системе расчетов Поставщика с Плательщиками за реализуемые товары (выполняемые
работы, оказываемые услуги).
1.5. Точка приема платежей (касса, банкомат, платежный терминал, системы удаленного
обслуживания банковского счета и иные системы обслуживания клиентов-владельцев
банковских карт) – обособленно расположенный аппаратно-программный комплекс,
зарегистрированный в соответствии с действующим законодательством РФ, включающий в
себя персональный компьютер, фискальный регистратор и прочее вспомогательное
оборудование.
1.6. Платеж – предварительный платеж, платеж по выставленным счетам и иной платеж,
уплачиваемый Плательщиком в пользу Поставщика наличными денежными средствами.
1.7. Обеспечительный взнос (далее «Обеспечение») – средство обеспечения Субагентом
своих обязательств по Договору.
1.8. Система
«ФРИСБИ»
автоматизированная
система,
обеспечивающая
информационное и технологическое взаимодействие между Оператором, Субагентом и
Поставщиком при приеме платежей от Плательщика.
1.9. Вознаграждение сумма, выплачиваемая Оператором Субагенту за прием
платежей.
1.10. Лимит – устанавливаемое Оператором в соответствии с Договором ограничение
суммы остатка денежных средств на текущем счете Субагента в Системе «ЕРЦ – Финансовая
логистика» по достижении которого Субагент обязан прекратить прием платежей, а Оператор
отключить Субагента от Системы «ФРИСБИ». Значение Лимита определяется как разница
между фактическим остатком денежных средств на текущем счете Субагента в Системе
«ФРИСБИ» и суммой принятых Субагентом платежей, с момента последнего перечисления
денежных средств, предусмотренного п. 3.1.10. Договора.
1.11. Текущий счет Субагента – аналитический счет в Системе «ФРИСБИ», на котором
учитывается списание и пополнение денежных средств Субагента.
2. ПРЕДМЕТ ДОГОВОРА
2.1. Субагент от своего имени и за счет Оператора осуществляет прием платежей от
Плательщиков в пользу Поставщиков, указанных в Приложении №1, используя Систему
«ФРИСБИ».
2.2. Оператор выплачивает Субагенту вознаграждение за осуществление приема
платежей с использованием Системы «ФРИСБИ».
3. ПРАВА И ОБЯЗАННОСТИ СТОРОН
3.1. Субагент обязан:
3.1.1. В
момент
принятия
Платежа
передавать
данные
о
Платеже
с
использованием собственных каналов передачи информации в Систему «ФРИСБИ»,
обеспечивающих внесение соответствующих изменений в Лицевой счет Плательщика.
3.1.2. В течение 3 (Трех) рабочих дней с момента подписания Договора внести на
расчетный счет Оператора (указанный в п. 14.2. Договора) Обеспечение, необходимое для
приема Субагентом Платежей от Плательщиков. Размер Обеспечения указан в Приложении №
2 Договора.
3.1.3. Осуществлять прием платежей от Плательщиков в соответствии с заключенным
Договором на прием платежей между Оператором и Поставщиком, включая требования о
предельном размере расчетов наличными деньгами и расходовании наличных денег,
поступивших в кассу юридического лица или кассу индивидуального предпринимателя в
соответствии с законодательством Российской Федерации, а также осуществлять
последующие расчеты с Оператором.
3.1.4. Не осуществлять прием платежей, требующих проведения идентификации
Плательщика, осуществляющего платеж, в соответствии с требованиями законодательства о
противодействии легализации (отмыванию) доходов, полученных преступным путем, и
финансированию терроризма.
3.1.5. Соблюдать требования законодательства Российской Федерации о применении
контрольно-кассовой техники.
3.1.6. Обеспечить прием от Плательщиков информации о наименовании Поставщика,
наименовании товара (работы, услуги), за который (которые) исполняются денежные
обязательства физического лица перед Поставщиком, о размере вносимых Субагенту
денежных средств, а также иной информации.
3.1.7. Обеспечить в каждом месте приема платежей предоставление Плательщикам
следующей информации:
 Адрес и место приема платежей;
 Наименование Поставщика;
 Реквизитов договора между Оператором по приему платежей и Субагентом;
 Размера вознаграждения, уплачиваемого Плательщиком Субагенту в случае взимания
такого вознаграждения;
 Способов подачи претензий (в соответствии с п. 3.1.19. Договора);
 Номеров контактных телефонов Оператора, Субагента, Поставщика;
 Адресов и номеров контактных телефонов федеральных органов исполнительной
власти, уполномоченных Правительством Российской Федерации на проведение
государственного контроля (надзора) за приемом платежей;
3.1.8. Обеспечить прием денежных средств, вносимых Плательщиками.
3.1.9. Обеспечить в момент осуществления платежа Плательщиком выдачу кассового чека,
подтверждающего осуществление соответствующего платежа. Кассовый чек, выдаваемый
Субагентом Плательщику, обязан соответствовать требованиям законодательства Российской
Федерации о применении контрольно-кассовой техники при осуществлении наличных
денежных расчетов и должен содержать следующие реквизиты:
 Наименование документа – кассовый чек;
 Наименование оплаченного товара (работ, услуг);
 Общую сумму принятых денежных средств;
 Размер вознаграждения, уплачиваемого Плательщиком, в случае его взимания;
 Дату, время приема денежных средств, номер кассового чека и контрольно-кассовой
техники;
 Адрес места приема денежных средств;
 Наименование и место нахождения Субагента, принявшего денежные средства, и его
идентификационный номер налогоплательщика;
 Номера контактных телефонов Поставщика, Оператора, Субагента.
Все реквизиты, напечатанные на кассовом чеке, должны быть четкими и легко читаемыми
в течение не менее шести месяцев.
3.1.10. До 13-00 рабочего дня, следующего за днем принятия Платежей от Плательщиков,
обеспечить зачисление на расчетный счет Оператора, указанный в п. 14.2. денежных средств
по принятым платежам за предыдущий день (дни). При перечислении Субагентом денежных
средств в платежном поручении в графе «Назначение платежа» должно быть указано
«Денежные средства в счет принятых платежей в пользу Поставщиков за «число месяц год»
по Договору № СА-____________ (ДПП) от «__» _________ 2013 года». Рабочими днями в
рамках Договора признаются календарные дни с понедельника по пятницу включительно,
если они не являются выходными или нерабочими праздничными днями в соответствии с
действующим законодательством Российской Федерации, либо календарные дни – суббота и
воскресенье, если в соответствии с действующим законодательством Российской Федерации
они объявлены рабочими днями.
3.1.11. По согласованию с Оператором оформить точки приема платежей рекламноинформационными материалами.
3.1.12. Не компрометировать и не нарушать права Оператора на Товарные знаки
Оператора.
3.1.13. Своевременно информировать Оператора о наступлении, существовании,
изменении любых обстоятельств, имеющих значение для исполнения Договора.
3.1.14. Хранить первичные документы (контрольные чеки), подтверждающие Платежи, в
течение 6 (Шести) месяцев с даты совершения Платежа Плательщиком. По запросу Оператора
предоставлять необходимые документы в течение 3 (Трех) рабочих дней.
3.1.15. В случае прекращения (приостановки) полномочий Субагента по использованию
Системы «ФРИСБИ», Субагент обязан немедленно прекратить пользование Системой
«ФРИСБИ» и не допускать использование рекламных материалов.
3.1.16. Письменно направлять Оператору предложения о включении новых точек приема
платежей в Систему «ФРИСБИ».
3.1.17. В течение 3 (Трех) рабочих дней до фактического момента передислокации точки
приема платежей уведомлять Оператора об изменении его местонахождения.
3.1.18. Не привлекать в качестве платежных субагентов для осуществления приема
платежей от плательщиков третьих лиц в рамках Договора.
3.1.19. Самостоятельно обеспечить информационную поддержку Плательщиков в части
платежей принятых Субагентом. В случае обращения Плательщиков к Оператору с
обоснованной жалобой об отказе Субагента в рассмотрении его заявления и не принятия
последним каких-либо мер, Оператор за каждый установленный случай необеспечения
информационной поддержки Плательщика по вине Субагента вправе применить штрафные
санкции в размере 250 (Двести пятьдесят) рублей.
3.2. Субагент имеет право:
3.2.1. Отказать Плательщику в проведении платежа в случае возникновения технических
неполадок у Субагента, Оператора или Поставщика.
3.2.2. Взимать с Плательщика дополнительную плату за совершение действий, связанных
с Приемом платежей. Дополнительная плата полностью поступает в распоряжение Субагента
и не включается в расчеты для выплаты вознаграждения, при этом Субагент самостоятельно
несет ответственность за неуплату всех налогов и сборов с суммы вознаграждения,
поступившей в распоряжение Субагента.
3.2.3. Извещать Плательщиков о возможности совершения Платежей за услуги
Поставщиков в точках приема платежей, а также предоставлять Плательщикам информацию о
местонахождении точек приема платежей Субагента.
3.3. Оператор обязан:
3.3.1. Отказать Субагенту в проведении платежа Плательщика в случае возникновения
технических неполадок у Оператора или Поставщика.
3.3.2. Выплачивать Субагенту вознаграждение, в соответствии с п. 2.2. Договора.
3.3.3. Своевременно информировать Субагента о наступлении, существовании, изменении
любых обстоятельств, имеющих значение для исполнения Договора.
3.3.4. Предпринимать все возможные и необходимые действия в рамках своей
компетенции, включая регулярную проверку качества работы Системы «ФРИСБИ» для того,
чтобы обеспечить нормальное предоставление Субагенту возможности приема платежей,
кроме времени, затрачиваемого на профилактические и ремонтные работы.
3.4. Оператор имеет право:
3.4.1. Изменять в одностороннем порядке условия и порядок перечисления Платежей,
предусмотренный п. 3.1.10. Договора, уведомив об этом Субагента письменно или по адресу
электронной почты, указанному в п. 14.1. Договора, не менее чем за 5 (Пять) рабочих дней до
момента изменения порядка расчетов.
3.4.2. Отказать в оказании услуг по Договору в случаях, предусмотренных
законодательством РФ.
3.4.3. Проверять в любое время ход исполнения Субагентом обязательств, связанных с
Договором, не вмешиваясь в его хозяйственную деятельность.
3.4.4. Вносить изменения в условия Договора, направляя Субагенту соответствующие
предложения не менее чем за 4 (Четыре) рабочих дня до момента изменения условий по
Договору. Субагент обязуется либо принять изменение условий, либо до момента изменения
условий предоставить Оператору ответ об отказе принять изменения условий Договора. В
случае не предоставления ответа об отказе принять предложение, предложение об изменении
условий Договора считается акцептованным Субагентом. В случае несогласия Субагента с
изменениями в условиях Договора, стороны имеют право расторгнуть Договор в порядке,
установленном п. 10.4. Договора, произведя предварительно все расчеты.
3.4.5. В случае неисполнения (ненадлежащего исполнения) Субагентом какого-либо из
обязательств, предусмотренных Договором, Оператор вправе без предварительного
уведомления отключить/блокировать Субагента в Системе «ФРИСБИ» и в письменной форме
потребовать немедленного устранения нарушений, а также возмещения убытков. В случае
если требования об устранении нарушения не были выполнены Субагентом в течение 3 (Трех)
календарных дней, Оператор вправе отказаться от исполнения Договора в одностороннем
порядке.
3.4.6. В случае отсутствия запросов Субагента на сервер Системы «ФРИСБИ» на
исполнение денежных обязательств Плательщиков в соответствии с настоящим Договором в
течение трех рабочих дней, Договор считается расторгнутым Сторонами по истечении
третьего рабочего дня с момента последнего запроса. Договор не считается расторгнутым в
случае направления Оператору письменного уведомления Субагента о приостановлении
приема платежей.
4.ФИНАНСОВЫЕ УСЛОВИЯ И ПОРЯДОК РАСЧЕТОВ
4.1. После заключения Договора и регистрации в системе Субагент вносит Обеспечение
на расчетный счет Оператора, указанный в п. 14.2. Договора, при этом Субагент согласен с
тем, что:
 Доступ к работе точек приема платежей Субагента в системе «ФРИСБИ» становится
возможным только после поступления Обеспечения на расчетный счет Оператора.
 Расчет суммы Обеспечения производится исходя из прогнозируемого оборота по
принимаемым ежедневно Платежам, устанавливается Оператором в одностороннем
порядке в соответствии с Приложением № 2.
 На сумму денежных средств Обеспечения никакие проценты не начисляются и не
выплачиваются.
Сумма Обеспечения может быть самостоятельно увеличена Субагентом путем
перечисления соответствующей суммы на расчетный счет Оператора, указанный в п. 14.2., с
указанием в реквизитах платежа «Сумма Обеспечения по Договору № СА-____________
(ДПП) от «__» ___________2013 года. НДС не облагается».
Информация о пополнении Обеспечения Субагентом из расчетного банка Системы
«ФРИСБИ» предоставляется и становится доступной Субагенту в 09:30; 12:00; 15:00; 17:00
местного времени.
Субагент обязуется поддерживать остаток денежных средств на счете Оператора в
Системе «ФРИСБИ» (текущий счет Субагента в Системе «ФРИСБИ»), необходимый для
выполнения действий по приему Субагентом Платежей. Пополнение счета Субагента в
Системе «ФРИСБИ» производится после фактического получения средств Оператором. Учет
операций осуществляется в рамках календарной даты принятых Платежей (с 00 часов до 24
часов текущей даты).
4.2. Оператор обязуется, используя Систему «ФРИСБИ», осуществлять транзакции по
пополнению лицевых счетов Плательщиков в соответствии с договорами, заключенными с
Поставщиками услуг.
4.3. Внесение соответствующих изменений в лицевые счета Плательщиков
осуществляется Оператором в пределах остатка денежных средств Субагента в Системе
«ФРИСБИ» и на основании информации, переданной Субагентом Оператору, с
использованием Системы «ФРИСБИ».
4.4. Оператор ежедневно в режиме реального времени в одностороннем порядке
списывает с текущего счета Субагента в Системе «ФРИСБИ» суммы денежных средств в
объеме производимых Субагентом Платежей. Распоряжение о безакцептном списании
денежных средств считается предоставленным Субагентом Оператору в силу Договора.
4.5. В случае недостаточности денежных средств, необходимых для осуществления
Платежа, на текущем счете Субагента в Системе «ФРИСБИ», полученные Оператором данные
о Платежах считаются не принятыми, а информация, обеспечивающая внесение изменений в
лицевые счета Плательщиков, Поставщику не передается.
4.6. В течение 5 (Пяти) рабочих дней по окончании каждого календарного месяца
Стороны производят окончательную сверку проведенных операций. По результатам данной
сверки Субагент направляет в адрес Оператора Акт выполненных работ, подписанный
последним числом отчетного календарного месяца (Приложение № 3) и счет-фактуру на
сумму начисленного в течение месяца вознаграждения. Счет фактура и Акт выполненных
работ передается уполномоченному лицу Оператора не позднее 10 (Десятого) числа месяца,
следующего за отчетным по адресу: г. Екатеринбург, ул. Репина, 103. Надлежащим фактом
предоставления Субагентом указанных документов в срок является направление данной
документации заказным письмом с уведомлением либо курьером с отметкой о вручении
Оператору.
4.7. В случае если данные о Платежах, включенные в Акт о выполнении работ,
составленный Субагентом не совпадают с данными по Платежам Оператора, то Оператор
формирует и направляет Субагенту не позднее 5 (Пяти) рабочих дней со дня представления
Акта, протокол разногласий, в котором указаны количество Платежей и денежные суммы, с
которыми не согласен Оператор.
4.8. Субагент в срок не позднее 5 (Пяти) рабочих дней со дня получения от Оператора
протокола разногласий либо подписывает его, либо предоставляет Оператору полный и
мотивированный ответ по имеющимся расхождениям. В случае невозможности определить
причину расхождений, суммой обязательств Оператора перед Субагентом считается сумма
успешных Платежей, принятых и обработанных Оператором за отчетный месяц.
4.9. Вознаграждение Субагента за оказанные услуги по Договору начисляется Оператором
ежемесячно. Расчет осуществляется по итогам каждого месяца в течение 10 рабочих дней
после подписания Сторонами Акта о выполнении работ и оформления счета-фактуры.
Оператор перечисляет сумму вознаграждения Субагенту по реквизитам, указанным в п. 14.1.
Договора.
4.10. Размер вознаграждения Субагента по настоящему Договору может быть изменен
Оператором в одностороннем порядке, исходя из объема Платежей, принятых Субагентом за
предыдущий месяц, изменений условий выплаты вознаграждения Поставщиками, а также
иных факторов. Оператор вправе направить на адрес электронной почты ответственного
сотрудника Субагента информацию об изменении Вознаграждения, с последующим
направлением дополнительного соглашения к Договору. Изменение размера Вознаграждения
Субагента наступает с даты, указанной в письме, отправленном Оператором на электронную
почту Субагента. При смене ответственного сотрудника по Договору со стороны Субагента,
последний обязуется письменно уведомить Оператора.
4.11. Все расчеты по Договору производятся в валюте Российской Федерации.
4.12. Операции по приему платежей от Плательщиков осуществляются в пределах остатка
денежных средств на текущем счете Субагента в Системе «ФРИСБИ». При достижении
остатка значения Лимита, указанного в Приложении № 2, операции по приему Платежей от
Плательщиков в пользу Поставщиков приостанавливаются до момента пополнения текущего
счета Субагента в Системе «ФРИСБИ».
4.13. Субагент несет безусловную финансовую ответственность за принятые Платежи.
4.14. В тех случаях, когда при проведении расчетов требуется округление, оно
производится до большей суммы, согласно общим правилам.
5. РАЗМЕР ВОЗНАГРАЖДЕНИЯ
5.1. За оказанные услуги в соответствии с Договором Оператор уплачивает
вознаграждение Субагенту в размере, в порядке и сроки, предусмотренные Договором, в
соответствии с Приложением № 1.
5.2. Сумма вознаграждения исчисляется в процентах от суммы Платежей, принятых и
перечисленных Субагентом за отчетный период, и включает в себя НДС – 18%. Отчетным
периодом является календарный месяц. В случае изменения установленной действующим
законодательством ставки НДС, ставка вознаграждения изменяется соразмерно без
дополнительного согласования Сторонами. В случае если Субагент не является плательщиком
НДС – начисленная сумма вознаграждения уменьшается на сумму НДС.
6. РЕГИСТРАЦИЯ КЛИЕНТА В СИСТЕМЕ «ЕРЦ – Финансовая логистика»
6.1. Субагент передает Оператору Заявку на регистрацию в системе «ФРИСБИ» в
соответствии с Приложением № 4 на адрес электронной почты, указанный в п.14.2. Договора
или факсу: 8 (343) 287-10-03.
6.2. Оператор в течение 5 (Пяти) рабочих дней с момента получения заявки предоставляет
Субагенту возможность доступа к Системе «ФРИСБИ» для проведения платежей в
соответствии с Приложением № 5.
6.3. Субагент должен самостоятельно обеспечить сохранность информации о состоянии
его текущего счета в Системе «ФРИСБИ».
6.4. При возникновении необходимости блокирования/отключения в Системе «ФРИСБИ»
самого Субагента или точек приема платежей Субагента, Субагент передает Заявку на
блокирование по электронной почте, указанной в п. 14.2. Договора или факсу: 8 (343) 287-1003.
7. ОТВЕТСТВЕННОСТЬ СТОРОН
7.1. В случае нарушения обязательств, предусмотренных п. 3.1.10. Договора Субагент
выплачивает пени в размере 0,5% от суммы не перечисленных платежей за каждый день
просрочки.
7.2. За неисполнение или ненадлежащее исполнение обязательств по Договору Стороны
несут ответственность в соответствии с действующим законодательством РФ и условиями
Договора.
7.3. В случае нарушения одной из Сторон условий Договора, в результате которого другой
Стороне были причинены убытки, виновная Сторона возмещает их в полном объеме.
В случае предъявления Поставщиком, государственными и муниципальными органами
претензий (штрафных санкций, неустоек и т.п.) Оператору в связи с неисполнением
(ненадлежащим исполнением) Субагентом своих обязательств, Оператор вправе потребовать
от Субагента возмещения в размере понесенных расходов. Возмещение производится в
течение 5 (Пяти) рабочих дней с момента получения Субагентом письменного требования
Оператора с приложением подтверждающих такие расходы документов.
7.4. Оператор не несет ответственности по спорам и разногласиям, возникшим между
Субагентом и Плательщиками в отношении передачи Субагентом некорректной информации
о платежах, а также во всех случаях, когда подобные споры и разногласия не относятся к
предмету Договора.
7.5. Оператор не несет ответственности за прямые или косвенные убытки Субагента, в том
числе упущенную выгоду, понесенную сторонами по вине Оператора, включая временное
снижение качества связи и (или) отказ оборудования сети.
7.6. Стороны несут ответственность за действия своего персонала, связанные с
нарушением положений Договора и/или Приложений к нему, если они повлекли
неисполнение или ненадлежащее исполнение обязательств Сторон.
7.7. Любые штрафные санкции: пени, неустойки, штрафы и т.п. (далее - штрафные
санкции), за нарушение обязательств любой из Сторон по Договору, если таковые
предусмотрены Договором начисляются в соответствии с законодательством, могут быть
применены Сторонами только при условии предварительного письменного требования о
применении таких санкций, направленного Стороной, чьи права нарушены, Стороне,
нарушающей обязательства; возможность применения штрафных санкций является правом, но
не обязанностью той Стороны, чьи права нарушены.
7.8. Оператор не несет ответственность за денежные средства, принятые Субагентом от
Плательщика после расторжения настоящего Договора, в том числе согласно п. 3.4.6.
Договора.
7.9. В случае нарушения Субагентом требований п. 4.6. Договора, последний обязуется
оплатить штраф в размере 5 000 (Пять тысяч) рублей за каждый факт непредоставления
документов в течение 3 (Трех) рабочих дней с момента выставления счета Оператором.
8. ФОРС-МАЖОРНЫЕ ОБСТОЯТЕЛЬСТВА
8.1. Сторона освобождается от ответственности за частичное или полное неисполнение
обязательств по Договору, если это неисполнение явилось следствием обстоятельств
непреодолимой силы, возникших после заключения Договора в результате обстоятельств
чрезвычайного характера, которые Сторона не могла ни предвидеть, ни предотвратить
разумными мерами. К таким обстоятельствам относятся: телекоммуникационные сбои
всеобщего характера, наводнение, пожар, землетрясение и иные явления природы, а также
война, военные действия, акты или действия государственных органов и др.
8.2. При наступлении указанных в п. 8.1. обстоятельств, Сторона, исполнению
обязательств которой они препятствуют, должна не позднее 3 (Трех) рабочих дней известить о
них в письменном виде другую Сторону. Извещение должно содержать данные о характере
обстоятельств, что должно быть подтверждено компетентной государственной или иной
организацией, а также, по возможности, оценку их влияния на возможность исполнения
Стороной обязательств по Договору и срок исполнения обязательств.
8.3. В случае если обстоятельства, указанные в п. 8.1., продлятся более 30 (Тридцати)
календарных дней, Оператор имеет право расторгнуть Договор в одностороннем внесудебном
порядке, при этом Стороны должны провести взаиморасчеты по возникшим при исполнении
Договора финансовым обязательствам.
9. КОНФИДЕНЦИАЛЬНОСТЬ
9.1. Стороны заверяют, что обладают законными полномочиями заключить настоящий
Договор; лица, подписавшие настоящий Договор, имели все права совершить указанные
действия.
9.2. Стороны принимают на себя обязательства не разглашать полученные в ходе
исполнения Договора сведения, являющиеся конфиденциальными для каждой из Сторон. Под
конфиденциальной информацией в Договоре понимаются не являющиеся общедоступными
сведения, разглашение которых может привести к возникновению убытков и/или повлиять на
деловую репутацию любой из Сторон, в том числе:
- информация о Плательщиках, Платежах, остатках на счетах, объемах операций;
- информация о тарифной политике Сторон.
9.3. Стороны обязуются не разглашать указанную в п. 9.2. Договора информацию третьим
лицам, за исключением согласованного предоставления конфиденциальной информации
третьим лицам в целях исполнения Договора и иных соглашений между Оператором и
Субагентом.
9.4. Информация, указанная в п. 9.2, может быть выдана только в порядке, установленном
законодательством Российской Федерации.
9.5. В случае прекращения действия Договора, Стороны обязуются также не разглашать и
не использовать в своих интересах и/или интересах третьих лиц информацию, указанную в п.
9.2 Договора.
9.6. Оператор не несет ответственности в случае несанкционированного доступа к
информации о текущем счете Субагента в Системе «ФРИСБИ» со стороны третьих лиц,
возникшие по вине Субагента.
10. ВСТУПЛЕНИЕ В СИЛУ, СРОК ДЕЙСТВИЯ И ПОРЯДОК РАСТОРЖЕНИЯ
ДОГОВОРА
10.1. Договор считается заключенным с момента его подписания и действует до 31
декабря 2013 года.
10.2. Договор считается пролонгированным на каждый последующий год, если не менее
чем за 30 (Тридцать) дней до окончания срока действия Договора ни одна из Сторон
письменно не уведомила другую Сторону о своем желании прекратить действие Договора.
10.3. Стороны выполняют свои обязательства в полном объеме до момента прекращения
действия Договора.
10.4. Стороны имеют право в одностороннем внесудебном порядке расторгнуть Договор,
письменно уведомив об этом другую Сторону за 30 (тридцать) дней до предполагаемой даты
расторжения Договора, произведя при этом все взаиморасчеты по возникшим при исполнении
договора финансовым обязательствам.
10.5. Стороны имеют право расторгнуть Договор в одностороннем порядке и по другим
основаниям, предусмотренным настоящим Договором.
10.6. С даты расторжения данного Договора прекращаются полномочия Субагента по
использованию Системы «ФРИСБИ».
10.7. Денежные обязательства Сторон, а также обязательства, определяющие
ответственность Сторон за нарушение Договора, сохраняются до момента их полного
исполнения и не зависят от окончания срока действия Договора.
11. ВОЗВРАТ ДЕНЕЖНЫХ СРЕДСТВ
11.1. По Договору возможен полный или частичный возврат Обеспечения как в связи с
расторжением Договора, так и без расторжения Договора.
11.2. Возврат Обеспечения по Договору осуществляется в течение 10 (Десяти) рабочих
дней с момента получения Заявления от Субагента, или с момента расторжения Договора, в
соответствии с реквизитами, указанными в п. 14.1. Договора.
11.3. Если Обеспечения на счете Субагента недостаточно для покрытия издержек,
связанных с перечислением средств, и финансовых обязательств Субагента по Договору,
Оператор отказывает Субагенту в проведении операции по возврату Обеспечения.
11.4. Порядок работы с проблемными платежами и случаи возврата денежных средств по
заявлению Плательщика устанавливаются Приложением № 6 к настоящему Договору.
12. ПРОЧИЕ УСЛОВИЯ
12.1. В случае изменений условий сотрудничества, отношения между Сторонами
регулируются Договором с учетом дополнений и изменений, вносимых в Договор.
Все изменения и дополнения к настоящему Договору совершаются по взаимному
согласию Сторон и оформляются посредством дополнительных соглашений, подписываемых
Сторонами.
12.1.1. В случае появления нового Поставщика услуг в Системе «ФРИСБИ», Оператор
направляет соответствующую информацию с уведомлением о возможности приема платежей
в пользу Поставщика услуг по электронной почте ____________________ ответственному
сотруднику Субагента __________________________с последующим направлением
дополнительного соглашения к Договору.
12.2. Все споры и разногласия, возникающие при выполнении условий Договора,
решаются сторонами путем переговоров. В случае не достижения согласия, возникший спор
подлежит разрешению в Арбитражном суде Свердловской области.
12.3. Все документы, на которые ссылается Договор, а также документы, составленные в
связи с его исполнением, являются его неотъемлемой частью.
12.4. Во всем, что прямо не предусмотрено Договором, Стороны руководствуются
законодательством РФ и обычаями делового оборота.
12.5. Если какое-либо положение Договора становится недействительным, это не влияет
на действительность остальных его положений.
12.6. Невыполнение любой Стороной одного из своих обязательств по Договору не
означает отказа от выполнения других обязательств и прав по Договору.
12.7. Договор составлен в 2 (Двух) экземплярах, по одному экземпляру для каждой из
Сторон. Оба экземпляра идентичны и имеют равную юридическую силу.
13. ПРИЛОЖЕНИЯ
13.1. К Договору прилагаются следующие Приложения, которые являются неотъемлемой
частью Договора:
13.1.1. Приложение №1 «Тарифы вознаграждения, выплачиваемые Оператором
Субагенту и условия передачи извещений Оператору»;
13.1.2. Приложение №2 «Размер Обеспечения и установленный Лимит»;
13.1.3. Приложение №3 «Акт выполненных работ»;
13.1.4. Приложение №4 «Форма заявки на регистрацию Субагента в Системе «ФРИСБИ»
13.1.5. Приложение №5 «Протокол обмена данными».
13.1.6. Приложение № 6 «Порядок работы с проблемными платежами».
Приложение №1
к Договору № СА-_______________ (ДПП) от «___» ____________ 2013 года
Тарифы вознаграждения, выплачиваемые Оператором Субагенту и условия передачи
извещений Оператору
№
п/п
Наименование Поставщика услуг
Взимание
дополнительного
вознаграждения,
уплачиваемого
Плательщиком
Субагенту
Вознаграждение
Субагента, без НДС,
%
Прочие условия
ЖКУ, в том числе г. Екатеринбург
Электроэнергия, в том числе:
Телефонная связь, в том числе:
Мобильная связь, в том числе:
Кабельное телевидение, в том числе:
Интернет, в том числе:
Прочие Поставщики, в том числе:
Оператор
Субагент
_________________/Зайков А.Ю./
_____________/
/
Приложение № 2
к Договору № СА-_______________ (ДПП) от «___» ____________ 2013 года
Размер Обеспечения и установленный Лимит.
1. Размер Обеспечения Субагента на момент подписания договора составляет 100 000
(сто тысяч) рублей (НДС не предусмотрен).
2. Стоимость лицензии для подключения одного рабочего места составляет 2 500 руб.
(НДС не облагается). При расторжении Договора по инициативе Субагента стоимость
лицензии не подлежит возврату.
3. В Системе «ФРИСБИ» установлен Лимит в размере 20 000 (двадцать тысяч) рублей.
Оператор
Субагент
_________________/Зайков А.Ю./
_____________/
/
Приложение № 3
к Договору № СА-_______________ (ДПП) от «___» ____________ 2013 года
Акт выполненных работ
г.Екатеринбург
«____»____________2013 г.
ООО «ЕРЦ – Финансовая логистика», именуемое в дальнейшем «Оператор», в лице Директора
Зайкова Алексея Юрьевича, действующего на основании Устава, с одной стороны, и
_________________________________________, именуемое в дальнейшем «Субагент», в лице
_________________________________________,
действующего
на
основании
_______________________________________, с
другой
стороны,
далее
именуемые
«Стороны», составили настоящий акт о нижеследующем: согласно условиям Договора об
осуществлении деятельности по приему платежей № ____________ от «____» _________ 2013
г., за период с «____» __________ 2013 года по «____» ___________2013 года сумма
Вознаграждения Субагента составила:
Задолжен
Задолжен
ность
Сумма
ность
Сумма
Оператор
перечисле
Оператор
Вознаграждение
принятых
Наименование
а перед
нных
а перед
Субагента
№
Субагент
Поставщика
Субагент
Субагент
Субагент
п/п
ом
услуг
ом на
ом
ом на
платежей,
начало
платежей,
конец
руб.
отчетного
руб.
отчетного
%
руб.
периода
периода
1
2
Итого:
Итого к оплате: ________________________________________(в т.ч.
________________________________________________________________
НДС/без
НДС)
Претензий к качеству оказанных услуг нет.
Настоящий Акт выполненных работ составлен в двух экземплярах, имеющих одинаковую
юридическую силу, по одному для каждой стороны.
Оператор
Субагент
_________________/Зайков А.Ю./
_____________/
/
Приложение № 4
к Договору № СА-_______________ (ДПП) от «___» ____________ 2013 года
Форма заявки на регистрацию Субагента в Системе «ФРИСБИ»
г. Екатеринбург
«____»
2013 года
Для регистрации в Системе «ФРИСБИ» Субагенту необходимо предоставить следующую
информацию:
1.
2.
3.
4.
5.
№
п/п
Наименование Организации;
Дата и номер договора;
Контактное лицо – Ф.И.О., номер мобильного телефона, электронная почта;
Номер мобильного телефона для SMS-уведомлений;
Сведения о точке приема платежей:
Наименование
торгового
объекта
Адрес точки
приема платежей
Технические характеристики точки
приема платежей*
1.
2.
*Необходимо указать:
1.
2.
3.
4.
5.
6.
Персональный Компьютер (объём ОЗУ и ЖД, частота работы процессора);
Способ подключения к сети Интернет;
Фискальный регистратор – марка, версия, интерфейс;
Купюроприёмник – марка, протокол, интерфейс;
Сканер штрихкода – марка, интерфейс;
Картридер – марка, интерфейс.
Прошу осуществить регистрацию точки (ек) приема платежей в Системе «ФРИСБИ»
Субагент
М.П.
__________/
/
Приложение № 5
к Договору № СА-_______________ (ДПП) от «___» ____________ 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" />
Приложение № 6
к Договору № СА-_______________ (ДПП) от «___» ____________ 2013 года
Порядок работы с проблемными платежами
В настоящем Приложении определяется порядок работы с проблемными платежами,
принятыми Субагентом в рамках Договора. При работе с платежами отдельных
Поставщиков Сторонами может устанавливаться иной порядок, отличный от изложенного
в настоящем Приложении.
Под проблемным платежом Стороны понимают платеж с неверно указанными
Плательщиком реквизитами (в т. ч. Лицевой счет Плательщика, Поставщик и т.п.).
2. Общие условия проведения корректировок проблемных платежей:
- согласие Поставщика на внесение изменений в Лицевой счет Плательщика;
- волеизъявление Плательщика.
3. В случае обращения Плательщика в службу поддержки Субагента в связи с проблемным
1.
платежом служба поддержки Субагента устанавливает:
- факт внесения Платежа;
- факт передачи информации о Платеже Оператору в соответствии с Договором;
- возможность корректировки реквизитов проблемного платежа без возврата денежных
средств.
3.1. Если Договором и настоящим Приложением допускается корректировка реквизитов
такого Платежа без возврата денежных средств, служба поддержки Субагента, на
основании обращения Плательщика, осуществляет соответствующую корректировку с
использованием Системы «ФРИСБИ».
4. Случаи невозможности проведения корректировок реквизитов проблемных платежей в
общем порядке устанавливаются Сторонами.
Оператор
Субагент
_________________/Зайков А.Ю./
___________/
/
14. РЕКВИЗИТЫ И ПОДПИСИ СТОРОН
14.1. Субагент:
Почтовый адрес:
Юридический адрес:
ИНН
, КПП _________________
ОГРН __________________
р/с _____________________________
к/сч ____________________ БИК _________________
Адрес электронной почты: _______________________
Тел. __________________________________________
14.2. Оператор:
ООО «ЕРЦ – Финансовая логистика»
Почтовый адрес: 620043, г. Екатеринбург, ул. Репина,103
Юридический адрес: 620043, г. Екатеринбург, ул. Репина, 103
ИНН 6658376074, КПП 665801001
ОГРН 1116658001074
спец/с 40821810300260003152 в филиале «Газпромбанк» (ОАО) в г. Екатеринбурге
к/сч 30101810800000000945 БИК 046568945
Адрес электронной почты: money@erc.ur.ru
Тел. (343) 287-10-06, факс (343) 287-10-03
Оператор
Субагент
_______________/Зайков А.Ю./
____________/
/