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

Приложение № 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. Электронный документооборот — система работы с электронными документами, при которой все электронные документы создаются, передаются и хранятся с помощью информационно-коммуникационных технологий на компьютерах, объединенных в сетевую структуру.

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. Самоподписанный сертификат — сертификат, который подписан ключом ЭП, соответствующим ключу проверки ЭП из этого сертификата. В полях издателя сертификата содержатся те же данные, что и в полях владельца сертификата.

2.16. Создание ЭП — результат работы средства ЭП при создании ЭП, в результате которого получается последовательность бит данных фиксированной длины после криптографического преобразования электронного документа в хеш и шифрования хеша ключом электронной подписи. Длина названия алгоритмов хеширования и шифрования задаются в Сертификате.

2.17. Подтверждение подлинности ЭП в ПЭД — положительный результат работы средства ЭП при проверке ЭП. Результат работы считается положительным, если после расшифрования ЭП с помощью ключа проверки ЭП по заданному в Сертификате криптографическому алгоритму получается значение, равное хешу электронного документа, полученному по заданному в Сертификате соответствующему криптографическому алгоритму.

2.18. Хеш — результат работы хеширующей функции, которая преобразовывает входной массив данных произвольной длины в выходную битовую строку фиксированной длины.

2.19. Участники электронного документооборота — лица, осуществляющие обмен информацией в электронной форме в рамках данного Соглашения.

2.20. Компрометация ключа ЭП — нарушение конфиденциальности ключа ЭП, при котором значение закрытого ключа стало известно лицу, не являющемуся владельцем Сертификата.

2.21. Основной договор — Договор об информационно – технологическом взаимодействии при осуществлении переводов физических лиц, совершаемых ими при оформлении заказов на сервисе Яндекс.Маркет, заключенный между Оператором, Контрагентом и Яндексом.

2.22. Система — комплекс программно-аппаратных средств, позволяющий осуществлять электронный документооборот между Оператором и Контрагентом в рамках настоящего Соглашения. Система включает в себя средства ЭП и обеспечивает подготовку ЭД, генерацию ЭП, прием, передачу и обработку ПЭД с использованием средств вычислительной техники каждой из сторон. Передача данных в Системе происходит по интернету.

2.23. Список отозванных сертификатов (далее также — СОС) — список, содержащий серийные номера сертификатов, которые были отозваны выдавшим их УЦ и к которым больше нет доверия. Сертификаты добавляются в СОС после извещения о компрометации ключа ЭП.

2.24. Экспертная комиссия — комиссия, создаваемая сторонами для разрешения разногласий, возникающих при обмене ПЭД.

3. Предмет Соглашения

3.1. Настоящее Соглашение устанавливает порядок организации и проведения электронного документооборота между сторонами во исполнение Основного договора.

3.2. Электронные документы, которые передаются по данному Соглашению, должны быть подписаны усиленной неквалифицированной электронной подписью. Далее в качестве ЭП подразумевается НЭП.

3.3. Электронные документы, которые передаются другой стороне: ежесуточные реестры, формируемые Оператором в соответствии с Основным договором.

3.4. Обмен иными ЭД в Системе не является основанием возникновения обязательств сторон по Основному договору и Соглашению. Стороны признают юридическую силу ПЭД, подписанных НЭП (при подтверждении подлинности ЭП в ПЭД), равной юридической силе документов на бумажном носителе, оформленных в соответствии с требованиями законодательства Российской Федерации и условиями Соглашения и Основного договора, и подписанных уполномоченными представителями сторон, с приложением оттисков печатей сторон.

3.5. ПЭД порождает обязательства сторон, установленные Соглашением и Основным договором, если передающей стороной он должным образом оформлен, подписан НЭП, а принимающей стороной получен, проверен и принят к обработке в установленном Соглашением порядке.

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

3.7. Передача ПЭД осуществляется через Систему между сторонами путем передачи сообщений электронной почты через интернет.

3.8. Подключение сторон к интернету выполняется самостоятельно и не является предметом Соглашения.

4. Общие принципы электронного документооборота

4.1. Каждая из Сторон при подписании ЭД применяет свой ключ ЭП, а при проверке подписи — ключ проверки ЭП, записанный в сертификате ключа проверки ЭП, другой стороны.

4.2. Стороны обмениваются сертификатами, которые будут использоваться для создания ЭП.

4.3. Для электронного документооборота стороны могут использовать самоподписанные сертификаты и сертификаты, подписанные другим ключом ЭП.

4.4. Если для документооборота используется несамоподписанный сертификат, выданный УЦ, то стороны также обмениваются корневыми сертификатами УЦ и, в случае существования, промежуточными сертификатами УЦ.

4.5. Перед началом работы стороны проверяют свои средства ЭП и с их помощью проверяют подлинность ЭП.

4.6. Стороны признают, что:

внесение изменений в ПЭД дает отрицательный результат проверки ЭП;
подделка ЭП невозможна без использования ключа ЭП владельца;
каждая сторона несет ответственность за сохранность своего ключа ЭП и за действия своего персонала при использовании средств ЭП;
моментом наступления юридической значимости ПЭД является момент получения этого ПЭД через Систему принимающей стороной и отраженный в журнале.

4.7. Средства ЭП должны быть встроены в Систему. Стороны признают эти средства достаточными для подписания ЭД и проверки подлинности ЭП в ПЭД.

4.8. В состав средств ЭП Системы входит программное обеспечение GnuGP, предоставляющее пользователю интерфейс для выполнения криптографических операций шифрования и расшифровывания данных, подписи данных и проверки корректности подписи, то есть являющееся средством электронной подписи.

5. Обязанности Сторон

Стороны обязуются:

5.1. Самостоятельно укомплектовать Систему необходимыми программно-техническими средствами и общесистемным программным обеспечением.

5.2. Назначить лиц, ответственных за работу с Системой в соответствии с настоящим Соглашением.

5.3. Назначить Администратора безопасности, отвечающего за генерацию, учет, обмен и сохранность ключей, используемых в Системе, за защиту от несанкционированного доступа и за поддержание средств ЭП Системы в рабочем состоянии.

5.4. Произвести обмен сертификатами.

5.5. Своевременно производить плановую замену ключей ЭП и соответствующих сертификатов ключей проверки ЭП в соответствии с регламентом УЦ и (или) действующего законодательства. Рекомендуется проводить плановую замену не реже 1 раза в год и за 10 дней до окончания срока действия сертификата.

5.6. Немедленно информировать другую сторону обо всех случаях утраты, хищения, несанкционированного использования ключей ЭП по следующим адресам: Оператора — по адресу merchants@yamoney.ru, Контрагента — по адресу электронной почты, указанному Контрагентом в Заявлении. При этом работа в Системе приостанавливается до проведения внеплановой смены ключей.

5.7. Принимать на себя все риски, связанные с работоспособностью своего оборудования и каналов связи.

5.8. За собственный счет поддерживать в рабочем состоянии входящие в Систему программно-технические комплексы обеспечения работоспособности вычислительной техники и техники связи, обеспечивающих электронный документооборот.

5.9. Своевременно (не менее, чем за три дня) уведомлять друг друга об изменении своего фактического места нахождения, сетевого адреса в интернете, а также об изменении иных реквизитов, имеющих существенное значение для определения юридического статуса и идентификации сторон и исполнения обязательств по Соглашению.

5.10. Не предпринимать действий, способных нанести ущерб другой стороне вследствие использования Системы.

5.11. Своевременно информировать (по электронной почте и/или телефону) другую сторону обо всех случаях возникновения технических неисправностей или других обстоятельств, препятствующих электронному документообороту.

5.12. В случае обнаружения возможных угроз безопасности стороны обязуются своевременно извещать друг друга о таких угрозах для принятия согласованных мер по их нейтрализации.

5.13. Строго выполнять требования технической и эксплуатационной документации к программному и аппаратному обеспечению Системы.

5.14. Разработать и выполнять мероприятия по обеспечению конфиденциальности, целостности и сохранности программных средств Системы, передаваемых ПЭД, протоколов регистрации событий, действующей ключевой информации и парольной информации, используемой для доступа в Систему.

5.15. Организовать внутренний режим функционирования рабочего места ответственного лица таким образом, чтобы исключить возможность использования Системы лицами, не имеющими допуска к работе с ней, а также исключить возможность использования средств ЭП не уполномоченными на это лицами.

5.16. Обеспечивать сохранение в тайне сведений по вопросам технологии защиты информации, используемых при обмене ЭД между сторонами, за исключением случаев, предусмотренных действующим законодательством Российской Федерации.

5.17. Поддерживать системное время программно-аппаратных средств Системы в соответствии с текущим астрономическим временем с точностью до пяти минут. Стороны признают в качестве единой шкалы времени время GMT с учетом часового пояса г. Москвы.

5.18. Обмениваться ЭД, не содержащими компьютерных вирусов и (или) иных вредоносных программ.

5.19. Направлять другой стороне и обеспечивать прием от другой стороны ПЭД с контролем целостности и авторства в случаях и в сроки, установленные Соглашением и (или) Основным договором.

5.20. Принимать к исполнению ЭД в установленные Соглашением и (или) Основным договором сроки, если ЭД получены через Систему, подписаны НЭП и ЭП была успешно проверена.

5.21. При осуществлении операций на основании полученных по Системе ЭД руководствоваться требованиями законодательства Российской Федерации, а также условиями Основного договора и Соглашения.

5.22. Стороны организуют архивное хранение ПЭД в течение срока действия аналогичных документов, оформленных на бумажных носителях.

6. Права Сторон

Стороны имеют право:

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. В поле «субъект» сертификата необходимо внести следующие сведения:

CN = ФИО ответственного сотрудника, или наименование организации, или псевдоним;
E = адрес электронной почты, совпадающий с адресом электронной почты, используемым для отправки ЭД;
OU = наименование подразделения организации;
O = название организации;
L = город размещения организации;
C = код страны (например, для России C=RU).

Остальные поля сертификата могут быть заполнены по желанию.

8.5. Сертификаты, используемые для формирования НЭП, должны иметь атрибуты расширенного использования ключа id_kp_clientAuth (OID 1.3.6.1.5.5.7.3.2) и id_kp_emailProtection (OID 1.3.6.1.5.5.7.3.4).

8.6. Сертификаты должны иметь запись с данными о точке распространения списка отозванных сертификатов, доступного по протоколу HTTP в интернете.

8.7. Удостоверяющий центр должен добавлять в СОС отозванные сертификаты в течение 1 рабочего дня и публиковать новый СОС в интернете после каждого добавления.

8.8. Удостоверяющий центр, который используется для выдачи сертификатов, должен соответствовать всем требованиям к неаккредитованным удостоверяющим центрам, установленным в ФЗ № 63-ФЗ «Об электронной подписи».

8.9. Стороны обмениваются следующими сертификатами:

корневой сертификат УЦ (если есть);
промежуточные сертификаты (если есть);
сертификат, который будет использоваться для подписи ЭД в Системе.

8.10. Файл сертификата должен быть в формате PKCS7.

8.11. Файлы сертификатов передаются другой стороне по электронной почте или через Систему, если она уже функционирует.

8.12. Корневой сертификат, а при его отсутствии самоподписанный, стороны печатают на бумажном носителе, подписывают ответственным лицом с оттиском печати организации и отправляют другой стороне курьером или передают друг другу в момент подписания данного Соглашения.

8.13. Стороны обязуются принимать все необходимые меры для сохранения конфиденциальности ключей ЭП.

8.14. Система средствами ЭП для каждого полученного ПЭД должна проверить:

подлинность ЭП для данного ПЭД;
факт того, что дата формирования ЭП находится в интервале от даты начала действия сертификата до даты завершения его действия;
корректность самого сертификата, используемого для формирования ЭП;
корректность цепочки выдачи сертификатов от используемого для подписи до корневого;
выполнение требований к ограничению использования сертификата, записанных в самом сертификате;
отсутствие используемого сертификата в списке отозванных сертификатов стороны, выдавшей этот сертификат.

8.15. При плановой замене сертификата ключа проверки ЭП сторона генерирует новые ключи и соответствующий сертификат и отправляет файл сертификата другой стороне по электронной почте или через Систему.

8.16. При компрометации ключа ЭП (или обоснованных подозрениях в компрометации), используемого для формирования НЭП в ПЭД, сторона должна:

остановить передачу ПЭД в Системе и немедленно (если невозможно, то в течение 1 рабочего дня) уведомить другую сторону о факте компрометации сертификата;
произвести генерацию нового ключа ЭП, ключа проверки ЭП и выпустить в УЦ новый сертификат ключа проверки ЭП;
передать другой стороне файл с новым сертификатом;
внести в список отозванных сертификатов своего УЦ серийный номер скомпрометированного сертификата и опубликовать новый СОС;
восстановить работу Системы по согласованию с другой стороной.

8.17. При компрометации корневого и (или) промежуточного ключа ЭП удостоверяющего центра сторона выполняет действия, указанные в предыдущем пункте, а также другие действия согласно своей нормативной документации.

8.18. Подписание настоящего Соглашения свидетельствует об обмене сертификатами.

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. В случае отсутствия согласия по спорным вопросам и добровольного исполнения решения Экспертной комиссии, все материалы по этим вопросам могут быть переданы на рассмотрение в Арбитражный суд города Москвы.

10. Уполномоченными лицами на использование ЭП от имени Сторон являются:
от Оператора — Председатель Правления Шабанова Татьяна Андреевна;
от Контрагента — юридического лица — лицо, уполномоченное учредительными документами или доверенностью; от Контрагента — индивидуального предпринимателя — лицо, зарегистрированное в качестве индивидуального предпринимателя, или лицо, уполномоченное доверенностью.

Приложение № 2. Формат ежедневного реестра совершенных и возвращенных переводов.

Требования к оформлению ежесуточного реестра переводов

Раз в сутки Оператор формирует реестр принятых в пользу Контрагента переводов. Реестр отправляется в теле электронного сообщения на email (*), указанный Контрагентом в заявлении (приложение № 4 или № 5 к Договору). Реестр подписывается сертификатом Оператора (S/MIME подпись). В реестре содержатся все переводы за указанную в реестре дату.

Тема (subject) электронного сообщения формируется по следующему шаблону (нумерация сквозная):

РЕЕСТР ПЛАТЕЖЕЙ В <Наименование_Контрагента>. № <номер>

Тело электронного сообщения формируется как:

РЕЕСТР ПЛАТЕЖЕЙ В <Наименование Контрагента>. № <номер>
Дата платежей:

Номер транзакции; Идентификатор клиента; Сумма платежа; Валюта платежа; Сумма за вычетом комиссии; Время платежа; Номер кошелька плательщика; Краткое описание; Тип платежа

<Данные платежей>

Сумма принятых платежей <Тип операции>:<общая сумма принятых переводов данного типа за сутки>
Сумма принятых платежей за вычетом комиссии типа <Тип операции>: <сумма принятых переводов данного типа за вычетом комиссии Оператора>
Число платежей типа <Тип операции>: <количество переводов данного типа>

Сумма принятых платежей:<общая сумма принятых переводов за сутки>
Сумма принятых платежей за вычетом комиссии: <сумма принятых переводов за вычетом комиссии Оператора>
Число платежей: <количество переводов>

Кому: <Наименование Контрагента>

(По договору <номер договора между Контрагентом и Оператором>)

Описание полей с данными платежей приведено в таблице ниже.

Таблица 1. Поля стандартного реестра принятых переводов

Поле	Значение
Номер транзакции	Уникальный номер транзакции в ИС Оператора (string, до 32 символов). Значение параметра invoiceId уведомлений Оператора.
Идентификатор клиента	Идентификатор плательщика в ИС Яндекс (string, до 64 символов). Значение параметра customerNumber платежной формы.
Сумма платежа	Сумма транзакции. Разделитель дробной части — точка, всегда ровно два знака после запятой, разделитель тысяч отсутствует.
Валюта платежа	Трехбуквенный код валюты (RUB — Рубль РФ).
Сумма за вычетом комиссии	Сумма к выплате Контрагенту на р/с. Разделитель дробной части — точка, всегда ровно два знака после запятой, разделитель тысяч отсутствует.
Время платежа	Момент доставки «Уведомления о переводе» Контрагенту. Дата и время в формате «dd.mm.yyyy hh:mm:ss», по часам Оператора.
Номер кошелька плательщика	Номер счета в ИС Оператора, с которого произведена оплата.
Краткое описание	Текстовое наименование оплаченного товара в ИС Оператора.
Тип платежа	Способ, которым был совершен платеж. Значения соответствуют значениям параметра paymentType (см. таблицу.2). Необязательное поле.

Образец реестра:

Subject: РЕЕСТР ПЛАТЕЖЕЙ В Наименование_Контрагента. № 3355
РЕЕСТР ПЛАТЕЖЕЙ В ООО «Наименование_Контрагента». № 3355
Дата платежей: 14.03.2014

Номер транзакции; Идентификатор клиента; Сумма платежа; Валюта платежа; Сумма за вычетом комиссии; Время платежа; Номер кошелька плательщика; Краткое описание; Тип платежа
549755819524; 4956; 10.00; RUB; 9.50; 18.12.2007 17:46:58; 410038366898; оплата услуг Интернет Магазин; GP
549755819525; 4957; 15.00; RUB; 14.25; 18.12.2007 17:47:32; 410038366898; оплата услуг Интернет Магазин; PC
Сумма принятых платежей типа PC: 15.00 RUB
Сумма принятых платежей за вычетом комиссии типа PC: 14.25 RUB
Число платежей типа PC: 1

Сумма принятых платежей типа AC: 10.00 RUB
Сумма принятых платежей за вычетом комиссии типа GP: 9.50 RUB
Число платежей типа AC: 1

Сумма принятых платежей: 25.00 RUB
Сумма принятых платежей за вычетом комиссии: 23.75 RUB
Число платежей: 2

Кому: ООО «Наименование_Контрагента»

(По договору 111.1111.11)

Таблица 2. Значения параметра paymentType

Значение	Пояснение
PC	Оплата из кошелька в Яндекс.Деньгах.
AC	Оплата с произвольной банковской карты.

Формат ежедневного реестра возвращенных переводов

Реестр возвратов переводов предоставляется в теле электронного сообщения (email).

Тема электронного сообщения (email Subject):

РЕЕСТР ВОЗВРАТОВ ОТ . № <номер>

Где, — юридическое наименование Контрагента.
<номер> — номер электронного сообщения в адрес Контрагента, нумерация сквозная.

Реестр отправляется на email Контрагента, указанный в заявлении (Приложение № 4 или № 5 к Договору).

Реестр подписывается сертификатом Оператора, S/MIME подпись (detach, тип сертификата PKCS#7).

В реестре содержатся все успешно осуществленные возвраты за указанную в теле реестра дату.

Реестры формируются и отправляются ежесуточно. В том случае, если за прошедшие сутки возвратов не было, реестр будет нулевым.

Тело реестра:

РЕЕСТР ВОЗВРАТОВ ОТ . № <номер>

Дата возвратов:

Подзаголовок:

Номер транзакции; Сумма возврата; Валюта платежа; Время зачисления возврата на счет плательщика; Номер счета плательщика; Тип платежа;

Данные:

Идентификатор	Содержание	Примечание
Номер транзакции	Номер транзакции Оператора. (string, до 32 символов).	Уникальный идентификатор перевода, по которому производится возврат.
Сумма возврата	Сумма возврата.	Разделитель дробной части — точка, всегда ровно два знака после запятой, разделитель тысяч отсутствует.
Валюта платежа	Валюта перевода и возврата.
Время зачисления возврата на счет плательщика	Момент времени зачисления суммы возврата на счет в Системе (по часам Оператора).	Дата и время в формате dd.mm.yyyy hh:nn:ss
Номер счета плательщика	Номер счета в сервисе Яндекс.Деньги, с которого был произведен перевод и на который производится возврат.	Длина от 11 до 33 цифр, начинается с константы 41001.
Тип платежа	Способ, которым пользователь совершил платеж в Магазин	Строка, два символа. PC — платеж, совершаемый со счета пользователя в Яндекс.Деньгах или с банковской карты, добавленной в электронный кошелек. AC — платеж, совершаемый с любой банковской карты, которая не добавлена в кошелек пользователя в Яндекс.Деньгах. Список возможных значений может быть расширен.

Итог реестра:

Сумма возвратов: <общая сумма возвратов за сутки>

Число возвратов: <количество возвратов за сутки>

От: <Юридическое лицо интернет магазина>

(По договору <номер договора между Контрагентом и Оператором>)

Образец ежедневного реестра возвратов:

РЕЕСТР ВОЗВРАТОВ ОТ ООО «Интернет Магазин». № 3355

Дата возвратов: 18.12.2009

549755819524; 10.00; RUB; 18.12.2009 17:46:58; 410038366898; PC;

549755819525; 15.00; RUB; 18.12.2009 18:47:32; 410038366898; AC;

Сумма возвратов: 25.00

Число возвратов: 2

От: ООО «Интернет Магазин»

(По договору НЭК.111111.01)

Приложение № 6. Таблица способов платежа

Наименование способов платежа	Описание	Возможность Возврата или Отмены перевода
Яндекс.Деньги	перевод посредством уменьшения остатка электронных денежных средств плательщика, учитываемых Оператором	есть
WebMoney	перевод, инициированный плательщиком, действующим в качестве пользователя системы WebMoney Transfer, за счет денежных средств, предоставленных в указанную систему	есть
Оплата в терминалах и кассах	перевод посредством приема наличных денежных средств плательщика банковским платежным агентом (субагентом) Оператора или кредитной организацией, с которой Оператор заключил соответствующий договор	для контрагентов–резидентов: нет для контрагентов–нерезидентов: есть
Банковские карты	перевод с использованием плательщиком банковской карты	есть
Мобильная коммерция	перевод, инициированный абонентом оператора радиотелефонной подвижной связи за счет денежных средств абонента, являющихся авансом за услуги связи	есть
Инвойсинг	перевод, осуществленный посредством списания денежных средств с банковского счета клиента ОАО «Сбербанк России» на основании распоряжения, переданного с использованием системы дистанционного банковского обслуживания «Сбербанк ОнЛ@йн»	нет
Инвойсинг	перевод посредством списания денежных средств с банковского счета клиента ОАО «АЛЬФА-БАНК» на основании распоряжения, переданного с использованием системы дистанционного банковского обслуживания «Альфа-Клик»	есть
Инвойсинг	перевод посредством списания денежных средств с банковского счета клиента ПАО «Промсвязьбанк» на основании распоряжения, переданного с использованием системы дистанционного банковского обслуживания PSB-Retail	нет
Мобильный терминал	перевод с использованием банковской карты посредством платежного приложения «2can for Yandex.Money»	есть
MasterPass	перевод с использованием банковской карты посредством сервиса MasterPass	есть
КупиВкредит (Тинькофф Банк)	перевод в оплату товаров/услуг, приобретенных за счет кредитных средств АО «Тинькофф Банк»	есть
QIWI Wallet	перевод с использованием банковской карты КИВИ Банк (АО)	есть