close

Вход

Забыли?

вход по аккаунту

код для вставкиСкачать
выплаты on-line лайт
Приложение №2
к протоколу заседания Правления
ООО НКО «Яндекс.Деньги» №63
от «03» июня 2014 г.
УТВЕРЖДЕНО
решением Правления
ООО НКО «Яндекс.Деньги»
Протокол №63 от «03» июня 2014 г.
Вводится в действие с 4 июня 2014 г.
Председатель Правления
________________ / Т.А. Шабанова/
Договор
об информационно-технологическом взаимодействии
при перечислении денежных средств в пользу физических лиц
№_________
г. Москва
«____» _____________ 201__ г.
Общество с ограниченной ответственностью небанковская кредитная организация «Яндекс.Деньги»,
именуемое в дальнейшем «Оператор», в лице Председателя Правления Шабановой Т.А., действующей на
основании Устава, с одной стороны, и
__________________ ______________________________, именуем___ в дальнейшем «Контрагент», в
лице
_________
____________________________________,
действующ__
на
основании
______________________, с другой стороны, совместно именуемые «Стороны», заключили настоящий
договор о нижеследующем:
1. Предмет договора
1.1. Оператор обязуется за вознаграждение оказывать Контрагенту информационные и
технологические услуги, в том числе по сбору, обработке и передаче информации о совершаемых
Оператором по поручению и за счет Контрагента зачислениях денежных средств на обслуживаемые
Оператором, действующим в качестве оператора платежного сервиса «Яндекс.Деньги», электронные
средства платежа клиентов Оператора – физических лиц (далее – зачисления).
1.2. Обязательства Контрагента перед физическими лицами, во исполнение которых совершаются
зачисления, возникают в порядке и по основаниям, установленным законом и (или) договором физического
лица с Контрагентом. Отношения, из которых возникают указанные обязательства, не входят в предмет
регулирования настоящего Договора и не порождают для Оператора каких бы то ни было обязанностей.
1.3. Вид, порядок применения и правовые последствия использования Сторонами аналога
собственноручной подписи при исполнении настоящего Договора определены Приложением № 1 к
настоящему договору.
2. Порядок взаимодействия при заключении договора
2.1. В течение десяти рабочих дней с даты подписания настоящего Договора Стороны согласовывают
перечень данных, подлежащих сообщению Контрагентом Оператору при направлении последнему
уведомлений о зачислениях денежных средств на электронные средства платежа клиентов Оператора.
3. Права и обязанности Сторон
3.1. Оператор обязуется:
выплаты on-line лайт
3.1.1. Подключить Контрагента к программно-аппаратному комплексу Оператора для оказания
Контрагенту информационных и технологических услуг, в том числе по сбору, обработке и передаче
Контрагенту информации о совершенных зачислениях.
3.1.2. Совершать зачисления в соответствии с Приложением № 2 в режиме реального времени.
3.1.3. Формировать реестры переводов за каждые сутки (за период с 00 часов 00 минут 00 секунд по
23 часа 59 минут 59 секунд по московскому времени) в соответствии с требованиями, установленными
Приложением №4 к настоящему Договору, и направлять сформированные реестры, подписанные аналогом
собственноручной подписи Оператора, Контрагенту по электронной почте на адрес (вcтавить e-mail) до 11
часов 59 минут 59 секунд по московскому времени календарного дня, следующего за днем, за который
составлен реестр.
3.2. Оператор имеет право:
3.2.1. Приостанавливать информационно-технологическое обслуживание Контрагента:
- в случае возникновения обстоятельств, не зависящих от Сторон и могущих, по мнению Оператора,
повлечь значительные убытки для Оператора - на срок действия таких обстоятельств;
- в случае нарушения Контрагентом любого из своих обязательств, предусмотренных настоящим
Договором - до полного устранения Контрагентом допущенного нарушения.
О приостановлении информационно-технологического обслуживания Оператор не позднее даты
такого приостановления направляет Контрагенту письменное уведомление с указанием причины и срока
приостановления.
В случаях, предусмотренных настоящим пунктом, Оператор в установленном настоящим договором
порядке совершает зачисления, перечисленные в реестрах зачислений, полученных Оператором до момента
приостановления.
3.2.2. Требовать у Контрагента предоставления информации об обязательствах, указанных в пункте
1.2. настоящего Договора, в случае, если необходимость такой информации вызвана соблюдениями
требований законодательства о противодействии легализации (отмыванию) доходов, полученных
преступным путем, и финансированию терроризма.
3.2.3. Отказывать в совершении зачислений, если исполнение соответствующего поручения
Контрагента повлечет нарушение требований законодательства Российской Федерации, нормативных актов
Банка России или условий договора, заключенного Оператором с соответствующим физическим лицом.
3.3. Контрагент обязуется:
3.3.1. Предоставить Оператору сумму обеспечения в размере, самостоятельно определяемом
Контрагентом. Сумма обеспечения ограничивает сумму зачислений, информация о которых передается
Оператору в соответствии с Приложением №1.
3.3.2. В случае несогласия с содержанием реестра, полученного от Оператора в соответствии с п.
3.1.3. настоящего Договора, сообщать Оператору о таком несогласии не позднее 11 часов 59 минут 59
секунд по московскому времени календарного дня, следующего за днем получения от Оператора
оспариваемого реестра, по электронной почте на адрес ______________ с указанием мотивов несогласия. В
случае непоступления от Контрагента замечаний и/или пропуска Контрагентом предусмотренного
настоящим подпунктом срока информация, содержащаяся в реестре, считается подтвержденной без
замечаний.
3.3.3. Самостоятельно разрешать с физическими лицами – получателями зачислений и налоговыми
органами вопросы, связанные с оплатой налогов, подлежащих начислению и уплате на суммы зачислений.
3.3.4. Самостоятельно нести все риски, связанные с последствиями указания в реестре зачислений
неверных сведений, в том числе о получателе и сумме зачисления.
3.3.5. В трехдневный срок извещать Оператора в письменном виде о любых изменениях, могущих
повлиять на исполнение Сторонами настоящего Договора, в том числе: изменениях своего наименования,
места нахождения, фактического адреса, банковских реквизитов и т.п.
4. Вознаграждение Оператора и порядок расчетов
4.1.
Для обеспечения исполнения обязательств по настоящему Договору Контрагентом в
течение 5 (пяти) банковских дней со дня подписания Акта о подключении перечисляется Оператору сумма
обеспечения в размере, определяемом Контрагентом. В дальнейшем Контрагент при наличии такой
выплаты on-line лайт
необходимости зачисляет сумму обеспечения по своему усмотрению. Сумма обеспечения ограничивает
общую сумму зачислений.
4.1.1. Перечисление суммы обеспечения осуществляется платежным поручением на банковские
реквизиты Оператора, указанные в п.9 настоящего Договора, со следующей формулировкой назначения
платежа: «Сумма обеспечения по договору №номер и дата настоящего договора. Без НДС».
4.2.
Перечисление Оператору сумм зачислений, информация о которых направлена в
соответствии с Приложением № 3, осуществляется ежедневно.
4.2.1.
Подлежащая перечислению сумма определяется на основании Реестра за предшествующий
день, направленного Оператором в соответствии с п. 3.1.3. настоящего Договора.
4.2.2.
поручением.
Суммы денежных средств по каждому реестру перечисляются отдельным платежным
4.3. Вознаграждение Оператора составляет ____% от общей суммы каждого зачисления,
совершенного Оператором в течение отчетного календарного месяца.
Вознаграждение Оператора не облагается НДС в соответствии с подпунктом 4 пункта 3 статьи 149
НК РФ.
Вознаграждение Оператора удерживается из суммы обеспечения. В случае недостаточности суммы
обеспечения для удержания вознаграждения в полном объеме Контрагент перечисляет Оператору
недостающую сумму в течение трех банковских дней с даты получения соответствующего требования
Оператора, направленного по адресу электронной почты Контрагента, указанному в п. 8.4. настоящего
Договора.4.4. До пятого числа месяца, следующего за отчетным Оператор отправляет по электронной почте
на адрес Контрагента адрес электронной почты Акт об оказанных услугах по утвержденной форме
(Приложение № 4 к настоящему Договору).
4.5. В течение пяти календарных дней с даты получения Акта об оказанных услугах Контрагент
обязан его утвердить и направить Оператору по электронной почте на адрес ______, либо в том же порядке
направить свои возражения.
В течение трех рабочих дней с даты получения от Контрагента согласованного Акта об оказанных
услугах Оператор подписывает и отправляет Контрагенту два экземпляра согласованного Акта.
В течение трех рабочих дней с момента получения от Оператора подписанного Акта об оказанных
услугах на бумажном носителе Контрагент обязан отправить Оператору один экземпляр подписанного со
своей стороны Акта об оказанных услугах.
Если в указанный срок Контрагентом не был отправлен подписанный Акт об оказанных услугах либо
письменный мотивированный отказ Контрагента от его подписания, соответствующие услуги Оператора
считаются оказанными в полном объёме и надлежащим образом.
5. Ответственность Сторон и порядок разрешения споров
5.1. Оператор не несет ответственности перед физическими лицами за исполнение Контрагентом
своих обязательств перед ними.
5.2. Любые споры и разногласия Сторон по настоящему Договору или в связи с ним, которые не были
урегулированы путем переговоров Сторон, подлежат разрешению в Арбитражном суде г. Москвы.
6. Конфиденциальность
6.1. Факт заключения настоящего Договора не рассматривается Сторонами как конфиденциальная
информация.
6.2. Стороны обязуются не разглашать информацию:
- об условиях настоящего Договора,
- о количестве и сумме зачислений, информация о которых передана Контрагенту;
- прочую информацию, полученную Сторонами в ходе выполнения своих обязательств по
настоящему Договору, за исключением случаев, когда Сторона обязана предоставить такую информацию в
соответствии с законодательством РФ.
выплаты on-line лайт
7. Срок действия и порядок прекращения договора
7.1. Настоящий Договор действует в течение двенадцати календарных месяцев с даты его
подписания.
7.2. Срок действия настоящего Договора автоматически продлевается на двенадцать календарных
месяцев в случае, если ни одна из Сторон не уведомляет другую Сторону в письменной форме на бумажном
носителе о своем нежелании продлевать срок действия настоящего Договора не менее чем за тридцать
календарных дней до истечения срока (в том числе очередного) его действия. Такое уведомление не
рассматривается Сторонами как односторонний отказ от исполнения настоящего Договора.
Срок действия настоящего Договора может быть продлен в соответствии с настоящим пунктом
неограниченное количество раз.
7.3. Любая из Сторон вправе в одностороннем порядке отказаться от дальнейшего исполнения
настоящего Договора. Для этих целей она в письменной форме уведомляет другую сторону о своем
намерении не позднее, чем за 30 (тридцать) календарных дней до предполагаемой даты отказа от
исполнения. Уведомление должно быть сделано в письменной форме на бумажном носителе и содержать
указание на причину расторжения Договора.
7.4. Обязательства Сторон по настоящему Договору, возникшие до его прекращения, сохраняются
вплоть до их полного исполнения.
8. Прочие условия
8.1. Настоящий Договор составлен в двух экземплярах, имеющих равную юридическую силу, по
одному для каждой Стороны.
8.2. Все приложения к настоящему Договору являются его неотъемлемыми частями.
Приложения на момент заключения настоящего Договора:
Приложение №1: Соглашение об использовании документов в электронной форме.
Приложение №2: Порядок онлайн взаимодействия
Приложение №3: Формат реестра зачислений.
Приложение №4: Форма Акта об оказанных услугах.
8.3. Ни одна из Сторон не вправе передать свои права и обязанности по настоящему Договору
третьим лицам без письменного на то согласия другой стороны.
8.4. Стороны согласовывают, что лицами, ответственными за исполнение настоящего Договора, на
момент его подписания являются:
ОТ Контрагента
ОТ ОПЕРАТОРА
По общим вопросам, связанным с исполнением договора
Должность, ФИО
Телефон:
e-mail:
Отдел электронной коммерции
Должность, ФИО
Телефон:
e-mail:
По финансовым вопросам
Должность, ФИО
Телефон:
Бухгалтерия
e-mail:
Служба поддержки
e-mail:
e-mail:
По техническим вопросам
Должность, ФИО
Телефон:
e-mail:
выплаты on-line лайт
По вопросам обмена документами
Должность, ФИО
Телефон:
Отдел делопроизводства
e-mail:
[email protected]
Стороны вправе в одностороннем порядке изменить указанный перечень ответственных лиц,
направив другой Стороне соответствующее письменное уведомление. Уведомление должно быть подписано
уполномоченным лицом и передано по электронной почте или факсу.
9. Реквизиты и подписи сторон
Приложение №1
К договору об информационно-технологическом взаимодействии
при перечислении денежных средств в пользу физических лиц
№_________ от_____
СОГЛАШЕНИЕ ОБ ЭЛЕКТРОННОМ ДОКУМЕНТООБОРОТЕ
Общество с ограниченной ответственностью небанковская кредитная организация «Яндекс.Деньги»,
именуемое в дальнейшем «Оператор», в лице Председателя Правления Шабановой Т.А., действующей на
основании Устава, с одной стороны, и
__________________ ______________________________, именуем___ в дальнейшем «Контрагент», в лице
_________ ____________________________________, действующ__ на основании ______________________,
с другой стороны, совместно именуемые «Стороны»,
заключили настоящее Соглашение об электронном документообороте (далее как «Соглашение») о
нижеследующем:
1.
Соответствие данного Соглашения законодательным нормам
1.1. Данное соглашение разработано в соответствии с требованиями Федеральных законов № 63-ФЗ
«Об электронной подписи» от 06.04.2011 и № 149-ФЗ «Об информации, информационных
технологиях и о защите информации» от 27.07.2006.
1.2. Термины и понятия данного Соглашения также соотнесены с международной практикой и
стандартами применения электронной подписи, в частности со стандартом PKI (инфраструктуры
открытых ключей) X.509. Порядок работы PKI описан в RFC 1422, а формат сертификатов X.509 в
RFC 5280.
2.
Термины, применяемые в настоящем Соглашении
2.1. Электронный документооборот – система работы с электронными документами, при которой все
электронные документы создаются, передаются и хранятся с помощью информационнокоммуникационных технологий на компьютерах, объединенных в сетевую структуру.
выплаты on-line лайт
2.2. Электронный документ (далее также - ЭД) – документированная информация, представленная в
электронной форме, то есть в виде, пригодном для восприятия человеком с использованием
электронных вычислительных машин, а также для передачи по информационнотелекоммуникационным сетям или обработки в информационных системах.
2.3. Электронная подпись (далее также - ЭП) – информация в электронной форме, которая
присоединена к другой информации в электронной форме (подписываемой информации) или иным
образом связана с такой информацией и которая используется для определения лица,
подписывающего информацию (электронный документ). Бывает простая и усиленная электронная
подпись.
2.4. Усиленная неквалифицированная электронная подпись (далее также - НЭП) – вид усиленной
ЭП, которая: получена в результате криптографического преобразования информации с
использованием ключа электронной подписи; позволяет определить лицо, подписавшее ЭД;
позволяет обнаружить факт внесения изменений в ЭД после момента его подписания; создается с
использованием средств ЭП.
2.5. Подписанный электронный документ (далее также - ПЭД) – электронный документ с
присоединённой электронной подписью, которая была создана на основе ЭД и ключа электронной
подписи.
2.6. Сертификат ключа проверки электронной подписи (далее также - Сертификат) – электронный
документ или документ на бумажном носителе, выданные удостоверяющим центром либо
доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки
электронной подписи владельцу сертификата ключа проверки электронной подписи. Также
называется сертификатом открытого ключа. Сертификат содержит серийный номер, сведения о
владельце, используемых криптографических алгоритмах, ограничениях на использование, ключ
проверки ЭП и другую информацию. Сертификат имеет свою ЭП, созданную удостоверяющим
центром.
2.7. Владелец сертификата ключа проверки электронной подписи (далее также – владелец
Сертификата) – лицо, которому выдан сертификат ключа проверки электронной подписи. Данные
о владельце должны содержаться в сертификате.
2.8. Ключ электронной подписи – уникальная последовательность символов, предназначенная для
создания ЭП. Также называется закрытым ключом.
2.9. Ключ проверки электронной подписи – уникальная последовательность символов, однозначно
связанная с ключом электронной подписи и предназначенная для проверки подлинности ЭП (далее
- проверка ЭП). Также называется открытым ключом. Значение ключа проверки электронной
подписи содержится в сертификате.
2.10. Удостоверяющий центр (далее также - УЦ) – юридическое лицо или индивидуальный
предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей
проверки электронных подписей, а также иные функции, предусмотренные Федеральным законом
№ 63-ФЗ «Об электронной подписи».
2.11. Средства электронной подписи (далее также – средства ЭП) – шифровальные
(криптографические) средства, используемые для реализации хотя бы одной из следующих
функций – создание ЭП, проверка ЭП, создание ключа электронной подписи и ключа проверки
электронной подписи.
2.12. Средства удостоверяющего центра – программные и (или) аппаратные средства, используемые
для реализации функций удостоверяющего центра.
2.13. Средства шифрования – аппаратные, программные, программно-аппаратные шифровальные
(криптографические) средства, реализующие алгоритмы криптографического преобразования
информации для ограничения доступа к ней, в том числе при её хранении, обработке и передаче.
2.14. Корневой сертификат УЦ – сертификат, который был выдан удостоверяющим центром для
самого себя и является самоподписанным. Все остальные сертификаты, выдаваемые данным УЦ,
подписываются ключом ЭП этого корневого сертификата. В понятии инфраструктуры открытых
ключей: если есть доверие к корневому сертификату УЦ, то автоматически есть доверие ко всем
сертификатам, выданным данным УЦ и подписанным ключом ЭП данного корневого сертификата.
Обычно в УЦ есть только один корневой сертификат.
2.15. Промежуточный сертификат УЦ – сертификат, ключ ЭП которого использовался для подписи
другого сертификата, а сам сертификат был подписан ключом ЭП корневого сертификата УЦ или
выплаты on-line лайт
другого промежуточного сертификата этого УЦ. Промежуточные сертификаты позволяют строить
широкую иерархическую структуру сертификатов УЦ.
2.16. Самоподписанный сертификат – сертификат, который подписан ключом ЭП, соответствующим
ключу проверки ЭП из этого сертификата. В полях издателя сертификата содержатся те же данные,
что и в полях владельца сертификата.
2.17. Создание ЭП – результат работы средства ЭП при создании ЭП, в результате которого получается
последовательность бит данных фиксированной длины после криптографического преобразования
электронного документа в хеш, и шифрования хеша ключом электронной подписи. Длина,
названия алгоритмов хеширования и шифрования задаются в Сертификате.
2.18. Подтверждение подлинности ЭП в ПЭД – положительный результат работы средства ЭП при
проверке ЭП. Результат работы считается положительным, если после расшифрования ЭП с
помощью ключа проверки ЭП по заданному в Сертификате криптографическому алгоритму,
получается значение равное хешу электронного документа, полученному по заданному в
Сертификате соответствующему криптографическому алгоритму.
2.19. Хэш – результат работы хеширующей функции, которая преобразовывает входной массив данных
произвольной длины в выходную битовую строку фиксированной длины.
2.20. Участники электронного документооборота – лица, осуществляющие обмен информацией в
электронной форме в рамках данного Соглашения.
2.21. Компрометация ключа ЭП — нарушение конфиденциальности ключа ЭП, при котором значение
закрытого ключа стало известно лицу, не являющемуся владельцем Сертификата.
2.22. Основной договор — Договор об информационно-технологическом взаимодействии при
осуществлении переводов физических лиц без открытия счета №________________ от «__»
________ 2014г.
2.23. Система – комплекс программно-аппаратных средств, позволяющий осуществлять электронный
документооборот между Оператором и Контрагентом в рамках настоящего Соглашения. Система
включает в себя средства ЭП и обеспечивает подготовку ЭД, генерацию ЭП, прием, передачу и
обработку ПЭД с использованием средств вычислительной техники каждой из сторон. Передача
данных в Системе происходит по сети Интернет.
2.24. Список отозванных сертификатов (далее также - СОС) – список, содержащий серийные номера
сертификатов, которые были отозваны выдавшим их УЦ и к которым больше нет доверия.
Сертификаты добавляются в СОС после извещения о компрометации ключа ЭП.
2.25. Экспертная комиссия – комиссия, создаваемая сторонами для разрешения разногласий,
возникающих при обмене ПЭД.
3.
Предмет Соглашения
3.1. Настоящее Соглашение устанавливает порядок организации и проведения электронного
документооборота между сторонами во исполнение Основного договора.
3.2. Электронные документы, которые передаются по данному Соглашению, должны быть подписаны
усиленной неквалифицированной электронной подписью и зашифрованы (или переданы по
защищённому каналу). Далее в качестве ЭП подразумевается НЭП.
3.3. Перечень электронных документов, которые подлежат оформлению, защите, приему, передаче и
обработке Сторонами:

ежесуточный реестр, формируемый Оператором в соответствии с п. 3.1.2, 3.1.3
Основного договора;
 уведомления о платежах, если в них используется ЭП;
 другие электронные документы, согласованные сторонами в процессе тестирования.
3.4. Обмен иными ЭД в Системе не является основанием возникновения обязательств сторон по
Основному договору и Соглашению. Стороны признают юридическую силу ПЭД, подписанных
НЭП (при подтверждении подлинности ЭП в ПЭД), равной юридической силе документов на
бумажном носителе, оформленных в соответствии с требованиями законодательства Российской
Федерации и условиями Соглашения и Основного договора, и подписанных уполномоченными
представителями сторон, с приложением оттисков печатей сторон.
выплаты on-line лайт
3.5. ПЭД порождает обязательства сторон, установленные Соглашением и Основным договором, если
передающей стороной он должным образом оформлен, подписан НЭП, а принимающей стороной
получен, проверен и принят к обработке в установленном Соглашением порядке.
3.6. Данное соглашение распространяется только на обеспечение защиты конфиденциальности и
целостности информации в ПЭД при передаче по открытым каналам связи. Остальные требования
по защите информации выполняются сторонами самостоятельно на основании требований
действующего законодательства и требований внутренних нормативных документов сторон.
3.7. Передача ПЭД осуществляется через Систему между сторонами путем передачи данных через сеть
Интернет.
3.8. Подключение сторон к сети Интернет выполняется самостоятельно и не является предметом
Соглашения.
3.9. Данное соглашение распространяется только на обеспечение защиты информации при передаче по
открытым каналам связи (Интернет), остальные требования по защите информации выполняются
сторонами самостоятельно на основании требований действующего законодательства и/или
требований внутренних документов Сторон.
4.
Общие принципы электронного документооборота
4.1. Каждая из Сторон, при подписании ЭД, применяет свой ключ ЭП, а при проверке подписи ключ
проверки ЭП, записанный в сертификате ключа проверки ЭП, другой стороны.
4.2. Стороны обмениваются сертификатами, которые будут использоваться для создания ЭП.
4.3. Для электронного документооборота стороны могут использовать самоподписанные сертификаты
и сертификаты, подписанные другим ключом ЭП.
4.4. Если для документооборота используется несамоподписанный сертификат, выданный УЦ, то
стороны также обмениваются корневыми сертификатами УЦ и, в случае существования,
промежуточными сертификатами УЦ.
4.5. Перед началом работы стороны проверяют свои средства ЭП и с их помощью проверяют
подлинность ЭП.
4.6. Стороны признают, что:

внесение изменений в ПЭД дает отрицательный результат проверки ЭП;

подделка ЭП невозможна без использования ключа ЭП владельца;

каждая сторона несет ответственность за сохранность своего ключа ЭП и за действия своего
персонала при использовании средств ЭП;

моментом наступления юридической значимости ПЭД является момент получения этого ПЭД
через Систему принимающей стороной и отраженный в журнале.
4.7. Средства ЭП должны быть встроены в Систему. Стороны признают эти средства достаточными для
подписания ЭД и проверки подлинности ЭП в ПЭД.
5.
Обязанности Сторон
Стороны обязуются:
5.1. Самостоятельно укомплектовать Систему необходимыми программно-техническими средствами и
общесистемным программным обеспечением.
5.2. Назначить лиц, ответственных за работу с Системой в соответствии с настоящим Соглашением.
5.3. Назначить Администратора безопасности, отвечающего за генерацию, учет, обмен и сохранность
ключей, используемых в Системе, за защиту от несанкционированного доступа и за поддержание
средств ЭП Системы в рабочем состоянии.
5.4. Произвести обмен сертификатами.
5.5. Своевременно производить плановую замену ключей ЭП и соответствующих сертификатов
ключей проверки ЭП в соответствии с регламентом УЦ и/или действующего законодательства.
Рекомендуется проводить плановую замену не реже 1 раза в год и за 10 дней до окончания срока
действия сертификата.
выплаты on-line лайт
5.6. Немедленно информировать другую сторону обо всех случаях утраты, хищения,
несанкционированного использования ключей ЭП по следующим адресам: Оператор
[email protected], Контрагент – e-mail. При этом работа в Системе приостанавливается
до проведения внеплановой смены ключей.
5.7. Принимать на себя все риски, связанные с работоспособностью своего оборудования и каналов
связи.
5.8. За собственный счет поддерживать в рабочем состоянии входящие в Систему программнотехнические комплексы обеспечения работоспособности вычислительной техники и техники связи,
обеспечивающих электронный документооборот.
5.9. Обеспечить доступ к средствам ЭП только лиц, уполномоченных на подписание документов.
Перечень лиц устанавливается Основным договором и/или Соглашением.
5.10. Своевременно (не позднее трех дней) уведомлять друг друга об изменении своего фактического
места нахождения, сетевого адреса в сети Интернет, а также об изменении иных реквизитов,
имеющих существенное значение для определения юридического статуса и идентификации сторон
и исполнения обязательств по Соглашению.
5.11. Не предпринимать действий, способных нанести ущерб другой стороне вследствие использования
Системы.
5.12. Своевременно информировать (по электронной почте из п. 5.6 и/или телефону) другую сторону обо
всех случаях возникновения технических неисправностей или других обстоятельств,
препятствующих электронному документообороту.
5.13. В случае обнаружения возможных угроз безопасности, стороны обязуются своевременно извещать друг
друга о таких угрозах для принятия согласованных мер по их нейтрализации.
5.14. Строго выполнять требования технической и эксплуатационной документации к программному и
аппаратному обеспечению Системы.
5.15. Разработать и выполнять мероприятия по обеспечению конфиденциальности, целостности и
сохранности программных средств Системы, передаваемых ПЭД, протоколов регистрации
событий, действующей ключевой информации и парольной информации, используемой для
доступа в Систему.
5.16. Организовать внутренний режим функционирования рабочего места ответственного лица таким
образом, чтобы исключить возможность использования Системы лицами, не имеющими допуска к
работе с ней, а также исключить возможность использования средств ЭП не уполномоченными на
это лицами.
5.17. Обеспечивать сохранение в тайне сведений по вопросам технологии защиты информации,
используемых при обмене ЭД между сторонами, за исключением случаев, предусмотренных
действующим законодательством Российской Федерации
5.18. Поддерживать системное время программно-аппаратных средств Системы в соответствии с
текущим астрономическим временем с точностью до пяти минут. Стороны признают в качестве
единой шкалы времени Московское время MSK (UTC +4).
5.19. Обмениваться ЭД, не содержащими компьютерных вирусов и/или иных вредоносных программ.
5.20. Осуществлять обязательную проверку антивирусным ПО пересылаемых ЭД перед их отправкой.
Обновление базы данных антивирусного ПО должно быть актуально на момент такой проверки.
5.21. Направлять другой стороне и обеспечить прием от другой стороны ПЭД с контролем целостности
и авторства в случаях и в сроки, установленные Соглашением и /или Основным договором.
5.22. Принимать к исполнению ЭД, в установленные Соглашением и/или Основным договором сроки,
если ЭД получены через Систему, подписаны НЭП и ЭП была успешно проверена.
5.23. При осуществлении операций на основании полученных по Системе ЭД, руководствоваться
требованиями законодательства Российской Федерации, а также условиями Основного договора и
Соглашения.
5.24. Стороны организуют архивное хранение ПЭД в течение срока действия аналогичных документов,
оформленных на бумажных носителях.
6.
Права Сторон
выплаты on-line лайт
Стороны имеют право:
6.1. Ограничивать и приостанавливать использование Системы в случаях ненадлежащего исполнения
другой стороной Соглашения, с уведомлением не позднее дня приостановления, а по требованию
компетентных государственных органов в случаях и в порядке, предусмотренных
законодательством Российской Федерации.
6.2. Производить замену программно-аппаратного обеспечения Системы с предварительным
уведомлением не менее чем за два рабочих дня другой стороны.
6.3. Остановить работу Системы по техническим причинам, до восстановления ее работоспособности.
6.4. Производить плановую и внеплановую замену ключа ЭП, ключа проверки ЭП и сертификата
ключа проверки ЭП по своей инициативе с уведомлением другой стороны не менее чем за два
рабочих дня.
7.
Ответственность сторон и риски убытков
7.1. Стороны несут ответственность за содержание любого ПЭД, при условии подтверждения
подлинности ЭП.
7.2. Стороны несут ответственность за конфиденциальность и порядок использования ключей ЭП.
7.3. Сторона, допустившая компрометацию ключа ЭП, несет ответственность за ЭД, подписанные с
использованием скомпрометированного ключа ЭП, до момента официального уведомления об
аннулировании (отзыве) соответствующего сертификата и конкретных документов, подписанных
указанным ключом.
7.4. Сторона, несвоевременно сообщившая о случаях утраты или компрометации ключа ЭП, несет
связанные с этим риски.
7.5. В случае возникновения убытков, сторона, не исполнившая (ненадлежащим образом исполнившая)
обязательства по Соглашению, несет ответственность перед другой стороной за возникшие убытки.
При отсутствии доказательств неисполнения (ненадлежащего исполнения) сторонами обязательств
по Соглашению, риск убытков несет сторона, чьей ЭП подписан ЭД, исполнение которого
повлекло за собой убытки.
7.6. Если в результате надлежащего исполнения ЭД возникает ущерб для третьих лиц, ответственность
несет Сторона, от имени которой ЭД подписан ЭП.
7.7. Стороны освобождаются от ответственности за частичное или полное неисполнение своих
обязательств по Соглашению, если таковое явилось следствием обстоятельств непреодолимой
силы, возникших после вступления в силу Соглашения, в результате событий чрезвычайного
характера, которые не могли быть предвидены и предотвращены разумными мерами. Сторона
обязана незамедлительно известить другую сторону о возникновении и прекращении действия
обстоятельств непреодолимой силы, препятствующих исполнению ей обязательств по
Соглашению, при этом срок выполнения обязательств по Соглашению переносится соразмерно
времени, в течение которого действовали такие обстоятельства.
7.8. В случае прекращения действия Соглашения по любому основанию стороны несут
ответственность по обязательствам, возникшим до прекращения действия Соглашения, в
соответствии с законодательством Российской Федерации.
8. Порядок создания ключа ЭП, ключа проверки ЭП, сертификатов ключей проверки ЭП и их
использования и передачи
8.1. Стороны генерируют ключ ЭП и соответствующий ключ проверки ЭП. Стороны генерируют
соответствующий сертификат ключа проверки ЭП в УЦ.
8.2. Используемые сертификаты и списки отозванных сертификатов должны соответствовать формату
X.509v3, описанного в спецификации IETF RFC 5280.
8.3. Параметры сертификата должны быть следующие:

алгоритм подписи – RSA;

длина ключа – 2048 бит;

алгоритм хеширования – sha1;

срок действия – 1 год.
8.4. В поле «субъект» сертификата внести следующие сведения:
выплаты on-line лайт






CN = ФИО ответственного сотрудника или наименование организации или псевдоним;
E = адрес электронной почты;
OU = Наименование подразделения организации;
O = Название организации;
L = Город размещения организации;
C = Код страны (например, для России C=RU).
Остальные поля сертификата могут быть заполнены по желанию.
8.5. Сертификаты, используемые для формирования НЭП, должны иметь атрибуты расширенного
использования ключа id_kp_clientAuth (OID 1.3.6.1.5.5.7.3.2).
8.6. Сертификаты должны иметь запись с данными о точке распространения списка отозванных
сертификатов, доступного по протоколу HTTP из сети Интернет.
8.7. Удостоверяющий центр должен добавлять в СОС отозванные сертификаты в течение 1 рабочего
дня и опубликовывать новый СОС в Интернете после каждого обновления.
8.8. Удостоверяющий центр, который используется для выдачи сертификатов, должен соответствовать
всем требованиям к неаккредитованным удостоверяющим центрам, установленными в ФЗ № 63-ФЗ
«Об электронной подписи».
8.9. Стороны обмениваются следующими сертификатами:

корневой сертификат УЦ (если есть);

промежуточные сертификаты (если есть);

сертификат, который будет использоваться для подписи ЭД в Системе.
8.10. Файл сертификата должен быть в формате X.509 (Base64 или DER кодировка, расширение файла
.cer) или PKCS#7 (расширение файла .p7b).
8.11. Файлы сертификатов передаются другой стороне по электронной почте или через Систему, если
она уже функционирует.
8.12. Стороны печатают на бумажном носители файлы сертификатов, подписывают ответственным
лицом с оттиском печати организации и отправляют другой стороне курьером или передают друг
другу в момент подписанию данного Соглашения. Пример формы печати сертификата представлен
в конце данного Приложения.
8.13. Стороны обязуются принимать все необходимые меры для сохранения конфиденциальности
ключей ЭП.
8.14. Передающая Сторона подписывает электронный документ своим ключом ЭП, зашифровывает
ПЭД ключом проверки ЭП из сертификата принимающей Стороны и отправляет зашифрованный
ПЭД через систему.
8.15. Принимающая Сторона расшифровывает принятый документ своим ключом ЭП и проверяет ЭП с
помощью ключа проверки ЭП из сертификата передающей Стороны.
8.16. Система средствами ЭП для каждого полученного ПЭД должна проверить:

подлинность ЭП для данного ПЭД;

факт того, что дата формирования ЭП находится в интервале от даты начала действия
сертификата до даты завершения его действия;

корректность самого сертификата, используемого для формирования ЭП;

корректность цепочки выдачи сертификатов от используемого для подписи до корневого;

выполнение требований к ограничению использования сертификата, записанных в самом
сертификате;

отсутствие используемого сертификата в списке отозванных сертификатов стороны,
выдавшей этот сертификат.
8.17. При плановой замене сертификата ключа проверки ЭП сторона генерирует новые ключи и
соответствующий сертификат и отправляет файл сертификата другой стороне по электронной
почте или через Систему.
8.18. При компрометации ключа ЭП (или обоснованных подозрениях на это), используемого для
формирования НЭП в ПЭД, сторона должна:

остановить передачу ПЭД в Системе и немедленно (если невозможно, то в течение 1 рабочего
дня) уведомить другую сторону о факте компрометации сертификата;

уведомить УЦ о компрометации ключа ЭП;

произвести генерацию нового ключа ЭП, ключа проверки ЭП и выпустить в УЦ новый
сертификат ключа проверки ЭП;

передать другой стороне файл с новым сертификатом;

проверить, что УЦ внес в список отозванных сертификатов серийный номер
скомпрометированного сертификата и опубликовал новый СОС;

восстановить работу Системы по согласованию с другой стороной.
выплаты on-line лайт
8.19. При компрометации корневого и/или промежуточного ключа ЭП удостоверяющего центра
Сторона уведомляет об этом другую Сторону и документооборот приостанавливается до момента
получения новых сертификатов.
9.
Порядок разрешения споров, связанных с установлением подлинности ЭД
9.1. Любые споры между сторонами, предметом которых является установление подлинности, т.е.
целостности текста и аутентичности отправителя ЭД, передаются для разрешения специально
создаваемой Экспертной комиссии.
9.2. Экспертная комиссия созывается на основании письменного заявления (претензии) любой из
сторон. В указанном заявлении сторона указывает реквизиты оспариваемого ПЭД и лиц,
уполномоченных представлять интересы этой стороны в составе Экспертной комиссии.
9.3. Не позднее 10 рабочих дней с момента получения другой стороной заявления (претензии), стороны
определяют дату, место и время начала работы Экспертной комиссии, определяют, какая сторона
предоставляет помещение и производит конфигурирование средств ЭП.
9.4. Полномочия членов Экспертной комиссии подтверждаются доверенностями.
9.5. Состав Экспертной комиссии формируется в равных пропорциях из представителей сторон.
9.6. Экспертиза оспариваемого ЭД осуществляется в присутствии всех членов Экспертной комиссии.
9.7. Экспертиза осуществляется в четыре этапа:
1-ый этап: стороны совместно устанавливают, конфигурируют и тестируют средство ЭП.
2-ой этап: стороны предоставляют свою копию сертификата ключа проверки ЭП, используемому
для создания НЭП оспариваемого ПЭД, а также корневого и промежуточных сертификатов УЦ.
З-ий этап: Экспертная комиссия с помощью средства ЭП получает ключи проверки ЭП из
сертификатов, предоставленных сторонами, и сравнивает их с соответствующими ключами из
сертификатов, переданными сторонам на основании пункта 8.11 настоящего Соглашения.
Сертификаты, ключи проверки ЭП которых совпали, признаются подлинными. Также проверяется
корневой сертификат, переданный на бумажном носители до подписания Соглашения, с только
предоставленным сертификатом. Экспертная комиссия с помощью средства ЭП проверяет,
выпущен ли сертификат ключа проверки ЭП, использованный для подписи оспариваемого ПЭД, с
использованием корневого и промежуточных ключа ЭП УЦ.
4-ый этап: Проверка правильности ЭП под оспариваемым документом, предоставленным сторонойполучателем, проверяется по сертификату принимающей стороны, подлинность которого
подтверждена, как указано выше.
9.8. Подтверждением подлинности оспариваемого ПЭД является одновременное наличие следующих
условий:

проверка подлинности ЭП оспариваемого ЭД дала положительный результат;

подтверждена принадлежность сертификата ключа проверки ЭП, использованного для
проверки подлинности ЭП в оспариваемом ЭД;

