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 запроса.
Время обработки запроса по часам сервера Системы. В
случае успеха операции зачисления — фактическое
время зачисления средств на счет.
Разница между суммой переводов, принятых
Контрагентом в пользу Системы, и суммой средств,
перечисленных Контрагентом на расчетный счет
Системы. Может быть отрицательным. Данный
параметр передается в ответе только на запрос
makeDeposition
и
только
если
зачисление
выполнено успешно.
Опциональное
поле.
Может
содержать
дополнительный поясняющий текст к отказам в
приеме перевода. Этот текст содержит техническую
информацию и не должен отображаться в каком-либо
интерфейсе пользователя.
Пример ответа о возможности зачисления:
<?xml version="1.0" encoding="UTF-8"?>
<testDepositionResponse clientOrderId="12345"
status="0"
processedDT="2011-07-01T20:38:01.000Z"/>
Пример ответа об успешном зачислении:
<?xml version="1.0" encoding="UTF-8"?>
<makeDepositionResponse clientOrderId="12345"
status="0"
processedDT="2011-07-01T20:38:01.000Z"
balance="1000.00"/>
Передача идентификационных данных (makeIdentificationDeposition)
Запрос предназначен для передачи Системе идентификационных данных пользователя (см. раздел 0
«Принципы работы»), подтвержденных Контрагентом. Передача идентификационных данных невозможна
без осуществления парного перевода.
Важно! Необходимо осуществлять проверку возможности зачисления указанной суммы на указанный Счет
в Системе, а также корректность идентификационных данных до выполнения makeIdentificationDeposition.
Запрос testIdentificationDeposition позволяет проверить параметры запроса до принятия средств от клиента.
Примечание: нельзя полностью исключить вероятность того, что между «проверкой возможности
зачисления с идентификацией» и «зачислением с идентификацией» состояние Системы изменится и
зачисление будет отвергнуто.
Адрес операции проверки возможности зачисления с идентификацией:
https://server:port/webservice/deposition/api/testIdentificationDeposition
Адрес операции зачисления с идентификацией:
https://server:port/webservice/deposition/api/makeIdentificationDeposition
выплаты on-line лайт
Формат запросов ИС
Таблица 4.3.1.1. Параметры запроса операций testIdentificationDeposition, makeIdentificationDeposition (все
параметры обязательные, кроме отмеченных символом «*»)
Параметр
Тип
Описание
clientOrderId
ClientTransactionNumber
requestDT
xs:dateTime
dstAccount
YMAccount
amount
currency
CurrencyAmount
CurrencyCode
agentId
subAgentId (*)
xs:long
xs:long
contract
xs:normalizedString, до 128
символов
docType
xs:int
docNumber
xs:normalizedString, до 33
символов
issueDate
xs:date
Идентификатор операции. Должен быть уникальным
для Контрагента на протяжении всей истории
операций. Рекомендуемые значения: целое
положительное число в десятичной системе счисления.
Дата и время формирования запроса операции на
стороне ИС, по часам Контрагента.
Идентификатор пользователя в Системе, на Счет
которого будет зачислен перевод, например:
4100175017397.
Номера телефонов и иные идентификаторы
получателя перевода не допускаются.
Сумма перевода, например: 12.34
Код валюты перевода. Возможные значения:
 643 — рубль Российской Федерации;
 10643 — тестовая валюта (демо-рублики
демо-системы «Яндекс.Деньги»).
Идентификатор Контрагента. Выдается Системой.
Уникальный идентификатор канала приема переводов.
Указывается только в случае разделения приема
переводов по нескольким каналам. Выдается
Системой.
Основание для зачисления перевода.
Необходимо указывать «Идентификация через систему
Название_Контрагента».
Тип идентифицирующего документа:
 21 - паспорт гражданина РФ;
 7 - военный билет солдата (матроса,
сержанта, старшины).
(Прочие коды см. в документе «Справочник типов
идентифицирующих документов».)
Серия и номер предъявленного документа. Между
серией и номером один пробел, символ № не
используется. Пример: 4004 123987.
Дата выдачи документа. YYYY-MM-DD.
authorityName
xs:normalizedString, до 129
символов
xs:normalizedString, до 65
символов
authorityCode (*)
expirationDate (*)
xs:date
residence
xs:normalizedString, до 256
символов
xs:int
nationality
birthDate
xs:date
Наименование государственного органа, выдавшего
документ (кем выдан).
Код подразделения, выдавшего документ. В случае
предъявления паспорта гражданина РФ (docType=21)
является обязательным параметром. Пример: 780025.
Дата окончания действия предъявленного документа.
Заполняется, только если дата явно указана в
документе.
Адрес места жительства владельца Счета.
Гражданство владельца Счета:
 643 – Российская Федерация;
 112 – Беларусь;
 398 – Казахстан;
 804 – Украина.
(Прочие коды см. в документе «Справочник кодов
стран мира».)
Дата рождения владельца Cчета. YYYY-MM-DD.
выплаты on-line лайт
birthPlace
xs:normalizedString,
символов
до
65
Место рождения владельца счета. Заполняется по
данным, предоставленным владельцем счета, если
место рождения не указано в документе.
Фамилия владельца Cчета. Допустимо использование
дефиса внутри двойных фамилий.
Имя владельца Cчета. Допустимо использование
дефиса внутри двойных имен.
Отчество
владельца
Cчета.
Отчество
может
отсутствовать.
Неформализованный комментарий.
xs:normalizedString, до 65
символов
name
xs:normalizedString, до 65
символов
patronymic (*)
xs:normalizedString, до 65
символов
comment (*)
xs:normalizedString, до 256
символов
Пример запроса проверки возможности зачисления с идентификацией:
surname
<?xml version="1.0" encoding="UTF-8"?>
<testIdentificationDepositionRequest
agentId="123"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Идентификация через систему Название_системы">
<identification
docType="21"
docNumber="4004 123987"
issueDate="1976-01-01"
authorityName="25 о/м Приморского р-на г. Санкт-Петербурга"
authorityCode="780-025"
residence="г.Санкт-Петербург, 3-я улица Строителей, д.25, кв.12"
nationality="643"
birthDate="1940-01-01"
birthPlace="гор.Ленинград"
surname="ЛУКАШИН"
name="ЕВГЕНИЙ"
patronymic="МИХАЙЛОВИЧ"
/>
</testIdentificationDepositionRequest>
Пример запроса проверки возможности зачисления с идентификацией c указанием subAgentId:
<?xml version="1.0" encoding="UTF-8"?>
<testIdentificationDepositionRequest
agentId="123"
subAgentId="456"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Идентификация через систему Название_системы">
<identification
docType="21"
docNumber="4004 123987"
issueDate="1976-01-01"
authorityName="25 о/м Приморского р-на г. Санкт-Петербурга"
authorityCode="780-025"
residence="г.Санкт-Петербург, 3-я улица Строителей, д.25, кв.12"
nationality="643"
birthDate="1940-01-01"
birthPlace="гор.Ленинград"
surname="ЛУКАШИН"
name="ЕВГЕНИЙ"
patronymic="МИХАЙЛОВИЧ"
/>
</testIdentificationDepositionRequest>
выплаты on-line лайт
Пример запроса на зачисление с идентификацией:
<?xml version="1.0" encoding="UTF-8"?>
<makeIdentificationDepositionRequest
agentId="123"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Идентификация через систему Название_системы">
<identification
docType="21"
docNumber="4004 123987"
issueDate="1976-01-01"
authorityName="25 о/м Приморского р-на г. Санкт-Петербурга"
authorityCode="780-025"
residence="г.Санкт-Петербург, 3-я улица Строителей, д.25, кв.12"
nationality="643"
birthDate="1940-01-01"
birthPlace="гор.Ленинград"
surname="ЛУКАШИН"
name="ЕВГЕНИЙ"
patronymic="МИХАЙЛОВИЧ"
/>
</makeIdentificationDepositionRequest>
Пример запроса на зачисление с идентификацией c указанием subAgentId:
<?xml version="1.0" encoding="UTF-8"?>
<makeIdentificationDepositionRequest
agentId="123"
subAgentId="456"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"
dstAccount="410011234567"
amount="10.00"
currency="643"
contract="Идентификация через систему Название_системы">
<identification
docType="21"
docNumber="4004 123987"
issueDate="1976-01-01"
authorityName="25 о/м Приморского р-на г. Санкт-Петербурга"
authorityCode="780-025"
residence="г.Санкт-Петербург, 3-я улица Строителей, д.25, кв.12"
nationality="643"
birthDate="1940-01-01"
birthPlace="гор.Ленинград"
surname="ЛУКАШИН"
name="ЕВГЕНИЙ"
patronymic="МИХАЙЛОВИЧ"
/>
</makeIdentificationDepositionRequest>
Формат ответов Системы
Таблица 4.3.2.1. Параметры ответа операций testIdentificationDeposition, makeIdentificationDeposition
Параметр
Тип
Описание
status
xs:int
error
xs:int
Результат выполнения операции. По значению этого
поля ИС Контрагента должна принимать решение о
состоянии запроса. См. табл. 5.1.1 «Коды состояний
запроса».
Код ошибки выполнения запроса (см. таблицу 5.2.1).
Является дополнительной расшифровкой к полю
status. В случае успеха поле отсутствует.
выплаты on-line лайт
clientOrderId
processedDT
ClientTransactionNumber
xs:dateTime
balance
xs:decimal
techMessage
xs:string
Копия параметра clientOrderId запроса.
Время обработки запроса по часам сервера Системы. В
случае успеха операции зачисления с идентификацией
— фактическое время зачисления средств на счет.
Разница между суммой переводов, принятых
Контрагентом в пользу Системы, и суммой средств,
перечисленных Контрагентом на расчетный счет
Системы. Может быть отрицательным. Данный
параметр передается в ответе только на запрос
makeIdentificationDeposition
и
только
если
зачисление с идентификацией выполнено успешно.
Опциональное
поле.
Может
содержать
дополнительный поясняющий текст к отказам в
приеме перевода. Этот текст содержит техническую
информацию и не должен отображаться в каком-либо
интерфейсе пользователя.
Пример ответа о возможности зачисления с идентификацией:
<?xml version="1.0" encoding="UTF-8"?>
<testIdentificationDepositionResponse clientOrderId="12345"
status="0"
processedDT="2011-07-01T20:38:01.000Z"/>
Пример ответа об успешном зачислении с идентификацией:
<?xml version="1.0" encoding="UTF-8"?>
<makeIdentificationDepositionResponse clientOrderId="12345"
status="0"
processedDT="2011-07-01T20:38:01.000Z"
balance="1000.00"/>
Запрос баланса Контрагента (balance)
Данный запрос позволяет узнать баланс в Системе по операциям Контрагента. В ответе на запрос
возвращается разница между суммой переводов, принятых Контрагентом в пользу Системы, и суммой
средств перечисленных Контрагентом на расчетный счет Системы.
Адрес операции: https://server:port/webservice/deposition/api/balance
Формат запроса ИС:
Таблица 4.4.1. Параметры запроса операции balance
Параметр
Тип
Описание
clientOrderId
ClientTransactionNumber
requestDT
xs:dateTime
agentId
xs:long
Идентификатор операции. Должен быть уникальным
для Контрагента на протяжении всей истории
операций. Рекомендуемые значения: целое
положительное число в десятичной системе счисления.
Дата и время формирования запроса операции на
стороне ИС, по часам Контрагента.
Идентификатор Контрагента. Выдается Системой.
Пример запроса проверки баланса:
<?xml version="1.0" encoding="UTF-8"?>
<balanceRequest agentId="123"
clientOrderId="12345"
requestDT="2011-07-01T20:38:00.000Z"/>
Формат ответа Системы:
Таблица 4.4.2. Параметры ответа операции balance
выплаты on-line лайт
Параметр
Тип
Описание
status
xs:int
error
xs:int
clientOrderId
processedDT
ClientTransactionNumber
xs:dateTime
Результат выполнения операции. По значению этого
поля ИС Контрагента должна принимать решение о
состоянии запроса. См. табл. 5.1.1 «Коды состояний
запроса».
Код ошибки выполнения запроса (см. таблицу 5.2.1).
Является дополнительной расшифровкой к полю
status. В случае успеха поле отсутствует.
Копия параметра clientOrderId запроса.
Время обработки запроса по часам сервера Системы.
balance
xs:decimal
Разница между суммой переводов, принятых
Контрагентом в пользу Системы, и суммой средств,
перечисленных Контрагентом на расчетный счет
Системы. Может быть отрицательным.
Пример ответа о состоянии баланса:
<?xml version="1.0" encoding="UTF-8"?>
<balanceResponse clientOrderId="12345"
status="0"
processedDT="2011-07-01T20:38:01.000Z"
balance="1000.00"/>
Справочники
Состояния обработки запроса
Таблица 5.1.1. Коды состояний запросов ИС
Код
состояния
0
1
3
Описание
Успех. Обработка завершена. Запрос выполнен успешно. Зачисление перевода
проведено успешно.
В обработке. Запрос в процессе обработки. Возвращается, если истекло время
ожидания завершения обработки запроса. Требуется повторить запрос для уточнения
результата.
Отвергнут. Обработка завершена. Запрос обработан и отвергнут. Причина отказа
передается в параметре error.
Коды ошибок обработки запросов
Таблица 5.2.1. Ошибки, возвращаемые при обработке запросов ИС
Код ошибки
Описание ошибки
Ошибки параметров запроса
10
Ошибка синтаксического разбора XML-документа. Синтаксис документа нарушен,
отсутствуют обязательные элементы XML.
11
Отсутствует или неверно задан идентификатор Контрагента (agentId).
12
Отсутствует или неверно задан идентификатор канала приема переводов (subAgentId).
14
Отсутствует или неверно задана валюта (currency).
15
Отсутствует или неверно задано время формирования документа (requestDT).
16
Отсутствует или неверно задан идентификатор получателя средств (dstAccount).
либо
17
Отсутствует или неверно задана сумма (amount).
18
Отсутствует или неверно задан номер транзакции (clientOrderId).
19
Отсутствует или неверно задано поле текст контракта (contract).
21
Запрашиваемая операция запрещена для данного типа подключения Контрагента.
26
Операция с таким номером транзакции (clientOrderId), но другими параметрами уже выполнялась.
50
Невозможно открыть криптосообщение, ошибка целостности пакета.
51
АСП не подтверждена (данные подписи не совпадают с документом).
53
Запрос подписан неизвестным Системе сертификатом.
55
Истек срок действия сертификата ИС Контрагента.
Ошибки в идентификационных данных
60
Отсутствует или неверно задано значение параметра docType.
выплаты on-line лайт
61
Отсутствует или неверно задано значение параметра docNumber.
62
Отсутствует или неверно задано значение параметра issueDate.
63
Отсутствует или неверно задано значение параметра authorityName.
64
Отсутствует или неверно задано значение параметра authorityCode.
65
Неверно задано значение параметра expirationDate.
66
Отсутствует или неверно задано значение параметра residence.
67
Отсутствует или неверно задано значение параметра nationality.
68
Отсутствует или неверно задано значение параметра birthDate.
69
Отсутствует или неверно задано значение параметра surname.
70
Отсутствует или неверно задано значение параметра name.
71
Неверно задано значение параметра patronymic.
72
Неверно задано значение параметра comment.
73
Отсутствует или неверно задано значение параметра birthPlace.
Ошибки обработки зачисления
40
Счет закрыт.
41
Счет в Системе заблокирован. Данная операция для счета запрещена.
42
Счета с таким идентификатором не существует.
43
Превышено ограничение на единовременно зачисляемую сумму.
44
Превышено ограничение на максимальную сумму зачислений за период времени.
45
Недостаточно средств для проведения операции.
46
Сумма операции слишком мала.
Прочие ошибки
30
Технические проблемы на стороне Системы. Рекомендуется повторять запрос с разумным
интервалом (см. рекомендации в разделе 4.1).
От Оператора:
От Контрагента:
М.П.
М.П.
Председатель Правления Шабанова Т.А.
Должность, ФИО
выплаты on-line лайт
Приложение №3
К договору об информационно-технологическом взаимодействии
при перечислении денежных средств в пользу физических лиц
№_________ от_____
ФОРМАТ РЕЕСТРА ЗАЧИСЛЕНИЙ
Версия от 08.06.2012
Принципы работы
Ежедневно система «Яндекс.Деньги» (далее Система) формирует реестр успешных переводов на
счета в системе, проведенных за предыдущие сутки. «Сутками» считается период времени от
00:00:00.000+04 по 23:59:59.999999+04:00 (от полуночи до полуночи по московскому времени).
Реестр формируется в виде файла. Формат файла соответствует спецификации CSV (comma-separated
values). Формат файла совместим с программой Microsoft Excel. Описание формата CSV см. в Формат
данных CSV (Comma Separated Values). Кодировка символов – UTF-8.
Формат имени файла
settlement_file_agentId_YYYY-MM-DD_registerId.csv
Таблица 1. Поля имени файла
Поле
Описание
agentId
Идентификатор Контрагента в Системе.
YYYY-MM-DD
Дата начала отчетного периода реестра, год-месяц-день.
registerId
Идентификатор сформированного реестра, уникальный на протяжении всей истории
операций.
Пример имени файла
settlement_file_159001_2011-07-01_13467262.csv
Реестр отправляется электронной почтой в виде письма в формате S/MIME. Реестр подписан ключом
оператора системы и зашифрован на сертификат Контрагента.
Для того чтобы открыть письмо с реестром Контрагенту требуется:
 Установить сертификат Оператора Системы в хранилище доверенных сертификатов;
 Установить ключевую пару Контрагента в хранилище личных сертификатов;
 Использовать любую почтовую программу, поддерживающую формат S/MIME (Microsoft Outlook,
Mozilla Thunderbird и другие). Расшифровка и открытие сообщения с реестром происходит
прозрачно для пользователя, без специальных действий.
Контрагент должен получить сертификат, с использованием которого он cможет получать реестры от
Оператора Системы. См. документ «Процедура обмена сертификатами».
Структура реестра
Реестр состоит из следующих элементов:
 заголовка реестра, содержащего данные о номере и дате реестра;
 список переводов;
 контрольная строка или маркер отсутствия переводов в конце реестра.
