لغو سفارش API وقتی مشتری لینک نادرست فرستاده است

ابتدا بررسی کنید که آیا سفارش به تأمین‌کننده ارسال شده است یا نه

لینک نادرست همیشه به این معنا نیست که تبلیغ уже شروع شده است. در پایگاه داده شخصی شما سفارش ممکن است ایجاد شده باشد، اما هنوز از طریق API ارسال نشده باشد. در این حالت لغو فقط به منطق پردازش شما بستگی دارد: کافی است سفارش را لغوشده علامت بزنید، پرداخت خودکار را متوقف کنید و ارسال را آغاز نکنید.

شناسه سفارش، زمان ایجاد، لینک، نوع خدمت و گزارش درخواست‌های API را بررسی کنید. اگر درخواست به تأمین‌کننده ارسال نشده است، سفارش جدیدی روی سفارش قبلی ایجاد نکنید. ابتدا لغو درخواست اصلی را ثبت کنید، وگرنه مشتری ممکن است دو اجرا روی دو لینک مختلف دریافت کند.

وضعیت سفارش را نزد تأمین‌کننده مشخص کنید

اگر درخواست API قبلاً ارسال شده است، وضعیت فعلی را از تأمین‌کننده بخواهید. نام وضعیت‌ها متفاوت است، اما معمولاً می‌توان آن‌ها را به چند گروه تقسیم کرد: در انتظار، در حال پردازش، اجرای جزئی، تکمیل و لغو. برای تصمیم‌گیری، وضعیت در پنل شما مهم نیست، بلکه پاسخ طرفی که خدمت را اجرا می‌کند اهمیت دارد.

• در انتظار: سفارش ممکن است هنوز قابل لغو باشد.
• در حال پردازش: توقف گاهی ممکن است، اما بخشی از حجم ممکن است قبلاً اجرا شده باشد.
• اجرای جزئی: فقط باقی‌مانده قابل لغو است، اگر تأمین‌کننده از چنین عملیاتی پشتیبانی کند.
• تکمیل: اصلاح لینک از طریق لغو دیگر ممکن نیست.

عیب بررسی فقط بر اساس وضعیت داخلی این است که ممکن است با تأخیر به‌روزرسانی شود. به آخرین پاسخ API و زمان دریافت آن تکیه کنید.

سفارش را پیش از شروع خدمت لغو کنید

برای سفارشی که در صف است، از متد لغو استفاده کنید، اگر در مستندات تأمین‌کننده پیش‌بینی شده باشد. شناسه‌ای را که هنگام ایجاد سفارش دریافت کرده‌اید ارسال کنید، نه شماره داخلی خود را، اگر این دو مقدار متفاوت هستند. پاسخ کامل را ذخیره کنید: کد عملیات، وضعیت، متن خطا و زمان درخواست.

تا زمانی که API لغو را تأیید نکرده است، سفارش را لغوشده ندانید. پاسخ پذیرش درخواست و توقف واقعی خدمت می‌توانند دو رویداد متفاوت باشند. در برخی یکپارچه‌سازی‌ها ابتدا تأیید پذیرش می‌آید و وضعیت نهایی بعداً تغییر می‌کند.

عیب این گزینه این است که تأمین‌کننده ممکن است فرصت نکند سفارش را از پردازش خارج کند. در این صورت لغو رد می‌شود یا فقط برای بخش اجرانشده اعمال می‌شود.

لینک سفارش ایجادشده را بدون تأیید تغییر ندهید

در بسیاری از APIها لینک در لحظه ایجاد سفارش تثبیت می‌شود. تلاش برای ارسال لینک جدید با همان شناسه ممکن است نادیده گرفته شود، به‌عنوان خطا پردازش شود یا وضعیت غیرقابل پیش‌بینی ایجاد کند. انتظار نداشته باشید که ارسال مجدد درخواست به‌طور خودکار آدرس را جایگزین کند.

اگر مستندات صراحتاً ویرایش لینک را پشتیبانی می‌کند، ابتدا مطمئن شوید که خدمت هنوز شروع به اجرا نکرده است. سپس مقدار قدیمی، مقدار جدید و پاسخ API را ذخیره کنید. این در صورت اختلاف با مشتری یا تأمین‌کننده به کار می‌آید.

عیب ویرایش این است که حتی با وجود متد در دسترس، بخشی از اقدامات ممکن است پیش از به‌روزرسانی به صفحه قدیمی رفته باشد. لینک اصلاح‌شده نتیجه‌ای را که قبلاً دریافت شده جابه‌جا نمی‌کند.

در صورت اجرای جزئی چه باید کرد

وقتی تبلیغ روی لینک نادرست شروع شده است، لغو باقی‌مانده را درخواست کنید. در مکاتبه با تأمین‌کننده شناسه سفارش، لینک نادرست، لینک صحیح، وضعیت فعلی و زمان کشف خطا را ذکر کنید. جزئیات درخواست را چند بار تغییر ندهید: این کار بررسی تاریخچه را دشوار می‌کند.

اگر لغو باقی‌مانده تأیید شد، حجمی را که قبلاً اجرا شده ثبت کنید. بازگشت وجه، اگر در قوانین تأمین‌کننده پیش‌بینی شده باشد، معمولاً فقط به بخش اجرانشده مربوط می‌شود. حجم اجراشده را نمی‌توان از نظر فنی از یک کانال، ویدیو یا پروفایل به دیگری منتقل کرد.

عیب لغو جزئی واضح است: مشتری ممکن است قبلاً نتیجه را در صفحه نادرست دریافت کرده باشد و بودجه این بخش از سفارش همیشه بازگردانده نمی‌شود.

اگر سفارش تکمیل شده است، اصلاح را در قالب درخواست جداگانه ثبت کنید

سفارش تکمیل‌شده معمولاً از طریق API قابل لغو نیست. در چنین شرایطی رکورد را حذف نکنید و لینک را در تاریخچه تغییر ندهید: داده‌های اولیه برای تطبیق لازم هستند. بررسی کنید که آیا خدمت واقعاً به آدرس اشتباه ارائه شده است یا فقط با تأخیر نمایش داده می‌شود.

سپس دو راه وجود دارد: مذاکره درباره جبران خسارت با تأمین‌کننده طبق قوانین او، یا ایجاد سفارش جدید روی لینک صحیح پس از هماهنگی با مشتری. سفارش جدید باید شناسه، مبلغ و یادداشت مشخص درباره دلیل ایجاد جداگانه داشته باشد.

عیب اجرای جدید این است که بودجه اضافی می‌طلبد و جبران خسارت برای خدمت تکمیل‌شده ممکن است در دسترس نباشد.

پیش از اجرای مجدد وضعیت را به مشتری اطلاع دهید

اگر لینک متعلق به مشتری است و خطا از طرف او آمده، جایگزینی را به تشخیص خودتان اجرا نکنید. لینک اولیه، وضعیت سفارش، امکان لغو و پیامدهای هر گزینه را برایش بفرستید. این موضوع به‌ویژه وقتی بخشی از خدمت قبلاً انجام شده اهمیت دارد.

• اگر سفارش ارسال نشده است، لینک صحیح را بخواهید و لغو درخواست قبلی را تأیید کنید.
• اگر سفارش در صف است، اطلاع دهید که درخواست لغو ارسال شده اما منتظر پاسخ تأمین‌کننده هستید.
• اگر اجرای جزئی وجود دارد، ذکر کنید که فقط باقی‌مانده قابل توقف است.
• اگر سفارش تکمیل شده است، درباره اجرای جدید یا راه‌حل دیگر توافق کنید.

عیب هماهنگی طولانی این است که در این مدت سفارش در صف ممکن است به پردازش برود. بنابراین ابتدا درخواست فنی لغو را ارسال کنید، اگر چنین امکانی وجود دارد، و سپس اقدامات بعدی را روشن کنید.

لاگ‌ها و شواهد عملیات را ذخیره کنید

برای هر سفارش مورد اختلاف، لینک اولیه مشتری، تاریخ دریافت، شماره داخلی، شناسه نزد تأمین‌کننده، درخواست‌ها و پاسخ‌های API را ذخیره کنید. اگر مشتری لینک را در مکاتبه فرستاده است، پیام را در کارت سفارش با نسخه ویرایش‌شده جایگزین نکنید مگر اینکه اصل آن حفظ شود.

به‌طور جداگانه ثبت کنید چه کسی و چه زمانی خطا را متوجه شده است. این کمک می‌کند داده‌های نادرست ارسال‌شده از خطای مدیر، فرم سفارش یا جایگذاری خودکار تفکیک شود. در تماس‌های مکرر با تأمین‌کننده از یک زنجیره داده استفاده کنید تا تناقضی پیش نیاید.

عیب نگهداری دستی لاگ‌ها زمان‌بر بودن آن است. اما بدون تاریخچه، تأیید وضعیت لغو و توضیح به مشتری درباره اینکه چرا وجه به‌طور کامل بازگردانده نمی‌شود دشوارتر است.

پردازش خطا در یکپارچه‌سازی را بررسی کنید

پس از چنین موردی بررسی کنید که سیستم چگونه لینک‌ها را به API ارسال می‌کند. خطا ممکن است نه فقط از سوی مشتری باشد: گاهی فرم پارامترها را کوتاه می‌کند، مقدار قدیمی را از کش جایگزین می‌کند، لینک پروفایل را به‌جای لینک انتشار می‌پذیرد یا لینکی با کاراکترهای اضافی را عبور می‌دهد.

پیش از ایجاد سفارش بررسی فرمت را اضافه کنید: تطابق با پلتفرم، نوع خدمت و شیء مورد انتظار. برای خدمات ویدیویی، سیستم باید لینک ویدیو را از لینک کانال تشخیص دهد و برای شبکه‌های اجتماعی، پروفایل را از یک انتشار جداگانه. بررسی صحت لینک را تضمین نمی‌کند، اما بخشی از خطاهای واضح را فیلتر می‌کند.

بهتر است ارسال سفارش را با یک بررسی کوتاه داده از ایجاد آن جدا کنید. عیب این مرحله اضافی این است که سفارش فوراً به اجرا نمی‌رود، اما زمان پیدا می‌کنید تا آدرس نادرست را متوجه شوید.

سناریوی لغو روشن برای تیم تنظیم کنید

یک رویه واحد بنویسید: توقف ارسال خودکار، بررسی وضعیت نزد تأمین‌کننده، ارسال لغو، ذخیره پاسخ، اطلاع به مشتری و تنها پس از آن هماهنگی برای اجرای مجدد. چنین سناریویی برای تشریفات نیست، بلکه برای این است که کارمندان مختلف اقدامات متناقض انجام ندهند.

دسترسی به لغو را بدون محدودیت مجوز و گزارش اقدامات ندهید. اگر چند مدیر همزمان روی یک سفارش کار کنند، یکی ممکن است لغو درخواست کند و دیگری پیش از دریافت پاسخ جایگزین ایجاد کند. این امر به هزینه‌های اضافی و سردرگمی در محاسبات منجر می‌شود.

عیب سناریوی سخت‌گیرانه انعطاف کمتر در موارد فوری است. اما برای سفارش‌های API، کنترل اینکه کدام لینک واقعاً به اجرا رفته مهم‌تر از سرعت یک اقدام خاص است.