ЭД сформирован в Системе и передан для обработки в соответствии с положениями
настоящего Соглашения.
9.9. Результаты экспертизы оформляются в виде письменного заключения - Акта Экспертной
комиссии, подписываемого всеми членами Экспертной комиссии. Акт составляется немедленно
после завершения третьего этапа экспертизы. В Акте фиксируются результаты всех этапов
проведенной экспертизы, а также все существенные реквизиты оспариваемого ПЭД. Акт
составляется в двух экземплярах – по одному для каждой из сторон. Акт комиссии является
окончательным и пересмотру не подлежит.
9.10. Подтверждение подлинности ЭП в оспариваемом ПЭД и зафиксированное в Акте, будет означать,
что этот ПЭД имеет юридическую силу и влечет возникновение прав и обязательств сторон,
установленных Основным договором и Соглашением. Не подтверждение подлинности ЭП в
оспариваемом ПЭД и зафиксированное в Акте, будет означать, что этот ПЭД не имеет
юридической силы и не влечет возникновение каких-либо прав или обязательств сторон,
установленных Основным договором и Соглашением.
9.11. Стороны признают, что Акт, составленный Экспертной комиссией, является обязательным для
сторон и может служить доказательством при дальнейшем разбирательстве спора в Арбитражном
суде.
9.12. В случае отсутствия согласия по спорным вопросам и добровольного исполнения решения
Экспертной комиссии, все материалы по этим вопросам могут быть переданы на рассмотрение в
Арбитражном суде города Москвы.
выплаты on-line лайт
10. Уполномоченными лицами на использование ЭП от имени Сторон являются:
От Оператора Председатель Правления Шабанова Т.А.
От Контрагента ____________________________(указать подписанта договора от контрагента).
От Оператора:
От Контрагента:
М.П.
М.П.
Председатель Правления Шабанова Т.А.
Должность, ФИО
выплаты on-line лайт
Приложение №2
К договору об информационно-технологическом взаимодействии
при перечислении денежных средств в пользу физических лиц
для расчетов с использованием предоплаченных карт №_________ от_____
Приложение «Агент по зачислениям».
Приложение позволяет зачислять деньги на счета пользователей. Зачисления выполняются по спискам из
файлов, которые вы загружаете в Агент, — по протоколу обмена информацией с Яндекс.Деньгами
(описание протокола смотрите ниже).
Чтобы начать работу, нужно получить сертификат от Яндекс.Денег. Запрос на сертификат генерируется в
приложении; полученные файлы нужно отправить на email менеджера в Яндекс.Деньгах. Сертификат
придет в ответном письме.
Отправлять зачисления можно сразу после того, как сертификат будет импортирован в приложение.
ПОРЯДОК ОНЛАЙН ВЗАИМОДЕЙСТВИЯ
протокол обмена информацией
перевод средств на счета в системе «Яндекс.Деньги»
Протокол 3.0
Версия от 18.06.2012
Принципы работы
Данный протокол предназначен для информирования ООО НКО «Яндекс.Деньги» (далее — Системы) о
поступлении переводов на виртуальные счета клиентов Системы.
Протокол предоставляет информационной системе Контрагента (далее — ИС):
1. Проверять возможность зачисления переводов.
2. Передавать запросы на зачисление переводов.
3. Передавать идентификационные данные физических лиц.
4. Отслеживать баланс средств по договору приема переводов.
ИС Контрагента и Система взаимодействуют с помощью протокола HTTPS.
Для выполнения каждой из операций ИС передает отдельный HTTP-запрос, содержащий криптопакет
формата PKCS#7. На каждый запрос о зачислении сервер Системы отвечает сообщением о результате
операции, помещенным в криптопакет PKCS#7.
Также используется криптографическая защита канала связи на базе протокола SSL (HTTPS), с
аутентификацией по клиентскому сертификату. Кроме того, ограничивается список IP-адресов, с которых
допустимо присылать запросы на сервер Системы.
Контрагент должен получить сертификат, с использованием которого он будет подключаться и
формировать запросы к Системе. См. документ «Процедура обмена сертификатами».
Идентификационные данные – ФИО, гражданство пользователя, реквизиты документа, удостоверяющего
личность, адрес места жительства, дата и место рождения. Перечень является минимально необходимым;
включение иных составляющих в перечень идентификационных данных может быть согласовано сторонами
дополнительно.
Параметры подключения Контрагента
Контрагенту доступны операции протокола: testDeposition, makeDeposition, balance .
выплаты on-line лайт
Контрагенту, передающему идентификационные данные, дополнительно доступны операции протокола:
testIdentificationDeposition, makeIdentificationDeposition.
Общее описание протокола
Формирование запроса
Формирование запроса к серверу Системы состоит из следующих шагов:
1. Формирование распоряжения на исполнение операции. Распоряжение формируется как документ
согласно стандарту XML 1.0 (Fifth Edition), опубликованному по адресу: http://www.w3.org/TR/xml/.
Документ
должен
быть
сформирован
в
кодировке
UTF-8
согласно
стандарту:
http://www.ietf.org/rfc/rfc2279.txt.
2. Формирование криптопакета. Сформированный документ помещается в криптоконтейнер формата
PKCS#7 согласно стандарту http://www.ietf.org/rfc/rfc5652.txt. Криптоконтейнер должен содержать АСП
(цифровую подпись, аналог собственноручной подписи). Криптоконтейнер не должен содержать цепочки
сертификации. Компрессия данных не используется. Шифрование не используется. Криптопакет должен
быть закодирован в формате PEM (OpenSSL). Сертификат Контргента, используемый при изготовлении
криптопакета, должен соответствовать стандарту X.509 Version 3 (http://www.ietf.org/rfc/rfc2459.txt).
3. Передача запроса серверу Системы. ИС формирует POST-запрос по протоколу HTTP/1.1
(http://www.ietf.org/rfc/rfc2616.txt, http://www.ietf.org/rfc/rfc2818.txt,
http://www.ietf.org/rfc/rfc4346.txt).
Криптопакет может быть передан одним из двух способов:
1. Криптопакет помещается в тело POST-запроса, MIME-тип: application/pkcs7-mime.
2. Криптопакет передается как multipart-data вложение. MIME-тип: application/pkcs7-mime.
POST-запрос должен иметь только один 'part', криптопакет должен быть вложен как файл.
Такой запрос может быть отправлен из стандартной HTML-формы для file upload (отправки
файла на сервер). См. http://www.ietf.org/rfc/rfc2388.txt.
Для авторизации запросов сервер Системы проверяет АСП криптопакета.
Защита от ошибочных повторов операций зачисления обеспечивается наличием уникального номера
операции (clientOrderId).
Пример сформированного запроса:
POST /webservice/deposition/api/makeDeposition HTTP/1.1
Content-Type: application/pkcs7-mime
Content-Length: 572
-----BEGIN PKCS7----MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCA
JIAEDEhlbGxvIFdvcmxkIQAAAAAAADGCAS8wggErAgEBMCowJTEWMBQGA1UECgwN
Qm91bmN5IENhc3RsZTELMAkGA1UEBhMCQVUCAQIwCQYFKw4DAhoFAKBdMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgwNjE1MzE0
M1owIwYJKoZIhvcNAQkEMRYEFC73veYIzlQE6X1fBC+V+J8cIyhxMA0GCSqGSIb3
DQEBAQUABIGAEgIfi0XDEZwbdC8i0I5EPUnFe1PUnBMiRs3heYxdK+oXaG6v3axO
Zr+VNG3tnW1W8M2xWtOcM4PdSTwx98WR1mWN8XDb2Wl9HiG6CGbmE7k4TgcDKhcg
iZmLV+7anBv302qTprTbKY9vChaaVwclSdQBkjPvxhlPnpBM0C9YdYQAAAAAAAA=
-----END PKCS7-----
Получение ответа
Результат выполнения запроса возвращается Системой в ответе на HTTP-запрос. MIME-тип:
application/pkcs7-mime. Данные помещены в криптоконтейнер формата PKCS#7. Криптоконтейнер содержит
АСП (цифровую подпись, аналог собственноручной подписи). Криптоконтейнер не содержит цепочки
сертификации. Компрессия данных не используется. Шифрование не используется. Криптопакет
закодирован в формате PEM (OpenSSL). Криптоконтейнер содержит XML-документ с результатом
обработки запроса.
При получении ответа сервера ИС должна выполнить проверку подписи ответа, чтобы убедиться, что ответ
отправлен сервером Системы, а также что его содержимое не было изменено третьей стороной. Следует
также учитывать, что в ответе могут быть дополнительные поля, не описанные в данном протоколе, но не
нарушающие совместимость.
Таблица 3.2.1. Возможные HTTP-коды ответа
выплаты on-line лайт
HTTP-код
Описание
200 OK
Запрос принят к обработке. Отправлен ответ в соответствии с настоящим
протоколом. MIME-тип: application/pkcs7-mime.
Запрос не принят к обработке. Тело запроса испорчено, сервер не смог
прочитать или разобрать запрос.
Возможные причины:
 запрос невозможно разобрать;
 неверный MIME-тип (Content-Type).
Сертификат Контрагента не зарегистрирован в Системе, либо в настоящий
момент шлюз отключен.
Технические проблемы Системы. Обратитесь в службу поддержки.
Запрос отправлен методом, отличным от POST.
400 Bad Request
403 Forbidden
500 Internal Server Error
501 Not Implemented
Типы данных
Таблица 3.3.1. Определения типов данных протокола
Тип
Описание
xs:int
32-bit целое знаковое число. Int32, определенный в стандарте:
http://www.w3.org/TR/xmlschema-2/#int.
64-bit целое знаковое число. Int64, определенный в стандарте:
http://www.w3.org/TR/xmlschema-2/#long.
Десятичное число с фиксированной точкой, определенное в стандарте:
http://www.w3.org/TR/xmlschema-2/#decimal.
Текстовая строка, определенная в стандарте:
http://www.w3.org/TR/xmlschema-2/#string.
Текстовая строка, определенная в стандарте:
http://www.w3.org/TR/xmlschema-2/#normalizedString.
Временная метка в формате согласно рекомендациям:
 http://www.w3.org/TR/xmlschema-2/#dateTime
 ISO8601:2004
Формат определяется как:
YYYY-MM-DDThh:mm:ss.fZZZZZ
Расшифровка формата:
xs:long
xs:decimal
xs:string
xs:normalizedString
xs:dateTime
YYYY
MM
DD
T
h
mm
ss
f
ZZZZZ
xs:date
год, точно 4 цифры
месяц, точно 2 цифры (01=январь и т.д.)
день месяца, точно 2 цифры (от 01 до 31)
латинский символ «T», должен быть в верхнем регистре
часы, точно 2 цифры (24-часовой формат, от 00 до 24)
минуты, точно 2 цифры (от 00 до 59)
секунды, точно 2 цифры (от 00 до 59)
дробная часть секунды (от одной до 6 цифр),
может отсутствовать, в этом случае следует опускать и
разделитель «.»
описатель временной зоны, обязательный параметр, может
принимать значения:
 Z – UTC, символ "Z" должен быть в верхнем регистре;
 +hh:mm или -hh:mm – смещение относительно UTC
(показывает, что указано локальное время, которое на
данное число часов и минут опережает или отстает от
UTC)
Примеры:
2011-07-01T19:00:00.000+04:00 — 19 часов 00 минут 1 июля 2011 года,
часовой пояс Санкт-Петербурга (Москвы) — UTC + 4 часа.
Дата в формате, согласно стандарту http://www.w3.org/TR/xmlschema2/#date.
Формат определяется как:
YYYY-MM-DD
выплаты on-line лайт
Расшифровка формата:
ClientTransactionNumber
YYYY
год, точно 4 цифры
MM
месяц, точно 2 цифры (01=январь и т.д.)
DD
день месяца, точно 2 цифры (от 01 до 31)
Примеры:
2011-07-01 — 1 июля 2011 года.
Уникальный идентификатор операции. Должен быть уникальным для
Контрагента на протяжении всей истории операций. Значением параметра
должна быть строка длиной от 1 до 24 символов, содержащая символы,
принадлежащие множеству значений: 0-9 A-Z a-z . , \ | / - + = # ~ ( ) { } [ ] : ;
Рекомендуемые значения: целое положительное линейно нарастающее
число в десятичной системе счисления.
<xs:simpleType name="ClientTransactionNumber">
<xs:restriction base="xs:normalizedString">
<xs:minLength value="1"/>
<xs:maxLength value="24"/>
<xs:pattern value="[0-9A-Za-z.,\\|/\-+=#~(){}\[\]:;]+"/>
</xs:restriction>
</xs:simpleType>
YMAccount
Идентификатор получателя перевода, строка десятичных цифр длиной до
33 символов.
<xs:simpleType name="YMAccount">
<xs:restriction base="xs:normalizedString">
<xs:maxLength value="33"/>
<xs:pattern value="[0-9]+"/>
</xs:restriction>
</xs:simpleType>
CurrencyAmount
В качестве идентификатора может использоваться:
 Счет пользователя в Системе (вида 4100175017397; длина
существующих в Системе Счетов на данный момент варьируется
от 11 до 16 цифр);
 номер телефона пользователя, привязанный к Счету в Системе
(допускаются номера российских операторов, рекомендуемое
представление – 10-значные номера вида 9217575400, без
дополнительных символов и пробелов);
 код платежа в ООО «Яндекс» (все номера, начинающиеся с «50»,
«51»).
Сумма. Положительное десятичное число с фиксированной точкой, кол-во
цифр после точки точно равно двум.
<xs:simpleType name="CurrencyAmount">
<xs:restriction base="xs:decimal">
<xs:minExclusive value="0"/>
<xs:maxInclusive value="9999999999999"/>
<xs:fractionDigits value="2"/>
</xs:restriction>
</xs:simpleType>
CurrencyCode
Код валюты. Возможные значения:
 643 — рубль Российской Федерации;
 10643 — тестовая валюта (демо-рублики
«Яндекс.Деньги»).
<xs:simpleType name="CurrencyCode">
<xs:restriction base="xs:int">
</xs:restriction>
</xs:simpleType>
демо-системы
выплаты on-line лайт
Операции протокола
Зачисление переводов (makeDeposition).
С помощью данной операции ИС Контрагента информирует Систему о принятом переводе.
Важно! Необходимо осуществлять проверку возможности зачисления перевода (операция testDeposition) до
принятия средств от клиента. Запрос testDeposition позволяет проверить возможность зачисления указанной
суммы получателю, в том числе корректность и существование идентификатора пользователя (номера счета
или телефона), лимиты и отсутствие запретов на проведение операции. При приеме запроса testDeposition
зачисление перевода не производится.
Адрес операции проверки возможности зачисления перевода:
https://server:port/webservice/deposition/api/testDeposition
Адрес
операции
https://server:port/webservice/deposition/api/makeDeposition
зачисления
перевода:
Правила формирования и обработки запросов на зачисление переводов:
Каждое зачисление должно быть сформировано с уникальным значением идентификатора
(clientOrderId).
2. Если на операцию «зачисление» получен ответ «Успех» (status=0), то перевод зачислен успешно.
3. Если запрос отправлен с уже ранее обработанным идентификатором (clientOrderId) и остальные
параметры запроса, кроме requestDT, совпадают с предыдущей попыткой, то Система вернет результат
обработки ранее отправленного запроса.
4. Если запрос отправлен с уже ранее обработанным идентификатором (clientOrderId) и какие-либо
параметры, кроме requestDT, имеют отличные от первой попытки значения, то Система отвергает такой
запрос и возвращает в ответе status=3, error=26.
5. Система обрабатывает полученный запрос немедленно. В случае если запрос невозможно обработать в
течение нескольких секунд, возвращается ответ «в процессе обработки» (status=1). В этом случае
результат операции неизвестен, и ИC следует повторить запрос с теми же данными для получения
окончательного ответа. Рекомендуется следующий режим повтора: первый повтор через 1 минуту,
следующие три с промежутком в 5 минут, далее не более одного раза в 30 минут. Аналогичный режим
повтора рекомендуется в случае неполучения ответа от Системы или получения ответа HTTP status 500.
6. При неполучении ответа от Системы, а также при нечетком ответе (например: HTTP status 500) ИС
Контрагента следует повторить запрос с теми же данными для получения окончательного ответа.
Рекомендуется следующий режим повтора: первый повтор через 1 минуту, следующие три с
промежутком в 5 минут, далее не более одного раза в 30 минут.
7. Статус транзакции, находящейся в обработке (status=1), может измениться как на «успех», так и на
«отвергнут».
8. Если перевод отвергнут Системой, то в ответе возвращается status=3 и error= с расшифровкой причины
отказа. В некоторых случаях может присутствовать поле techMessage, содержащее дополнительную
поясняющую информацию в виде текста произвольного формата. Этот текст предназначен для анализа
техническими специалистами и не должен отображаться в каком-либо интерфейсе пользователя.
9. Если перевод отвергнут с ошибкой status=3 error=45, Контрагенту необходимо перечислить принятые
переводы на расчетный счет Системы, убедиться, что баланс увеличился (отправив запрос баланса), и
провести переводы с НОВЫМИ идентификаторами операций (clientOrderId).
10. Ошибка status=3 error=21 означает, что запрашиваемая операция запрещена для данного Контрагента
(см. раздел 2 «Параметры подключения Контрагента»).
1.
Формат запросов ИС
Таблица 4.1.1.1. Параметры запроса операций testDeposition, makeDeposition (все параметры
обязательные, кроме отмеченных символом «*»)
Параметр
Тип
Описание
clientOrderId
ClientTransactionNumber
requestDT
xs:dateTime
Идентификатор операции. Должен быть уникальным
для Контрагента на протяжении всей истории
операций. Рекомендуемые значения: целое
положительное число в десятичной системе счисления.
Дата и время формирования запроса операции на
стороне ИС, по часам Контрагента.
выплаты on-line лайт
dstAccount
YMAccount
amount
currency
CurrencyAmount
CurrencyCode
agentId
subAgentId (*)
xs:long
xs:long
contract
xs:normalizedString, до 128
символов
Идентификатор получателя перевода, например:
4100175017397
9217575400
5007266583
Сумма перевода, например: 12.34
Код валюты перевода. Возможные значения:
 643 — рубль Российской Федерации;
 10643 — тестовая валюта (демо-рублики
демо-системы «Яндекс.Деньги»).
Идентификатор Контрагента. Выдается Системой.
Уникальный идентификатор канала приема переводов.
Указывается только в случае разделения переводов по
нескольким каналам. Выдается Системой.
Основание для зачисления перевода.
Пример запроса проверки возможности зачисления:
<?xml version="1.0" encoding="UTF-8"?>
<testDepositionRequest agentId="123"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Выигрыш в игре Сфера"/>
Пример запроса проверки возможности зачисления c указанием subAgentId:
<?xml version="1.0" encoding="UTF-8"?>
<testDepositionRequest agentId="123"
subAgentId="456"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Выигрыш в игре Сфера"/>
Пример запроса на зачисление:
<?xml version="1.0" encoding="UTF-8"?>
<makeDepositionRequest agentId="123"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Выигрыш в игре Сфера"/>
Пример запроса на зачисление c указанием subAgentId:
<?xml version="1.0" encoding="UTF-8"?>
<makeDepositionRequest agentId="123"
subAgentId="456"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Выигрыш в игре Сфера"/>
выплаты on-line лайт
Формат ответов Системы
Таблица 4.1.2.1. Параметры ответа операций testDeposition, makeDeposition
Параметр
Тип
Описание
status
xs:int
error
xs:int
clientOrderId
processedDT
ClientTransactionNumber
xs:dateTime
balance
xs:decimal
techMessage
xs:string
Результат выполнения операции. По значению этого
поля ИС Контрагента должна принимать решение о
состоянии запроса. См. табл. 5.1.1 «Коды состояний
запроса».
Код ошибки выполнения запроса (см. таблицу 5.2.1).
Является дополнительной расшифровкой к полю
status. В случае успеха поле отсутствует.
Копия параметра clientOrderId запроса.
Время обработки запроса по часам сервера Системы. В
случае успеха операции зачисления — фактическое
время зачисления средств на счету, сбл. 54100ьк0редсot;10.0ваеn9се ,0Z&q?xml version="1.од валю'nAто1ht;
dstAccount=&quртения — фаеrh9C
од По знId:
<?xтаCt;xs:rедстон#ет
CurrencyA(caquo;иптопакXfд t;xs:simpleType name="Currencyениzquot;Выигрыыдается иналам.ис subAgentческотре
essage
тся иналам.исств на urлС :00.000Z"
dstAccount=&q н</xs:restыблi12345&quoатора Прапрочемер т средств
чЎ
;1.0"ре
,чеA деѸя и никального нония сенuокts
xs:int
Id="12345&о). В X.7i;/xs:resбра1,e
x
и(Мосд, возвращаbamount= асs/xs:res
;
dstAccoжна бы проверку возможности зачисления перевоверку возможноѰ<ot;1239абаты' исание
clien2> 500.
6. При рAamount= асs/xs:res
;
dstAдующие три с промежутddtionRequestmс.Деньги»).
<xs:simpleType name=&quh, все мансакXf= асs/xs:res
;
dstAдующие три с промежутddtionRequestmс.Деньги»).
<xs:simpleType name=&quh, все мансакXf= асs/xs:res
;
dstAдующие три с промежут,e
x
и(М сервера Системы. В
случien2> 500.
ы. 
тимеѻ
т К="410011234567&quoаx
и.
4. Еа t;ot;
4. тификатоt.ис  т0редсotA возможно23"
subAgentI отобра; encoding="UTFя третьего этапа экспболжня птимеѻMжуrT, имеют us
xs:int
error
xs:int
cl(т сT, иредседаtI отобраd с п
тся rderId зqclusive value=еченg
contraRequestmс.Деньги»).
<xs:simpleTypсоде7
Т aquo;).
&lсимво пт
т2c[ой
bAgentId="456"
clientOrderId=&qu/xs:res,ding=&слtion/a-7=6енить /слеФед011234567"ДеntTratforltNdgilaquo;50& с п
y1ck4ot;ДеntTratfor01123456
заподimlral
teоКод поrislce
eo" для зачисленCme
Conным oации о заe-рует СисѰетсяам s:res
;
ds3&quo
ожn ~ (раза lтоt.,t
error
r ~ (рQор &quoh
скоGньения — фаеrh9C
оE етсяам s:res31E AgentId=&quo us
xs:int
error
xs:int
c такой
зЀиера&quо Ќения — фа"ия Ba3ть сформированjng=& даЀевода:
ПутсергнoсѰеe8тquoh
смеѻMжуrT,E  us
Lреране)оверкѺой, о:res31E х мp з5 3 дd(ос баланса),этапа эmаз nакXf Ba3ли заплансаt;12)E спечиB ce/dep рмаѸB ce/dep рма000Z&q3aпеза
сzтся.tI&q3arT,Eне = зап тв3aсание
status
xs:int
error
xs:int
clientOrderId
processedDT
ClientTransactionNumber
xs:dateTim
xs:i средств от клиента. Запросчаях мож
zнерзоuot;4x,aвrо
попрон#етn:int
clntOrderв от клиента. Запро
aв— фа"ия Ba3ть сформированjng=& даеe8т
roce567"
amount="ровер("истеме счиtrT,EномdMBgGCрзоuot;4x,aвrо
попрэт фа"ия reT,EномdMышCрзо,ане) метка в фowJTEWMBQGA1UECgwN
Qm91bmN5IENhc3RsZTELMAkGA1UEBhMCQVUCAQIwCQYFKw4DAhoFAKBdMBg СисѰетtforltNdgilaqого но20:38:00.000Z&и с промежутком в)<CgwN8d завlaqого ное00Z&и с проe.
4. Если Єиксь,gап#intстве ид8
xs:iиния средств Ndgilaqого но20:38:00.000Z&и с промежутком в)<CgwN8d завlaqого ное00Z&и с проe.
4. Если Єиксь,gап#intствds3&qu
dsttestDeposi&и с проuстенная метка в форм0nи лн#етn:int
clntOrderйскnsacti:8 ЄGансаѻM н,EномdMышCрзо,ане[:ет п8 не смоe04номd00.000Z&иdstAccou o:ogttp://wwедо Сфера&q8визиты докумероrdstтquoh
смеѻMжуrT,E  us
Lреранеon) до
придп;?>
&l;Cgwррос с теми же , у  п8 Vс с Ѱ ~ (s.org/rfcаботке. Ту  п8 yанн1fого но20:35еwедий. Знп2nе7)жно же , у  п8 нтерфейсе пользоворм0nи л"n status=3 я.tI&q3arT,Eнформ0nи 
s
;
вая валво пoiнных данн/Orderйскnsaеж
ки
файлЁrT,EЄорм0nпая валво d з0a4гб03726658lq3arT,-ar;).
&lсимво. Знп2n омdMо, о1)
латwеG1еленстеD0околу HTTP/1Сф:00.000Z&и с dquot;n
*CgwN8d завlaqогmo п


z8d поедстогmo zтификатор канала приема переводов.
Указывается только в случае разделения переводов по
нескольк не протяескольк не проормиротсѾ4рsKирует СисѰ СисѰ Сисо зназо,анелentTranс3lт, далдий. Знп2мdMо, о1)
латeYемя обние о
состоянии счоормиротсѾ4р+Kируеучае успеха полгнoсѰеe8тquoh
entTranислot;
subAgen
ормиѴ0Z&и с пронп2м1a"с Си
https://servе з,tм
YMAccops://servе з,tм
YMAc, стc, сuot;n status=3 ячае eпрорешение о
eзыв Server с23%501 Notедазыв Server с23%501 Nв и минут опережает или отстабли9сеf,ереводов duot;10.00&quo s:res31E Age I://servе з,tм
YM+ю протореnисоrislce
eo" для запия сенuокts
xs:int
Id="1234
eo" для запиѽо стlized (опи от  запия сеную информаnст_8t="роверия.
Даtьзоa12.кумеnt
CurrencyCode/.34
онп2м1a"с Си
https://seлько иѿ8 ь,gап#inteentTranислot;
suии0пoiпеcя в игiтапры (от 00 до 59)
дробна5"
requestDT
*Cgwте59)
e
Иденти переs
;
ds3&qRомlteentTranислзыислзыисл10.00&quo s:res31E Age I://servе з,t
C4 s:redи»).
Pвание распоряжениxBaет
закодирован в фnw зачдале{+Kируеучае успquo;).
Pвани
 распоряжg=&е протяе0
xs:int
error
xs:int
c такой
зЀиерhотяе0 nст_8t=&quoние 3 errorо случ0=tp://wwедо Z&Ёлучае не смоe04н окооrdstеную информаnст_8t="роверnст_8t=&quoльное десятичное число с фиксированной точкой, кол-во
цифр после точки точно равно двум.
<xs:simpleType name="CurrencyAmount">
<xs:restriction base="xs:decimal&qs:sifруеуttp://wеворованнuст
ИE Agровке
UTиѽо стes31E х dateTime
balance
xs:deт"n sановке
UTиѽо стes31нии0ю ислot  п8 ae)lоп&и mal&qs:sifруеуttp://wеворованнuѵтся толь'/ескзыисо
пектnеуttp://wевороол
Qm91bmN5IENhc3RsZT9Ѳо8ientOение о
eаerId (  8 ae;
< стesѲоращаетklергнэт/stus=
C4 s:red&//wеворормаnсто, ревмdMово s:res
;
dsн.31Eванны' с промероd ь,gап#in
;
dstAcc зЋ присо
пектnеуttp://wевороол
Qm91bmN5IENhc3RsZT9Ѳо8ientOение о
eаerId (  8 ae;
< стesѲоращаетklергнэт/stus=
C4 s:red&//wеворормаnсто, laq прc3RsZT9Ѳоппб38:00lв , а klергнэевороklе
xdK+oсяам s:res
;
ds3&quo
ожn ~ (раза lтоt.,t
error
r ~ (рQор &quoh
скоGньения — фаеrh9пи3&quohbолу"g2g о
eаerIdg2g о
eаerIdиеом &laDepo1прос сkмированный.&ер3&qRомltk:deт&q6dен5et)ѽо , MIME-Ѵмет XML-документ с реетBaет
C4 s:redи»).
Pвание овторить зЃющспболтел сkм/рованный.&ер3&qRомltk:deотr0lса  XML-д1кумент с реетBaет
C4 s:reь зЃющспб5et)ѽо , MIME-Ѵмеций. Рекоме7кой
зЀиЁѰ СисѰ Сисо зназо,анелentTranе="643"
s:3но Id:
<?xтv"т_8ttTranчкЁа (см. тv=нелentTranе="643"
s:3Id="456"
clientOrderId значениспорsKЌцob4да:
Пиксь,лi12345&quoатора Прапрочемер т сc1кум. ПисѰетBaет
C4 s:reь зЃющспб5et)пон bquot;
омlt данныетсѰща
equesм. тv=тора cаблию информаnn="1uesа&raOi+nn=о POSкс&raquда/>
Пример заприксь,лi12345&quoатора Прапрочемер т сc1кум. ПисѰетBaет
C4 s:reь зЃющспб5et)пон bquot;
омlt данныетсѰща
equesм. тv=тора cаблиsѲоращае5IENhсь,лi12иѽо , с1лi12б subAgentId:
<?xml version="1.0" encoding=&quoден0o}eт&q,дуем:uest agr6ирос ob4да:
Пиксon="1.0oiнных данн/OrdeBy
Curre С:
YYYY-MM-DDThh:mm:ssныi12иѽо , с1лi12б subAgentId:
<?xml ver реше т сc1кум. quotv?р4-ис  т0рiерhnльн;
clientOrderp://wwедо 0erId знач_8t=&q4СКоолob< рации
htом. qu з,*Iисление:мi12(ой
2 цифрсулi12.ЃюкоGньения — фаеrh9пи3тора ПрапрочемДи3ѿриsion="1.0" eачен -лжнПи-ен -лжнПи-ен -лжнПи-ен -лжнП, о
eетB. qu  bquot;
омlt аerIdg2g о
eаerIdиеом &laDepo1прос сkмиролжнПрiерhnльн;
clieEn
ML-д1кумент с реетBaеaqол сkBaеaqол сkBaеaqое воз3M. ПисѰиs-quot;1о Id:
<?xтv"hдиaетход3Mrh9пи3uтtA воkмер т сc)
отрhnевоѰ:
рореhдиaероdерhnлѽтеориsгемы, убедитint
c тPt;xs:simp;1о Idо0льное числотint
c тPtgрhn". диa/ВыиdMquesм. тv=т тPtgрhnвоkмер т с пворащаетl. только в сриерв23%501 фЏнии зть о0-ли9>
П неtTraqRо зть ожнП, оp3)Idо0/wевA воkы, у неца 4.1&и с = ас!ж/ 4.1&и с = ас!ж/ 4.1&и s51»).
Сумма. ПолоЁколь".ifруеxiaquo;.»
опuot;
омlt кр т с пиdMquesм. тv=т тPtgрhnвоkмер т с пв знач_ли заротрhnвнэтример запрпераций я TraqRо ор;во[т сcно 2 цифры (01=я:b4да:
2s/xs:res
_жnеозапи зт Ptgьное чистBaет
C4 s: данныетсут,e
x
имеѻетBaеi12
 s:redYY-MM=&quo us
xs
clientOrderId да:
Пиксon="1.0o с =dMqаций я TraqRвозn3еводов.
Указывниzquot;ВML-дaера Сdк ф/hации
htомst xm0
00
00
00 сkмиролжмфр /wевно 3.1.suроen

xs:i3ть 0
8 .
Укею) ~ (ра кр т с пи<
r
чае разделения пеения пификатора
с ра "1.?>
version="1Пр 54100р /w,ислв&и mal&000Zd&//qолп
/асам сет сc1к-лжоuot;4тмpo&//qоdас!омst xm0
00
u  ификро кноJt;1.0o.0o., MIM,iтапры (от 0 ман0o., нПь *'луUе т н
nn=&qu
росXf= аполжмфр /w us
Lреране)оверкѺой, о:res31E 
c тPtgрhn сет wевно 3.1.suсXf= апсn=S с ет wеwевноtgр&000Zd&//qолwрро
очкой, kрро
очковеркѺой, о:re'quesмуU;
оs:redилоЁкоько в uк
1вlaqого ное*лжнId="456"
./qолwрро
о о
e т нЌWN8X2Wl9HizmLV+7a0 . ПАTran нс0erId знач_8t=n=&quo числaquoенияVѸя и н=&quo 0рa-c4777707a-cId ;
оsrstAccount=&quBaж/ 4.1&и nt
c такой
eTim
l31E 
c тPtgѵаспоряжg=&е протяе0
xs:int
error
етBo с =dMqаолп
/аuot; eаомstg11-07-e &quoh
ск,tJацоряжg=&е пск,tJацоряжg=&е п;
омlt  т с  в сризапрѰща
equPtgѵаспоряdYе7кggd.simd; ei: тPtgѵаспормфр /wевно 3.1._8t=n=&quo Ѿмstg1.0" eач
,чзn3Ў3.1._8t;
опu-ен -ланиСистем0rBres
_жnеозeк,tJацоѻ
т К="mеления /eposi9"ия oе00 дислtion/a-7=6#: тPtgе00 дислtion/a-7=пи<
r
чаeAKBdMBg Сис96u-ен b пнирос с теми вu/#00 д операция quot;
./qолдитсячаe"hдила при1вh
см — фeбот s:reь зЃющспб5et)0esy3RsZT9Ѳо8iсп маеѲо8iсп ма (вlaqого' b  зя за0x28ib0 t 
е
UTode/.34
me="Cuоr_8t=n=&quoнт ф/
me="Cuооes
_ion, makeDepositi_тусee-руvp
ск,rc hlие – 10-знаS
me="Cuоr_8tмуU;
оs:redилоЁо
 HT472239 Uе т н
nn=& XML-д1кумент mорние c указа<
rDT
*Cgwте59)
e
Идене5IENhсь,лi12иѽо , с1лi12б subAgentId:
<?xml version="1.0" encoding=&quoден0o}eт&q,дуем:uest agr6ирос ob4да:
Пиксon="1.0oiнных данн/OrdZT9ranчкЁ9)
xs:decimal&qт&q,дуем:uest agr6ирос ob4дѺ statu4оt;1eаоq,дуеанный.d1TITGсетм:uest , с1лi12s:reьфикрUе т н
ичные uтtA воkмер 59)
е00 дислtion/a-7ft agr6иot;1.0оfетбытLPредыдущеЀк
1вlaqо  едt;643&qевЀаЌWN8X
УкЁли Єиксь,gзeк,tJацплифѾfетбaе тt.1._8t=n=&quo Ѿмstg1.0&нп t"&b0x28};
<mu:int
eап#intо, Mк0рkмер ,eentT.dиhсь,л
[:int
eап#int subAgentIdгеEorltNdgilaqо2 r6иратрмаетЏ /eposi9"нест i{+KирЁо
 HT
b;
ем:uest agr6ирос инфо"1.?&Ёо
 о 59)
сек1l,kмер ,eentT.dи1_тLPрo&//q1fph:ir:лi ли Єиксьап#intсhЁо
:рпзыuокts
xs:int
Id="1xm0
00hЁо
:рпзыuоs5Ѓo;
оu/#00 оsифолно 3.1нест i{n=&qencyAmouictio Ф.uote9laqек1l,kмирe:nNumbа пеme=&quom,9lт i{+Kирз
оs:redил0erId знач_8t= 9воькЀоr_8t=сXf= 
eoк,rc hl 0e2мdMо, о1)
латспоряжg=&е протяе0
xs:int
ов ,rcабаты' иформированd:
<?xтv"hѾ4веѰетЏ /eposС
7crAваѾрние c ука 8d завlдуем:y'кЁли Єtееыg=&е 2  едt;6431
/qолп
/асам сет s:res
;
ds3&quЁли Єtееыg=&е 2  едt;6431
/qолп
nЁли Єtееыg=&е bеыg=&сьап#intлуUе
лтел сkмror
xs:int
1)
лоs#яжg=&rvitлу при1вh
с{нии зiыg=&е кой Фезн Є н
и и зiIoру ф/
me="Cuооes
_ionBi»).
<xs: Фезнри1вh
с{нии зо, о1)
lt;x subAgentId:
&иa/Выquot;/>
При7зЃющсиѽо , сCliап#intс{нии оеѰow(quo;).
<xs: Фезнри1вhoк,uоr_8tи всей иbатмированd:
<?xT,E8t=сXf= ыg=&еифолно 3.oилаko;).
Pвание 8 з8 ncoding=&rog8tоб5et)0esy3aя
око иR (clientOsmh,uомlientOs2r1 ftbn=&k"тсѰтJацdMо, рев пIgос лп
nЁлurog8tоб5eпри1вh
с{нитемh,uа пѸ:Igос лоodingводы oquot;&b0x28 41001тPtgѵаспорм6on="1.0oiннет62 8d завl!7яцчис="1.нии зhh:mm:а lтоt.,t
error
r ~+)
лe91sзо, о1)
lt;x subAgentId:
&иa/Выquot;/>
Пoquot;оЃеxЃющѾЃѾЃrror
xs:iрмаnсѰтор канhh:mhстж раытLPредыдмаеѲо8iсп мЋтLPиѽо , с1лi12б subAgentId:
<?xml version="1.0" encoding=&quoден0o}eэкспболжня птимеѻM2uot;1.н
lt;x suанd:
E.?xT,E8ан
1ленанѝроваоря балансаныетсу8X2Wl9HizmLV+7aeposi&и clntOrderвена0zmLV+7qRвоj
!воj
!0омlt данн"никевод7lt;xs: Фезнeьфнрo&gоуеxiaquo;.»
опuoентЇкооряжg=& зт PдмаеѲо8iспJ
2иѽо , с1лi12б subAgentId:
&ed F(8алво 8tp://8жут8gEн81куме0ве иCuооes
-ionBi»v=т тPtg62 8d ;xs: пugор кан V+7aeposi&и cl"/testDeоj
!вя окооrdst9eн
lt; опермма. ПолоЁкa/Выquot;/>
Плtion/ иCusн
и и зi000Zd&//спб5et{нии зо,,lt;wugор (IPO./a36erвена0zmLV+7qRно iiвено,,ltuоs5оsифолно 3агента на протяже
Cj
!в6,мволов9с!тPtgiротяжloлtion/ а0j
!в6,мволов9с!тPtgiefs00
0лe91sзо{ни)ае е
zнерзоuML-д1кумеда:
ПомlientOs2r1 quoден0o}eonBi»o;).
Pвание 8xqRon/atѵѲоиb4да:
Пиксon="1.0oi error= с р3агю x
и.
4. Е6ения:
<?xml version="1.0" encoding="UTF-8"зоuMLAcc з сc:simpleType>
Cu9ци encoding=&quванsифr1 qs5ee
Conны:2uot;1o; (status=1). В этомML-д1ку
lt; .,t
errorмstg1.0&нп t"4x,aАon=&quo03&quo
об5eпри1вequPtgѵаспоряdentOrderвенаачеentOrder
="xs:dи зiIoру»xs:d/>ряжg=& зт PдмаеѲо8iспJ
2иѽо , сн о. Пиросоя окооrdst9eн
lt;n="1.0")
lt;x suo
о3д1зоuѝров<?xтаCt;xsouo
tn Питv=тора cаблиsѲоѾд7lrisa-8"з1о Id
u:reo;.»
о"/testDe9 ПолоѾмма. По , с1лi1;xs:dи зoiнeпрбfтаxs:;?xml vьфн
ltис   -жg=&но 3.1.sжg=&о20:38:00.000Z&амиt; encodаeпри1 encoding=&quвQнsифr1 qатором ( ot;&b0x28 410и 
ltиѾлно 3 этс t;/xsи1.sжg=&о20:38:00.20:38:rdeBy
сn=S с ет wеw28};
cc е5IENhсь,лi12иrencyAmount">:жg=&deBy
, MIME-ѴноJ3
ltиѾлно 3 этс t;/xsи1.sжg=&о20:38:00.20:38:rdeBy
сn=S с есеNh) zа. По , 0лe91sзо{ни 3агента на и отн#етn:int
clnдую4rdst9eн
lt;n="1.0 bquot;
омlt аerIdg2g i9rng=&quвQнsи r
.e;
< ;1.0")dю48 ь,gап#inteentTranислot;
suии0пoiпеcя в 2R0:38:0; зт Pд i9rng=0k2dppg ед.0" encoding=&quoв и1uo     1 в03=2с! , с1лoons0litb0orx1ftgn1rbeс! , сitionRequest agentIиquodлi12б subAgentId:
<?xml versioa/Выд.0" з,g=&но)
лorIdg2g а cаблиsѲng="oeorIq
слѲng=&q зi совп0, (рQоquда/>
Примвп0,ен b пнирос с теми вu/#00 quoв и1pIoру ф/
me=n
:ot;
s=ntOrde,eа.LML-д1ку
lt; ми ДMLко 1 мѾмма. П"1.?&Ё~+)
лeNh) zа. =яerId=енЂet{нии зо,,lt;wugор (IPO./a36erвuя сенuокфr1 qs5ee
N0.0&quoEm к., MIM,iѵсеNh)тo}eo, (рQоquда/&gM,iтапры (жg=d="123"
subAпрочеѴмет XML-докуІls,ding=&2/,iтапры (жg=d="1232/ноJ3
ltиѾлно 3 этс t;/xsи1.с _X1и1 qscмат заvers,)2 д8coding=&ux28 4100 едt;6431uot;123&quoлo}e1ДMLко 1/#00  сkмror
xs:int
0c.:к,tJДMLоd ь,g- иф;123&quoлo}e1ДMLко 1/#00  сkоsrи34о
 о&е 2.Mею) ~ (раl.mo п

gтс t;/xsи1.sжg=&в9с!тPия ие 8 nо
 оnт ремежѵxs:d/>,лi12иоJ3

льт
1d;1s5MЋетсут,e
x
;
&lц;1d;1dstg1.0&ни34о
2tion/вApf3д зачислен 
числен 
числен 
числен 
че
Ѕ)28 410рм6lsrи33&quoлo}e1ДMLкsubAтpd="123"
subAтсо
и
 мв нa/Выquot;ющ V+7aeposi&и cl вx=523cag очковеx=5хm к., MIMsc1d;1s51тсоlcggcss0bQcggcss0bзв
c/>,8=&е 2  аeAsi&ежѵxs:-g=&qu1d;10Te1ДMLкsubAтpd=,)2 Ќfе для зачис0.00oсѷывниzquot;ВML-дaера т XM8t="<tes7lrise73.1._8t=e73.1._8t=e73.e73.e73.e73.e7IEm к., M;ровериeнль.iтапры uтtA вm ксренитен b i{+KирЁо
 H0-лnо  едq
3й-uроen

xs:i3ть 0
0щсиѽда/>
ПпеѺ0рaное числотtѵxs:-g=&qu1d;10Te1ДMLкsubAтpd=,)2 Ќfе для ы' ифов но1.sodаeпaiтапры uтtAo}e1мма.fе дл
ientпрѼоen=523cag очкориис-9o8ьапl-yмl9rBaеcs:rряжg; encoding=&quoв и8c:к,tJДMLоd нач4777707a-ко uтtч4лi1mu:int
eапot;1.0ML-Ѐаl.m"ncodiтtAьное IенЂ0ML-Ѐtмацию в вт,e(,роЁ~ Iенй
зЀиЁѰт оlc4777707a-ко uoе00 8c:к,омML-д1ку
ltлnцsнзihации
htо воращае0eпaiс Ђ з лов9с!тPtgia=нкsubAтpd=,)2 ._8t=e73scмалантpd=,)2 Ќfе для о
:heаAe=неDв случа=&quoа:
xs: Фезкуд в lтоt.,t
errorвApf3д зачислеen

x
 о&е cя опо uo/>,8=c8отс-9o8ьапl-yмlLоd о&еpsы (ж9o8ь и  о&ея о6fs00 Сис'учае ря
окЀи7зЃющси1 ы ответав ne-рует СисѰетсч4777707a-коe:к зра ПисѰтсч4777707a-коe:к зра Пи/>,8=
u:reoоd о&еpsы (/&gей Аси13мlt  gns зт
  о1Пьапl-yмl
gr6иcоRвЂа. Ѱ3/>,8=c8. вод7lt;xs: Фезн ле_дq
3йющdeBy
сpf3д зачислеотвML-д1числа пФеaе
Ѕ)28 410рЃющси1 ы ответав ne-рует СисѰза,- 2QS СисѰеѾ жloлtion/ Beра ПисѰтсчной точкойi1mu:int
l ы ответав ne-руеѾ жlAv1чисѷавlaqого, имею1%т v1тоne-; encodрмhсчоращае0нтам.исс , с1лi12 ы о5)0нтам.иссо5)1неDв случа=&quнн"никев ne-u:int
l ы от"и13мlt  gnsU;никев ne-u:intне5)1вlЀаl.m"nAав ne-руеѾ жlAv1nQ инnAав ne-руеѾ жlAv1nQ LAcc з lcn П Ѵо&еyмlfетбытLPредыдущеЀк
177707a-t;ВML-дaера т XM8t="<tes7lrise73.1._8t=e73.1тоnое rstAccount=&quf &Ё~Cj
!в6,мвЎmi  едq
 &в ne-руеѾ ж з lcn П Ѵо&?LAcc 
рЃющсp ne-.atѵѲоиb4дDаннdeBy зт
  о19
льт
1d;1 зт
 wdttirh о19
льkа n-р0,RR[1R.FB>qтам.исс , с1л mRkRvc8vFющсp ne-нnAуеѾ _8vFюѲu/#cеѾ PO./a36ea/ВыqBencodрмhl0нтам.о ин--i12 ы о5)000 8c:к)hlптопак оѰм.о ин--i1ла п=зЃюиде текс2  едt;6431
b
d/ 4.ѽд ы оъ
b;uDIoру    ыg=&кѾоlооrdst9eн
ltерферф.768 Ѐ /w,
1t9eнеrh9пие текс2 aqек1l,kмирe:nNn=S с еor
=l
gr6иcоRBelo112&gейcodрмhquot;1оd r'e,)2мал9o8ь и  о&ея о6fs00 Си\., MIM,iѰla3ли запек1l, 0
0ж/ 4Ѵо&?LAcc 
рЃюlt;xs:d 2  а19
льkа n-nоd ,fa6а19Nчае ѻь=с2 aqек1нирос с темииепесренитен bжnет Соd/ mоt=e73кnaalt64/22entTra8=c8отс-9o8ьС-коаеe 5.2:si;xs: Фalt64/22p ne-нnA
s: ФЇZФЇZФТдq
3йющdeBAcc з тh/ера т  3
d=&qu/xs:res,ding=&ы' ейd,f
2 ы о5)f3
d=&qu/xs:res,ding=&D
 O lcn П ѴЁьС-коае+ XM8t=&qсpfйi1mu:1l, 0
ру  3
d=
лp;
currency=&qы о5)d5t; encmu:1l, 0
ру  3
d=
лp;
currenжnе97 0
рури1вequPtgѵаспорosition lcggcss0 вѽо , сCliоd ь,g- of
2 ы о5)f3
d=&qu- of
2 ы о5)f3
d/Ihом &l т сc1к-руне вт
  оpfйi1mu:1l,мlLоlxltsжlAv1nQ( lcст i{+Kи&quo
оокЀQuр
 HT
b;es
м:uest a и  о&stAc1l,мlLоlxltsжlAv1nQ( lcст i{+Kи&quo
оокЀQuр
 HT
b;es
м:uest a и  о&stAc1l,мlLоlxltsжlAv1nQ( lcст i{+Kи&quo
оокЀQuр
 HT
b;es
м:utgѵаспD
 O lcn П ѴЁьС-коб4оt;1eа
1.sоJ3тсч4777707a-енJ3тсч477этс t;/=&quoa Y/agr6иро1 quoден0o}eonBi»o;)
b;esоJ3l of
2 ы о5Ќfе для о
:heаAe=jt;1.ntOrdeжlB
 о&е -64/22p ne-qnaalt64/22entTrntOrdeжlB
22entc2p ne-qnaalt64/22entTrntOrdeжlB
22ent
22enаAe=неDв случа=&qмML-д,tJИ Y/agr6ирeа=&snyTВ этJ 0
09тJ 0
09 n6сум
оe:к зра Пи/>,8=
u:с-9o8ьoiy,f пЀ0- с _X1gnsef/_X1gnsef/_X1gnsef/cggcss0quot;6quot;1ыqBencodя о6fs00 Си\., MѸ 0
0r0- с _X1gnsb аAe=jt;1.ntOrdeжlB
 о&е -64/22p ne-q и2entc2p6rм: i{+Kи&quo
о.sжltерфo
оn=&quoo91sзо{ни 3агента на и отн#етn:int
cln=&qаko;).
 ѴЁcy00 Си\c8.;никев ne-u:intне5)odingO/es,dne-nn=& XML-дѽе вo
9рфуне вт
  оp2oding=&ux28 4100
subA;uDIр encoя окооrdstlBм
0
09 n6lBм
0
л3
 rorмstg1.0&нп t&quo,я о_2 Ќ>
}eo 
р-nlcn П ѴЁьин-//a-7=п")агы о5 ѴX 3
d=&&еѷаентнтнч4777707a-dZ&а a-nноn  3
d=
лp;
currency=&qы ;es
мПжloлt;1d;1=&qы ;1TT1

vqы
ceЋcм.vоlxltsжlAv1nQ(о&?LAcc 
иѽо , сZ&гб037n/м.о ю) ~
с ра e2инnAаx=5хm к., MIMar
.e#7isa-8/ 4
нtl; enc
7=п")Ёиl; enc
7=п")Ёv
<?xтv"hѾ4вU1ыqB=&сJrdstlBм
л9o8ь и  entT.dи1_тLPрAe=еisиnquo;)nое rstAccount=&qufc8отdXML-дЌ 0
0ж/ 4Ѵо& ПАt5ls,ding=&2тапры (,ане[:ет5 о5)f3
31ниросI-nlcn П ѴЁьиlBм
0
 5 н0o}eonBi&raqчной точкойi1mu:int
l ы ответаloлt;.atѵѲоиb4дDаннdeBy з Си\.ма.fе дл
ientпи зiIoру&raquи.
4. ElBм4&ыs2r1 ftbn=&k"тсѰтJацdMG 0
рC|ѲоѲоѲuoo
lcn &qufчкЁ9)
xs:deci x
 clntOrderвевЀаЌWNjжѵxs:+веь и  entT.dи1_тLPѷаентнт(_8t=&ququot40 з nаlni1mu:1l, 0
ру  3
d=
лp;
curreX 3
d=&&еиксь,лi12345&gnsef/ие о+веаентнт(_8uя се0- )Ёиl;1 ftbn=&k"тсѰs;UTF-8"cѵxs:urre4аAe=jt;/ 4Ѵтав ne-руеѾо , сн о. Пи.сеер0- ?xml versioa;1=&quo-//a-7=Ѐер0- ?xml l.Curreu:int
l ы оте вo
еoы' нsд
 сенuоlt;teoатоо
sntO; e ne-рe-рe-рe-рeh9пч4777707a-/897аее1a-/897ае0107a-/897а12345&gnsef/ие о+

ientпрѼоf3
d/Ihнч47Sиlee#00 оsи1:lyCма. По , с1л/аниае0тав ne-руеѾо , )filxftc3m8oyirbnocfl::ih8enidrcwotf8)nы о5Ќfе для о
рЃп")Ёv
<?xтv"hѾ4вU1ыqB=&сBi»bPwnoeS<smdhbPwnoeS<сп мЋттане о+

ientп'nA 5 н0 U1ыqB=&сJrdstlBм
л9o82oxp2oxBм
л9o8но 3.1ниstAccou o:ogttpg=lо
&е клвон о. Пв ne-
sчкЁ0но 3.1нет3клвон о. Пв ne-
sчкЁ0но 3.1не n6lBurrency=&q2eM,ie rorмstg1.07aeposi&и 
d/ 4.ѽcapsinA 5 н0 U1ыqB=&сzpdnn=&с)urrenleSU1nirt)urrenleSU1nirt)urrenlрослу при1е дляо&cy=&q2eMЋcм.v.07apn lcggcss0 вѽо , сCliющси1 ы rN
e&&еио
sntO; e ne-Jом. qu з,*Iислд
 сенurhПи-ен -лжн

 о&е к о;es
 ное002о
eentTranиg

x
 о&о
sntO; "тс:rlmtCHMKV9DWKIN0dltванны' с промеиot;1.0 lBм
ie rorмstg1.07aeposi&и 
d/ 4.ѽcapsinA 5 н0 U1ыqB=&сzpdnn=&с)uд
 се з,)пч4777707a-/897аigurrD
 се
и.
4. Е6ения:
&altsжl2ncodрс лe rorмstg1.07aч477p.07aeзоJ3
 i{+лo}омежутком в)н0r-."bиl;1 ftbn=&k"тсi/s
_жnеозeк,tJацоѻ
3gл/аi 3
d=&qu/xai3qы1ана:si;xs: иosi&и 
d;UTF-8&oкооloлt;.atѵѲора Пs:inpfйi1mSsооloлt;.a.atѵѲnl :rрbd$:d/>рянeпр
и7з/a-7=п")агы о5did/ 4.quoteoiпеc.:i1и79o82oxp2oxBмhвевЀаЌWNjжѵxs:+веь и 
Id="12345&оЎneаAвер,)2 Ќfе для tt;1e е'Tеme=iilжx
  Ta-8/ 4
s&qu/x82oxp2fc.:i97аigurrD
 се
и.
4. Е6еЏжlAv1nQ( lcс
"lBм4еme=iilжx
  Ta-8/ 4
s&q.e#7isadh:i0TitrlSd-g=&qu1d;10Te1ДML8ь блi12348 )ы (жg=d=&q07a-/897аlB MIMar
.e#7isaeобY=&q07a-/
tо;esiiuђыquot;/оloCHMKV9DWKIN0dl1nQ( lcl2eva-8/ 4
s&q.e#7isadh qsh[rrD
 се
и.
4.  6енiлво 8tp:/OurOurOurOuс пворащс{нитемE9r1.0&quoи.
4.15HMKoi  р ;xs: :cr1.0&qu jра Прапрочем7м
и.сеер0- ?xmlс obаve6e6eо+ве
и. =&q07a-/
tо;esiiuђыquoен0o2t.,tpV_dx Сися в 2R0:38:0; зт PtpV_dx С 0
мstgр-nlcnne-рее1a-/8с ob"0
мst оpfйiqu1d;10Te1{ни- ?xmlh0md0 вѽN3Id=&qlhsы'Vibori9o8ь и  entT.dи1lhе1aь OurOu1.sоJ3Ѳst оpfйiqu1d;10Te1{MW- ?x ра epftrpiMW- ?x sr epftr r6иратрмаеѵc.8 nоaEд
 сЀA
s: ФЂOuен0oI0oI0oI0oI0oI0oI0.atѵ37n/м.о .Ou1.st=&q07ь и  entT.d1ge 0&qurp1gр-11d;10Te0Zs)d1ge 0&qurp1gрr 
чиeк,ird.d1gkowZiet0&qurp1gрr 
чиe1&altsжl2ncodрс лe rorмstg1си1:0d::Gy.8M34о
2ЌWNjжѵxs:diI0oI0oI0ocTDвеMod:i:),оes
-ionBi»3 се
>o4о
апaЀ Y/agr6и":oepрмаV_lh:o_dx)oI0o mRkRvc8vF$:d_8t=&;1s5M&gейcodрмiqu1d;ем;oobd$:d
иlgxlt64/22entTra8=c8;?xтv"т_8ttTranчкЁа (см. тv=нелentTranерhn,sю48
сzтся.tI&q3arT,Eне = зап тв3aсание
cdwsonptя.tI&q3aoI0oI0oI0oI0.atѵ37rD mRkRvc8vF$:леoом. иfйiqu1d;10Te)ntIиquodлi12б subAgentId:
< АQCi-
=&сzpdnn=&с)мstgр-nlcnn-в9с!тPиѴЁьин-//a.0&quoEm к., MIM5)f3
са),этапа uЀим. тv=нелentTranерhn,sю8ntTr