Заголовок реестра (HD строка)
Заголовок реестра содержит:
 Идентификатор Контрагента в Системе;
 Серийный номер реестра (идентификатор реестра);
выплаты on-line лайт

Отчетный период, за который сформирован реестр.
Формат строки
HD;agentId;registerId;from;till
Таблица 2. Поля заголовка реестра
Поле
Тип данных
registerId
xs:long
agentId
from
xs:long
xs:dateTime
till
xs:dateTime
Описание
Идентификатор
сформированного
реестра,
уникальный на протяжении всей истории операций.
Идентификатор Контрагента в Системе.
Начало отчетного периода, за который сформирован
реестр, включительно («от» включая).
Конец отчетного периода, за который сформирован
реестр, исключительно («до» не включая).
Пример строки
HD;123;456;2011-07-01T00:00:00.000+04:00;2011-07-02T00:00:00.000+04:00
Зачисление (D строка)
Для каждого перевода, зачисленного за отчетный период, формируется отдельная D-строка.
Внимание! Временем совершения операции считается время, возвращенное сервером Системы в поле
processedDT в ответе на запрос Контрагента. Границы отчетного периода исчисляются в соответствии со
значением поля processedDT.
Формат строки
D;clientOrderId;amount;currency;ymAccount;processedDT;subAgentId
Таблица 3. Поля зачисления
Поле
Тип данных
clientOrderId
ClientTransactionNumber
amount
currency
ymAccount
CurrencyAmount
CurrencyCode
YMAccount
processedDT
xs:dateTime
subAgentId
xs:long
Описание
Идентификатор операции, ранее указанный
Контрагентом для данной операции.
Сумма операции.
Код валюты по ISO-4217 (643 - рубль РФ)
Идентификатор получателя перевода в системе
"Яндекс.Деньги"
Время зачисления средств на счет получателя, ранее
возвращенное в ответе на запрос операции
зачисления.
Идентификатор канала приема переводов.
Необязательный параметр. Присутствует в случае,
если Контрагент разделяет платежи по нескольким
каналам.
Пример строки
D;123;1000.00;643;41001000040;2011-07-01T10:52:01.000+04:00
Пример строки для Контрагента разделяющего переводы по subAgentId
D;123;1000.00;643;41001000040;2011-07-01T10:52:01.000+04:00;456
Контрольная строка (TD строка)
Контрольная строка представляет собой сумму операций по реестру. Для нулевого реестра
контрольная строка отсутствует.
Формат строки
TD;count;sum;currency
Таблица 4. Поля контрольной строки
выплаты on-line лайт
Поле
count
sum
currency
Тип данных
xs:int
CurrencyAmount
CurrencyCode
Описание
Количество операций в реестре.
Общая сумма по операциям в реестре.
Код валюты суммы по ISO-4217 (643 - рубль РФ)
Пример строки
TD;10;10547.25;643
Нулевая строка (Z строка)
Указывает, что за данный отчетный период операций не было (нулевой реестр). Присутствует только
для нулевого реестра.
Формат строки
Z
Пример строки
Z
Примеры реестров
Пример реестра за сутки 01.07.2011
HD;123;456;2011-07-01T00:00:00.000+04:00;2011-07-02T00:00:00.000+04:00
D;123;1000.00;643;41001000040;2011-07-01T10:52:01.000+04:00;456
D;124;25000.00;643;41001000040;2011-07-01T10:52:02.000+04:00;457
TD;2;26000.00;643
Пример нулевого реестра за сутки 01.07.2011
HD;123;456;2011-07-01T00:00:00.000+04:00;2011-07-02T00:00:00.000+04:00
Z
Приложения
Формат данных CSV (Comma Separated Values)
Реализация формата CSV соответствует рекомендации IETF RFC4180 http://tools.ietf.org/html/rfc4180
.
Разделитель полей точка с запятой «;». Кодировка символов - UTF-8.
Текстовый формат CSV представляет собой набор строк, разделенных символом переноса строки (LF
или CRLF). Каждая строка содержит поля, разделенные точкой с запятой «;». Если в значении параметра
встречаются символы двойные кавычки «"» или точки с запятой «;» или переносы строк, то такие
параметры должны заключаться в кавычки «"». Если в значении поля присутствуют кавычки, то они
удваиваются:
Пример
643;5000.00;”ОАО КБ ””Банк”””
Допустимо помещать в кавычки все поля, вне зависимости от присутствующего в них набора
символов. Если поле не помещено в кавычки, то все «соседние» пробелы (до точек с запятой или до начала
или конца строки) игнорируются.
Обязательные и необязательные параметры, NULL значения
NULL-значение (отсутствие данных) поля указывается как пустая строка (строка нулевой длины).
Значение поля “пустая строка” указывается как строка нулевой длины, заключенная в двойные
кавычки.
выплаты on-line лайт
Структура CSV документа требует обязательного наличия всех полей. Разрешается опускать
необязательные поля, но только в том случае, если они находятся в конце строки.
Пример: NULL значение в середине строки
col1;;col2
Пример: «пустое» значение в середине строки
col1;””;col2
Пример: отсутствующие необязательные поля в середине строки
col1;col2;;;col3
Пример: отсутствующие необязательные поля в конце строки
col1;col2;;;
col1;col2
Типы данных
Таблица 5. Типы данных
Тип
Описание
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
год, точно 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 часа.
выплаты on-line лайт
ClientTransactionNumber
Уникальный идентификатор операции. Должен быть уникальным для
Контрагента на протяжении всей истории операций. Значением параметра
должна быть строка длиной от 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>
Идентификатор получателя перевода, строка десятичных цифр длиной до
33 символов.
YMAccount
<xs:simpleType name="YMAccount">
<xs:restriction base="xs:normalizedString">
<xs:maxLength value="33"/>
<xs:pattern value="[0-9]+"/>
</xs:restriction>
</xs:simpleType>
В качестве идентификатора может использоваться:
 Счет пользователя в Системе (вида 4100175017397; длина
существующих в Системе Счетов на данный момент варьируется
от 10 до 16 цифр);
 номер телефона пользователя, привязанный к Счету в Системе
