Скасування API-замовлення, якщо клієнт надіслав неправильне посилання

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

Неправильне посилання не завжди означає, що просування вже запущено. У власній базі замовлення може бути створене, але ще не відправлене через API. У цьому випадку скасування залежить лише від вашої логіки обробки: достатньо позначити замовлення скасованим, зупинити автоплатіж і не запускати передачу.

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

Визначте статус замовлення у постачальника

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

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

Недолік перевірки лише за внутрішнім статусом — він може оновлюватися із затримкою. Орієнтуйтеся на останню відповідь API та час її отримання.

Скасуйте замовлення до запуску послуги

Для замовлення в черзі використовуйте метод скасування, якщо він передбачений документацією постачальника. Передавайте ідентифікатор, отриманий під час створення замовлення, а не ваш внутрішній номер, якщо це різні значення. Збережіть повну відповідь: код операції, статус, текст помилки та час запиту.

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

Недолік цього варіанта в тому, що постачальник може не встигнути зняти замовлення з обробки. Тоді скасування поверне відмову або спрацює лише для невиконаної частини.

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

У багатьох API посилання фіксується в момент створення замовлення. Спроба передати нове посилання з тим самим ідентифікатором може бути проігнорована, оброблена як помилка або створити непередбачуваний стан. Не розраховуйте, що повторне надсилання запиту автоматично замінить адресу.

Якщо документація прямо підтримує редагування посилання, спочатку переконайтеся, що послуга ще не почала виконуватися. Потім збережіть старе значення, нове значення та відповідь API. Це стане в пригоді під час спору з клієнтом або постачальником.

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

Що робити при частковому виконанні

Коли за неправильним посиланням уже почалося просування, запросіть скасування залишку. У зверненні до постачальника вкажіть ідентифікатор замовлення, неправильне посилання, коректне посилання, поточний статус і час виявлення помилки. Не змінюйте деталі звернення кілька разів: це ускладнює перевірку історії.

Якщо скасування залишку підтверджено, зафіксуйте обсяг, який уже було виконано. Повернення, якщо воно передбачене правилами постачальника, зазвичай стосується лише невиконаної частини. Виконаний обсяг не можна технічно перенести з одного каналу, ролика чи профілю на інший.

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

Якщо замовлення завершено, оформлюйте виправлення окремою заявкою

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

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

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

Повідомте клієнту про ситуацію до повторного запуску

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

• Якщо замовлення не передано, запросіть правильне посилання та підтвердьте скасування старої заявки.
• Якщо замовлення в черзі, повідомте, що скасування надіслано, але очікується відповідь постачальника.
• Якщо є часткове виконання, вкажіть, що можна зупинити лише залишок.
• Якщо замовлення завершено, узгодьте новий запуск або інший спосіб вирішення.

Недолік тривалого узгодження — за цей час замовлення в черзі може перейти в обробку. Тому спочатку надсилайте технічний запит на скасування, якщо така можливість є, а потім уточнюйте подальші дії.

Збережіть логи та докази щодо операції

Для кожного спірного замовлення зберігайте вихідне посилання від клієнта, дату отримання, внутрішній номер, ідентифікатор у постачальника, API-запити та відповіді. Якщо клієнт надіслав посилання в листуванні, не замінюйте повідомлення відредагованим варіантом у картці замовлення без збереження оригіналу.

Окремо фіксуйте, хто і коли помітив помилку. Це допомагає відокремити неправильно передані дані від помилки менеджера, форми замовлення або автоматичної підстановки. При повторних зверненнях до постачальника використовуйте один ланцюжок даних, щоб не виникло суперечностей.

Недолік ручного ведення логів — він займає час. Але без історії складніше підтвердити статус скасування та пояснити клієнту, чому кошти не можна повернути повністю.

Перевірте обробку помилок в інтеграції

Після такого випадку перевірте, як система передає посилання в API. Помилка може з'явитися не лише через клієнта: іноді форма обрізає параметри, підставляє старе значення з кешу, приймає посилання на профіль замість посилання на публікацію або пропускає посилання із зайвими символами.

Додайте перевірку формату до створення замовлення: відповідність майданчику, типу послуги та очікуваному об'єкту. Для послуг на відео система повинна відрізняти посилання на ролик від посилання на канал, а для соціальних мереж — профіль від окремої публікації. Перевірка не гарантує правильність посилання, але відсіює частину явних помилок.

Передачу замовлення краще відокремити від його створення короткою перевіркою даних. Недолік додаткового кроку — замовлення піде в роботу не миттєво, зате у вас з'явиться час помітити неправильну адресу.

Налаштуйте зрозумілий сценарій скасування для команди

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

Не давайте доступ до скасування без обмеження прав і журналу дій. Якщо кілька менеджерів одночасно працюють з одним замовленням, один може запросити скасування, а інший — створити заміну до отримання відповіді. Це призводить до зайвих витрат і плутанини в розрахунках.

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