Отмена API-заказа, если клиент прислал неверную ссылку

Сначала проверьте, был ли заказ передан поставщику

Неправильная ссылка не всегда означает, что продвижение уже запущено. В личной базе заказ может быть создан, но ещё не отправлен по API. В этом случае отмена зависит только от вашей логики обработки: достаточно пометить заказ отменённым, остановить автоплатёж и не запускать передачу.

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

Определите статус заказа у поставщика

Если API-запрос уже отправлен, запросите актуальный статус у поставщика. Названия статусов отличаются, но обычно можно разделить их на несколько групп: ожидание, обработка, частичное выполнение, завершение и отмена. Для решения важен не статус в вашей панели, а ответ стороны, которая запускает услугу.

• Ожидание: заказ может ещё допускать отмену.
• Обработка: остановка иногда возможна, но часть объёма уже может быть запущена.
• Частичное выполнение: отменить можно только остаток, если поставщик поддерживает такую операцию.
• Завершение: исправить ссылку отменой уже нельзя.

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

Отмените заказ до запуска услуги

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

Не считайте заказ отменённым, пока API не подтвердило отмену. Ответ о принятии запроса и фактическая остановка услуги могут быть разными событиями. В некоторых интеграциях сначала приходит подтверждение принятия, а итоговый статус меняется позже.

Недостаток этого варианта в том, что поставщик может не успеть снять заказ с обработки. Тогда отмена вернёт отказ или сработает только для неисполненной части.

Не меняйте ссылку в уже созданном заказе без подтверждения

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

Если документация прямо поддерживает редактирование ссылки, сначала убедитесь, что услуга ещё не начала выполняться. Затем сохраните старое значение, новое значение и ответ API. Это пригодится при споре с клиентом или поставщиком.

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

Что делать при частичном выполнении

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

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

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

Если заказ завершён, оформляйте исправление отдельной заявкой

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

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

Недостаток нового запуска — он требует дополнительного бюджета, а компенсация за завершённую услугу может быть недоступна.

Сообщите клиенту о ситуации до повторного запуска

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

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

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

Сохраните логи и доказательства по операции

Для каждого спорного заказа сохраняйте исходную ссылку от клиента, дату получения, внутренний номер, идентификатор у поставщика, API-запросы и ответы. Если клиент прислал ссылку в переписке, не заменяйте сообщение отредактированным вариантом в карточке заказа без сохранения оригинала.

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

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

Проверьте обработку ошибок в интеграции

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

Добавьте проверку формата до создания заказа: соответствие площадке, типу услуги и ожидаемому объекту. Для услуг на видео система должна отличать ссылку на ролик от ссылки на канал, а для социальных сетей — профиль от отдельной публикации. Проверка не гарантирует правильность ссылки, но отсеивает часть явных ошибок.

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

Настройте понятный сценарий отмены для команды

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

Не давайте доступ к отмене без ограничения прав и журнала действий. Если несколько менеджеров одновременно работают с одним заказом, один может запросить отмену, а другой — создать замену до получения ответа. Это приводит к лишним расходам и путанице в расчётах.

Недостаток строгого сценария — меньше гибкости в срочных случаях. Но для API-заказов важнее не скорость отдельного действия, а контроль того, какая ссылка фактически ушла в работу.