(допускаются номера российских операторов, рекомендуемое
представление – 10-значные номера вида 9217575400, без
дополнительных символов и пробелов);
 код платежа в ООО «Яндекс» (все номера, начинающиеся с «50»,
«51»).
Сумма. Положительное десятичное число с фиксированной точкой, кол-во
цифр после точки точно равно двум.
CurrencyAmount
<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>
Код валюты. Возможные значения:
 643 — рубль Российской Федерации;
 10643 — тестовая валюта (демо-рублики
«Яндекс.Деньги»).
CurrencyCode
<xs:simpleType name="CurrencyCode">
<xs:restriction base="xs:int">
</xs:restriction>
</xs:simpleType>
От Оператора:
От Контрагента:
М.П.
М.П.
Председатель Правления Шабанова Т.А.
Должность, ФИО
демо-системы
выплаты on-line лайт
Приложение №4
К договору об информационно-технологическом взаимодействии
при перечислении денежных средств в пользу физических лиц
№_________ от_____
АКТ
об оказанных услугах
по Договору № ____________ от «____» ______________ 20___ г.
г. Москва
«____» ____________ 20___ г.
____________________________________ «___________», именуем(__) в дальнейшем «Оператор», в лице
______________________________, действующего на основании _________________, составил (__),
а_______________________________________, именуемое в дальнейшем «Контрагент» , в
лице______________________________________, действующего на основании ____________а, утвердил(__) настоящий
Акт о том, что Оператор надлежащим образом исполнил обязательства по Договору в соответствии с
нижеприведенными данными:
1
Дата, время начала Отчетного периода
[ДД/MM/ГГ]
[ЧЧ:ММ:СС]
2
Дата, время конца Отчетного периода
[ДД/MM/ГГ]
[ЧЧ:ММ:СС]
3
Задолженность Контрагента перед Оператором на начало Отчетного
периода
[сумма цифрами]
[сумма прописью]
4
Задолженность Оператора перед Контрагентом на начало Отчетного
периода
[сумма цифрами]
[сумма прописью]
5
Общая сумма зачислений за Отчетный период
[сумма цифрами]
[сумма прописью]
6
Сумма вознаграждения Оператора за оказанные в отчетном периоде
услуги, НДС не облагается
[сумма цифрами]
[сумма прописью]
7
Перечислено Контрагентом на расчетный счет Оператора в Отчетном
периоде
[сумма цифрами]
[сумма прописью]
8
Перечислено Контрагентом вознаграждение на расчетный счет
Оператора в Отчетном периоде
[сумма цифрами]
[сумма прописью]
9
Задолженность Оператора перед Контрагентом на конец Отчетного
периода
[сумма цифрами]
[сумма прописью]
10
Задолженность Контрагента перед Оператором на конец Отчетного
периода
[сумма цифрами]
[сумма прописью]
Контрагент не имеет претензий по выполненным Оператором действиям.
Настоящий Акт составлен, утвержден и подписан в двух экземплярах, имеющих одинаковую юридическую силу, по
одному для Оператора и Контрагента.
От Оператора
От Контрагента:
_______________/_______________./
_______________ /_________________ /
м.п.
м.п.
1/--страниц
Пожаловаться на содержимое документа