close

Вход

Забыли?

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

код для вставкиСкачать
Договор
об информационно-технологическом взаимодействии
при осуществлении переводов физических лиц
без открытия счета
1. Предмет договора
1.1. Оператор обязуется за вознаграждение оказывать Контрагенту информационные и технологические
услуги, в том числе по сбору, обработке и передаче информации о переводах физических лиц без открытия счета в
пользу Контрагента (далее — переводы).
1.2. Обязательства физических лиц перед Контрагентом, во исполнение которых совершаются переводы,
возникают в порядке и по основаниям, установленным законом, и (или) договором физического лица с
Контрагентом. Отношения, из которых возникают указанные обязательства, не входят в предмет регулирования
настоящего Договора и не порождают для Оператора каких бы то ни было обязанностей.
2. Порядок заключения договора и технического взаимодействия Сторон
2.1. Настоящий Договор является адресованным неопределенному кругу потенциальных Контрагентов —
юридических лиц и индивидуальных предпринимателей, зарегистрированных в соответствии с законодательством
Российской Федерации — приглашением Оператора делать оферты о заключении Договора на условиях и в
порядке, изложенных в настоящем Договоре и в заявлении Контрагента о заключении Договора (далее —
Заявление).
2.2. Контрагент инициирует заключение Договора путем направления заявки на сайте Оператора
https://money.yandex.ru/ (далее – Заявка).
2.3. Контрагентам, направившим Заявку начиная с 20.08.2014г., Оператор предоставляет личный кабинет программу для ЭВМ, интерфейс которой размещен и/или доступен в сети Интернет на сайте Оператора
https://kassa.yandex.ru/ и отображается посредством программы для просмотра интернет-сайтов (браузера) (далее –
Личный кабинет) - для обмена документами при заключении Договора.
2.3.1. Доступ к Личному кабинету предоставляется Контрагенту исключительно после его аутентификации,
осуществляемой путем проверки подлинности введенных авторизационных данных (логина и пароля).
Авторизационные данные создаются Контрагентом самостоятельно при направлении Заявки и признаются
Сторонами достаточными для аутентификации Контрагента при доступе к Личному кабинету.
2.3.2. Все документы/уведомления, размещенные в Личном кабинете Контрагента, признаются подлинными,
целостными, равнозначными документам/уведомлениями на бумажном носителе, которые удостоверены
собственноручной подписью уполномоченного лица Контрагента и направлены Оператору. Любые действия,
совершенные с использованием Личного кабинета, признаются совершенными Контрагентом.
2.3.3. Размещение Оператором информации в Личном кабинете признается надлежащим уведомлением
Контрагента о юридически значимых действиях и событиях, за исключением случаев, когда обязанность
уведомить другую Сторону в письменном виде на бумажном носителе или с использованием электронной почты
прямо предусмотрена настоящим Договором.
2.3.4. Контрагент обязан хранить свои авторизационные данные в тайне. Оператор не несет ответственности
за убытки и иные неблагоприятные последствия для Контрагента, возникшие в результате доступа третьих лиц к
Личному кабинету в результате разглашения или утраты Контрагентом его авторизационных данных.
2.3.5. В случае утраты авторизационных данных Контрагентом Оператор предоставляет Контрагенту
возможность восстановления доступа к Личному кабинету путем ввода корректного кода восстановления пароля,
ранее созданного Контрагентом при направлении Заявки.
2.4. Размещение Контрагентом в Личном кабинете сканированной копии заполненного, подписанного
уполномоченным лицом и скрепленного печатью Контрагента Заявления по форме Приложения № 4 к Договору
(для Контрагентов – индивидуальных предпринимателей) или Приложения № 5 к Договору (для Контрагентов —
юридических лиц) признается направлением Контрагентом Оператору безотзывной оферты о заключении
Договора на условиях, указанных в Договоре и Заявлении.
2.5. Договор считается заключенным с даты размещения Оператором в Личном кабинете Контрагента
уведомления об акцепте оферты.
2.6. Отношения Сторон при передаче уведомлений о переводах регулируются Приложением №2 к Договору.
В Личном кабинете Контрагент выбирает один из предложенных в пункте 1.2. Приложения №2 к Договору
способов передачи уведомлений о переводах с одновременным предоставлением технических данных,
необходимых для подключения Контрагента к программно-аппаратному комплексу Оператора.
Контрагент вправе направить Оператору на адрес электронной почты [email protected] предложение
об изменении способа передачи уведомлений о переводах в рамках содержащихся в пункте 1.2. Приложения №2 к
Договору схем подключения Контрагента. В этом случае новый способ передачи уведомлений о переводах будет
применяться к отношениям Сторон с даты направления Оператором уведомления Контрагенту о готовности к его
1
применению.
2.7. Адреса электронной почты Контрагента, указанные в Заявлении, будут использоваться для
информационного взаимодействия Сторон при исполнении настоящего Договора. Все электронные сообщения,
отправленные с указанных в Заявлении адресов электронной почты Контрагента, признаются исходящими от
уполномоченного лица Контрагента. Направление Оператором сообщений на адреса электронной почты
Контрагента, указанные в Заявлении, признается надлежащим уведомлением Контрагента о юридически значимых
действиях и событиях, за исключением случаев, когда обязанность уведомить другую Сторону в письменном виде
на бумажном носителе прямо предусмотрена настоящим Договором. В случаях когда Договором предусмотрено
право Контрагента использовать электронную связь для информационного взаимодействия, надлежащим
уведомлением Оператора признается направление Контрагентом электронного сообщения с адресов электронной
почты, указанных в Заявлении.
Контрагент, которому был предоставлен Личный кабинет, вправе изменить адреса электронной почты,
используемые для информационного взаимодействия, путем размещения соответствующей информации в Личном
кабинете. При отсутствии у Контрагента Личного кабинета уведомление об изменении адресов электронной почты
направляется в порядке, установленном настоящим пунктом 2.7.
2.8. Обмен электронными документами в порядке, установленном пунктами 2.4, 2.5. Договора, является
надлежащим соблюдением простой письменной формы Договора, заключенного в соответствии с пунктом 2 статьи
434 Гражданского кодекса Российской Федерации.
2.9. Обязанность Оператора по оказанию информационных услуг возникает с момента подключения
Контрагента к программно-аппаратному комплексу Оператора, осуществляемого совместными силами
Контрагента и Оператора. Факт такого подключения подтверждается направлением Оператором уведомления
Контрагенту о готовности к информационному взаимодействию с указанием идентификатора Контрагента в
программно-аппаратном комплексе Оператора.
2.10. Отношения Сторон, для которых пунктами 3.1.4. и 4.8 Договора предусмотрена возможность
различных вариантов их регулирования, применительно к конкретному Контрагенту регулируются следующим
образом:


если Контрагентом реализован протокол, необходимый для использования описанного в
Приложении №7 к Договору веб-сервиса, и направлено Оператору уведомление о готовности его
использования, к отношениям Сторон применяется вариант 2 пунктов 3.1.4. и 4.8. Договора;
если Контрагентом не реализован протокол, необходимый для использования описанного в
Приложении №7 к Договору веб-сервиса, к отношениям Сторон применяется вариант 1 пунктов
3.1.4. и 4.8. Договора.
2.11. К отношениям Сторон при заключении Договора и определении способа информационного
взаимодействия при передаче уведомлений о переводах применяется редакция Договора, действовавшая на дату
направления Контрагентом Заявки, с учетом права Контрагента на изменение способа передачи уведомлений о
переводах в порядке, установленном абзацем 3 пункта 2.6. Договора.
2.12. Условия Договора, в том числе содержащиеся в Заявлении, могут быть изменены по соглашению
Сторон.
3. Права и обязанности Сторон
3.1. Оператор обязуется:
3.1.1. Подключить Контрагента к программно-аппаратному комплексу Оператора для оказания Контрагенту
информационных и технологических услуг, в том числе по сбору, обработке и передаче информации о переводах в
пользу Контрагента.
3.1.2. В случае принятия решения о размещении информации о Контрагенте на своем официальном сайте и
в предназначенных для оказания платежных услуг программно-технических средствах, совершить такое
размещение в соответствии с пунктом 3.2.4. Договора.
3.1.3. В режиме реального времени направлять Контрагенту уведомление о переводе физического лица в
соответствии с процедурой, установленной Приложением № 2 к настоящему Договору.
3.1.4. Внимание!
Применимый вариант регулирования определяется в порядке, установленном пунктом 2.10.
Договора!
3.1.4. Вариант 1
Формировать реестры переводов за каждые сутки (за период с 00 часов 00 минут 00 секунд по 23 часа 59
2
минут 59 секунд по московскому времени) в соответствии с требованиями, установленными Приложением № 2 к
настоящему Договору, и направлять сформированные реестры Контрагенту по электронной почте на указанный
Контрагентом в Заявлении адрес до 11 часов 59 минут 59 секунд по московскому времени календарного дня,
следующего за днем, за который составлен реестр. Реестры подписываются усиленной неквалифицированной
электронной подписью Оператора, вид, порядок применения и правовые последствия использования которой
установлены Приложением №1 к Договору.
3.1.4. Вариант 2
Формировать реестры переводов и возвращенных переводов за каждые сутки (за период с 00 часов 00
минут 00 секунд по 23 часа 59 минут 59 секунд по московскому времени) в соответствии с требованиями,
установленными Приложениями № 2 и № 2.1 к настоящему Договору соответственно, и направлять
сформированные реестры, подписанные аналогом собственноручной подписи Оператора, Контрагенту по
электронной почте на указанный Контрагентом в Заявлении адрес до 11 часов 59 минут 59 секунд по московскому
времени календарного дня, следующего за днем, за который составлен реестр. Реестры подписываются усиленной
неквалифицированной электронной подписью Оператора, вид, порядок применения и правовые последствия
использования которой установлены Приложением №1 к Договору.
3.1.5. Представлять Контрагенту Акты об оказанных услугах в сроки и порядке согласно разделу 4
настоящего Договора.
3.1.6. В случае изменения своего места нахождения и (или) банковских реквизитов письменно уведомлять
об этом Контрагента в течение трех рабочих дней с даты наступления соответствующего события.
3.2. Оператор имеет право:
3.2.1. Приостанавливать информационно-технологическое обслуживание Контрагента:


в случае возникновения обстоятельств, не зависящих от Сторон и могущих, по мнению Оператора,
повлечь значительные убытки для Оператора, — на срок действия таких обстоятельств;
в случае нарушения Контрагентом любого из своих обязательств, предусмотренных настоящим
Договором, — до полного устранения Контрагентом допущенного нарушения.
О приостановлении информационно-технологического обслуживания Оператор не позднее даты такого
приостановления направляет Контрагенту письменное уведомление с указанием причины и срока
приостановления.
В случаях, предусмотренных настоящим пунктом, Оператор перечисляет Контрагенту в установленном
настоящим договором порядке суммы переводов, распоряжения о совершении которых были получены
Оператором до момента приостановления.
3.2.2. Требовать у Контрагента предоставления информации об обязательствах, указанных в п. 1.2.
настоящего Договора, в случае, если необходимость такой информации вызвана соблюдениями требований
законодательства о противодействии легализации (отмыванию) доходов, полученных преступным путем, и
финансированию терроризма.
3.2.3. Не представлять Контрагенту Акт об оказанных услугах в случае, если за отчетный период
Оператором не было исполнено ни одного распоряжения о совершении перевода.
3.2.4. Размещать товарный знак Контрагента или третьих лиц, иное средство индивидуализации Контрагента
(третьих лиц), предоставленное в качестве такового Контрагентом в соответствии с пунктом 3.3.9. Договора
3.2.5. В одностороннем порядке вносить изменения в любые условия настоящего Договора, включая
условие о вознаграждении Оператора, указанное в Заявлении. Об изменении размера вознаграждения Оператор
уведомляет Контрагента путем направления сообщения на адрес электронной почты, указанный в Заявлении, не
позднее, чем за три календарных дня до даты вступления изменений в силу. Изменения иных условий Договора
вступают в силу и становятся обязательными для Сторон с момента их размещения на сайте Оператора с сетевым
адресом https://money.yandex.ru и не требуют направления Оператором Контрагенту уведомлений. Заключение
дополнительного соглашения к Договору между Сторонами при изменении его условий в порядке настоящего
подпункта 3.2.5. не требуется.
3.2.6. Требовать от Контрагента предоставления любых документов на основании соответствующих
запросов кредитных организаций, осуществляющих эквайринг банковских карт, с использованием которых были
осуществлены переводы.
3.2.7. Отказать Контрагенту в заключении Договора, направив уведомление на адрес электронной почты
Контрагента, указанный в Заявлении.
3.3. Контрагент обязуется:
3.3.1. Выплачивать Оператору вознаграждение в размере, указанном в Заявлении.
3
3.3.2. Разместить на своем сайте, адрес которого указан в Заявлении, средства индивидуализации Оператора
по требованию Оператора или по собственной инициативе при наличии письменного согласия Оператора.
3.3.3. Признавать обязательства физических лиц перед Контрагентом по оплате исполненными с момента
направления Оператором Контрагенту уведомления об оплате в соответствии с п. 3.1.3. настоящего Договора.
3.3.4. Не взимать с физических лиц вознаграждение и не возлагать на них никаких дополнительных
расходов в связи с осуществлением ими переводов через Оператора.
3.3.5. Самостоятельно разрешать претензии физических лиц о возврате сумм полученных переводов.
3.3.6. В случае несогласия с содержанием реестра, полученного от Оператора в соответствии с п. 3.1.4.
настоящего Договора, сообщать Оператору о таком несогласии не позднее 11 часов 59 минут 59 секунд по
московскому времени календарного дня, следующего за днем получения от Оператора оспариваемого реестра, по
электронной почте на адрес [email protected] с указанием мотивов несогласия. В случае непоступления от
Контрагента замечаний и (или) пропуска Контрагентом предусмотренного настоящим подпунктом срока
информация, содержащаяся в реестре, считается подтвержденной без замечаний.
3.3.7. В трехдневный срок извещать Оператора в письменном виде о любых событиях, могущих повлиять на
исполнение настоящего Договора, в том числе об изменениях своего наименования, места нахождения,
фактического адреса, банковских реквизитов, адреса интернет-сайта.
3.3.8. Предварительно согласовывать с Оператором раскрытие любой информации о сотрудничестве Сторон
независимо от формы и способа раскрытия информации.
3.3.9. Направить Оператору по электронной почте на адрес [email protected] изображения товарного
знака или иного средства индивидуализации Контрагента (третьих лиц) в формате .gif, размером 88*31 пикселей,
неанимированного для их размещения Оператором в соответствии с п. 3.2.4. настоящего Договора. В случае
предоставления средств индивидуализации третьих лиц Контрагент обязан иметь надлежащим образом
оформленное письменное согласие соответствующего лица на такое размещение.
3.3.10. Уведомлять Оператора о планируемом изменении перечня реализуемых товаров/работ/услуг в срок
не позднее, чем за 5 (пять) рабочих дней до планируемой даты изменений.
3.3.11. Не осуществлять продажу товаров/работ/услуг, запрещенных к продаже в соответствии с
законодательством Российской Федерации, а также товаров/работ/услуг, запрещенных к продаже через сеть
«Интернет» в соответствии с правилами международных платежных систем.
3.3.12. Предоставлять документы и исполнять иные требования, предъявленные Оператором на основании
соответствующих запросов (требований) кредитных организаций, осуществляющих эквайринг банковских карт, с
использованием которых были осуществлены переводы.
3.3.13. Определять процедуру отказа от товаров (сроки и условия), оплаченных с использованием
банковских карт, с учетом следующего условия: покупатель вправе отказаться как от всех, так и от части товаров,
оплаченных с использованием карты.
3.3.14. Определять процедуру (способы и сроки) возврата физическим лицом товаров, оплаченных с
использованием банковских карт, с учетом следующего: возврат уплаченной за товар суммы осуществляется
только на карту, с использованием которой были оплачены товары; покупатель праве возвратить как все, так и
часть товаров, оплаченных с использованием карты.
3.3.15. В течение 3 (трех) рабочих дней с даты получения соответствующего требования Оператора
предоставить Оператору описание процедуры оплаты товаров/услуг, процедуры предоставления физическим
лицам товаров/услуг, а также процедур отмены операций оплаты заказов и возврата товаров/отказа от услуг,
размещаемых на сайте Контрагента в сети «Интернет».
4. Вознаграждение Оператора и порядок расчетов
4.1. Размер вознаграждения Оператора за отчетный период, равный календарному месяцу, исчисляется на
основании Акта об оказанных услугах в процентах от суммы каждого перевода, информация о котором передана
Контрагенту за отчетный период.
Ставка вознаграждения устанавливается Оператором исходя из полученных от Контрагента сведений о виде
деятельности и размещается в Личном кабинете Контрагента.
Ставка вознаграждения Оператора указывается в Заявлении и может быть изменена Оператором в порядке,
установленном пунктом 3.2.5. настоящего Договора.
В случае получения Заявления, содержащего ставки вознаграждения, отличные от предварительно
согласованных Оператором, Оператор отказывает в акцепте оферты Контрагента с указанием на данное
обстоятельство.
4
Вознаграждение Оператора не облагается НДС в соответствии с подпунктом 4 пункта 3 статьи 149 НК РФ.
4.2. Вознаграждение удерживается Оператором из сумм, подлежащих перечислению Оператором
Контрагенту.
4.3. Суммы переводов, подлежащие перечислению Оператором Контрагенту, перечисляются Контрагенту за
вычетом всех удержаний, которые Оператор вправе осуществить по настоящему Договору, не позднее второго
банковского дня с даты направления Оператором уведомления Контрагенту, предусмотренного п. 3.1.3.
настоящего Договора.
4.4. Не позднее пятого числа месяца, следующего за отчетным, Оператор направляет Контрагенту Акт об
оказанных услугах по форме Приложения № 3 к настоящему Договору по электронной почте на адрес, указанный в
Заявлении. В случае, если за отчетный период Оператором не было исполнено ни одного распоряжения
физического лица о совершении перевода в пользу Контрагента, Оператор вправе не предоставлять Контрагенту
Акт об оказанных услугах.
4.5. Не позднее пятнадцатого числа месяца, следующего за отчетным, Контрагент при наличии у него
возражений к Акту об оказанных услугах обязан направить их Оператору по электронной почте на адрес
[email protected] В случае неполучения Оператором возражений Контрагента в указанный срок
соответствующие услуги Оператора считаются оказанными в полном объеме и надлежащим образом.
В случае, если возражения Контрагента относительно сумм, содержащихся в Акте об оказанных услугах,
будут признаны обоснованными, Оператор обязуется в срок не позднее трех рабочих дней с даты получения
Оператором возражений Контрагента направить Контрагенту по адресу электронной почты, указанному в п. 4.4.
настоящего Договора, уточненный Акт об оказанных услугах. Возражения к уточненному Акту об оказанных
услугах Контрагент вправе заявить не позднее рабочего дня, следующего за днем его получения, в противном
случае уточненный Акт об оказанных услугах считается принятым Контрагентом без замечаний, а
соответствующие услуги Оператора – оказанными в полном объеме и надлежащим образом.
При наличии у Контрагента необходимости подписания Акта об оказанных услугах в письменной форме на
бумажном носителе Контрагент после согласования Акта об оказанных услугах в порядке, установленном
абзацами первым либо первым и вторым настоящего пункта направляет Оператору два экземпляра подписанного
со своей стороны Акта об оказанных услугах. В этом случае Оператор обязуется в течение трех рабочих дней с
даты получения от Контрагента Акта об оказанных услугах на бумажном носителе подписать его и отправить один
экземпляр Акта Контрагенту.
4.6. При наличии у Сторон сертификатов ключей проверки электронной подписи, выданных одним или
разными аккредитованными удостоверяющими центрами и позволяющих Сторонам осуществлять электронное
взаимодействие, Стороны согласовывают Акты путем обмена документами, подписанными квалифицированной
электронной подписью, в сроки, установленные пунктами 4.4. и 4.5. Договора. Обмен Актами на бумажном
носителе в этом случае не требуется.
4.7. Любые расходы (издержки), понесенные Оператором при исполнении своих обязательств по
настоящему Договору, учтены в размере вознаграждения Оператора и не подлежат дополнительному возмещению
Контрагентом.
4.8. Внимание!
Применимый вариант регулирования определяется в порядке, установленном пунктом 2.10.
Договора!
4.8. Вариант 1
4.8.1. Возврат физическим лицам сумм переводов осуществляется Оператором на основании платежного
поручения Контрагента. Денежные средства для возврата физическим лицам Контрагент перечисляет на счет
Оператора, предназначенный для возвратов. При перечислении денежных средств для возврата физическому лицу
в графе «Назначение платежа» платежного поручения Контрагент указывает: «Возврат средств по договору №____
от____ по переводу № [номер транзакции] пользователя № [номер, присвоенный физическому лицу Оператором],
без НДС».
4.8.2. Возврат суммы перевода в соответствии с настоящим пунктом не влечет обязанности Оператора
возвратить Контрагенту сумму вознаграждения, полученного за уведомление Контрагента о переводе.
4.8.3. Возможность возврата суммы перевода зависит от способа осуществления перевода и указана в
Приложении №6 к Договору.
4.7. Вариант 2
Оператор совершает возврат физическим лицам сумм переводов и отмену переводов в порядке,
5
установленном настоящим пунктом.
4.8.1. Возврат суммы перевода — возврат Оператором физическим лицам части суммы перевода в день
приема перевода, а также полной суммы перевода или части суммы перевода после дня приема перевода на
основании распоряжения Контрагента.
Оператор возвращает физическим лицам полностью или частично суммы совершенных ими переводов на
основании распоряжения Контрагента, оформленного в соответствии с Приложением № 7 к настоящему Договору.
Возврат суммы перевода в соответствии с настоящим подпунктом не влечет обязанности Оператора
возвратить Контрагенту сумму вознаграждения, полученного за уведомление Контрагента о переводе.
Допускается направление Контрагентом нескольких распоряжений Оператору на возврат частей сумм
одного и того же перевода, если их общая сумма не превышает сумму данного перевода.
Сумму возвращенных физическим лицам переводов Оператор удерживает из суммы переводов,
подлежащих перечислению Оператором Контрагенту. В случае недостаточности суммы таких переводов для
совершения удержания в полном объеме Контрагент перечисляет Оператору недостающую сумму в течение трех
банковских дней с даты получения соответствующего требования Оператора, направленного по адресу
электронной почты и (или) по почтовому адресу Контрагента, указанным Контрагентом в Заявлении.
4.8.2. Отмена перевода (инициируется только на полную сумму перевода не позднее дня совершения
перевода).
На основании распоряжения Контрагента, оформленного в соответствии с Приложением № 7 к настоящему
Договору и направленного Оператору до перечисления последним Контрагенту суммы соответствующего
перевода, Оператор совершает полную отмену указанного Контрагентом перевода (переводов).
Вознаграждение Оператора по отмененным переводам не удерживается.
Отмененные переводы не считаются Сторонами совершенными Оператором за отчетный период. Суммы
отмененных переводов не включаются в отчет Оператора.
4.8.3. Возможность возврата или отмены суммы перевода зависит от способа осуществления перевода и
указана в Приложении №6 к Договору.
4.9. В случае необходимости повторного предоставления отчетности Оператором по обстоятельствам, за
которые Оператор не несет ответственности, с Контрагента взимается вознаграждение в размере 100 (сто) рублей
за один документ, в том числе НДС.
4.10. В случае, если кредитной организацией, осуществляющей эквайринг, будет предъявлено требование
Оператору о возврате суммы перевода, совершенного с использованием банковской карты, по основаниям,
установленным правилами международной платежной системы и/или кредитной организации, осуществляющей
эквайринг, Контрагент обязан возвратить сумму такого перевода Оператору.
4.11. В случае если в отношении перевода, совершенного с использованием банковской карты, эмитентом
карты/держателем карты предъявлены претензии (далее - оспариваемые операции), Контрагент обязан возвратить
Оператору денежные средства по оспариваемой операции в размере суммы, оспариваемой эмитентом
карты/держателем карты. Решение о возможности повторного перечисления Контрагенту суммы оспариваемой
операции принимается
по результатам разбирательства, осуществляемого в соответствии с правилами
международной платежной системы/эмитента карты.
4.12. Оператор вправе требовать от Контрагента возмещения сумм указанных в пунктах 4.10. и 4.11.
Договора переводов в течение срока действия настоящего Договора, а также 180 дней с даты расторжения
настоящего Договора.
4.13. Оператор вправе удержать денежные средства, которые должны быть возвращены Контрагентом
Оператору в соответствии с пунктами 4.10. и 4.11. настоящего Договора, из сумм переводов, подлежащих
перечислению Оператором Контрагенту. В случае недостаточности суммы таких переводов для совершения
удержания в полном объеме Контрагент перечисляет Оператору недостающую сумму в течение трех банковских
дней с даты получения соответствующего требования Оператора, направленного по адресу электронной почты
и/или по адресу места нахождения Контрагента.
4.14. В случаях, указанных в пунктах 4.10., 4.11 настоящего Договора, Оператор имеет право отложить, а
также не производить перечисление сумм переводов, предусмотренных названными пунктами.
4.15. Оператор имеет право отложить перечисление Контрагенту сумм переводов, совершенных с
использованием банковских карт, на срок до 180 календарных дней (в течение которого эмитент карты в
соответствии с правилами международных платежных систем имеет право предъявить претензию по операции) в
случае, если переводы вызывают подозрение относительно их правомерности, в том числе в случае получения
Оператором уведомления от кредитной организации, осуществляющей эквайринг (в том числе в электронном
6
виде/по факсу), о том, что проведенные с использованием банковских карт операции являются мошенническими.
По истечении указанного срока Оператор перечисляет Контрагенту суммы переводов либо отказывает в
перечислении на основании решения кредитной организации, осуществляющей эквайринг. На Контрагента
возлагаются все расходы Оператора, возникшие в связи с возвратом эмитенту карты суммы перевода,
совершенного с использованием банковской карты.
4.16. В случае взыскания кредитной организацией, осуществляющей эквайринг, с Оператора штрафов (в
соответствии с правилами международных платежных систем), связанных с совершением переводов по
поддельным, потерянным, украденным банковским картам, а также в иных случаях, когда штраф наложен по
обстоятельствам, за которые отвечает Контрагент, Контрагент обязан возместить Оператору сумму уплаченных
Оператором штрафов на основании предоставленных Оператором документов, подтверждающих взыскание с
Оператора штрафов.
5. Ответственность Сторон и порядок разрешения споров
5.1. Оператор не несет ответственности перед физическими лицами за исполнение Контрагентом своих
обязательств перед ними.
5.2. Контрагент самостоятельно разрешает любые споры с физическими лицами, возникающие в случае
несоответствия суммы совершенного Оператором перевода тарифам (прейскурантам) Контрагента.
5.3. В случае вступления в законную силу решения суда о взыскании с Оператора в пользу третьего лица
денежных средств на основании неправомерного (в отсутствие письменного согласия соответствующего
контрагента, предусмотренного п. 3.3.9. настоящего Договора) использования Оператором средства
индивидуализации данного лица, предоставленного Контрагентом в качестве такового, Контрагент обязуется при
условии совершения Оператором действий, предусмотренных абзацем вторым настоящего пункта, в течение
десяти рабочих дней с даты получения соответствующей претензии Оператора с приложением копии вступившего
в законную силу решения суда возместить Оператору убытки, причиненные нарушением своего обязательства,
предусмотренного п. 3.3.9. настоящего Договора, в размере полной суммы, взысканной с Оператора в пользу
третьего лица на основании соответствующего судебного акта, включая взысканную с Оператора сумму судебных
расходов.
В случае предъявления третьим лицом иска к Оператору по основанию, указанному в абзаце первом
настоящего пункта, Оператор обязуется уведомить Контрагента о принятии такого иска к производству и заявить в
предварительном судебном заседании первой инстанции ходатайство о привлечении Контрагента к участию в
соответствующем деле в качестве третьего лица.
5.4. В случае возникновения споров о факте получения одной из Сторон какого-либо
документа/уведомления, размещенного в Личном кабинете, о факте внесения в него изменений, о доступе и
использовании Личного кабинета в нарушение настоящего Договора бремя доказывания лежит на Стороне,
которая ссылается на данные обстоятельства.
5.5. В случае взыскания с Оператора третьим лицом денежных средств вследствие реализации Контрагентом
товаров/услуг в нарушение требований законодательства Российской Федерации, а также общепринятых норм
морали и нравственности Контрагент обязан возместить Оператору сумму взысканных с него денежных средств в
течение трех банковских дней с даты получения соответствующего требования Оператора, направленного по
адресу электронной почты и (или) по почтовому адресу Контрагента, указанным Контрагентом в Заявлении.
5.6. В случае возникновения между Сторонами споров о правомерности предоставления Оператором
доступа к Личному кабинету, Оператор использует программное обеспечение, которое применялось при
формировании и проверке авторизационных данных Контрагента, и выносит свое решение. Контрагент вправе
оспорить данное решение в судебном порядке.
5.7. Любые споры и разногласия Сторон по настоящему Договору или в связи с ним, которые не были
урегулированы путем переговоров Сторон, подлежат разрешению в Арбитражном суде города Москвы.
6. Конфиденциальность
6.1. Факт заключения настоящего Договора не рассматривается Сторонами как конфиденциальная
информация.
6.2. Стороны обязуются не разглашать информацию:


об условиях настоящего Договора;
о количестве и сумме переводов, информация о которых передана Контрагенту;
7


о статистических данных, основанных на сравнении сумм переводов, информация о которых
передана Оператором, и данных о переводах других операторов по переводу;
прочую информацию, полученную Сторонами в ходе выполнения своих обязательств по
настоящему Договору, за исключением случаев, когда Сторона обязана предоставить такую
информацию в соответствии с законодательством РФ.
7. Срок действия и порядок прекращения договора
7.1. Настоящий Договор действует в течение двенадцати календарных месяцев с даты его заключения.
7.2. Срок действия настоящего Договора автоматически продлевается на двенадцать календарных месяцев в
случае, если ни одна из Сторон не уведомляет другую Сторону в письменной форме на бумажном носителе о
своем нежелании продлевать срок действия настоящего Договора не менее чем за тридцать календарных дней до
истечения срока (в том числе очередного) его действия. Такое уведомление не рассматривается Сторонами как
односторонний отказ от исполнения настоящего Договора.
Срок действия настоящего Договора может быть продлен в соответствии с настоящим пунктом
неограниченное количество раз.
7.3. Любая из Сторон вправе в одностороннем порядке отказаться от дальнейшего исполнения настоящего
Договора. Для этих целей она в письменной форме уведомляет другую сторону о своем намерении не позднее, чем
за 30 (тридцать) календарных дней до предполагаемой даты отказа от исполнения. Уведомление должно быть
сделано в письменной форме на бумажном носителе и содержать указание на причину расторжения Договора.
7.4. В случае изменения условий Договора в порядке, установленном подпунктом 3.2.5, Контрагент праве
отказаться от исполнения Договора, направив Оператору уведомление на бумажном носителе в течение трех дней
с момента получения уведомления об изменении Договора или публикации изменений на сайте Оператора.
7.5. Обязательства Сторон по настоящему Договору, возникшие до его прекращения, сохраняются вплоть до
их полного исполнения.
8. Прочие условия
8.1. Все приложения к настоящему Договору размещены на
https://money.yandex.ru/merchants/annex и являются его неотъемлемыми частями.
сайте
Оператора
по
адресу
Приложения на момент заключения Договора:
№ 1. Соглашение об электронном документообороте.
№ 2. Протокол обмена информацией при осуществлении переводов: HTTP- и Email- уведомления.
№ 2.1. Формат ежедневного реестра возвращенных переводов (Приложение порождает права и
обязанности для Сторон только в случае, если для Контрагента применим вариант 2 пунктов 3.1.4. и 4.8.
Договора).
№ 3. Форма Акта об оказанных услугах.
№4. Форма Заявления для Контрагентов — индивидуальных предпринимателей;
№5. Форма Заявления для Контрагентов — юридических лиц.
№6. Возможность возврата или отмен переводов.
№7. Порядок осуществления возвратов сумм переводов и отмен переводов (Приложение порождает права
и обязанности для Сторон только в случае, если для Контрагента применим вариант 2 пунктов 3.1.4. и 4.8.
Договора).
8.2. Ни одна из Сторон не вправе передать свои права и обязанности по настоящему Договору третьим
лицам без письменного на то согласия другой стороны.
8
ПРИЛОЖЕНИЕ № 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. Корневой сертификат УЦ — сертификат, который был выдан удостоверяющим центром самому себе и
является самоподписанным. Все остальные сертификаты, выдаваемые данным УЦ, подписываются
ключом ЭП этого корневого сертификата. В понятии инфраструктуры открытых ключей: если есть
доверие к корневому сертификату УЦ, то автоматически есть доверие ко всем сертификатам, выданным
данным УЦ и подписанным ключом ЭП данного корневого сертификата. Обычно в УЦ есть только один
корневой сертификат.
9
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.1.4 Основного договора.
3.4. Обмен иными ЭД в Системе не является основанием возникновения обязательств сторон по Основному
договору и Соглашению. Стороны признают юридическую силу ПЭД, подписанных НЭП (при
подтверждении подлинности ЭП в ПЭД), равной юридической силе документов на бумажном носителе,
оформленных в соответствии с требованиями законодательства Российской Федерации и условиями
Соглашения и Основного договора, и подписанных уполномоченными представителями сторон, с
приложением оттисков печатей сторон.
3.5. ПЭД порождает обязательства сторон, установленные Соглашением и Основным договором, если
передающей стороной он должным образом оформлен, подписан НЭП, а принимающей стороной
получен, проверен и принят к обработке в установленном Соглашением порядке.
3.6. Данное соглашение распространяется только на обеспечение защиты информации в ПЭД при передаче по
открытым каналам связи. Остальные требования по защите информации выполняются сторонами
самостоятельно на основании требований действующего законодательства и требований внутренних
нормативных документов сторон.
3.7. Передача ПЭД осуществляется через Систему между сторонами путем передачи сообщений электронной
почты через интернет.
3.8. Подключение сторон к интернету выполняется самостоятельно и не является предметом Соглашения.
4.
Общие принципы электронного документооборота
4.1. Каждая из Сторон при подписании ЭД применяет свой ключ ЭП, а при проверке подписи — ключ
проверки ЭП, записанный в сертификате ключа проверки ЭП, другой стороны.
4.2. Стороны обмениваются сертификатами, которые будут использоваться для создания ЭП.
10
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. Немедленно информировать другую сторону обо всех случаях утраты, хищения, несанкционированного
использования ключей ЭП по следующим адресам: Оператора — по адресу [email protected],
Контрагента — по адресу электронной почты, указанному Контрагентом в Заявлении. При этом работа в
Системе приостанавливается до проведения внеплановой смены ключей.
5.7. Принимать на себя все риски, связанные с работоспособностью своего оборудования и каналов связи.
5.8. За собственный счет поддерживать в рабочем состоянии входящие в Систему программно-технические
комплексы обеспечения работоспособности вычислительной техники и техники связи, обеспечивающих
электронный документооборот.
5.9. Своевременно (не менее, чем за три дня) уведомлять друг друга об изменении своего фактического места
нахождения, сетевого адреса в интернете, а также об изменении иных реквизитов, имеющих
существенное значение для определения юридического статуса и идентификации сторон и исполнения
обязательств по Соглашению.
5.10. Не предпринимать действий, способных нанести ущерб другой стороне вследствие использования
Системы.
5.11. Своевременно информировать (по электронной почте и/или телефону) другую сторону обо всех случаях
возникновения технических неисправностей или других обстоятельств, препятствующих электронному
документообороту.
5.12. В случае обнаружения возможных угроз безопасности стороны обязуются своевременно извещать друг друга
о таких угрозах для принятия согласованных мер по их нейтрализации.
5.13. Строго выполнять требования технической и эксплуатационной документации к программному и
аппаратному обеспечению Системы.
5.14. Разработать и выполнять мероприятия по обеспечению конфиденциальности, целостности и сохранности
программных средств Системы, передаваемых ПЭД, протоколов регистрации событий, действующей
ключевой информации и парольной информации, используемой для доступа в Систему.
5.15. Организовать внутренний режим функционирования рабочего места ответственного лица таким образом,
чтобы исключить возможность использования Системы лицами, не имеющими допуска к работе с ней, а
также исключить возможность использования средств ЭП не уполномоченными на это лицами.
5.16. Обеспечивать сохранение в тайне сведений по вопросам технологии защиты информации, используемых
при обмене ЭД между сторонами, за исключением случаев, предусмотренных действующим
законодательством Российской Федерации.
11
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 бит;
12

алгоритм хеширования — 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.
Порядок разрешения споров, связанных с установлением подлинности ЭД
13
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. Уполномоченными лицами на использование ЭП от имени Сторон являются:
от Оператора — Председатель Правления Шабанова Татьяна Андреевна;
от Контрагента - юридического лица — лицо, уполномоченное учредительными документами или
доверенностью; от Контрагента – индивидуального предпринимателя – лицо, зарегистрированное в качестве
индивидуального предпринимателя, или лицо, уполномоченное доверенностью.
14
ПРИЛОЖЕНИЕ № 2
Протокол обмена информацией при осуществлении переводов:
HTTP- и email-уведомления
Протокол 3.0, редакция от 16.09.2014
ОГЛАВЛЕНИЕ
1.
Общие сведения ........................................................................................................................................... 16
Назначение документа .......................................................................................................................... 16
Подключение Контрагента ................................................................................................................... 16
2.
Обобщенное описание взаимодействия ..................................................................................................... 17
3.
Платежная форма ......................................................................................................................................... 18
4.
HTTP-уведомления о переводах ................................................................................................................. 21
Формат взаимодействия ........................................................................................................................ 21
Проверка заказа (сheckOrder) ............................................................................................................... 21
4.2.1.
Формат запроса Оператора ................................................................ 22
4.2.2.
Формат ответа Контрагента................................................................ 23
Уведомление о переводе (paymentAviso) ............................................................................................ 25
4.3.1.
Формат запроса Оператора ................................................................ 25
4.3.2.
Формат ответа Контрагента................................................................ 26
Правила обработки HTTP-уведомлений Контрагентом ..................................................................... 26
5.
Email-уведомления о переводах ................................................................................................................. 27
6.
Приложения .................................................................................................................................................. 29
Параметры подключения Контрагента ................................................................................................ 29
Особенности взаимодействия при оплате наличными через терминалы ......................................... 31
Реестры принятых переводов ............................................................................................................... 33
Способы оплаты ..................................................................................................................................... 35
Типы данных .......................................................................................................................................... 36
15
1. Общие сведения
Назначение документа
Данный документ описывает взаимодействие ООО НКО «Яндекс.Деньги» (далее – Оператор,
Яндекс.Деньги) с информационной системой (далее – ИС) Контрагента, необходимое для уведомления
Контрагента о совершенном в его пользу переводе (далее также – платеж) в режиме реального
времени.
Оператор обеспечивает прием платежей, осуществляемых различными способами: с банковских карт,
из электронных кошельков (в том числе со счетов Яндекс.Денег), наличными через терминалы, со
счетов мобильных телефонов. Перечень способов, доступный конкретному Контрагенту, зависит от
условий договора и дополнительно контролируется настройками на стороне Оператора.
Упрощенно процесс взаимодействия можно представить в виде нескольких последовательных
действий:
1. Передача Оператору данных о заказе и способе его оплаты (осуществляется с помощью браузера
плательщика).
2. Уведомление Контрагента о платеже (осуществляется Оператором, возможна отправка HTTP- или
email-уведомлений).
3. Формирование реестра принятых в пользу Контрагента переводов (пересылается Оператором по
электронной почте).
4. Перечисление денежных средств на банковский счет Контрагента.
5. При необходимости – возврат успешных платежей плательщикам по инициативе Контрагента.
Пп. 1–3 описаны далее по тексту, пп. 4–5 выходят за рамки данного документа. Для работы с возвратами
Контрагенту дополнительно потребуется выпустить сертификат и реализовать протокол Merchant Web
Services (MWS). Процедура обмена сертификатами и протокол MWS описаны в отдельных документах.
Подключение Контрагента
Контрагенту доступны две схемы подключения к Яндекс.Деньгам:
 схема с отправкой уведомлений о платежах в адрес Контрагента посредством вызовов по
протоколу HTTP (далее – HTTP-схема, подробное описание взаимодействия представлено в
разделе Error! Reference source not found. «Error! Reference source not found.»);
 схема с отправкой уведомлений о платежах в адрес Контрагента по электронной почте (далее –
email-схема, подробное описание представлено в разделе Error! Reference source not found.
«Error! Reference source not found.»).
Принципиальное различие в том, что email-схема не предполагает обратной связи, а HTTP-схема
позволяет Контрагенту производить онлайн-проверку параметров заказа при оплате. Если Контрагенту
необходимо в режиме реального времени демонстрировать плательщику у себя на сайте, что товар или
услуга уже оплачены, Контрагент должен использовать HTTP-схему подключения к Яндекс.Деньгам.
Схемы не могут использоваться одновременно. Количество доступных способов оплаты от выбранной
схемы не зависит.
16
В зависимости от схемы Контрагент должен сообщить Оператору параметры подключения: URL'ы (адрес
электронной почты) для отправки уведомлений, URL'ы для редиректа плательщика после оплаты, адрес
электронной почты для отправки реестров принятых переводов и т.д. (подробная информация – в
разделе Error! Reference source not found. «Error! Reference source not found.»).
Оператор в ответ предоставляет настройки для доступа к тестовой среде Яндекс.Денег, а после
завершения процедуры отладки – настройки для «боевого» взаимодействия. Подключение к MWS
производится отдельно.
2. Обобщенное описание взаимодействия
0. Контрагент размещает на странице оплаты заказа «платежную форму» с данными заказа и указанием
способов оплаты (в ряде случаев возможно размещение «платежной формы» на сайте Оператора:
https://money.yandex.ru/shops.xml).
При HTTP-схеме подключения
При email-схеме подключения
1-2. Браузер плательщика передает заполненную форму в ИС Оператора.
3. На основании полученных данных Оператор определяет способ оплаты и отображает для
плательщика страницу подтверждения платежа.
4. Плательщик вводит дополнительные данные (например, реквизиты банковской карты) и
подтверждает платеж.
5. Перед тем как провести платеж, Оператор
5. Шаг пропускается.
отправляет в ИС Контрагента запрос
«Проверка заказа (сheckOrder)».
6. Контрагент подтверждает корректность
6. Шаг пропускается.
заказа либо отказывается от проведения
платежа.
7-8. Если ИС Контрагента ответила на запрос
7-8. Оператор списывает деньги с плательщика
«Проверка заказа» положительно, то
и отображает для него результат проведения
17
Оператор списывает деньги с плательщика и
платежа.
отображает для него результат проведения
платежа.
9. На странице результата отображается ссылка «Вернуться в магазин».
URL, на который будет перенаправлен плательщик, определяется Контрагентом.
10-11. По факту успешного прохождения
10. По факту успешного прохождения платежа
платежа Оператор отправляет ИС Контрагента Оператор отправляет ИС Контрагента emailзапрос «Уведомление о переводе
уведомление о переводе.
(paymentAviso)».
Обратите внимание: взаимодействие Оператора и Контрагента в случае оплаты заказа наличными
через терминалы имеет ряд особенностей. Описание этого сценария приведено в разделе Error!
Reference source not found. «Error! Reference source not found.».
Раз в сутки Оператор отправляет Контрагенту по электронной почте реестр принятых переводов.
Контрагент должен сверять список успешных платежей по данным своей ИС со списком операций из
реестра и сообщать Оператору о расхождениях. Формат реестра описан в разделе Error! Reference
source not found. «Error! Reference source not found.».
3. Платежная форма
Платежная форма размещается Контрагентом на странице оплаты, определяет параметры заказа и
способ платежа. Отправка через браузер плательщика платежной формы по стандартному адресу
(http://money.yandex.ru/eshop.xml) инициирует на стороне Оператора формирование и обработку
распоряжения на перевод.
Пример платежной формы:
18
<!-- Значения всех полей условны и приведены исключительно для примера -->
<form action="https://money.yandex.ru/eshop.xml" method="post">
<!-- Обязательные поля -->
<input name="shopId" value="1234" type="hidden"/>
<input name="scid" value="4321" type="hidden"/>
<input name="sum" value="100.50" type="hidden">
<input name="customerNumber" value="abc000" type="hidden"/>
<!-- Необязательные поля -->
<input name="shopArticleId" value="567890" type="hidden"/>
<input name="paymentType" value="AC" type="hidden"/>
<input name="orderNumber" value="abc1111111" type="hidden"/>
<input name="cps_phone" value="79110000000" type="hidden"/>
<input name="cps_email" value="[email protected]" type="hidden"/>
<input type="submit" value="Заплатить"/>
</form>
Для передачи данных о заказе и способе его оплаты нужно использовать параметры из таблицы ниже.
Все параметры регистрозависимые.
Таблица 3.1. Параметры платежной формы
Параметр
Тип
Служебные параметры:
shopId
xs:long,
обязательный
shopArticleId
xs:long,
необязательный
scid
sum
customerNumber
xs:long,
обязательный
CurrencyAmount,
обязательный
xs:normalizedString,
до 64 символов,
обязательный
Описание
Идентификатор Контрагента, выдается Оператором.
Идентификатор товара, выдается Оператором.
Применяется, если Контрагент использует несколько
платежных форм для разных товаров.
Номер витрины Контрагента, выдается Оператором.
Стоимость заказа.
Идентификатор плательщика в ИС Контрагента. В
качестве идентификатора может использоваться номер
договора плательщика, логин плательщика и т. п.
19
Возможна повторная оплата по одному и тому же
идентификатору плательщика.
orderNumber
xs:normalizedString, Уникальный номер заказа в ИС Контрагента.
до 64 символов,
Уникальность контролируется Оператором в сочетании
необязательный
с параметром shopId.
Если платеж с таким номер заказа уже был успешно
проведен, то повторные попытки оплаты будут
отвергнуты Оператором.
shopSuccessURL
xs:string, до 250
URL, на который нужно отправить плательщика в случае
символов,
успеха перевода. Используется при выборе
необязательный
соответствующей опции подключения Контрагента (см.
раздел Error! Reference source not found. «Error!
Reference source not found.»).
shopFailURL
xs:string, до 250
URL, на который нужно отправить плательщика в случае
символов,
ошибки оплаты. Используется при выборе
необязательный
соответствующей опции подключения Контрагента.
cps_email
xs:string, до 100
Адрес электронной почты плательщика. Если он
символов,
передан, то соответствующее поле на странице
необязательный
подтверждения платежа будет предзаполнено (шаг 3
на схеме выше).
cps_phone
xs:string, до 15
Номер мобильного телефона плательщика. Если он
символов, только передан, то соответствующее поле на странице
цифры,
подтверждения платежа будет предзаполнено (шаг 3
необязательный
на схеме выше). Номер телефона используется при
оплате наличными через терминалы.
paymentType
xs:normalizedString, Способ оплаты. Например:
до 5 символов,
 PC – оплата из кошелька в Яндекс.Деньгах;
необязательный
 AC – оплата с произвольной банковской карты.
Полный список значений см. в таблице 6.4.1.
Обратите внимание:
 отсутствие paymentType интерпретируется как
оплата из кошелька в Яндекс.Деньгах;
 если в платежной форме указан способ оплаты,
который не разрешен для Контрагента, плательщик
не сможет совершить платеж.
Параметры, добавляемые Контрагентом:
Любые
xs:string
Параметры, добавленные Контрагентом в платежную
названия,
форму, будут сохранены и переданы ИС Контрагента в
отличные от
запросах «Проверка заказа» и «Уведомление о
перечисленных
переводе».
выше
Суммарная длина всех добавленных Контрагентом
параметров не должна превышать 4096 символов.
Обратите внимание: в email-уведомлениях
произвольные параметры Контрагента не передаются.
Для передачи дополнительных данных о платеже
Контрагент может воспользоваться стандартными
параметрами, перечисленными ниже.
Служебные параметры, используемые в email-уведомлениях о переводе:
custName
xs:string,
ФИО плательщика.
необязательный
custAddr
xs:string,
Адрес доставки товара или адрес проживания
необязательный
плательщика.
custEMail
xs:string,
Адрес электронной почты плательщика, только для
20
orderDetails
необязательный
xs:string,
необязательный
отправки в email-уведомлениях.
Детали заказа: список приобретенных товаров, их
количество, назначение платежа и т. п.
4. HTTP-уведомления о переводах
Формат взаимодействия
При подключении по HTTP-схеме Контрагент определяет адрес, по которому он будет принимать HTTPуведомления от Оператора.
Данные от Оператора передаются в ИС Контрагента посредством вызова по протоколу HTTP/1.1,
методом POST. Параметры сообщения упаковываются как набор параметров POST-запроса в виде пар
«имя=значение». MIME-тип: application/x-www-form-urlencoded, кодировка символов – UTF-8.
Параметр «md5» запроса содержит значение хэш-функции от свертки параметров сообщения совместно
с секретным словом, указанным Контрагентом при подключении. Контрагенту следует проверять
значение параметра «md5» (алгоритм приведен в разделе Error! Reference source not found. «Error!
Reference source not found.») и отказывать в обработке запроса при неуспехе проверки. Успех проверки
хэша удостоверяет:
• факт того, что запрос отправлен Оператором;
• факт целостности данных запроса.
Дополнительно рекомендуется проверять IP-адреса, с которых ИС Контрагента принимает запросы
(список IP Оператора можно получить при подключении).
При взаимодействии ИС Оператора и Контрагента для защиты информации о платежах обязательно
соблюдение одного из условий ниже:
1. передача информации происходит по защищенному каналу (Контрагент использует протокол
HTTPS для приема сообщений от Оператора);
2. сообщения Оператора шифруются перед отправкой(*).
* Требуется подключение Контрагента по схеме XML/PKCS#7. В этом случае сообщения
передаются Оператором в виде XML-документа, вложенного в криптоконтейнер PKCS#7.
Данные подписываются SSL-сертификатом Оператора. Для получения подробной
информации о схеме подключения XML/PKCS#7 обратитесь к своему менеджеру.
Результат выполнения запроса Оператора должен быть возвращен Контрагентом в виде XML-документа
в теле ответа на HTTP-запрос. Документ формируется согласно стандарту XML 1.0 (Fifth Edition),
опубликованному по адресу: http://www.w3.org/TR/xml/. Имена элементов и атрибутов чувствительны к
регистру. MIME-тип: application/xml, кодировка символов – UTF-8.
21
Проверка заказа (checkOrder)
Запрос проверки корректности параметров заказа. Этот шаг позволяет исключить ошибки, которые
могли возникнуть при прохождении платежной формы через браузер плательщика.
В случае успешного ответа Контрагента Оператор предлагает плательщику оплатить заказ и при успехе
отправляет Контрагенту «Уведомление о переводе».
Обратите внимание:
1. Формирование запроса «Проверка заказа» чаще всего происходит до списания денег со счета
плательщика. На этом шаге Контрагент может отказаться от приема перевода.
2. При оплате с банковской карты авторизация платежа производится до формирования запроса
«Проверка заказа». В случае отказа Контрагента деньги будут автоматически возращены на карту.
3. При оплате способами, отличными от платежа из кошелька в Яндекс.Деньгах, внешние системы
могут брать дополнительную комиссию. Тогда при отказе Контрагента от приема перевода
средства возвращаются плательщику за вычетом такой комиссии.
4.2.1. Формат запроса Оператора
Таблица 4.2.1.1. Параметры запроса операции checkOrder
Параметр
Тип
Описание
requestDatetime
action
Момент формирования запроса в ИС Оператора.
Тип запроса. Значение: «checkOrder» (без
кавычек).
MD5-хэш параметров платежной формы, правила
формирования описаны в разделе Error! Reference
source not found. «Error! Reference source not
found.».
shopId
xs:dateTime
xs:normalizedString,
до 16 символов
xs:normalizedString,
ровно 32
шестнадцатеричных
символа, в верхнем
регистре
xs:long
shopArticleId
xs:long
invoiceId
orderNumber
xs:long
xs:normalizedString,
до 64 символов
xs:normalizedString,
до 64 символов
md5
customerNumber
orderCreatedDatetime
orderSumAmount
xs:dateTime
CurrencyAmount
orderSumCurrencyPaycash
orderSumBankPaycash
CurrencyCode
CurrencyBank
shopSumAmount
CurrencyAmount
shopSumCurrencyPaycash
CurrencyCode
Идентификатор Контрагента, присваиваемый
Оператором.
Идентификатор товара, присваиваемый
Оператором.
Уникальный номер транзакции в ИС Оператора.
Номер заказа в ИС Контрагента. Передается,
только если был указан в платежной форме.
Идентификатор плательщика (присланный в
платежной форме) на стороне Контрагента: номер
договора, мобильного телефона и т. п.
Момент регистрации заказа в ИС Оператора.
Стоимость заказа. Может отличаться от суммы
платежа, если пользователь платил в валюте,
которая отличается от указанной в платежной
форме. В этом случае Оператор берет на себя все
конвертации.
Код валюты для суммы заказа.
Код процессингового центра Оператора для суммы
заказа.
Сумма к выплате Контрагенту на р/с (стоимость
заказа минус комиссия Оператора).
Код валюты для shopSumAmount.
22
shopSumBankPaycash
CurrencyBank
paymentPayerCode
YMAccount
paymentType
xs:normalizedString
Любые названия,
отличные от
перечисленных выше
xs:string
Код процессингового центра Оператора для
shopSumAmount.
Номер счета в ИС Оператора, с которого
производится оплата.
Способ оплаты заказа. Список значений приведен
в таблице 6.4.1.
Параметры, добавленные Контрагентом в
платежную форму.
Обратите внимание: запросы Оператора могут содержать параметры, не описанные в этом документе.
Контрагенту следует их игнорировать.
Пример параметров запроса checkOrder:
requestDatetime
2011-05-04T20:38:00.000+04:00
action
checkOrder
md5
8256D2A032A35709EAF156270C9EFE2E
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
AC
MyField
Добавленное Контрагентом поле
4.2.2. Формат ответа Контрагента
Таблица 4.2.2.1. Параметры ответа операции checkOrder
Параметр
Тип
Описание
23
performedDatetime xs:dateTime
code
xs:int
shopId
invoiceId
orderSumAmount
message
techMessage
Момент обработки запроса по часам ИС Контрагента.
Код результата обработки. Список допустимых значений
приведен в таблице ниже.
xs:long
Идентификатор Контрагента. Должен дублировать поле
shopId запроса.
xs:long
Идентификатор транзакции в ИС Оператора. Должен
дублировать поле invoiceId запроса.
CurrencyAmount Стоимость заказа в валюте, определенной параметром
запроса orderSumCurrencyPaycash.
xs:string, до 255 Текстовое пояснение в случае отказа принять платеж.
символов
xs:string, до 64
Дополнительное текстовое пояснение ответа
символов
Контрагента. Как правило, используется как
дополнительная информация об ошибках.
Необязательное поле.
Таблица 4.2.2.2. Коды результата обработки запроса checkOrder
Код Значение
Описание ситуации
0
Успешно
Контрагент дал согласие и готов принять перевод.
1
Ошибка
авторизации
Несовпадение значения параметра md5 с результатом расчета хэшфункции. Оператор считает ошибку окончательной и не будет
осуществлять перевод.
100
Отказ в приеме
перевода
Отказ в приеме перевода с заданными параметрами. Оператор
считает ошибку окончательной и не будет осуществлять перевод.
200
Ошибка разбора ИС Контрагента не в состоянии разобрать запрос. Оператор считает
запроса
ошибку окончательной и не будет осуществлять перевод.
Пример ответа на checkOrder при успехе обработки:
<?xml version="1.0" encoding="UTF-8"?>
<checkOrderResponse performedDatetime="2011-05-04T20:38:01.000+04:00"
code="0" invoiceId="1234567"
shopId="13"/>
Пример ответа на checkOrder при ошибке, ИС отказала в приеме перевода на этапе проверки
корректности заказа:
<?xml version="1.0" encoding="UTF-8"?>
<checkOrderResponse performedDatetime="2011-05-04T20:38:01.000+04:00"
24
code="100" invoiceId="1234567"
shopId="13"
message="Указанный номер телефона не существует"
techMessage="Неверный номер телефона"/>
Уведомление о переводе (paymentAviso)
Уведомление Контрагента о принятом переводе. Этот запрос обозначает факт успешного перевода
денежных средств плательщика в адрес Контрагента и обязанность Контрагента выдать товар
плательщику.
Обратите внимание: на этом шаге Контрагент не может отказаться от приема перевода.
4.3.1. Формат запроса Оператора
Параметры запроса «Уведомление о переводе» совпадают с параметрами для запроса «Проверка
заказа» (см. описание в разделе Error! Reference source not found.). Специфичные для операции
paymentAviso параметры приведены в таблице ниже:
Таблица 4.3.1.1. Параметры запроса операции paymentAviso
Параметр
Тип
Описание
action
xs:normalizedString,
до 16 символов
xs:dateTime
Тип запроса, значение: paymentAviso.
paymentDatetime
Момент регистрации оплаты заказа в ИС
Оператора.
Обратите внимание: запросы Оператора могут содержать параметры, не описанные в данном
документе. Контрагенту следует их игнорировать.
Пример параметров запроса paymentAviso:
requestDatetime
2011-05-04T20:38:00.000+04:00
action
paymentAviso
md5
45125C95A20A7F25B63D58EA304AFED2
shopId
13
shopArticleId
456
invoiceId
1234567
customerNumber
8123294469
orderCreatedDatetime
2011-05-04T20:38:00.000+04:00
orderSumAmount
87.10
25
orderSumCurrencyPaycash
643
orderSumBankPaycash
1001
shopSumAmount
86.23
shopSumCurrencyPaycash
643
shopSumBankPaycash
1001
paymentDatetime
2011-05-04T20:38:10.000+04:00
paymentPayerCode
42007148320
paymentType
AC
MyField
Добавленное Контрагентом поле
4.3.2. Формат ответа Контрагента
Параметры ответа Контрагента на запрос «Уведомление о переводе» совпадают с параметрами для
операции «Проверка заказа» (см. описание в разделе Error! Reference source not found.).
Возможные коды результата обработки запроса «Уведомление о переводе» приведены в таблице
ниже:
Таблица 4.3.2.1. Коды результата обработки запроса paymentAviso
Код Значение
Описание ситуации
0
Успешно
Успешно — даже если Оператор прислал данный запрос повторно.
1
Ошибка
авторизации
Значение параметра md5 не совпадает с результатом расчета хэшфункции. Оператор не будет повторять запрос и пометит заказ как
«Уведомление Контрагенту не доставлено».
200
Ошибка разбора ИС Контрагента не в состоянии разобрать запрос. Оператор не будет
повторять запрос и пометит заказ как «Уведомление Контрагенту не
запроса
доставлено».
Пример ответа на paymentAviso при успехе обработки:
<?xml version="1.0" encoding="UTF-8"?>
<paymentAvisoResponse
performedDatetime ="2011-05-04T20:38:11.000+04:00"
code="0" invoiceId="1234567"
shopId="13"/>
26
Правила обработки HTTP-уведомлений Контрагентом
1. Контрагенту следует проверять значение параметра md5 для проверки целостности и подлинности
запросов. Если значение md5 не совпадает с результатом расчета хэш-функции MD5, нужно
отказывать в обработке запроса.
MD5-хэширование применяется к тексту, формируемому как последовательность значений ряда
параметров запроса, разделенных символом «точка с запятой» — «;». Порядок следования
параметров следующий:
action;orderSumAmount;orderSumCurrencyPaycash;orderSumBankPaycash;shopId;invoi
ceId;customerNumber;shopPassword
Пример:
Исходная строка (без переносов)
Результат хеширования
checkOrder;87.10;643;1001;13;55;8123294469;
s<kY23653f,{9fcnshwq
1B35ABE38AA54F2931B0C58646FD1321
2. ИС Контрагента должна отвечать на запросы Оператора в течение 10 секунд.
3. При отсутствии ответа от Контрагента на запрос «Проверка заказа» или при любом ответе кроме
«Успешно» Оператор сообщит плательщику о невозможности заплатить.
4. При длительном многократном отсутствии ответа Контрагента на запросы «Уведомление о
переводе» (либо при многократных технических ошибках) ИС Оператора будет повторять попытки
доставки уведомления в течение суток: первый раз – через минуту, потом еще до пяти раз с
интервалом 5–30 минут. После этого платеж будет переведен в окончательный статус. Успешный
или неуспешный – зависит от параметров подключения Контрагента (подробная информация
приведена в разделе Error! Reference source not found. «Error! Reference source not found.»).
5. Оператор присваивает каждому переводу уникальный номер (invoiceId). Контрагент должен быть
готов к тому, что запрос «Уведомление о переводе» для одного и того же invoiceId может
приходить неоднократно (из-за проблем со связью или ошибок в ответе ИС Контрагента на этот
запрос). На повторные уведомления ИС Контрагента должна отвечать успехом (code="0").
5. Email-уведомления о переводах
При подключении по email-схеме Контрагент определяет адрес электронной почты, на который он будет
принимать email-уведомления от Оператора.
Уведомления отправляются в теле электронного сообщения (email) и подписываются сертификатом
Оператора (S/MIME подпись).
Оператор формирует отдельное уведомление по итогам каждого успешного платежа в пользу
Контрагента. Формат уведомления представлен ниже:
Таблица 5.1. Поля email-уведомления о переводе
Поле
Значение
Извещение №
Номер email-уведомления о переводе в адрес Контрагента. Нумерация
сквозная.
27
Получатель
Время перевода
Сумма
Номер
транзакции
Идентификатор
плательщика
Номер у
контрагента
ФИО
Адрес доставки
Email
Содержание
заказа
Юридическое наименование Контрагента, указанное при подключении.
Дата и время перевода в формате «dd.mm.yyyy hh:mm:ss», по часам ИС
Оператора.
Сумма перевода. Разделитель дробной части – точка, всегда ровно два
знака после точки, разделитель тысяч отсутствует.
Уникальный номер транзакции в ИС Оператора.
Идентификатор плательщика в ИС Контрагента. Значение параметра
customerNumber платежной формы (здесь и ниже см. раздел Error!
Reference source not found. «Error! Reference source not found.»).
Уникальный номер заказа в ИС Контрагента. Значение параметра
orderNumber платежной формы. Если поле не заполнено, подставляется
значение из «Номер транзакции».
ФИО плательщика. Значение параметра custName платежной формы.
Адрес доставки товара или адрес проживания плательщика. Значение
параметра custAddr платежной формы.
Адрес электронной почты плательщика. Значение параметра custEMail
платежной формы.
Детали заказа: список приобретенных товаров, их количество, назначение
платежа и т. п. Значение параметра orderDetails платежной формы.
Обратите внимание: некоторые поля могут прийти с пустыми значениями, если соответствующий
параметр не был включен Контрагентом в платежную форму или не был заполнен плательщиком.
Образец email-уведомления:
Subject: Yandex.Dengi payment for Наименование_Контрагента #87
Извещение № 87
Получатель: ООО «Наименование_Контрагента»
Время перевода: 18.01.2008 16:32:37
Сумма: 12.00 RUB
Номер транзакции: 1099511628638
Идентификатор плательщика: 4637937
Номер у Контрагента: 1099511628638
Заполнено плательщиком в платежной форме Контрагента:
28
ФИО: Иванов Иван Иванович
Адрес доставки: г.Москва, ул. Московская 3-45
Email: [email protected]
Содержание заказа: какое-то описание заказа
6. Приложения
Параметры подключения Контрагента
Для подключения к ИС Оператора Контрагент должен сообщить следующие настройки (пп. 3-6
требуются только при HTTP-схеме подключения, п. 9 – только при email-схеме):
Таблица 6.1.1. Параметры подключения Контрагента
Параметр
Значение
Комментарий
1. Наименование
Контрагента
До 128 символов
Название магазина Контрагента,
которое плательщик должен видеть в
процессе платежа.
o Для тестирования
o Для продакшн
* до 200 символов
URL, по которому ИС Контрагента будет
доступна для запросов Оператора
«Проверка заказа». Для
взаимодействия необходимо
использовать протокол HTTPS.
4. paymentAvisoURL o Для тестирования
o Для продакшн
* до 200 символов
URL, по которому ИС Контрагента будет
доступна для запросов Оператора
«Уведомление о переводе». Для
взаимодействия необходимо
использовать протокол HTTPS.
5. Секретное
слово Контрагента
Рекомендуется использовать
случайно сгенерированный
набор символов длиной не
менее 20 символов.
Необходимо для формирования md5
хэша, передаваемого в запросах
«Проверка заказа» и «Уведомление о
переводе» в адрес Контрагента.
6. Учет переводов
при недоставке
уведомления о
переводе
o 6.1 Считать неуспешным
o 6.2 Считать успешным
Настройка определяет взаимное
поведение Контрагента и Оператора
при невозможности доставки
«Уведомления о переводе»
(длительное многократное отсутствие
ответа Контрагента на запросы
2. Адрес сайта
Контрагента
3. checkURL
29
Оператора либо многократные
технические ошибки ИС Контрагента).
Описание вариантов см. в таблице 6.1.2
ниже.
7. Порядок
перенаправления
плательщика
после завершения
перевода
o 7.1 На статические адреса
Контрагента:
articleId
articleId
successURL
(*)
failURL
(*)
successURL
(*)
failURL
(*)
Настройка определяет порядок
перенаправления плательщика на сайт
Контрагента после завершения оплаты.
Переход происходит со страницы
результата платежа — по клику на
ссылку «Вернуться в магазин».
Описание вариантов перенаправления
см. в таблице 6.1.3 ниже.
* до 200 символов; адреса для
тестирования и для продакшн
o 7.2 На адреса, передаваемые
Контрагентом в платежной
форме
8. Email для
реестров
Адрес электронной почты для отправки
реестров переводов, принятых
Оператором в пользу Контрагента.
9. Email для
уведомлений о
переводах
Адрес электронной почты для отправки
уведомлений.
Таблица 6.1.2. Варианты учета переводов при недоставке «Уведомления о переводе»
Вариант
Комментарий
«Считать
неуспешным»
(по умолчанию)
Оператор прекращает попытки доставки уведомления, помечает перевод как
недоставленный Контрагенту и не помещает его в реестр принятых
переводов. Сумма неуспешного перевода будет автоматически возвращена
плательщику. Контрагент может обнаружить «потерянные уведомления»
путем сверки с использованием сервиса Merchant Web Services (MWS).
«Считать
Оператор прекращает попытки доставки уведомления и помечает перевод
успешным»
как успешный. Перевод будет включен в реестр принятых переводов согласно
времени последней попытки доставки «Уведомления о переводе».
Контрагент может обнаружить «потерянные уведомления» путем сверки с
реестром или с использованием сервиса MWS (*).
* Для доступа к просмотру списка операций через веб-интерфейс MWS Контрагенту
потребуется выпустить только сертификат, программировать ничего не нужно.
Реализация протокола MWS требуется, если Котрагенту нужен функционал возвратов. За
документацией обратитесь к своему менеджеру.
30
Таблица 6.1.3. Варианты перенаправления плательщика после завершения перевода
Вариант
Комментарий
«На статические
адреса товара
Контрагента»
(по умолчанию)
«На адреса,
передаваемые
Контрагентом в
платежной
форме»
Для перехода используются фиксированные адреса, определенные в
следующих настройках (отдельно по каждому товару):
 successURL
 failURL
Для перехода используются адреса, которые Контрагент должен передавать в
параметрах платежной формы (отдельно по каждому платежу):
 shopSuccessURL
 shopFailURL
Обратите внимание:
1. При
редиректе
к
URL'у
для
перехода
добавляются
«?action=PaymentSuccess»
(«?action=PaymentFail»), а также все параметры запроса от Оператора к ИС Контрагента
(параметры платежной формы). Переход осуществляется при помощи метода GET (исключение –
неуспех оплаты из кошелька в Яндекс.Деньгах, в этом случае переход осуществляется методом
POST).
2. При неопределенном статусе платежа редирект производится на главную страницу сайта
Контрагента (URL, указанный при подключении: «2. Адрес сайта Контрагента»), дополнительные
параметры к URL'у при этом не подклеиваются.
3. Если Контрагент собирается отображать персональную информацию, предназначенную для
конкретного плательщика, то он должен авторизовать такого плательщика собственными
средствами. Это могут быть стандартная авторизация на сайте Контрагента (через cookies и т. п.)
или через сессионные ключи Контрагента, помещенные им в платежную форму.
4. При оплате наличными через терминалы и при платеже со счета мобильного телефона редирект
осуществляется на главную страницу сайта Контрагента, дополнительные параметры к URL'у не
подклеиваются.
5. При оплате из кошелька в системе WebMoney редирект плательщика на сайт Контрагента
производится напрямую из системы WebMoney. При этом WebMoney могут подклеивать к URL'у
для перехода свои собственные дополнительные параметры.
Особенности взаимодействия при оплате наличными через терминалы
Взаимодействие Оператора и Контрагента в случае оплаты заказа наличными через терминалы имеет
ряд особенностей по сравнению с базовым сценарием (описан в разделе Error! Reference source not
found. «Error! Reference source not found.»). Эти особенности необходимо учитывать:
31
3-4. После получения параметров платежной формы и определения способа платежа у плательщика
дополнительно запрашиваются телефон и адрес электронной почты.
Если Контрагент передал среди параметров платежной формы телефон плательщика (cps_phone) и/или
email (cps_email), форма подтверждения платежа будет предзаполнена этими данными.
5. Плательщику выдается специальный код и инструкция по оплате через терминалы и кассы. Этот же
код, а также сумма к оплате, высылаются Оператором в SMS на указанный телефон.
При клике по ссылке «Вернуться в магазин», размещенной на странице выдачи кода, плательщик
перенаправляется на адрес Контрагента, указанный при подключении («2. Адрес сайта Контрагента»).
Параметры (shop)successURL, (shop)failURL в данной ситуации не используются.
6. Полученный на шаге 5 код плательщик может указать в качестве назначения платежа в любом
терминале или банкомате, где принимаются деньги для пополнения кошельков в Яндекс.Деньгах.
7-11. После получения от терминальной сети информации о том, что плательщик внес деньги, Оператор
выполняет последовательные запросы «Проверка заказа» (checkOrder) и «Уведомление о переводе»
(paymentAviso).
Обратите внимание:
 если Контрагент откажется принимать перевод, Оператор самостоятельно вернет деньги
плательщику;
 если плательщик внесет в терминал сумму, которая больше стоимости заказа, сдача будет
автоматически перечислена на счет указанного при платеже мобильного телефона;
32
 если плательщик внесет в терминал сумму, которая меньше стоимости заказа, Оператор пришлет
ему SMS с информацией о недостающей сумме. Для проведения платежа плательщик должен
будет довнести недостающую сумму.
11. После ответа от ИС Контрагента на «Уведомление о переводе» Оператор отправляет на указанный
плательщиком адрес электронной почты сообщение о результате проведения платежа.
Реестры принятых переводов
Раз в сутки Оператор формирует реестр принятых в пользу Контрагента переводов. Реестр отправляется
в теле электронного сообщения на email (*), указанный Контрагентом при подключении («8. Email для
реестров»). Реестр подписывается сертификатом Оператора (S/MIME подпись). В реестре содержатся
все переводы за указанную в реестре дату.
* Также возможна отправка реестров по (s)ftp. За подробной информацией обратитесь к своему
менеджеру.
Тема (subject) электронного сообщения формируется по следующему шаблону (нумерация сквозная):
РЕЕСТР ПЛАТЕЖЕЙ В <Наименование_Контрагента>. № <номер>
Тело электронного сообщения формируется как:
РЕЕСТР ПЛАТЕЖЕЙ В <Наименование Контрагента>. № <номер>
Дата платежей: <dd.mm.yyyy>
Номер транзакции; Идентификатор клиента; Сумма платежа; Валюта платежа; Сумма за
вычетом комиссии; Время платежа; Номер кошелька плательщика; Краткое описание;
Тип операции
<Данные платежей>
Сумма принятых платежей типа <Тип операции>: <общая сумма принятых переводов
данного типа за сутки>
Сумма принятых платежей за вычетом комиссии типа <Тип операции>: <сумма принятых
переводов данного типа за вычетом комиссии Оператора>
Число платежей типа <Тип операции>: <количество переводов данного типа>
Сумма принятых платежей: <общая сумма принятых переводов за сутки>
Сумма принятых платежей за вычетом комиссии: <сумма принятых переводов за вычетом
комиссии Оператора>
Число платежей: <количество переводов>
33
Кому: <Наименование Контрагента>
(По договору <номер договора между Контрагентом и Оператором>)
Описание полей с данными платежей приведено в таблице ниже.
Таблица 6.3.1. Поля стандартного реестра принятых переводов
Поле
Значение
Номер транзакции
Уникальный номер транзакции в ИС Оператора (string, до 32 символов).
Значение параметра invoiceId уведомлений Оператора.
Идентификатор
клиента
Идентификатор плательщика в ИС Контрагента (string, до 64 символов).
Значение параметра customerNumber платежной формы.
Сумма платежа
Сумма транзакции. Разделитель дробной части – точка, всегда ровно два
знака после точки, разделитель тысяч отсутствует.
Валюта платежа
Трехбуквенный код валюты (RUB – Рубль РФ).
Сумма за вычетом
комиссии
Сумма к выплате Контрагенту на р/с. Разделитель дробной части – точка,
всегда ровно два знака после точки, разделитель тысяч отсутствует.
Время платежа
Момент доставки «Уведомления о переводе» Контрагенту (при работе по
email-схеме – момент регистрации оплаты заказа в ИС Оператора). Дата и
время в формате «dd.mm.yyyy hh:mm:ss», по часам Оператора.
Номер кошелька
плательщика
Номер счета в ИС Оператора, с которого произведена оплата.
Краткое описание
Текстовое наименование оплаченного товара в ИС Оператора.
Тип операции
Способ, которым был совершен платеж. Значения соответствуют
значениям параметра paymentType (см. таблицу 6.4.1). Необязательное
поле.
Образец реестра:
Subject: РЕЕСТР ПЛАТЕЖЕЙ В Наименование_Контрагента. № 3355
34
РЕЕСТР ПЛАТЕЖЕЙ В ООО «Наименование_Контрагента». № 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
Сумма принятых платежей типа GP: 10.00 RUB
Сумма принятых платежей за вычетом комиссии типа GP: 9.50 RUB
Число платежей типа GP: 1
Сумма принятых платежей: 25.00 RUB
Сумма принятых платежей за вычетом комиссии: 23.75 RUB
Число платежей: 2
Кому: ООО «Наименование_Контрагента»
(По договору 111.1111.11)
Способы оплаты
Таблица 6.4.1. Значения параметра paymentType
Значение Пояснение
PC
AC
Оплата из кошелька в Яндекс.Деньгах.
Оплата с произвольной банковской карты.
35
MC
GP
WM
SB
MP
AB
Платеж со счета мобильного телефона.
Оплата наличными через кассы и терминалы.
Оплата из кошелька в системе WebMoney.
Оплата через Сбербанк Онлайн.
Оплата через мобильный терминал (mPOS).
Оплата через Альфа-Клик.
Типы данных
Таблица 7.1. Определения типов данных протокола
Тип
Описание
xs:int
32-bit целое знаковое число. Int32, определенный в стандарте:
http://www.w3.org/TR/xmlschema-2/#int
xs:long
64-bit целое знаковое число. Int64, определенный в стандарте:
http://www.w3.org/TR/xmlschema-2/#long
xs:decimal
Десятичное число с фиксированной точкой, определенное в стандарте:
http://www.w3.org/TR/xmlschema-2/#decimal
xs:boolean
Логическое значение (true/false), определенное в стандарте:
http://www.w3.org/TR/xmlschema-2/#boolean
xs:string
Текстовая строка, определенная в стандарте:
http://www.w3.org/TR/xmlschema-2/#string
xs:normalizedString Текстовая строка, определенная в стандарте:
http://www.w3.org/TR/xmlschema-2/#normalizedString
xs:dateTime
Временная метка в формате согласно рекомендациям:
 http://www.w3.org/TR/xmlschema-2/#dateTime
 ISO8601:2004
Формат определяется как:
YYYY-MM-DDThh:mm:ss.fZZZZZ
Расшифровка формата:
YYYY
год, точно 4 цифры
MM
месяц, точно 2 цифры (01=январь и т. д.)
DD
день месяца, точно 2 цифры (от 01 до 31)
T
латинский символ «T», должен быть в верхнем регистре
hh
часы, точно 2 цифры (24-часовой формат, от 00 до 23)
36
mm
минуты, точно 2 цифры (от 00 до 59)
ss
секунды, точно 2 цифры (от 00 до 59)
f
дробная часть секунды (от 1 до 6 цифр),
может отсутствовать, в этом случае следует опускать и
разделитель «.»
ZZZZZ
Описатель временной зоны, может принимать значения:
Z – UTC, символ «Z» должен быть в верхнем регистре.
+hh:mm или -hh:mm – смещение относительно UTC (GMT)
(показывает, что указано локальное время, которое на данное
число часов и минут опережает или отстает от UTC).
Обязательно должны присутствовать все указанные элементы, можно
опускать только дробную часть секунд (в этом случае следует опускать и
разделитель «.»). Если нужно задать только дату, то время все равно
следует указать как 00:00:00.
Примеры:
YMAccount
 2011-07-24T19:00:00+04:00 – 19 часов 00 минут 24 июля 2011 года,
часовой пояс – UTC + 4 часа;
 2004-07-24T15:00:00Z – тот же момент времени в каноническом
представлении;
 2004-07-24T15:00:00.666Z – тот же момент времени плюс 666
миллисекунд.
Номер виртуального счета в ИС Оператора, строка десятичных цифр
длиной от 11 до 33 символов.
<xs:simpleType name="YMAccount">
<xs:restriction base="xs:normalizedString">
<xs:minLength value="11"/>
<xs:maxLength value="33"/>
<xs:pattern value="[0-9]+"/>
</xs:restriction>
</xs:simpleType>
CurrencyAmount
Сумма. Положительное десятичное число с фиксированной точкой, после
точки – две цифры.
37
<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>
CurrencyBank
Код процессингового центра Оператора. Возможные значения:


1001 – ЭкомБанк;
1003 – ДемоБанк демо-системы «Яндекс.Деньги».
<xs:simpleType name="CurrencyBank">
<xs:restriction base="xs:int">
</xs:restriction>
</xs:simpleType>
38
ПРИЛОЖЕНИЕ № 2.1.
ФОРМАТ ЕЖЕДНЕВНОГО РЕЕСТРА ВОЗВРАЩЕННЫХ ПЕРЕВОДОВ
Реестр возвращенных переводов предоставляется в теле электронного сообщения (e-mail).
Тема электронного сообщения (e-mail Subject):
РЕЕСТР ВОЗВРАТОВ ОТ <Agent_name>. № <номер>,
где <Agent_name> - юридическое наименование Контрагента (далее по тексту приложения – «магазин», «Интернет
Магазин»).
<номер> - номер электронного сообщения в адрес магазина, нумерация сквозная.
Реестр отправляется на e-mail Интернет Магазина, указанный в технической анкете.
Реестр подписывается сертификатом Центра Приема Платежей, S/MIME подпись (detach, тип сертификата
PKCS#7).
В реестре содержатся все успешно осуществленные возвраты за указанную в теле реестра дату.
Реестры формируются и отправляются ежесуточно. В том случае, если за прошедшие сутки возвратов не было,
реестр будет нулевым.
Тело реестра:
РЕЕСТР ВОЗВРАТОВ ОТ <Agent_name>. № <номер>
Дата возвратов: < dd.mm.yyyy >
Подзаголовок:
Номер транзакции; Сумма возврата; Валюта платежа; Время зачисления возврата на счет плательщика; Номер
счета плательщика;
Данные:
Идентификатор
Номер транзакции
Содержание
Примечание
Номер транзакции ЦПП.
(string, до 32 символов).
Уникальный
идентификатор
платежа,
по
которому
производится возврат.
Сумма возврата
Сумма возврата
Разделитель дробной части –
точка, всегда ровно два знака
после запятой, разделитель тысяч
отсутствует.
Валюта платежа
Валюта платежа и возврата
Время
зачисления
возврата
на
счет
плательщика
Момент времени зачисления
суммы возврата на счет в
Системе (по часам Системы
дата
и
время
в
dd.mm.yyyy hh:nn:ss
формате
39
Яндекс.Деньги).
Номер
плательщика
счета
Номер счета в системе
Яндекс.Деньги, с которого
был произведен платеж и на
который
производится
возврат.
Длина от 11 до 15 цифр,
начинается с константы 41001.
Итог реестра:
Сумма возвратов: <общая сумма возвратов за сутки>
Число возвратов: <количество возвратов за сутки>
От: <Юрлицо интернет магазина>
(По договору <номер договора между Интернет Магазином и Яндекс.Деньги>)
Образец ежедневного реестра возвратов:
РЕЕСТР ВОЗВРАТОВ ОТ ООО «Интернет Магазин». № 3355
Дата возвратов: 18.12.2009
Номер транзакции; Сумма возврата; Валюта платежа; Время зачисления возврата на счет плательщика; Номер счета
плательщика;
549755819524; 10.00; RUB; 18.12.2009 17:46:58; 410038366898;
549755819525; 15.00; RUB; 18.12.2009 18:47:32; 410038366898;
Сумма возвратов: 25.00
Число возвратов: 2
От: ООО «Интернет Магазин»
(По договору НЭК.111111.01)
40
ПРИЛОЖЕНИЕ № 3
Форма Акта об оказанных услугах
Акт оказанных услуг / Акт сверки
по Договору № ____________ от «____» ________ 20__ г.
г. Москва
"____" ______________ _____ г.
Общество с ограниченной ответственностью небанковская кредитная организация «Яндекс.Деньги»,, именуемое
«Оператор», в лице <Должность Фамилия Имя Отчество>, действующего на основании <Устава / доверенности
№___ от дд.мм.гггг> составил, а <Организационно-правовая форма> «Название компании», именуемое
«Контрагент», в лице <Должность Фамилия Имя Отчество>, действующего на основании <Устава / доверенности
№___ от дд.мм.гггг> утвердил настоящий Акт о том, что Оператор надлежащим образом исполнил обязательства по
Договору в соответствии с нижеприведенными данными:
1
Дата, время начала Отчетного периода
[ДД/MM/ГГ]
[ЧЧ:ММ:СС]
2
Дата, время конца Отчетного периода
[ДД/MM/ГГ]
[ЧЧ:ММ:СС]
3
Задолженность Оператора перед
Контрагентом на начало Отчетного периода,
валюта
[сумма цифрами]
[сумма прописью]
4
Задолженность Контрагента перед
Оператором на начало Отчетного периода,
валюта
[сумма цифрами]
[сумма прописью]
5
Cумма переводов, принятых Оператором в
Отчетном периоде, валюта
[сумма цифрами]
[сумма прописью]
6
Сумма вознаграждения Оператора за
Отчетный период, НДС не облагается в
соответствии с пп. 4 п. 3 статьи 149
Налогового кодекса РФ, валюта
[сумма цифрами]
[сумма прописью]
7
Возвращено Оператором переводов
физическим лицам в Отчетном периоде,
валюта
[сумма цифрами]
[сумма прописью]
8
Перечислено Контрагентом на
корреспондентский счет Оператора, валюта
[сумма цифрами]
[сумма прописью]
9
Перечислено Оператором на расчетный счет
Контрагента в Отчетном периоде, валюта
[сумма цифрами]
[сумма прописью]
10
Задолженность перед Контрагентом на конец
Отчетного периода, валюта
[сумма цифрами]
[сумма прописью]
11
Задолженность Контрагента перед
Оператором на конец Отчетного периода,
валюта
[сумма цифрами]
[сумма прописью]
Примечание:
Суммы в п.11, п.10 приведены с учетом сумм оспариваемых операций, подлежащих удержанию в
следующих отчетных периодах.
Информация об оспариваемых операциях в отчетном периоде:
Общая сумма оспариваемых операций в отчетном периоде – Х руб. (Сумма прописью), из них:
- удержано в отчетном периоде – Y руб. (Сумма прописью),
- подлежит удержанию в следующих отчетных периодах – Z руб. (Сумма прописью).
Таблица расшифровки платежей
41
№ п/п
Способ осуществления перевода
плательщиком
Итого
Сумма переводов,
принятых Оператором
в Отчетном периоде
Возвращено
Оператором
переводов физическим
лицам в Отчетном
периоде
0.00р.
Сумма
вознаграждения
Оператора, руб.
(НДС не
облагается)
0.00р.
0.00р.
Примечание:
В строках таблицы расшифровки платежей указывается информация по каждому из способов осуществления
перевода, содержащемуся в заявлении Контрагента.
1.
1.Стороны претензий друг к другу не имеют.
2.Настоящий Акт составлен, утвержден и подписан в двух экземплярах, имеющих одинаковую юридическую силу, по
одному для Оператора и Контрагента.
Должность
______________ / ФИО /
м.п.
Должность
______________ / ФИО /
м.п.
42
ПРИЛОЖЕНИЕ № 4
Форма Заявления для Контрагентов — индивидуальных предпринимателей
ЗАЯВЛЕНИЕ КОНТРАГЕНТА №_________
о заключении договора об информационно – технологическом взаимодействии при
осуществлении переводов физических лиц без открытия счета
Индивидуальный
предприниматель
_______________________________________________
___________________________, именуем___ в дальнейшем «Контрагент», настоящим безотзывно представляет
обществу с ограниченной ответственностью небанковской кредитной организации «Яндекс.Деньги», именуемому
в дальнейшем «Оператор», оферту о заключении договора об информационно-технологическом взаимодействии
при осуществлении переводов физических лиц без открытия счета (далее — Договор) на условиях Договора,
размещенных на сайте Оператора в интернете по адресу https://money.yandex.ru/merchants/agreement, и условиях
приложений
к
Договору,
размещенных
на
сайте
Оператора
в
интернете
по
адресу
https://money.yandex.ru/merchants/annex с учетом следующих вариантов регулирования отношений:
1.
Ставка вознаграждения Оператора в
составляет:
процентах от суммы каждого перевода (пункт 4.1. Договора)

____________________________________________________________ % (цифрами и прописью) в
случае осуществления перевода посредством уменьшения остатка электронных денежных средств
плательщика, учитываемых Оператором,
 _____________________________________________________________ % (цифрами и прописью) в
случае осуществления перевода посредством приема наличных денежных средств плательщика
банковским платежным агентом (субагентом) Оператора или кредитной организацией, с которой
Оператор заключил соответствующий договор,
 _____________________________________________________________ % (цифрами и прописью) в
случае совершения плательщиком перевода с использованием банковской карты,
 ____________________________________________________________ % (цифрами и прописью) в
случае осуществления перевода плательщиком, действующим в качестве пользователя системы
WebMoney Transfer, за счет денежных средств, предоставленных в указанную систему,
 ____________________________________________________________ % (цифрами и прописью) в
случае инициирования перевода абонентом оператора радиотелефонной подвижной связи
_________________ (указывается наименование оператора связи) за счет денежных средств
абонента, являющихся авансом за услуги связи,
 ________________________________________________________ % (цифрами и прописью) в случае
совершения плательщиком перевода с использованием банковской карты посредством платежного
приложения «2can for Yandex.Money» или «Lifepay for Yandex.Money»,
 _____________________________________________________ % (цифрами и прописью) в случае
осуществления перевода посредством списания денежных средств с банковского счета клиента на
основании распоряжения, переданного с использованием системы дистанционного банковского
обслуживания,

_____________________________________________________ % (цифрами и прописью) в случае
совершения плательщиком перевода с использованием банковской карты посредством сервиса
MasterPass.
Сообщаю следующие сведения о Контрагенте и гарантирую их соответствие действительности:
1.
Фамилия, имя, отчество
Дата рождения
Место рождения
Гражданство
Вид документа, удостоверяющего личность
ПЕРСОНАЛЬНЫЕ ДАННЫЕ:
Серия и номер
Дата выдачи
Орган, выдавший документ, и код подразделения
43
Данные документа, подтверждающего право
иностранного гражданина или лица без гражданства на
пребывание (проживание) на территории РФ (если
гражданство не Российской Федерации)
Серия
Номер
Дата начала срока
Дата окончания срока
СВЕДЕНИЯ О ГОСУДАРСТВЕННОЙ РЕГИСТРАЦИИ
2.
Дата государственной регистрации
Наименование регистрирующего органа
Место регистрации
ОГРНИП
ИНН
Адрес регистрации (индекс, регион/субъект, город, улица,
дом, строение/корпус, квартира)
Почтовый адрес (индекс, регион/субъект, город, улица,
дом, строение/корпус, офис/квартира, А/Я)
3.
СВЕДЕНИЯ О ЛИЦЕНЗИИ (заполняется, если деятельность лицензируется)
Перечень видов лицензируемой деятельности
Вид лицензии
Дата выдачи
Номер
Срок
действия
Вид лицензии
Дата выдачи
Номер
Срок
действия
Вид лицензии
Дата выдачи
Номер
Срок
действия
4. СВЕДЕНИЯ О ПРЕДСТАВИТЕЛЕ КОНТРАГЕНТА ПРИ ЗАКЛЮЧЕНИИ ДОГОВОРА С ООО НКО
«ЯНДЕКС.ДЕНЬГИ» (фамилия, имя, отчество лица, которое будет от имени контрагента заключать договор с ООО НКО
«Яндекс.Деньги»)
Фамилия, имя, отчество
Гражданство
Дата рождения
Место рождения
Вид документа, удостоверяющего личность
Серия и номер
Дата выдачи
Орган, выдавший документ, и код подразделения
Место регистрации (страна, регион/субъект, город, улица,
дом/корпус, квартира)
Данные документа, подтверждающего право
Серия
иностранного гражданина или лица без гражданства на
Номер
пребывание (проживание) на территории РФ (если
Дата начала срока
гражданство не Российской Федерации)
Дата окончания срока
Основание полномочий (номер доверенности, дата
выдачи)
5.
ИНФОРМАЦИЯ О БАНКОВСКОМ СЧЕТЕ
Р/С
Наименование банка
БИК
К/С
6.
ОПИСАНИЕ ОСНОВНЫХ ВИДОВ
ДЕЯТЕЛЬНОСТИ
7.
URL САЙТА В ИНТЕРНЕТЕ
8.
ДЕЙСТВУЕТЕ ЛИ ВЫ В ИНТЕРЕСАХ ТРЕТЬИХ ЛИЦ (ВЫГОДОПРИОБРЕТАТЕЛЕЙ), В ТОМ ЧИСЛЕ НА
ОСНОВАНИИ АГЕНТСКОГО ДОГОВОРА, ДОГОВОРОВ ПОРУЧЕНИЯ, КОМИССИИ, ДОВЕРИТЕЛЬНОГО
УПРАВЛЕНИЯ, ЗАКЛЮЧАЯ ДОГОВОР С ООО НКО «ЯНДЕКС.ДЕНЬГИ»?
ДА
НЕТ
☐
☐
9.
Телефон/факс
Главный бухгалтер (ФИО)
КОНТАКТНАЯ ИНФОРМАЦИЯ
ФИО
Должность
Email
Телефон
44
Контактное лицо по общим вопросам
Контактное лицо по финансовым вопросам (адрес
электронной почты используется для направления
актов об оказанных услугах)
Контактное лицо по техническим вопросам (адрес
электронной почты используется для направления
уведомлений, предусмотренных пунктами 2.6., 2.9.
Договора)
Контактное лицо по вопросам ежедневной сверки реестров
переводов (адрес электронной почты используется для
направления реестров переводов и возвращенных
переводов).
_____________________ /______________________/
м.п.
ПРИЛОЖЕНИЕ № 5
Форма Заявления для Контрагентов — юридических лиц
ЗАЯВЛЕНИЕ КОНТРАГЕНТА №_________
о заключении договора об информационно – технологическом взаимодействии при
осуществлении переводов физических лиц без открытия счета
_____________________________________________________________________________________________,
именуем___ в дальнейшем «Контрагент», в лице ________________________________________________
______________________________________________________________,
действующ___
на
основании
_________________________________________, настоящим безотзывно представляет обществу с ограниченной
ответственностью небанковской кредитной организации «Яндекс.Деньги», именуемому в дальнейшем «Оператор»,
оферту о заключении договора об информационно-технологическом взаимодействии при осуществлении
переводов физических лиц без открытия счета (далее — Договор) на условиях Договора, размещенных на сайте
Оператора в интернете по адресу https://money.yandex.ru/merchants/agreement, и условиях приложений к
Договору, размещенных на сайте Оператора в интернете по адресу https://money.yandex.ru/merchants/annex с
учетом следующих вариантов регулирования отношений:
1. Ставка вознаграждения Оператора в процентах от суммы каждого перевода (пункт 4.1. Договора)
составляет:





____________________________________________________________ % (цифрами и прописью) в
случае осуществления перевода посредством уменьшения остатка электронных денежных средств
плательщика, учитываемых Оператором,
_____________________________________________________________ % (цифрами и прописью) в
случае осуществления перевода посредством приема наличных денежных средств плательщика
банковским платежным агентом (субагентом) Оператора или кредитной организацией, с которой
Оператор заключил соответствующий договор,
_____________________________________________________________ % (цифрами и прописью) в
случае совершения плательщиком перевода с использованием банковской карты,
____________________________________________________________ % (цифрами и прописью) в
случае осуществления перевода плательщиком, действующим в качестве пользователя системы
WebMoney Transfer, за счет денежных средств, предоставленных в указанную систему,
____________________________________________________________ % (цифрами и прописью) в
случае инициирования перевода абонентом оператора радиотелефонной подвижной связи
_____________ (указывается наименование оператора связи) за счет денежных средств абонента,
являющихся авансом за услуги связи,
45

_____________________________________________________________ % (цифрами и прописью) в
случае совершения плательщиком перевода с использованием банковской карты посредством
платежного приложения «2can for Yandex.Money» или «Lifepay for Yandex.Money»,

_____________________________________________________ % (цифрами и прописью) в случае
осуществления перевода посредством списания денежных средств с банковского счета клиента на
основании распоряжения, переданного с использованием системы дистанционного банковского
обслуживания,
_____________________________________________________ % (цифрами и прописью) в случае
совершения плательщиком перевода с использованием банковской карты посредством сервиса
MasterPass.

Сообщаем следующие сведения о Контрагенте и гарантируем их соответствие действительности:
1.
Полное фирменное наименование
Сокращенное наименование
Наименование на иностранном языке
2.
НАИМЕНОВАНИЕ ЮРИДИЧЕСКОГО ЛИЦА:
СВЕДЕНИЯ О ГОСУДАРСТВЕННОЙ РЕГИСТРАЦИИ:
Дата государственной регистрации
Наименование регистрирующего органа
Место регистрации
ОГРН
ИНН
КПП
ОКВЭД
Адрес местонахождения
Фактический адрес (не заполняется, если совпадает с адресом
местонахождения юридического лица)
Почтовый адрес (для корреспонденции)
3.
СВЕДЕНИЯ О ЛИЦЕНЗИИ (заполняется, если деятельность лицензируется):
Перечень видов лицензируемой деятельности:
Вид лицензии
Дата выдачи
Вид лицензии
Дата выдачи
Вид лицензии
Дата выдачи
4.
Номер
Номер
Номер
Срок действия
Срок действия
Срок действия
ИНФОРМАЦИЯ О БАНКОВСКОМ СЧЕТЕ:
Р/С
Наименование банка
БИК
К/С
5.
СТРУКТУРА И ПЕРСОНАЛЬНЫЙ СОСТАВ ОРГАНОВ УПРАВЛЕНИЯ ЮРИДИЧЕСКОГО ЛИЦА:
Наименование органа
Персональный состав
управления
Наименование органа
Персональный состав
управления
Наименование органа
Персональный состав
управления
6.
СВЕДЕНИЯ О ПРЕДСТАВИТЕЛЕ ЮРИДИЧЕСКОГО ЛИЦА:
6.1
ПЕРСОНАЛЬНЫЕ СВЕДЕНИЯ ОБ ЕДИНОЛИЧНОМ ИСПОЛНИТЕЛЬНОМ ОРГАНЕ
Фамилия, имя, отчество
Гражданство
Дата и место рождения
Вид документа, удостоверяющего личность
Серия и номер
Дата выдачи
Орган, выдавший документ, и код подразделения
Место регистрации (страна, регион/субъект, город, улица,
дом/корпус, квартира)
Данные документа, подтверждающего право иностранного
гражданина или лица без гражданства на пребывание
(проживание) на территории РФ (если гражданство не
Российской Федерации)
Серия
Номер
Дата начала срока
Дата окончания срока
46
6.2
СВЕДЕНИЯ О ПРЕДСТАВИТЕЛЕ ЮРИДИЧЕСКОГО ЛИЦА (ПОДПИСАНТЕ ДОГОВОРА)
(не заполняется, если подписантом является единоличный исполнительный орган):
Фамилия, имя, отчество
Гражданство
Дата рождения
Место рождения
Вид документа, удостоверяющего личность
Серия и номер
Дата выдачи
Орган, выдавший и код подразделения
Место регистрации (страна, регион/субъект, город, улица,
дом/корпус, квартира)
Данные документа, подтверждающего право иностранного
гражданина или лица без гражданства на пребывание
(проживание) на территории РФ (если гражданство не
Российской Федерации)
Серия
Номер
Дата начала срока
Дата окончания срока
Основание полномочий (номер доверенности, дата выдачи)
7.
СВЕДЕНИЯ О ПРИСУТСТВИИ ИЛИ ОТСУТСТВИИ ПО МЕСТУ НАХОЖДЕНИЯ ЮРИДИЧЕСКОГО ЛИЦА ПОСТОЯННО
ДЕЙСТВУЮЩЕГО ИСПОЛНИТЕЛЬНОГО ОРГАНА
Присутствует
☐
*Если постоянно действующий исполнительный орган
отсутствует по месту нахождения юридического лица, то
необходимо указать адрес его фактического местонахождения
(город, улица, дом, корпус/строение)
СВЕДЕНИЯ О ВЕЛИЧИНЕ ЗАРЕГИСТРИРОВАННОГО
8. И ОПЛАЧЕННОГО УСТАВНОГО (СКЛАДОЧНОГО)
КАПИТАЛА (РУБ.)
9. ОПИСАНИЕ ОСНОВНЫХ ВИДОВ ДЕЯТЕЛЬНОСТИ
10. URL САЙТА В ИНТЕРНЕТЕ
Отсутствует*
☐
ДЕЙСТВУЕТЕ ЛИ ВЫ В ИНТЕРЕСАХ ТРЕТЬИХ ЛИЦ (ВЫГОДОПРИОБРЕТАТЕЛЕЙ), В ТОМ ЧИСЛЕ НА ОСНОВАНИИ
11. АГЕНТСКОГО ДОГОВОРА, ДОГОВОРОВ ПОРУЧЕНИЯ, КОМИССИИ, ДОВЕРИТЕЛЬНОГО УПРАВЛЕНИЯ, ЗАКЛЮЧАЯ
ДОГОВОР С ООО НКО «ЯНДЕКС.ДЕНЬГИ»?
ДА
НЕТ
☐
☐
12
КОНТАКТНАЯ ИНФОРМАЦИЯ:
Телефон/факс
Главный бухгалтер (ФИО)
ФИО
Должность
Email
Телефон
Контактное лицо по общим вопросам
Контактное лицо по финансовым вопросам (адрес электронной
почты используется для направления актов об оказанных
услугах)
Контактное лицо по техническим вопросам (адрес электронной
почты используется для направления уведомлений,
предусмотренных пунктами 2.6., 2.9. Договора)
Контактное лицо по вопросам ежедневной сверки реестров
переводов (адрес электронной почты используется для направления
реестров переводов и возвращенных переводов).
____________________ /_____________________/
м.п.
47
ПРИЛОЖЕНИЕ № 6
Возможность возврата или отмен переводов
Способ осуществления перевода
перевод посредством уменьшения остатка электронных денежных средств
плательщика, учитываемых Оператором
перевод, инициированный плательщиком, действующим в качестве
пользователя системы WebMoney Transfer, за счет денежных средств,
предоставленных в указанную систему
перевод посредством приема наличных денежных средств плательщика
банковским платежным агентом (субагентом) Оператора или кредитной
организацией, с которой Оператор заключил соответствующий договор
перевод с использованием плательщиком банковской карты
перевод, инициированный абонентом оператора радиотелефонной подвижной
связи за счет денежных средств абонента, являющихся авансом за услуги связи
перевод с использованием банковской карты посредством платежного
приложения «2can for Yandex.Money» или «Lifepay for Yandex.Money»
перевод посредством списания денежных средств с банковского счета клиента
ОАО «АЛЬФА-БАНК» на основании распоряжения, переданного с
использованием системы дистанционного банковского обслуживания «АльфаКлик».
перевод посредством списания денежных средств с банковского счета клиента
ОАО «Сбербанк России» на основании распоряжения, переданного с
использованием системы дистанционного банковского обслуживания
«Сбербанк [email protected]».
перевод посредством списания денежных средств с банковского счета клиента
ПАО «Промсвязьбанк» на основании распоряжения, переданного с
использованием системы дистанционного банковского обслуживания PSBRetail
перевод с использованием банковской карты посредством сервиса MasterPass
Возможность
возврата или отмены
перевода
есть
есть
нет
есть
нет
есть
есть
нет
нет
есть
48
ПРИЛОЖЕНИЕ № 7
Интерфейс Merchant Web Services сервиса «Яндекс.Деньги»
Версия 3.0 от 05.08.2013
1.
Общее описание
Веб-сервисы Яндекс.Денег для Контрагентов (далее — MWS) предоставляют интерфейс для защищенного
взаимодействия автоматизированной информационной системы Контрагента (далее — ИС) и Оператора сервиса
«Яндекс.Деньги» (далее — Оператор) через интернет.
Интерфейс предусматривает запросы двух типов:


информационные (получение выписок по заказам и прочее);
исполнение финансовых операций, полные или частичные возвраты переводов.
Для защиты канала используется SSL. Для работы Контрагенту требуется SSL-сертификат. Аутентификация
производится по данным SSL-сертификата. Взаимодействие сторон происходит по протоколу HTTP версии 1.1.
Результат выполнения запросов возвращается в ответе на HTTP-запрос.
Таблица 1. Возможные HTTP-коды ответа
HTTP-код
Описание
200 OK
Запрос принят к обработке. Отправлен ответ в соответствии с настоящим
протоколом.
400 Bad Request
Запрос не принят к обработке. Тело запроса испорчено, сервер не смог
прочитать или разобрать запрос.
Возможные причины:

запрос невозможно разобрать;

неверный MIME-тип (Content-Type).
403 Forbidden
Недостаточно прав на выполнение операции.
404 Not Found
В запросе указан неверный URI, либо в настоящий момент операция
недоступна.
500 Internal Server Error
Технические проблемы на стороне сервиса «Яндекс.Деньги».
501 Not Implemented
Запрос отправлен методом, отличным от POST.
Таблица 2. Описание общих параметров ответа
Параметр
Тип
Описание
49
status
xs:int
Результат выполнения операции. По значению этого
поля ИС Контрагента должна принимать решение о
состоянии запроса. См. Таблица 3. Коды состояний
запроса (status)».
error
xs:int
Код ошибки выполнения запроса (см. Таблицу 12).
Является дополнительной расшифровкой к полю
status. Опциональное поле.
clientOrderId
ClientTransactionNumber
Копия параметра clientOrderId запроса. Используется
для финансовых операций.
processedDT
xs:dateTime
Время обработки
Яндекс.Денег.
techMessage
xs:string
Опциональное
поле.
Может
содержать
дополнительный поясняющий текст к ответам
сервера.
Этот
текст
содержит
техническую
информацию и не должен отображаться в каком-либо
интерфейсе пользователя.
запроса
по
часам
сервера
Таблица 3. Коды состояний запроса (status)
Код
Описание
состояния
0
Успех. Обработка завершена. Запрос выполнен успешно.
1
В обработке. Запрос в процессе обработки. Возвращается, если истекло время ожидания
завершения обработки запроса. Требуется повторить запрос для уточнения результата.
3
Отвергнут. Обработка завершена. Запрос отвергнут. Причина отказа передается в
параметре error.
2.
Параметры подключения Контрагента
2.1. Сертификат Контрагента
Контрагенту следует получить сертификат X.509, посредством которого он будет формировать запросы к
сервису «Яндекс.Деньги». См. документ «Процедура обмена сертификатами».
3.
Информационные запросы
3.1. Запрос списка заказов (listOrders)
Запрос позволяет получить перечень заказов и их свойств. Список параметров приведен в Таблице 4. Типы
данных описаны в разделе «Типы данных».
Адрес операции: https://server:port/webservice/mws/api/listOrders
3.1.1. Формат запроса
ИС
формирует
POST-запрос
по
протоколу
HTTP/1.1
(http://www.ietf.org/rfc/rfc2616.txt,
http://www.ietf.org/rfc/rfc2618.txt ). Параметры запроса упаковываются как набор параметров POST запроса в виде
пар «имя=значение». MIME-тип: application/x-www-form-urlencoded. Кодировка символов: UTF-8.
50
Некоторые параметры могут отсутствовать в запросе, в этом случае для них используется значение параметра
по умолчанию. Если параметр присутствует в запросе, но имеет пустое значение, то значение по умолчанию для
параметра не используется. Если отсутствует обязательный параметр, возвращается ошибка «Неверное значение
параметра NNNN».
Таблица 4. Параметры запроса списка заказов
Название параметра
Тип
Примечания
xs:dateTime
Дата и время запроса по часам ИС. Обязательный параметр.
outputFormat
xs:normalizedStri
ng
Формат представления результата запроса. Допустимые значения —
«XML» или «CSV». Необязательный параметр: значение по
умолчанию «XML».
csvDelimiter
xs:string,
символ
Разделитель значений для формата CSV. Не может быть равен
символу «”» (кавычка). Необязательный параметр: значение по
умолчанию «;».
shopID
xs:long
requestDT
1
Идентификатор
запрашивается.
Контрагента,
список
заказов
которого
Если параметр не задан, то возвращаются заказы по shopID, для
которых у данного пользователя MWS имеется право получать
список заказов.
orderCreatedDatetimeGr
eaterOrEqual
xs:dateTime
orderCreatedDatetimeLes
sOrEqual
xs:dateTime
paid
xs:boolean
Нижняя граница времени создания заказа.
Выбираются заказы, время создания которых больше или равно
значению этого параметра.
Верхняя граница времени создания заказа.
Выбираются заказы, время создания которых меньше или равно
значению этого параметра.
Если параметр имеет значение «true», то возвращаются только
оплаченные заказы.
Если параметр имеет значение «false», то возвращаются только
неоплаченные заказы.
Если параметр не задан, будут возвращены как оплаченные, так и
неоплаченные заказы.
paymentDatetimeGreater
OrEqual
xs:dateTime
paymentDatetimeLessOrE
qual
xs:dateTime
invoiceId
xs:long
Нижняя граница времени оплаты заказа.
Выбираются заказы, время оплаты которых больше или равно
значению этого параметра.
Верхняя граница времени оплаты заказа.
Выбираются заказы, время оплаты которых меньше или равно
значению этого параметра.
Уникальный номер транзакции Оператора.
51
orderNumber
outputFields
xs:string, до 64
символов
Уникальный номер заказа в ИС.
xs:string,
до
4000 символов
Список свойств заказа, которые должны быть выведены в
результате выполнения запроса.
Использование параметра возможно, если Оператор получает от
Контрагента и хранит номера заказов.
Разделитель имен в списке — символ «;» (без кавычек).
Значение по умолчанию:
«shopID;shopName;articleId;articleName;invoiceId;orderNumber;paym
entSystemOrderNumber;
customerNumber; createdDatetime;paid;orderSumAmount;
orderSumCurrencyPaycash;orderSumBankPaycash;paidSumAmount;
paidSumCurrencyPaycash;paidSumBankPaycash;receivedSumAmount;
receivedSumCurrencyPaycash;receivedSumBankPaycash;
shopSumAmount;shopSumCurrencyPaycash;shopSumBankPaycash;
paymentDatetime;paymentAuthorizationTime;payerCode;
payerAddress;payeeCode;paymentSystemDatetime;
avisoReceivedDatetime;avisoStatus» (без кавычек).
Полный список свойств заказа, которые могут присутствовать в
ответе на запрос списка заказов, см. в Таблица 6. Свойства заказа,
которые могут присутствовать в ответе на запрос списка
заказов.
В параметрах запроса списка заказов обязательно должно быть задано как минимум одно из условий:




номер транзакции (invoiceId) и идентификатор Контрагента (shopID);
номер заказа (orderNumber) и идентификатор Контрагента (shopID);
диапазон времени создания заказа (orderCreatedDatetimeGreaterOrEqual и/или
orderCreatedDatetimeLessOrEqual);
диапазон времени оплаты заказа (paymentDatetimeGreaterOrEqual и/или paymentDatetimeLessOrEqual).
При запросах по номеру транзакции (invoiceId) или номеру заказа (orderNumber) в запросе обязательно
должен быть указан идентификатор Контрагента (shopID).
Для запросов, выборка в которых ограничена диапазоном времени создания или диапазоном времени
оплаты заказа, действуют следующие правила:

если задана только одна граница диапазона для времени создания или оплаты заказа, то значение второй
берется по умолчанию. Значение по умолчанию для верхней границы — текущее время Оператора,
значение по умолчанию для нижней границы — время верхней границы, указанное в запросе, минус одни
сутки;

если задан диапазон времени оплаты заказа, то в запросе обязательно должен присутствовать параметр
paid со значением «true» (без кавычек);

длина диапазона времени, ограничивающего выборку, не должна превышать 31 день.
3.1.2. Формат ответа
Формат ответа определяется входными параметрами запроса outputFormat и csvDelimiter. В случае ошибки
52
ее код и описание возвращаются в заказанном формате представления результата.
Пример 1. Сообщение об ошибке в формате XML
<?xml version="1.0" encoding="UTF-8"?>
<listOrdersResponse
status="3" error="111"
processedDT="2011-07-02T20:38:01.000+04:00"
techMessage="Неверное значение параметра requestDT"
/>
Пример 2. Сообщение об ошибке в формате CSV
status=3;error=111;processedDT=2011-07-21T13:20:14.869+04:00;"techMessage=Неверное значение параметра
requestDT"
Если результат выборки списка заказов содержит более 10 000 записей, возвращается ошибка с кодом 216.
Получив такую ошибку, следует изменить параметры запроса, чтобы уменьшить длину временного диапазона,
ограничивающего выборку.
Таблица 5. Дополнительные поля заголовка ответа запроса списка заказов
Название
orderCount
Содержание
Количество
результате.
заказов
в
Тип
Примечания
xs:int
Присутствует в случае
успешной выборки списка
заказов.
Ниже приведен полный перечень свойств заказа, которые могут быть получены в результате запроса списка
заказов.
Таблица 6. Свойства заказа, которые могут присутствовать в ответе на запрос списка заказов
Название
Содержание
Тип
Идентификатор
Контрагента, присвоенный
Оператором.
xs:long
articleId
Идентификатор
товара,
присвоенный Оператором.
xs:long
shopName
Название Контрагента.
xs:string, до
символов
articleName
Название товара.
xs:string, до 128
символов
invoiceId
Уникальный
номер
транзакции Оператора.
xs:long
orderNumber
Номер
заказа
Контрагента.
xs:string, до
символов
shopID
в
ИС
Примечания
64
64
Если Оператор получает
от ИС и хранит номера
заказов,
то
свойство
содержит номер заказа в
ИС. В противном случае
свойство содержит номер
53
транзакции, назначенный
Оператором.
paymentSystemOrderNumb
er
Идентификатор перевода на
стороне Оператора.
xs:string, до
символов
40
customerNumber
Идентификатор покупателя
в
ИС
Контрагента
(присланный в платежной
форме).
xs:string, до
символов
64
Присутствует только для
оплаченных заказов.
Номер мобильного
телефона, договора и т. п.,
специфично для
Контрагента.
createdDatetime
Момент (дата и время)
регистрации
заказа
на
стороне Оператора.
xs:dateTime
paid
Имеет значение «true», если
заказ оплачен. Иначе —
«false».
xs:boolean
paymentDatetime
Момент (дата и время)
оплаты заказа по часам
Оператора.
xs:dateTime
Значение присутствует в
ответе
только
для
оплаченных заказов.
paymentAuthorizationTime
Номер
заказа
в
процессинговом
центре
Оператора.
xs:long
Значение присутствует в
ответе
только
для
оплаченных заказов.
payerCode
Номер счета плательщика.
xs:string, до
символов
33
Значение присутствует в
ответе
только
для
оплаченных заказов.
payerAddress
IP-адрес плательщика, если
он известен.
xs:string, до
символов
33
Значение присутствует в
ответе
только
для
оплаченных заказов.
payeeCode
Номер счета получателя
перевода при оплате заказа.
xs:string, до
символов
33
Значение присутствует в
ответе
только
для
оплаченных заказов.
paymentSystemDatetime
Момент (дата и время)
регистрации оплаты заказа в
процессинговом
центре
Оператора.
xs:dateTime
Значение присутствует в
ответе
только
для
оплаченных заказов.
avisoReceivedDatetime
Момент
времени
регистрации оплаты заказа в
ИС Контрагента.
xs:dateTime
Присутствует,
если
Контрагент на момент
запроса
получил
уведомление о данном
переводе.
avisoStatus
Код состояния уведомления
о переводе.
xs:int
Состояния уведомлений
описаны в разделе «Коды
состояний уведомления о
54
переводе».
avisoRegistryId
Номер реестра, в котором
содержится данный заказ.
xs:long
orderSumAmount
Сумма заказа.
CurrencyAmount
orderSumCurrencyPaycash
Код
валюты
orderSumAmount.
для
CurrencyCode
orderSumBankPaycash
Код процессингового центра
для orderSumAmount.
CurrencyBank
contractAmount
Сумма к оплате в валюте
счета плательщика.
CurrencyAmount
contractCurrency
Код
валюты
плательщика.
CurrencyCode
paidSumAmount
Сумма,
уплаченная
плательщиком.
CurrencyAmount
Значение присутствует в
ответе
только
для
оплаченных заказов.
paidSumCurrencyPaycash
Код
валюты
paidSumAmount.
для
CurrencyCode
Значение присутствует в
ответе
только
для
оплаченных заказов.
paidSumBankPaycash
Код процессингового центра
для paidSumAmount.
CurrencyBank
Значение присутствует в
ответе
только
для
оплаченных заказов.
shopSumAmount
Сумма,
получаемая
Контрагентом на р/с: сумма
заказа за вычетом комиссии
Оператора.
CurrencyAmount
shopSumCurrencyPaycash
Код валюты для суммы,
получаемой Контрагентом
на р/с.
CurrencyCode
shopSumBankPaycash
Код процессингового центра
для суммы, получаемой
Контрагентом на р/с.
CurrencyBank
receivedSumAmount
Сумма,
Оператором
плательщика.
CurrencyAmount
Значение присутствует в
ответе
только
для
оплаченных заказов.
receivedSumCurrencyPayca
sh
Код
валюты
receivedSumAmount.
для
CurrencyCode
Значение присутствует в
ответе
только
для
оплаченных заказов.
receivedSumBankPaycash
Код
банка
receivedSumAmount.
для
CurrencyBank
Значение присутствует в
ответе
только
для
оплаченных заказов.
счета
полученная
от
55
paymentFormParams
Параметры
формы.
платежной
paymentType
Способ проведения платежа
пользователем.
xs:string
Значение присутствует в
ответе
только
для
Контрагентов, у которых
установлена
настройка
«сохранять
параметры
платежной формы».
PaymentType
Если в запросе указан формат представления результата CSV, то заголовок и тело ответа представляют собой
набор строк, разделенных переводами строк (\r\n). В первой строке ответа содержатся значения полей заголовка
результата выполнения запроса. Во второй строке содержится перечень названий свойств заказа в том порядке, в
котором в последующих строках будут содержаться значения соответствующих свойств заказа. Каждая строка
ответа, начиная с третьей, содержит свойства одного заказа.
В качестве разделителя свойств заказа используется значение параметра запроса csvDelimiter. Если свойство
заказа содержит символ разделителя значений (параметр запроса csvDelimiter) или символ «”» (без обрамляющих
кавычек), то в ответе MWS значение свойства помещается в кавычки «”» (без обрамляющих кавычек), при этом
кавычки, содержащиеся внутри свойства, удваиваются.
Если значение какого-либо свойства не может быть определено (например, время перевода для
неоплаченного заказа), то в ответе формата CSV значение этого свойства будет пустым.
Пример 3. Ответ на запрос списка заказов, формат CSV, набор свойств заказа по умолчанию
Длинные строки перенесены, их границы показаны строками таблицы.
status=0;error=0;processedDT=2011-08-02T18:28:08.541+04:00;orderCount=2
shopID;articleId;invoiceId;orderNumber;paymentSystemOrderNumber;customerNumber;createdDatetime;paid;ord
erSumAmount;orderSumCurrencyPaycash;orderSumBankPaycash;paidSumAmount;paidSumCurrencyPaycash;paidS
umBankPaycash;receivedSumAmount;receivedSumCurrencyPaycash;receivedSumBankPaycash;shopSumAmount;sh
opSumCurrencyPaycash;shopSumBankPaycash;paymentDatetime;paymentAuthorizationTime;payerCode;payerAdd
ress;payeeCode;paymentSystemDatetime;avisoReceivedDatetime;avisoStatus;avisoRegistryId
1;2;2000000294394;12345670;;;2011-08-02T18:28:08.269+04:00;false;2.08;10643;1003;;;;;;;
2.00;10643;1003;;;;;;;;;;
2;3;2000000294386;12345671;334074060091013004;;2011-0802T18:20:58.562+04:00;true;350.00;10643;1002;350.00;10643;1003;350.00;10643;1003;300.00;10643;1002;
2011-08-02T18:21:00.091+04:00;334074060091013004;41003321020;192.168.1.127;410031234567;
2011-08-02T18:21:00.091+04:00;2011-08-02T18:27:59.448+04:00;81;
Если значение какого-либо свойства не может быть определено (например, время перевода для неоплаченного
заказа), то в ответе формата XML соответствующий атрибут будет отсутствовать.
Пример 4. Ответ на запрос списка заказов, формат XML
56
<?xml version="1.0" encoding="utf-8"?>
<listOrdersResponse status="0" error="0"
processedDT="2011-08-02T20:38:01.000+04:00"
orderCount="2">
<order shopID="1" articleId="2" invoiceId="2000000294393"
shopName="ЗАО &quot;Мобильник&quot;"
articleName="Оплата мобильного телефона"
orderNumber="12345678"
paymentSystemOrderNumber="334074426144011004"
createdDatetime="2011-08-02T18:27:05.568+04:00"
paid="true"
paymentDatetime="2011-08-02T18:27:06.144+04:00"
paymentAuthorizationTime="334074426144011004"
payerCode="41003122233"
payerAddress="192.168.1.127"
payeeCode="41003987654"
paymentSystemDatetime="2011-08-02T18:27:06.144+04:00"
avisoReceivedDatetime="2011-08-02T18:27:06.144+04:00"
avisoStatus="1000"
orderSumAmount="2.08"
orderSumCurrencyPaycash="643"
orderSumBankPaycash="1001"
paidSumAmount="2.08"
paidSumCurrencyPaycash="643"
paidSumBankPaycash="1001"
shopSumAmount="2.07"
shopSumCurrencyPaycash="643"
shopSumBankPaycash="1001"
receivedSumAmount="2.07"
receivedSumCurrencyPaycash="643"
receivedSumBankPaycash="1001"
/>
<order shopID="2" articleId="3" invoiceId="2000000294394"
shopName="ЗАО &quot;Виртуальная реальность&quot;"
articleName="Футбол навсегда"
orderNumber="12345679"
createdDatetime="2011-08-02T18:28:08.269+04:00"
paid="false"
orderSumAmount="2.08"
orderSumCurrencyPaycash="643"
orderSumBankPaycash="1001"
shopSumAmount="2.07"
shopSumCurrencyPaycash="643"
shopSumBankPaycash="1001"
/>
</listOrdersResponse>
Формат отображения параметров платежной формы в ответе зависит от того, какой формат ответа задан в
параметре запроса outputFormat:

в формате CSV параметры платежной формы возвращаются в свойстве заказа paymentFormParams в виде
перечисления пар «имя=значение» (без кавычек), в качестве разделителя пар используется символ «;»
(без кавычек). Если пара содержит кавычки (“), то она помещается в двойные кавычки;
57

в формате XML параметры платежной формы возвращаются как вложенные элементы элемента
paymentFormParams. Для каждого параметра платежной формы создается элемент, атрибут «key»
которого содержит имя параметра, а «val» — значение параметра.
Пример 5. Параметры платежной формы в ответе в формате CSV
“PROPERTY1=123;PROPERTY2=1234567;Sum=10.00;NetSum=0;ShopArticleId=2;ShowCaseId=99901;
BankId=1003;CurrencyId=10643;TargetBankId=1003;TargetCurrencyId=10643;
BuyButton=Оплатить;””ArticleName=””””Оплата мобильного телефона”””””””
Пример 6. Параметры платежной формы в ответе в формате XML
<paymentFormParams>
<param key="Sum" val="10.00"/>
<param key="NetSum" val="0"/>
<param key="ShopArticleId" val="3"/>
<param key="PROPERTY1" val="123"/>
<param key="PROPERTY2" val="1234567"/>
</paymentFormParams>
3.2. Запрос списка возвратов успешных переводов (listReturns)
Данный запрос позволяет получить выборку истории выполнения операций возврата успешных переводов.
Полный список параметров для этого типа запрашиваемой операции приведен в Таблица 7. Параметры запроса
списка возвратов успешных переводов.
См. также описание операции returnPayment.
Адрес операции: https://server:port/webservice/mws/api/listReturns
3.2.1. Формат запроса
ИС
формирует
POST-запрос
по
протоколу
HTTP/1.1
(http://www.ietf.org/rfc/rfc2616.txt,
http://www.ietf.org/rfc/rfc2618.txt). Параметры вызова операции упаковываются как набор параметров POST
запроса в виде пар «имя=значение». MIME-тип: application/x-www-form-urlencoded. Кодировка символов: UTF-8.
Некоторые параметры могут отсутствовать в запросе. В этом случае для них используется значение параметра
по умолчанию. Если параметр присутствует в запросе, но имеет пустое значение, то значение по умолчанию для
параметра не используется. Если отсутствует обязательный параметр, возвращается ошибка «Неверное значение
параметра NNNN».
Таблица 7. Параметры запроса списка возвратов успешных переводов
Название параметра
Тип
Примечания
xs:dateTime
Дата и время запроса по часам ИС. Обязательный параметр.
shopID
xs:long
Идентификатор Контрагента, присвоенный Оператором.
from
xs:dateTime
Время выборки «от».
till
xs:dateTime
Время выборки «до».
requestDT
58
status
xs:int
Статус операции (необязательный параметр).
partial
xs:boolean
Необязательный параметр. Возможные значения:



true — будут выведены только те операции, где
возвращается только часть суммы перевода;
false — будут выведены только те операции, где
возвращается полная сумма перевода;
параметр отсутствует — будут выведены все
операции.
Значение по умолчанию: отсутствует.
outputFormat
xs:normalizedString
Формат представления результата, допустимые значения —
«XML» или «CSV». Значение по умолчанию: XML.
csvDelimiter
xs:string, 1 символ
Разделитель значений для формата CSV. Не может быть
равен символу «”» (кавычка). Необязательный параметр:
если отсутствует в запросе, используется разделитель «;» (без
кавычек).
Замечание: параметры запроса from и till применяются к полю createdDT (время регистрации запроса на возврат
по часам Оператора).
3.2.2. Формат ответа
Формат ответа определяется входными параметрами запроса outputFormat и csvDelimiter. В случае ошибки
ее код и описание возвращаются в заказанном формате представления результата.
Таблица 8. Параметры операций возврата успешного перевода, возвращаемые в ответе
Название параметра
Тип
Примечания
xs:long
Уникальный идентификатор операции возврата в сервисе
«Яндекс.Деньги».
invoiceId
xs:long
Номер транзакции перевода.
shopID
xs:long
Идентификатор Контрагента, присвоенный Оператором.
amount
CurrencyAmount
Сумма возврата.
currency
CurrencyCode
Код валюты.
cause
xs:string,
символов
status
xs:int
Код состояния запроса.
error
xs:int
Код ошибки.
createdDT
xs:dateTime
Время регистрации запроса на возврат.
processedDT
xs:dateTime
Фактическое время возврата средств плательщику. Поле
присутствует только в случае успешного возврата.
sender
xs:string
Отправитель приказа на возврат. Параметр содержит поле
CN X509 сертификата, которым был подписан запрос на
возврат (returnPayment).
returnId
до
255
Описание причины возврата.
59
articleAmount
CurrencyAmount
Сумма возврата в валюте товара.
articleCurrency
CurrencyCode
Код валюты товара.
orderNumber
xs:string,
символов
до
64
Уникальный для данного shopID номер заказа в ИС
Контрагента.
60
Пример 7. Успешный ответ в формате XML
<?xml version="1.0" encoding="UTF-8"?>
<listReturnsResponse
status="0" error="0"
processedDT="2011-07-02T20:38:01.000Z">
<returnPayment
returnId="123"
status="0" error="0"
invoiceId="2000000123"
shopID="6689"
amount="10.00"
currency="643"
createdDT="2011-07-02T20:38:01.000Z"
processedDT="2011-07-02T20:38:01.000Z"
cause="покупатель отказался принять товар"
sender="shopName"
articleAmount="10.00"
articleCurrency="643"
orderNumber="12345"
/>
<returnPayment
returnId="124"
status="3" error="506"
invoiceId="2000000125"
shopID="6689"
amount="12.00"
currency="643"
createdDT="2011-07-02T20:38:01.000Z"
cause="покупатель отказался принять товар"
sender="shopName"
articleAmount="12.00"
articleCurrency="643"
orderNumber="12346"
/>
</listReturnsResponse>
Пример 8. Успешный ответ в формате CSV
status=0;error=0;processedDT=2011-07-02T20:38:01.000Z
123;0;0;2000000123;6689;10.00;643;2011-07-02T20:38:01.000Z;2011-0702T20:38:01.000Z;"покупатель отказался принять
товар";shopName;10.00;643;12345
124;3;506; 2000000125;6689;12.00;643;2011-07-02T20:38:01.000Z;;
"покупатель отказался принять товар";shopName;12.00;643;12346
Примечание: в случае отсутствующего параметра в формате CSV передается пустое поле.
Пример 9. Сообщение об ошибке в формате XML
<?xml version="1.0" encoding="UTF-8"?>
<listReturnsResponse
status="3" error="113"
processedDT="2011-07-02T20:38:01.000Z"/>
Пример 10. Сообщение об ошибке в формате CSV
61
status=3;error=113;processedDT=2011-07-02T20:38:01.000Z
4.
Финансовые операции
Финансовые операции предназначены для совершения действий с переводами, такими как полный или
частичный возврат успешного перевода плательщику.
4.1. Формат запроса на исполнение финансовой операции
Формирование запроса к серверу Оператора состоит из следующих шагов:
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/rfc2618.txt ). Криптопакет может быть передан одним из
двух способов:


криптопакет помещается в тело POST-запроса, MIME тип: application/pkcs7-mime;
криптопакет передается как multipart-data вложение. MIME тип: application/pkcs7-mime. POST запрос
должен иметь только один 'part', криптопакет должен быть вложен как файл. Такой запрос может быть
отправлен из стандартной HTML-формы для file upload (отправки файла на сервер). См.
http://www.ietf.org/rfc/rfc2388.txt.
Для авторизации запросов Оператор проверяет АСП криптопакета.
Защита от ошибочных повторов операций обеспечивается наличием уникальных номеров операций
(clientOrderId).
Пример 11. HTTP-запрос
POST /webservice/mws/api/returnPayment HTTP/1.1
Content-Type: application/pkcs7-mime
Content-Length: 906
-----BEGIN PKCS7----MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCA
JIAEgbE8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KPG1h
a2VEZXBvc2l0aW9uUmVzcG9uc2UgY2xpZW50T3JkZXJJZD0iMTI5MTExNjIzNDUy
OCIgc3RhdHVzPSIwIiBlcnJvcj0iMCIgcHJvY2Vzc2VkRFQ9IjIwMTAtMTEtMzBU
MTE6MjM6NTQuNjI0WiIgYmFsYW5jZT0iNTQxNDYuNzMiIC8+DQoAAAAAAAAxggF8
MIIBeAIBATB3MGoxCzAJBgNVBAYTAlJVMQ8wDQYDVQQIEwZSdXNzaWExFjAUBgNV
BAcTDVN0LlBldGVyc2J1cmcxITAfBgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5
IEx0ZDEPMA0GA1UEAxMGc2VydmVyAgkAy2xbdQckXjIwCQYFKw4DAhoFAKBdMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEzMDEx
MjM1NVowIwYJKoZIhvcNAQkEMRYEFEYNh8glwqIXGR/n6oYrApa8DaO5MA0GCSqG
SIb3DQEBAQUABIGAHlgGsYK30RXWBvuQao0V73KIPQEx2hH/9GY6Iag/xlmZ3rBB
kFpszF/O2fB+t84pCHfV15ErZQEkAqIotkEYEgA3hAddEW5+RWUzp+3npHpW5OY7
h3niP5Pj+r0P8EDgHe2j0Zb3dzj2mbwOshZD+FP1IcR8AmiTV3u35C6KAEsAAAAA
AAA=
-----END PKCS7-----
62
4.2. Формат ответа
Результат выполнения запроса возвращается в ответе HTTP запрос в виде XML документа согласно стандарту
XML 1.0 (Fifth Edition), опубликованному по адресу: http://www.w3.org/TR/xml/ MIME тип: application/xml.
Кодировка символов — UTF-8.
4.3. Запрос возврата успешного перевода (returnPayment)
Данный запрос позволяет осуществить возврат успешного перевода на счет плательщика. Успешный перевод
может быть возвращен как полностью, так и частично. Полный список параметров для этого типа запрашиваемой
операции приведен в Таблица 9. Параметры запроса возврата успешного перевода». Все параметры
обязательные. В случае если обязательный параметр отсутствует, возвращается ошибка «Неверное значение
параметра NNNN».
Адрес операции: https://server:port/webservice/mws/api/returnPayment.
Таблица 9. Параметры запроса возврата успешного перевода
Название параметра
Тип
Примечания
ClientTransactionNumbe
r
Уникальный
идентификатор
операции
возврата.
Рекомендуемые значения: целое, положительное, линейно
нарастающее десятичное число.
requestDT
xs:dateTime
Время формирования запроса на выполнение операции по
часам ИС Контрагента.
invoiceId
xs:long
Номер транзакции возвращаемого перевода.
shopID
xs:long
Идентификатор Контрагента, присвоенный Оператором.
amount
CurrencyAmount
Сумма, которую необходимо вернуть на счет плательщика.
currency
CurrencyCode
Код валюты возвращаемого перевода.
сause
xs:string,
символов
clientOrderId
до
255
Описание причины возврата.
Ответ содержит общие поля состояния операции (см. Таблица 2. Описание общих параметров ответа»).
Ошибки, которые могут возникнуть при запросе возврата успешного перевода, перечислены в Таблица 11. Коды
ошибок операций».
1.
4.3.1. Правила обработки запросов
Каждый запрос должен быть сформирован с уникальным значением номера операции (clientOrderId).
2.
Если запрос отправлен с уже ранее обработанным номером операции (clientOrderId) и остальные параметры
запроса, кроме requestDT, совпадают с предыдущей попыткой, то Оператор возвращает результат обработки
ранее отправленного запроса.
3.
Если запрос отправлен с уже ранее обработанным номером операции (clientOrderId), а остальные параметры
имеют отличные от первой попытки значения, то Оператор отвергает такой запрос и возвращает в ответе
status=3, error=405.
4.
Оператор обрабатывает полученный запрос немедленно. Если обработать запрос в течение нескольких
63
секунд невозможно, то возвращается ответ «в процессе обработки» (status=1). В этом случае ИC следует
повторить запрос с теми же данными для получения окончательного ответа. Рекомендуется следующий
режим повтора: первый повтор через 1 минуту, следующие три — с промежутком в 5 минут, далее — не чаще
чем раз в 30 минут.
5.
При отсутствии ответа от Оператора, а также при нечетком ответе (например, HTTP status 500 или status=1)
следует повторить запрос с теми же данными для получения окончательного ответа. Рекомендуется
следующий режим повтора: первый повтор через 1 минуту, следующие три — с промежутком в 5 минут,
далее — не чаще чем раз в 30 минут.
6.
Статус операции, находящейся в обработке (status=1), может измениться как на «успех», так и на «отвергнут».
7.
Если запрос отвергнут Оператором, то в ответе возвращается status=3 и error= с расшифровкой причины
отказа. В некоторых случаях может присутствовать поле techMessage, содержащее дополнительную
поясняющую информацию в виде текста произвольного формата. Этот текст предназначен для анализа
техническими специалистами и не должен отображаться в каком-либо интерфейсе пользователя.
Пример 12. Запрос
<?xml version="1.0" encoding="UTF-8"?>
<returnPaymentRequest
clientOrderId="12345"
requestDT="2011-07-02T20:38:00.000Z"
invoiceId="2000000123"
shopID="6689"
amount="10.00"
currency="643"
cause="Пользователь отказался принять заказ"
/>
Пример 13. Ответ
<?xml version="1.0" encoding="UTF-8"?>
<returnPaymentResponse
clientOrderId="12345"
status="0" error="0"
processedDT="2011-07-02T20:38:01.000Z"
/>
5.
Типы данных
Таблица 10. Определения типов данных протокола
Тип
xs:int
Описание
32-bit, целое знаковое число. Int32,
http://www.w3.org/TR/xmlschema-2/#int
определенный
в
стандарте:
xs:long
64-bit, целое знаковое число. Int64,
http://www.w3.org/TR/xmlschema-2/#long
определенный
в
стандарте:
xs:decimal
Десятичное число с фиксированной точкой,
http://www.w3.org/TR/xmlschema-2/#decimal
xs:boolean
Логическое
значение
(true/false),
определенно
определено
в
в
стандарте:
стандарте:
64
http://www.w3.org/TR/xmlschema-2/#boolean
xs:string
Текстовая строка, определенная в стандарте: http://www.w3.org/TR/xmlschema2/#string
xs:normalizedString
Текстовая строка, определенная в стандарте: http://www.w3.org/TR/xmlschema2/#normalizedString
xs:dateTime
Временная метка в формате согласно рекомендациям:

http://www.w3.org/TR/xmlschema-2/#dateTime

ISO8601:2004
Формат определяется как:
YYYY-MM-DDThh:mm:ss.fZZZZZ
Расшифровка формата:
YYYY
год, точно 4 цифры
MM
месяц, точно 2 цифры (01=январь и так далее)
DD
день месяца, точно 2 цифры (от 01 до 31)
T
латинский символ «T», должен быть в верхнем регистре
hh
часы, точно 2 цифры (24-часовой формат, от 00 до 23)
mm
минуты, точно 2 цифры (от 00 до 59)
ss
секунды, точно 2 цифры (от 00 до 59)
f
дробная часть секунды (от одной до 6 цифр),
может отсутствовать, в этом случае следует опускать и разделитель
«.»
ZZZZZ
Описатель временной
принимать значения:
зоны,
обязательный
параметр,
может

Z — UTC, символ «Z» должен быть в верхнем регистре;

+hh:mm или -hh:mm — смещение относительно UTC
(показывает, что указано локальное время, которое на
данное число часов и минут опережает или отстает от UTC).
Обязательно должны присутствовать все указанные элементы, допустимо опускать
только дробную часть секунд (в этом случае следует опускать и разделитель «.»).
Если нужно задать только дату, то время всё равно следует указать как 00:00:00.
Примеры:



2011-07-24T19:00:00+04:00 – 19 часов 00 минут 24 июля 2011 года, часовой
пояс — UTC + 4 часа;
2011-07-24T15:00:00Z — тот же момент времени, в каноническом
представлении;
2011-07-24T15:00:00.666Z — тот же момент времени, плюс 666
65
миллисекунд.
ClientTransactionNum
ber
Уникальный идентификатор транзакции. Должен быть уникальным для
Контрагента на протяжении всей истории операций. Значением параметра должна
быть строка длиной от 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
Номер счета в сервисе «Яндекс.Деньги», строка десятичных цифр, длиной от 11 до
33 символов.
<xs:simpleType name="YMAccount">
<xs:restriction base="xs:normalizedString">
<xs:minLength value="11"/>
<xs:maxLength value="33"/>
<xs:pattern value="[0-9]+"/>
</xs:restriction>
</xs:simpleType>
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>
66
CurrencyCode
Код валюты. Возможные значения:

643 — рубли Российской Федерации;

10643 — тестовая валюта (демо-рубли демо-сервиса «Яндекс.Деньги»).
<xs:simpleType name="CurrencyCode">
<xs:restriction base="xs:int">
</xs:restriction>
</xs:simpleType>
CurrencyBank
Код процессингового центра «Яндекс.Деньги». Возможные значения:

1001 – ЭкомБанк;

1003 – ДемоБанк.
<xs:simpleType name="CurrencyBank">
<xs:restriction base="xs:int">
</xs:restriction>
</xs:simpleType>
PaymentType
Способ совершения платежа. Строка, два символа:




PC — платеж, совершаемый со счета пользователя в Яндекс.Деньгах или с
банковской карты, привязанной к этому счету;
AC — платеж, совершаемый с любой банковской карты, которая не
привязана к счету пользователя в Яндекс.Деньгах;
GP — платеж, совершаемый через терминал приема платежей;
MC — платеж, совершаемый со счета мобильного телефона.
Список возможных значений может быть расширен.
<xs:simpleType name="PaymentType">
<xs:restriction base="xs: normalizedString">
<xs:minLength value="2"/>
<xs:maxLength value="2"/>
</xs:restriction>
</xs:simpleType>
6.
Коды ошибок
Таблица 11. Коды ошибок операций
Код
Название
Примечания
67
Общие ошибки
0
Без ошибок.
10
Ошибка синтаксического разбора XML-документа.
Возможные причины:


нарушение синтаксиса XML;
отсутствие обязательных элементов XML.
50
Невозможно открыть PKCS#7 криптопакет, ошибка
целостности данных криптопакета.
51
АСП не подтверждена (данные цифровой подписи
не совпадают с передаваемым документом).
53
Запрос
подписан
неизвестным
«Яндекс.Деньги» сертификатом.
55
Истек срок действия сертификата Контрагента.
110
У данного пользователя нет прав на выполнение
операции с запрошенными параметрами.
сервису
Например, нет прав на просмотр списка
заказов по заданному shopID.
Общие ошибки параметров
111
Неверное значение параметра requestDT.
112
Неверное значение параметра invoiceId.
113
Неверное значение параметра shopID.
114
Неверное значение параметра orderNumber.
115
Неверное значение параметра clientOrderId.
117
Неверное значение параметра status.
118
Неверное значение параметра from.
119
Неверное значение параметра till.
Ошибки параметров информационных запросов
200
Неверное значение параметра outputFormat.
201
Неверное значение параметра csvDelimiter.
202
Неверное
значение
orderCreatedDatetimeGreaterOrEqual.
параметра
203
Неверное
значение
orderCreatedDatetimeLessOrEqual.
параметра
204
Неверное значение параметра paid.
205
Неверное
значение
paymentDatetimeGreaterOrEqual.
Допустимо: XML, CSV.
параметра
68
206
Неверное
значение
paymentDatetimeLessOrEqual.
параметра
207
Неверное значение параметра outputFields.
208
В запросе указан пустой диапазон времени создания
заказа.
Верхняя граница времени создания заказа
orderCreatedDatetimeLessOrEqual
меньше
или равна нижней границе времени
создания
заказа
orderCreatedDatetimeGreaterOrEqual.
209
В запросе указан слишком большой диапазон
времени создания заказа.
Диапазон
времени,
ограниченный
значениями
параметров
orderCreatedDatetimeGreaterOrEqual
и
orderCreatedDatetimeLessOrEqual, больше 31
дня.
210
В запросе указан пустой диапазон времени оплаты
заказа.
Верхняя граница времени оплаты заказа
paymentDatetimeLessOrEqual меньше или
равна нижней границе времени оплаты
заказа paymentDatetimeGreaterOrEqual.
211
В запросе указан слишком большой диапазон
времени оплаты заказа.
Диапазон
времени,
ограниченный
значениями
параметров
paymentDatetimeGreaterOrEqual
и
paymentDatetimeLessOrEqual, больше 31 дня.
212
Логическое противоречие между диапазоном
времени оплаты и флагом «только оплаченные».
В запросе задан диапазон времени оплаты
заказа, но отсутствует параметр paid, либо
его значение не равно «true».
213
Не указано ни одно условие для ограничения
выборки.
214
В запросе по номеру заказа (orderNumber) не задан
идентификатор Контрагента (shopID).
215
В запросе по номеру транзакции (invoiceId) не задан
идентификатор Контрагента (shopID).
216
Результат содержит слишком много элементов.
Следует изменить параметры запроса, чтобы
уменьшить длину временного диапазона,
ограничивающего выборку.
217
Неверное значение параметра partial.
Допустимые значения: true, false.
Ошибки запросов финансовых операций
402
Неверное значение параметра amount.
403
Неверное значение параметра currency.
404
Неверное значение параметра cause.
Параметр отсутствует или у этого параметра
недопустимая длина.
405
Неуникальный номер операции.
Операция с таким номером (clientOrderId) но
другими параметрами уже выполнялась.
69
410
Заказ не оплачен. Возврат невозможен.
411
Неуспешный
переводе.
412
Валюта перевода отличается от заданной в запросе.
В параметре запроса currency указана не та
валюта, в которой был сделан перевод.
413
Сумма возврата, заданная в запросе, превышает
сумму перевода.
С учетом ранее проведенных возвратов
сумма, указанная в запросе, превышает
сумму исходного перевода.
414
Перевод возвращен ранее.
Вся сумма перевода уже возвращена на счет
плательщика.
415
Заказ с указанным номером транзакции (invoiceId)
отсутствует.
416
Недостаточно средств для проведения операции.
417
Счет плательщика закрыт. Возврат средств на него
невозможен.
418
Счет плательщика заблокирован. Возврат средств на
него невозможен.
статус
доставки
уведомления
Заказ не был оплачен плательщиком.
о
Уведомление о переводе не было успешно
доставлено в ИС Контрагента.
На счете Контрагента недостаточно средств
для проведения операции возврата.
Прочие ошибки
1000
7.
Техническая ошибка
Коды состояний уведомления о переводе
Таблица 12. Коды состояний уведомления о переводе
Состояние
уведомления
-1
Описание
Уведомление о переводе еще не создано.
81
Уведомление ожидает отправки.
100
Уведомление было доставлено, но Контрагент отверг его.
103
Доставка уведомления отменена.
1000
Контрагент успешно уведомлен о данном переводе.
1010
Уведомление не было доставлено. Тем не менее уведомление считается
обработанным успешно.
1020, 1021
Уведомление было доставлено успешно. Перевод возвращен плательщику.
1022
Уведомление было доставлено успешно. Часть суммы перевода возвращена
плательщику.
70
71
1/--страниц
Пожаловаться на содержимое документа