Редакция утверждена Правлением ООО нко «Яндекс. Деньги»


Порядок разрешения споров, связанных с установлением подлинности ЭД



страница3/8
Дата17.11.2018
Размер1.15 Mb.
ТипПротокол
1   2   3   4   5   6   7   8

Порядок разрешения споров, связанных с установлением подлинности ЭД

  1. Любые споры между сторонами, предметом которых является установление подлинности, то есть целостности текста и аутентичности отправителя ЭД, передаются для разрешения специально создаваемой Экспертной комиссии.

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

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

  4. Полномочия членов Экспертной комиссии подтверждаются доверенностями.

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

  6. Экспертиза оспариваемого ЭД осуществляется в присутствии всех членов Экспертной комиссии.

  7. Экспертиза осуществляется в четыре этапа:

1-й этап: стороны совместно устанавливают, конфигурируют и тестируют средство ЭП.

2-й этап: стороны предоставляют свою копию сертификата ключа проверки ЭП, используемого для создания НЭП оспариваемого ПЭД, а также корневого и промежуточных сертификатов УЦ.

З-й этап: Экспертная комиссия с помощью средства ЭП получает ключи проверки ЭП из сертификатов, предоставленных сторонами, и сравнивает их с соответствующими ключами из сертификатов, переданными сторонам на основании пункта 8.11 настоящего Соглашения. Сертификаты, ключи проверки ЭП которых совпали, признаются подлинными. Также сравнивается корневой сертификат, переданный на бумажном носителе до подписания Соглашения, с только что предоставленным сертификатом. Экспертная комиссия с помощью средства ЭП проверяет, выпущен ли сертификат ключа проверки ЭП, использованный для подписи оспариваемого ПЭД, с использованием корневого и промежуточных ключа ЭП УЦ.

4-й этап: проверка правильности ЭП под оспариваемым документом, предоставленным стороной-получателем, проверяется по сертификату принимающей стороны, подлинность которого подтверждена как указано выше.



    1. Подтверждением подлинности оспариваемого ПЭД является одновременное наличие следующих условий:

      • проверка подлинности ЭП оспариваемого ЭД дала положительный результат;

      • подтверждена принадлежность сертификата ключа проверки ЭП, использованного для проверки подлинности ЭП в оспариваемом ЭД;

      • ЭД сформирован в Системе и передан для обработки в соответствии с положениями настоящего Соглашения.

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

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

    4. Стороны признают, что Акт, составленный Экспертной комиссией, является обязательным для сторон и может служить доказательством при дальнейшем разбирательстве спора в Арбитражном суде.

    5. В случае отсутствия согласия по спорным вопросам и добровольного исполнения решения Экспертной комиссии, все материалы по этим вопросам могут быть переданы на рассмотрение в Арбитражный суд города Москвы.

  1. Уполномоченными лицами на использование ЭП от имени Сторон являются:

от Оператора — Председатель Правления Шабанова Татьяна Андреевна;

от Контрагента - юридического лица — лицо, уполномоченное учредительными документами или доверенностью; от Контрагента – индивидуального предпринимателя – лицо, зарегистрированное в качестве индивидуального предпринимателя, или лицо, уполномоченное доверенностью.



ПРИЛОЖЕНИЕ № 2

Протокол обмена информацией

Вариант 1 Приложения № 2



Протокол обмена информацией при осуществлении переводов

HTTP-транспорт
Версия commonHTTP-3.0
от 13.06.2013


  1. Общие сведения

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

Далее приводится описание протокола, позволяющего доставлять уведомления Контрагенту, использующему любую программно-аппаратную платформу своих ИС.



    1. Порядок взаимодействия

yamoney_shop_scheme

На веб-странице, где плательщик может инициировать перевод, Контрагент должен расположить «платежную форму» с данными, характеризующими покупку (сумма перевода, ID Контрагента и прочее). Платежная форма в минимальном варианте представляет собой статический HTML, возможно, с заполняемыми плательщиком полями. Например, для пополнения счета в онлайн-игре это могут быть «номер игрового счета» и «сумма».

Упрощенно можно считать, что интернет-браузер плательщика передает заполненную форму Оператору (см. шаг 1 на схеме). Реальный способ передачи всегда подразумевает шифрование передаваемых данных.

На основании данных, полученных на платежной форме, Оператор формирует контракт на оплату и запрос «проверка заказа» (checkOrder) в ИС Контрагента. Контрагент проверяет параметры заказа, Плательщик подтверждает контракт на оплату (шаги 2–5 на схеме).

Если Контрагент ответил положительно на запрос «Проверка заказа» и Плательщик подтвердил контракт на оплату, то Оператор уменьшает остаток электронных денежных средств плательщика (шаг 6 на схеме) и, в случае успеха, отправляет в ИС «Уведомление о переводе» — paymentAviso (шаги 8–9).

Контрагент может отказаться принимать перевод только на стадии «Проверка заказа» (checkOrder). Отправка Оператором Контрагенту «Уведомления о переводе» (paymentAviso) фиксирует факт принятого перевода.

В результате плательщик видит веб-страницу Оператора (интерфейс портала Яндекс.Денег), где сообщается об успехе или неуспехе перевода (шаг 7), а также отображается ссылка «Вернуться в магазин». URL, на который будет осуществлен переход при нажатии этой ссылки, определяется в параметрах Контрагента (successURL, failURL).

При нажатии ссылки может быть осуществлен переход на входную страницу сайта Контрагента или же Контрагент может показать состояние конкретного заказа (шаг 10–11).



Если после положительного ответа на запрос «Проверка заказа» Контрагент не получил «Уведомление о переводе» по этому переводу, ему следует обратиться в специальный сервис Merchant Web Services, чтобы получить информацию о том, был ли перевод успешно осуществлен. Раз в сутки Оператор отправляет Контрагенту по электронной почте список переводов («реестр»). Контрагент должен сверять реестр с полученными «Уведомлениями о переводах».

1.2. Пример сеанса взаимодействия Оператора и Контрагента

  1. Плательщик заполняет платежную форму и отправляет Оператору.

    Параметр

    Значение

    shopID

    13

    shopArticleId

    456

    Sum

    87.1







    scid

    1643

    CustomerNumber

    8123294469

    paymentType

    GP

    paymentTypeProvider

    SVZNY

    cps_email

    name@domain.com

    cps_phone

    81231234567

    MyField

    Добавленное Контрагентом поле



  2. По данным, полученным из платежной формы, Оператор формирует контракт, отправляет его плательщику и ждет подтверждения оплаты.

  3. Плательщик подтверждает перевод.

  4. Оператор просит Контрагента проверить заказ.

    Параметр

    Значение

    requestDatetime

    2011-05-04T20:38:00.000+04:00

    action

    checkOrder

    shopID

    13

    shopArticleId

    456

    invoiceId

    1234567

    customerNumber

    8123294469

    orderCreatedDatetime

    2011-05-04T20:38:00.000+04:00

    orderSumAmount

    87.10

    orderSumCurrencyPaycash

    643

    orderSumBankPaycash

    1001

    shopSumAmount

    86.23

    shopSumCurrencyPaycash

    643

    shopSumBankPaycash

    1001

    paymentPayerCode

    42007148320

    paymentType

    GP

    MyField

    Добавленное Контрагентом поле



  5. Контрагент подтверждает корректность заказа.



    code="0" invoiceId="1234567"

    shopID="13"/>


  6. Оператор принимает и проверяет перевод.

  7. Оператор возвращает в браузер плательщика ответ — страницу с сообщением об успехе (неуспехе) перевода. На этой странице также расположена ссылка «Вернуться в магазин» (шаг 10).

  8. Оператор уведомляет Контрагента о совершенном переводе.

    Параметр

    Значение

    requestDatetime

    2011-05-04T20:38:00.000+04:00

    action

    paymentAviso

    shopID

    13

    shopArticleId

    456

    invoiceId

    1234567

    customerNumber

    8123294469

    orderCreatedDatetime

    2011-05-04T20:38:00.000+04:00

    orderSumAmount

    87.10

    orderSumCurrencyPaycash

    643

    orderSumBankPaycash

    1001

    shopSumAmount

    86.23

    shopSumCurrencyPaycash

    643

    shopSumBankPaycash

    1001

    paymentDatetime

    2011-05-04T20:38:10.000+04:00

    paymentPayerCode

    42007148320

    paymentType

    GP

    MyField

    Добавленное Контрагентом поле

  9. Контрагент подтверждает получение уведомления о переводе.




    performedDatetime ="2011-05-04T20:38:11.000+04:00"

    code="0" invoiceId="1234567"

    shopID="13"/>


  10. Плательщик нажимает на ссылку «Вернуться в магазин».

  11. Контрагент формирует страницу для плательщика. В данном случае это статическая страница.

<html>

<body>

Спасибо за покупку! С вами свяжется курьер для уточнения времени доставки Вашего заказа.



html >

  1. Параметры подключения Контрагента

Чтобы начать работу, Контрагент должен определить и предоставить Оператору описанные ниже параметры для подключения Контрагента к Оператору.

2.1 Формат сообщений

Опции данного раздела взаимоисключающие, можно выбрать только один из форматов.

2.1.1 NVP/MD5 (по умолчанию)

Данные передаются посредством вызова по протоколу HTTP/1.1 методом POST. Параметры сообщения (данные перевода) упаковываются как набор параметров POST-запроса в виде пар «имя=значение». MIME-тип: application/x-www-form-urlencoded.

Один из параметров (md5) содержит хеш данных платежной формы вместе с секретным словом. Секретное слово предоставляется Контрагентом.


  • 2.1.1.3 Секретное слово Контрагента

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

При выборе этого варианта следует учитывать низкую надежность как самой схемы с секретным словом (риск разглашения секрета), так и алгоритма md5.

2.1.2 XML/PKCS#7

Данные передаются посредством вызова по протоколу HTTP/1.1 методом POST. Параметры сообщения (данные перевода) представляются в виде XML-документа, вложенного в криптоконтейнер PKCS#7. MIME-тип: application/pkcs7-mime. Данные подписываются SSL-сертификатом Оператора.

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

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

Документ формируется согласно стандарту XML 1.0 (Fifth Edition), опубликованному по адресу: http://www.w3.org/TR/xml/.

Сформированный документ помещается в криптоконтейнер формата PKCS#7 согласно стандарту http://www.ietf.org/rfc/rfc5652.txt. Криптоконтейнер содержит АСП (цифровую подпись, аналог собственноручной подписи). Криптоконтейнер содержит конечный сертификат Оператора. Криптоконтейнер не содержит цепочки центров сертификации. Компрессия данных не используется. Шифрование не используется. Криптопакет закодирован в формате PEM (OpenSSL). Сертификат, используемый при изготовлении криптопакета, соответствует стандарту X.509 Version 3 (http://www.ietf.org/rfc/rfc2459.txt).

Схема рекомендуется как альтернатива 2.1.1, обладающая высоким уровнем безопасности.

2.2 Кодировка символов

Опция определяет, в какой кодировке передаются текстовые данные сообщений.

2.2.1 UTF-8 (по умолчанию).

2.2.2 Windows-1251.

Название__Содержание__shopSuccessURL'>Название__Содержание__successURL'>Название_Контрагента'>2.3 Название Контрагента

Название Контрагента отображается в контракте и может содержать до 128 символов.

2.4 Отображение текста отказа в приеме перевода на витрине

Опция определяет возможность передачи Контрагентом собственного текста для отображения пользователю в ответе на операцию проверки возможности перевода. См. параметр ответа message.

Возможные значения:



  • 2.4.1 True — текстовое пояснение в случае отказа принять перевод будет отображено на странице неуспеха перевода;

  • 2.4.1 False — текстовое пояснение игнорируется (по умолчанию).

2.5 Учет переводов при недоставке уведомления о переводе

Опция определяет взаимное поведение Контрагента и Оператора при невозможности доставки «Уведомления о переводе» (длительное многократное отсутствие ответа Контрагента на запросы Оператора, либо многократные технические ошибки ИС Контрагента).

Возможные значения:


  • 2.5.1 Считать неуспешным. Оператор прекращает попытки доставки уведомления, помечает перевод как недоставленный Контрагенту и не помещает его в ежесуточный реестр. Не доставленные Контрагенту переводы не подлежат перечислению на расчетный счет. Средства по неуспешному переводу будут возвращены плательщику в течение двух-трех рабочих дней. Контрагент может обнаружить «потерянные уведомления» путем сверки с использованием сервиса Merchant Web Services (по умолчанию).

  • 2.5.2 Считать успешным. Оператор прекращает попытки доставки уведомления и помечает перевод как успешный. Контрагент может обнаружить «потерянные уведомления» путем сверки с реестром или с использованием сервиса Merchant Web Services. Перевод будет включен в реестр согласно времени последней попытки доставки уведомления.

2.6 Порядок перенаправления пользователя по завершении перевода

Опция определяет порядок перенаправления пользователя на сайт Контрагента по факту завершения перевода.

Возможные значения:


  • 2.6.1 Статические адреса по каждому товару Контрагента, определенные в следующих настройках товара.

Название

Содержание

successURL

URL для ссылки «Вернуться в магазин» на странице, отображаемой плательщику после успешной оплаты.

failURL

URL для ссылки «Вернуться в магазин» на странице, отображаемой плательщику после неуспешной оплаты.



  • 2.6.2 Адреса, задаваемые Контрагентом в платежной форме.
    В этом случае Контрагент должен передавать поля платежной формы.

Название

Содержание

shopSuccessURL

URL для ссылки «Вернуться в магазин» на странице, отображаемой плательщику после успешной оплаты.

shopFailURL

URL для ссылки «Вернуться в магазин» на странице, отображаемой плательщику после неуспешной оплаты.

2.7 Адреса приема сообщений от Оператора

Таблица 2.7.1. Настройки адресов приема сообщений от Оператора



Название

Содержание

paymentAvisoURL

URL(https), на который отправляется запрос «Уведомление о переводе».

checkURL

URL(https), на который отправляется запрос «Проверка заказа».

2.8 Изменение контракта перевода

Возможные значения:



  • 2.8.1 Фиксированный контракт. Сумма к оплате выставляется Оператором. Контрагент может согласиться принять перевод как есть или отказаться от приема перевода (по умолчанию).

  • 2.8.2 Контрагент может изменять сумму перевода. Сумма перевода выставляется Оператором. Контрагент может согласиться принять перевод как есть, изменить сумму перевода или отказаться от приема перевода.

  1. Общее описание протокола

3.1 Платежная форма

Платежная форма определяет параметры заказа, а ее отправка инициирует формирование и обработку распоряжения на перевод (см. шаги 1–2 на схеме).

Параметры платежной формы могут быть двух типов:


  • служебные — значения этих параметров Контрагент получает в процессе подключения к программно-аппаратному комплексу Оператора;

  • пользовательские, то есть определяемые самим Контрагентом и позволяющие ему в дальнейшем опознавать переводы.

Контрагент может самостоятельно присваивать уникальные номера заказам, помещая эти номера в платежную форму (поле orderNumber). Значение поля orderNumber должно быть уникальным в рамках всей истории работы Контрагента. На стороне Оператора уникальность параметра orderNumber отслеживается в сочетании с параметром shopID.

При изменении суммы или состава заказа ему всегда должен присваиваться новый номер. В том случае, если плательщик дойдет до шага 3 («подтверждение оплаты»), а потом вернется на сайт Контрагента и что-то изменит в составе заказа, а номер заказа при этом будет иметь прежнее значение, перевод не будет принят, и плательщик получит сообщение об ошибке.

Следует учитывать, что все поля платежной формы видны плательщику и могут быть модифицированы недобросовестным плательщиком. Если в платежной форме указывается код заказа и сумма, то недобросовестный плательщик может оставить неизменным код, а сумму изменить, скажем, с 30 000 на 30.
Поэтому Контрагенту всегда следует проверять все параметры перевода, пришедшие в запросе «Проверка заказа» (см. шаги 4–5 на схеме, запрос checkOrder от Оператора к ИС), и отказывать в приеме перевода (ответ ИС code=100 на запрос checkOrder) в том случае, если параметры отличаются от ожидаемых.

Также следует осуществлять аналогичные проверки после перевода (запрос paymentAviso от Оператора к ИС Контрагента). И если, к примеру, уплачено меньше стоимости заказа, то следует не отгружать товар, а требовать доплаты у плательщика.

Контрагент имеет возможность указать способ, которым должен быть совершен платеж Плательщика. Для указания способа используются поля платежной формы paymentType и cps_provider. Если способ платежа не указан (параметр paymentType в платежной форме отсутствует или имеет некорректное значение), платеж будет производиться со счета пользователя в Яндекс.Деньгах или с банковской карты, привязанной к этому счету (способ платежа по умолчанию — “PC”).

paymentType указывает способ, которым должен быть совершен платеж, а cps_provider служит для уточнения деталей способа платежа. Значения параметров paymentType и cps_provider регистрозависимые.





Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница