1. 14. Дата последнего изменения версии api – 24 апреля 2017 года


Название1. 14. Дата последнего изменения версии api – 24 апреля 2017 года
страница1/7
ТипДокументы
  1   2   3   4   5   6   7
Программный интерфейс My-shop.ru
для партнерских магазинов


Содержание


Версия

Версия описываемого в данном документе программного интерфейса (API) – 1.14.
Дата последнего изменения версии API – 24 апреля 2017 года.
Версия документа – 1.14.0.

Дата последнего изменения документа – 24 апреля 2017 г.

Что нового в версии 1.14:

  • Параметр «error_3012» в ответах на запросы «order_pre» (Предварительная проверка параметров заказа и расчет стоимости) и «order_new» (Оформление нового заказа).


Что нового в версии 1.13:

  • Параметр «discount» (Скидка, %) в ответах на все запросы считается устаревшим, его использование не рекомендуется. Данный параметр может быть удалён в следующих версиях API. (Связано с переходом от начисления скидки на заказ целиком к начислению скидки отдельно для каждого товара в заказе.)

  • Если партнёр предоставляет скидку за счёт своего партнёрского вознаграждения, считается, что скидка, указанная в запросе, относится к основной системе скидок. Для товаров, относящихся к другим системам скидок, величина скидки вычисляется в соответствии с описанием систем скидок: http://my-shop.ru/my/helper_24

  • В ответе на запрос «product» (Информация о цене и доступности товара) появился параметр «ds» (код системы скидок).

  • С помощью запроса «list_orders» (Краткий отчет об оформленных заказах) теперь можно получить значение суммы партнёрского вознаграждения за каждый заказ.


Что нового в версии 1.12:

  • Запрос «list_search» (Поиск товаров).


Что нового в версии 1.11:

  • Параметр «phone_sms» (номер мобильного телефона для SMS-уведомлений) стал обязательным при оформлении заказа (запрос «order_new»).
    Изменение вступило в силу 17 августа 2013 г. Соответствующие уведомления были разосланы подписчикам рассылки «Новости партнерской программы My-shop.ru» за два с половиной месяца – 31 мая 2013 г.


Что нового в версии 1.10:

  • В ответе на запрос «list_regions» (Справочник регионов доставки) появился параметр «delivery_0_free» (см. описание ниже).

  • В ответе на запрос «list_delivery» (Справочник способов доставки) появились параметры «info» и «info_importance» (см. описание ниже). C 1 декабря 2012 года использование этих параметров обязательно!


Что нового в версии 1.9:

  • В ответе на запрос «Различные константы» («const») в параметрах «last_modified_list_regions» и «last_modified_list_delivery» всегда возвращается текущая дата. Эти параметры больше не используются, текущая дата в значениях этих параметров возвращается для совместимости с предыдущими версиями.

Права и обязанности партнера

Участник партнерской программы, использующий данный API, имеет право:

  • Создавать собственные интерфейсы для выбора товаров и оформления заказов без перенаправления клиентов на сайт Интернет-магазина My-shop.ru.

  • Вести собственную историю заказов.

  • Создавать собственную систему регистрации клиентов.

  • Создавать собственные интерфейсы для реализации «личных кабинетов» клиентов с информацией об оформленных ранее заказах и пр.

  • Использовать собственную систему оповещения клиентов о ходе выполнения их заказов.
    Начиная с сентября 2013 г., мы не рекомендуем этого делать, т.к. предоставляем всем клиентам, оформившим заказ в партнерском магазине, доступ к странице заказа на сайте Интернет-магазина My-shop.ru. На этой странице клиент может проверять состояние заказа, вносить изменения в заказ и вести переписку с операторами магазина. Кроме того, таким клиентам отправляются SMS-уведомления о ходе выполнения заказа.

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

  • Проводить рекламные акции с предоставлением скидок за счет своего партнерского вознаграждения.

  • Ограничивать ассортимент товаров.

  • Использовать собственные ограничения списка регионов доставки.

  • Использовать собственные ограничения набора способов доставки.

  • Использовать собственные ограничения набора способов оплаты.


Участник партнерской программы, использующий данный API, обязан:

  • Не допускать разглашения кода для аутентификации партнерского магазина. Изменять код для аутентификации партнерского магазина не реже одного раза в год.

  • Не допускать разглашения персональных данных клиентов и информации о заказах клиентов.

  • Разместить на индексируемой странице сайта партнерского магазина ссылку на Интернет-магазин My-shop.ru.

  • Информировать клиентов о том, что заказы выполняет «Интернет-магазин My-shop.ru», а сайт, на котором оформляется заказ, является партнером My-shop.ru.

  • Показывать клиентам текст, возвращаемый данным API в параметре «conditions» в ответ на запрос «const» («Различные константы»). Данный текст должен располагаться над кнопкой «Подтвердить заказ». Перед указанным текстом должна быть примерно такая фраза: «Нажимая кнопку "Подтвердить заказ", Вы подтверждаете свое согласие со следующими условиями». Сам текст может располагаться в поле «textarea», но при этом в видимой части данного поля (без прокрутки) должны находиться, как минимум, первый пункт и первые две строки второго пункта условий. Данный текст должен быть хорошо виден, его затемнение и/или уменьшение размера шрифта не допускается.

  • Предоставлять клиентам достоверную информацию о товарах и услугах Интернет-магазина My-shop.ru.

  • Перед подтверждением заказа клиентом сообщать ему итоговую стоимость заказа и ориентировочную дату отгрузки заказа (для заказов с предоплатой – ориентировочный срок формирования заказа), предлагать клиентам проверять прочие параметры заказа.

  • Сообщать клиенту номер оформленного им заказа (номер заказа в My-shop.ru) и настоятельно рекомендовать сохранять этот номер до момента получения заказа.

  • По запросу клиента предоставлять контактную информацию Интернет-магазина My-shop.ru (см. раздел «Различные константы»).

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

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

  • Выполнять прочие требования, указанные в настоящем описании программного интерфейса.

  • Не производить электронные, SMS и прочие рассылки от имени Интернет-магазина My-shop.ru или с упоминанием Интернет-магазина My-shop.ru без согласия администрации My-shop.ru, данного в письменной форме.


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

Популярные вопросы. Рекомендации My-shop.ru

Зачем столько пунктов в «обязанностях партнера»? Разве вам не достаточно, что я отправляю вам заказы?

My-shop.ru – клиент-ориентированная компания. Мы прилагаем все усилия для того, чтобы клиенты остались довольны нашей работой, и требуем того же от наших партнеров. Большая часть наших требований к партнерским магазинам касается правильного информирования клиентов о товарах и услугах. Мы стараемся не допускать ситуаций, когда клиентам не предоставляют необходимую им информацию о товарах и услугах, и тем более не позволяем специально вводить клиентов в заблуждение. Если вы считаете, что руководствоваться интересами клиентов неправильно, не начинайте работу в режиме «партнерского магазина».
Зачем нужно говорить клиенту, что заказы выполняет My-shop.ru?

Возможно, этого требования не было бы, если бы можно было избежать контактов My-shop.ru с клиентом. Но заказы выполняем мы, и в большинстве случаев при выполнении заказов мы так или иначе контактируем с клиентами. Соответственно, клиенту необходима информация о том, кто будет выполнять его заказ (см. предыдущий вопрос). Если клиенты не будут знать, кто выполняет их заказы, увеличится доля заказов, аннулированных из-за различных недоразумений, например, клиент может отказаться от получения заказа на почте, поскольку просто не узнает его: он сделал заказ в одном магазине (напр., наложенным платежом), а ему приходит неизвестно что из неизвестной ему компании, и за это почему-то просят денег. Разумеется, мы не можем себе позволить нести убытки из-за таких недоразумений.
Кроме того, этого требует наше законодательство. Клиент не может не знать, кто является продавцом, кто несет ответственность за выполнение заказа и к кому обращаться в случае возникновения спорного вопроса.

Если вас это не устраивает, возможно, вам нужно делать настоящий магазин, т.е. закупать у нас (или где-то еще) товары по оптовым ценам и продавать их самостоятельно. В этом случае у нас не будет никаких требований к вашему магазину.
Можно ли продавать товары по ценам, отличающимся от цен My-shop.ru?

Вы можете предоставлять клиентам скидки за счет своего партнерского вознаграждения, см. параметр «discount» в описании API. Такие скидки могут предоставляться только персонально (например, в рамках накопительной системы скидок партнерского магазина или в рамках каких-либо специальных акций, проводимых партнером). До авторизации на сайте партнера или до оформления заказа запрещается показывать цены, отличающиеся от цен на сайте Интернет-магазина My-shop.ru.
Повышение цены не допускается, но мы не исключаем предоставления такой возможности в будущем.
Почему нельзя принимать предварительные заказы и заказы от юридических лиц?

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

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

В данном случае совсем неразрешимых проблем нет, но и для нас, и для партнеров проще не использовать эту схему работы с юридическими лицами.

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

В любом случае, доля заказов юридических лиц и предварительных заказов невелика, в партнерских магазинах ими можно пренебречь.
Я сделал(а) партнерский магазин на своем сайте, однако при попытке оформить заказ ваш API сообщает об ошибке «Недопустимый тип запроса для тестового режима работы партнерского магазина». Как включить нормальный режим?

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

http://my-shop.ru/my/helper_11

В письме укажите ваш id партнера и URL страницы, где можно будет проверить работу вашего партнерского магазина.
Как получить код для аутентификации?

Секретный код вы должны указать сами в настройках партнерской программы (в вашем персональном разделе на странице «Партнерская программа»):

http://my-shop.ru/my/partnership

Поле, в котором нужно указать этот код, называется «Секретный код для запросов партнерского магазина». Введите в этом поле случайную последовательность от 20 до 50 символов. Секретный код можно изменить в любой момент.
Зачем вообще нужна аутентификация и секретный код? Если с моим id партнера будет оформлять заказы кто-то еще, я буду только рад(а).

Если кто-то от вашего имени будет оформлять заказы несуществующих клиентов, эти заказы, естественно, будут аннулироваться после попытки их выполнения. Мы при этом будем нести убытки – увидим, что сотрудничество с вами для нас не выгодно, и будем вынуждены заблокировать ваш аккаунт. Иными словами, аутентификация нужна вам, чтобы вы были уверены, что никто не действует от вашего имени без вашего ведома.
Какой метод аутентификации выбрать? Ваш «md5» – это надежно?

Сравним, что будет, если кто-то перехватит значение параметра «auth_code» в вашем запросе:

  • при аутентификации «plain», этот «кто-то» сможет делать любые запросы от вашего имени,

  • при аутентификации «md5», этот кто-то сможет делать запросы от вашего имени только с тем же значением «request» (для этого требуется одновременный перехват значений параметров «auth_code» и «auth_salt»).

В данном случае «md5» не сильно защищает, поэтому мы не настаиваем на его использовании.
В дополнение к этому мы рекомендуем вам указать в настройках партнерской программы (в вашем персональном разделе на странице «Партнерская программа») один или несколько IP-адресов, с которых должны приниматься запросы вашего партнерского магазина.
В описании API упоминается около 20 типов запросов. Для создания партнерского магазина нужно использовать все эти запросы?

В данном API действительно предусмотрено много типов запросов, и их количество еще может увеличиться. Чтобы принимать заказы на своем сайте, достаточно использовать лишь два типа запросов: «Предварительная проверка параметров заказа» и «Оформление нового заказа». Все остальное – на ваше усмотрение. Решайте сами, что понадобится для вашего магазина, а что нет.
Рекомендации по обновлению справочников и программного обеспечения партнерского магазина.

Мы рекомендуем сделать отдельную программу для ежедневной проверки ответов на запрос «Различные константы». Что стоит делать при этой проверке:

  1. Собственно обновлять константы, которые используются вашими программами.

  2. Проверять, не изменилась ли версия API. См. рекомендации в разделе «Проверка текущей версии API».

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

Даты изменения справочников в ответах на запрос «Различные константы» определяются не автоматически, эти даты мы обновляем вручную. Риск того, что мы забудем изменить дату при изменении справочника, очень невелик, но вы можете дополнительно обновлять справочники с какой-то перериодичностью, при этом лучше ориентироваться на значение параметра «expires_sec» (см. ниже). Обычно изменения справочников таковы, что даже устаревание справочника на несколько месяцев вряд ли будет критично для работы партнерского магазина.

Если вы хотите добиться максимальной надежности ваших программ, мы рекомендуем обновлять справочники при каждом из этих трех событий:

  1. Изменилась дата последнего обновления справочника в ответе на запрос «Различные константы».

  2. После последнего обновления справочника прошло время, указанное в параметре «expires_sec» (указанное время не является жестким требованием, его можно изменять в любую сторону).

  3. При работе партнерского магазина получена ошибка, косвенно указывающая на то, что какой-то из справочников устарел.


Рекомендации по проверке «статусов» заказов и новых писем.

Если вы храните историю оформленных заказов, вы также можете дать клиентам возможность отслеживать «статусы» (состояния) их заказов. Это можно сделать двумя способами:

  1. Пассивно: информация о заказе загружается и отображается в «личном кабинете», когда туда заходит клиент.

  2. Активно*: программное обеспечение партнерского магазина с какой-то периодичностью проверяет, не изменилось ли состояние заказов с помощью запроса «list_orders» («Краткий отчет об оформленных заказах»), и, обнаружив изменения, отправляет клиентам соответствующие уведомления по электронной почте. Как и с какой периодичностью это стоит делать (см. расшифровку «статусов» заказов в описании запроса «order_old» – «Информация о состоянии заказа»):

    1. если заказ в обработке (последний статус заказа «2», «3» или «4»), проверять его «статус» раз в три-четыре часа (в ночные часы проверять не стоит), пока статус не изменится на «0», «5» или «6»;

    2. если последний статус заказа «5», проверять его один раз в сутки, пока статус не изменится на «0» или «6»;
      при этом необходимо запоминать день, когда статус заказа последний раз изменился на «0» или «6»;
      обратите внимание, что не имеет смысла отправлять клиентам сообщение об изменении статуса с «5» на «6».

    3. если последний статус заказа «0» или «6», проверять его максимум один раз в сутки в течение 45 дней.

Если вы хотите обеспечить клиентам возможность переписываться с нашими операторами, проверять наличие новых писем от наших операторов можно теми же способами (в случае «активного» способа – с учетом статуса заказа по тому же алгоритму).

* Начиная с сентября 2013 г., мы не рекомендуем использовать описанный выше «активный» способ, т.к. предоставляем всем клиентам, оформившим заказ в партнерском магазине, доступ к странице заказа на сайте Интернет-магазина My-shop.ru. На этой странице клиент может проверять состояние заказа, вносить изменения в заказ и вести переписку с операторами магазина. Кроме того, таким клиентам отправляются SMS-уведомления о ходе выполнения заказа.
  1   2   3   4   5   6   7

Похожие:

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconПри работе через api следует последовательно пройти следующие шаги
Структура api реализована по архитектуре rest odata коммуникация осуществляется посредством

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconИзменения в сфере жкх с 2017 года с 1 января 2017 года повышающий...
Правительством РФ вводятся новые индексы изменения размера платы за коммунальные услуги в среднем по субъектам РФ на 2017 год

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconВажные изменения законодательства с 1 января 2017 года
В обзоре собраны изменения законодательства, вступившие в силу 1 января 2017 года, являющиеся в той или иной степени значимыми для...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года icon1. Создание нового Бюджета 2017 года
Перенос организационных ролей пользователей для справочников: «Бланки расходов», «Версии доходов/расходов/источников», «Версии межбюджетных...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconПамятка Заявителю при подаче документов в Национальный реестр специалистов...
Совет Ассоциации «Национальное объединение строителей» (далее – Совет) одобрил изменения в проект Регламента ведения Национального...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconПресс-релиз дачная амнистия сегодня и завтра Красноярск 7 апреля 2017 года
Красноярск 7 апреля 2017 года Благодаря «дачной амнистии», граждане могут в упрощенном порядке зарегистрировать права на земельные...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconПресс-релиз дачная амнистия сегодня и завтра Красноярск 7 апреля 2017 года
Красноярск 7 апреля 2017 года Благодаря «дачной амнистии», граждане могут в упрощенном порядке зарегистрировать права на земельные...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconАннотация к версии 0 от 10. 07. 2017 программы заполнения деклараций...
Программа «Декларация 2014» предназначена для автоматизированного заполнения налоговых деклараций по налогу на доходы физических...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconСправочник налоговые и бухгалтерские изменения с 2017 года
В этом году вступили в силу многочисленные поправки, повлиявшие на работу компаний. Но уже известно о новых налоговых и бухгалтерских...

1. 14. Дата последнего изменения версии api – 24 апреля 2017 года iconОтличия и изменения сборки 6 версии 78 Изменения во всех модулях комплекса
Изменить настройки в секции «Проверка паролей», влияющие на смену пароля, например

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск