Безопасные Сделки

Интеграция механизма Безопасных Сделок для торговых площадок, фриланс-бирж, аукционов, далее называемых обобщенным именем площадка, немного отличается от интеграции в интернет‑магазины. О нюансах будет сказано ниже.

Каждая Сделка имеет двух участников: Заказчика, именуемого ниже Покупателем, и Исполнителя, именуемого ниже Продавцом.

Ключевыми элементами каждой Сделки являются:

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

Обратите внимание...

Использование Безопасных Сделок сервиса Наложка подразумевает согласие Продавца и Покупателя на участие в Сделке третьей стороны — Гаранта Сделки в лице сервиса Наложка.

Функции Гаранта:

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

Ниже приведена полная диаграмма смены статусов Сделки:

Статусы Безопасной Сделки

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

Получение уведомлений о событиях Сделки

Безопасные Сделки через механизм уведомлений сообщают о следующих событиях созданных API-пользователем Сделок:

  • создание Сделки:
    • type = deals.deal.created,
    • deal = данные Сделки на момент возникновения события,
  • изменение данных Сделки:
    • type = deals.deal.updated,
    • deal = данные Сделки на момент возникновения события,
    • changes - список измененных полей верхнего уровня структуры Сделки
      {
        "field_name": [old_value, new_value],
        ...
      }
      
  • изменение статуса Сделки:
    • type = deals.deal.changed_status,
    • deal = данные Сделки на момент возникновения события,
    • old_status = из какого статуса перешла,
    • new_status = в какой статус перешла.

Создание Сделки для интернет‑магазина

При создании API-пользователя интернет‑магазина, создается связанный с ним профиль участника Сделок. Таким образом, при создании Сделок от имени этого пользователя, в качестве Продавца будет автоматически указан профиль магазина.

В настройках CMS интернет‑магазина желательно дать возможность указать/сменить токен доступа к API Наложки.

В процесс заказа в интернет‑магазине Наложка интегрируется как способ оплаты.

В момент нажатия Покупателем кнопки оплаты заказа необходимо создать Сделку в системе Наложка, а после отправить Покупателя на страницу оплаты заказа (см. ниже).

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

При создании Сделки не нужно указывать Продавца. В качестве Продавца, как было сказано выше, будет подставлен профиль интернет‑магазина.

В случае обновления Заказа до внесения депозита Покупателем, соответствующие изменения следует вносить в Сделку посредством обновления через API.

Если заказ изменяется уже после внесения депозита Покупателем (например менеджером через административную часть ИМ), то необходимо произвести отмену ранее созданной Сделки и создать новую Сделку. При отмене Сделки Покупателю будут возвращены ранее задепонированные средства, заказ должен стать неоплаченным, и от Покупателя потребуется повторно оплатить его (внести депозит).

Если при изменении заказа не удалось изменить или отменить Сделку (ошибка или недоступность сервиса), то необходимо заблокировать изменение заказа (не сохранять изменения) и однозначно дать понять администратору ИМ о проблемах Сервиса Наложка и предложить ему попробовать позднее или обратиться в службу поддержки Сервиса Наложка.

Оплата заказа

Далее, для произведения оплаты заказа необходимо отправить Покупателя на страницу Наложки https://safebuy.nalogka.ru/{deal_id}/payment, где {deal_id} — идентификатор Сделки, полученный при ее создании.

В параметрах этого запроса нужно передать следующие данные:

  • success_url — Адрес, на который будет перенаправлен Покупатель в случае удачного внесения депозита обязательно
  • fail_url — Адрес, на который будет перенаправлен Покупатель в случае ошибки внесения депозита обязательно

При переходе на эту страницу Покупатель будет перенаправлен на страницу платежного шлюза, где он должен ввести данные банковской карты и осуществить платеж.

После фиксации оплаты Сделка переходит в статус Ожидает исполнения, что с точки зрения интернет‑магазина имеет смысл "Обработка заказа".

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

Для подтверждения оплаты необходимо дождаться уведомления об изменении статуса Сделки на Ожидает исполнения.

Создание Сделки на площадке

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

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

Внесение депозита выглядит так:

  • через API Безопасных Сделок получаются параметры формы для отправки пользователя на страницу платежного шлюза;
  • отрисовывается web-форма с указанным методом запроса, адресом и данными, указанными в скрытых полях. Отправка данной формы переведет пользователя на страницу ввода карты;
  • после успешной оплаты Покупатель будет возвращен на страницу, указанную в параметре success_url, а при безуспешной оплате — на fail_url.

После успешного внесения депозита Сделка, созданная на площадке, переходит в статус Ожидает исполнения.

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

Для подтверждения оплаты необходимо дождаться уведомления об изменении статуса Сделки на Ожидает исполнения.

Прикрепление вложений к Сделке

Для возможности арбитража спорных ситуаций сервису Наложка необходимы документальные подтверждения (фото, сканы документов) состояния предмета Сделки.

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

Модерация для площадок

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

Если у сотрудника Наложки имеются замечания, он переводит Сделку в статус Модерация и Сделка считается несогласованной. При этом, если дополнение Сделки влечет изменение суммы депозита, то внесенный депозит возвращается на карту Покупателя, а после согласования новых условий Покупателю придется внести депозит заново (переход к статусу Внесение депозита). А если изменения в Сделке не повлияли на сумму депозита, то Сделка после согласования условий вернется в статус, в котором Сделка находилась до перевода её в статус Модерация.

Если же замечаний нет, сотрудник отправляет Сделку в статус Ожидает исполнения.

Трекинг исполнения

Исполнение Сделки — это длительный процесс производства и/или доставки предмета Сделки. Отслеживание прогресса исполнения Сделки реализуется внешней (относительно Безопасной Сделки) системой трекинга.

Ограничение

На данный момент реализован единственный трекер — доставка отправлений службой СДЭК.

В дальнейшем список трекеров будет расширяться.

Для перехода Сделки из статуса Ожидает исполнения в Исполнение необходимо получение информации от системы трекинга. А для этого необходимо привязать к Сделке трекинг-код.

В случае доставки товара, это будет номер отправления, полученный от службы доставки. Создание накладной для отправления может осуществляться способом, уже существующим на момент подключения Безопасной Сделки от Наложки. Если же автоматизация расчета доставки и создания накладных не реализована, мы предлагаем рассмотреть наш функционал Агрегатора Служб Доставки.

Ошибочно привязанный трекинг-код можно через API отвязать от Сделки и привязать правильный.

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

Когда появляется прогресс исполнения в системе трекинга сервис Безопасных Сделок переводит Сделку в статус Исполнение.

После того, как система трекинга определила финальный этап исполнения (в случае доставки - это "груз получен"), трекинг считается завершенным.

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

Успешное завершение Сделки

После успешной приемки предмета Сделки, она переходит в статус Расчет при завершении и запускается процедура перевода депозита Продавцу.

По окончании процедуры выплаты Сделка переходит в статус Завершена.

Отмена Сделки

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

Если Сделка отменяется на первоначальном этапе, до внесения депозита, то никаких издержек ни одна из сторон не несет и Сделка сразу попадает в статус Отменена.

Если на момент отмены Сделки депозит уже внесен, то Сделка переходит в статус Запрошена отмена и запускается процедура возврата депозита. При этом, если отмена инициирована Покупателем и Продавец понес издержки по некоторым позициям из списка сопутствующих услуг, то из депозита будет удержана сумма издержек в пользу Продавца. Если же отмена инициирована Продавцом, то депозит Покупателю будет возвращен полностью, а все издержки по Сделке возлагаются на Продавца.

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

По окончании процедуры возврата депозита Сделка переходит в статус Отменена.

Отмена Сделки в интернет-магазине

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

При отмене заказа администратором ИМ или покупателем через страницы ИМ, от сайта ИМ должен придти API-запрос на отмену Сделки. Если при API-запросе отмены Сделки произошла ошибка Сервиса Наложка или Сервис был недоступен, отмена заказа не блокируется.

Если Сделка отменяется покупателем через страницы Наложки, в ИМ придет уведомление через вебхук и заказ в ИМ должен быть отменен, а администратор ИМ должен быть уведомлен об этом.

Споры и арбитраж

В статусе Исполнение возможно открытие Спора. Например, при несоблюдении Продавцом сроков исполнения Сделки, Покупатель может открыть Спор. А в Сделке покупки товара с доставкой, например, Спор будет открыт при отказе Покупателя принять товар.

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

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

API Безопасных Сделок

API Безопасных Сделок позволяет осуществить:

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

Для работы с API Безопасных Сделок используются следующие адреса:

Изменения в API описаны ниже под заголовком Изменения в API.

Ниже приведены доступные методы API с подробным пояснением:

Изменения в API

Версия 1.2.0

  • изменен порядок смены статусов сделки;
  • удален метод присоединения участника к сделке POST /deals/{id}/join, при создании сделки подразумевается, что оба участника согласны с условиями сделки;
  • контактные данные покупателя можно передавать при создании сделки, а не в момент перехода на страницу оплаты;
  • в структуру сделки добавлены поля: status_updated_by, status_updated_comment, workflow;
  • ссылка страницы для оплаты заказа изменена с https://cabinet.nalogka.ru/deals/{deal_id}/payment на https://safebuy.nalogka.ru/{deal_id}/payment

Версия 1.1.0

  • документация дополнена пояснениями о том, кому доступны те или иные действия;
  • список сделок теперь можно фильтровать и по дате обновления статуса status_updated_at;
  • детали сделки доступны площадке без указания инициатора запроса;
  • в структуре депозита платежи payments заменены на транзакции transactions, которые более детально отражают действия со средствами (холдирование, списание со счета, возврат, выплата и т.п.);
  • список событий сделки доступен площадке без указания инициатора запроса;
  • в структуре данных события сделки поле occured_at (момент возникновения события) переименовано в occurred_at;
  • добавлена возможность прикрепления файлов-вложений к сделке POST /deals/{id}/add-attachments;
  • удалены методы POST /deals/{id}/done и POST /deals/{id}/undone;
  • добавлен метод явного подтверждения приемки предмета сделки заказчиком/покупателем POST /deals/{id}/confirm-acceptation;
  • при обновлении сделки невозможно изменить привязку участника сделки;
  • добавлен метод присоединения участника к сделке POST /deals/{id}/join;
  • добавлен метод остановки исполнения сделки POST /deals/{id}/performing-stop (возвращает сделку в статус ожидает исполнения);
  • введено понятие трека исполнения сделки, добавлены методы управления треком исполнения: добавление/замена PUT /deals/{id}/performing-track, получение GET /deals/{id}/performing-track и удаление DELETE /deals/{id}/performing-track.