آنچه فروشنده در واقع می‌بیند
یک خرید عامل‌محور در لایهٔ موجودی غیرعادی به نظر نمی‌رسد. کالا رزرو می‌شود، سبد قیمت‌گذاری می‌شود، سفارش ایجاد می‌شود، و یک مجوز پرداخت از همان مسیری می‌رسد که هر تراکنش کارت‌حاضر یا کارت‌غایب دیگری. در لایهٔ پرداخت، سفارش عادی است. در لایهٔ تقلب، عادی نیست.
نشستی که سفارش را تولید کرده، شکل خودکارسازی دارد: یک کلاینت headless، بدون حرکت ماوس، بدون زمان توقف در صفحات محصول، آهنگی از درخواست‌ها که شبیه مرور کردن نیست، و آدرس ارسالی که ممکن است با پیش‌فرض تاریخی حساب متفاوت باشد. سیستم‌های تقلب آموزش دیده‌اند که این شکل را به‌عنوان یک سیگنال در نظر بگیرند. در این کار اشتباه نمی‌کنند. همان اثر انگشت نشست توسط ابزارهای credential stuffing و ربات‌های اسکرپینگی که سفارش آزمایشی ثبت می‌کنند تولید می‌شود.
بنابراین فروشنده دو خوانش متناقض از یک رویداد دارد. اعتبار پرداخت معتبر است. نشست غیرعادی است. هیچ فیلدی در سابقهٔ سفارش وجود ندارد که بگوید کاربر این خرید را به یک فرایند ثالث واگذار کرده، و هیچ فیلدی که یک عامل واگذارشده را از مهاجمی که کارتی را دزدیده و آن را با یک اسکریپت می‌چرخاند، متمایز کند.
وقتی تنها سیگنال موجود شکل نشست باشد، مسدود کردن پیش‌فرض عقلانی است. این یک موضع سیاستی علیه عامل‌ها نیست. این رفتار سیستمی است که هیچ ادعایی که بتواند راستی‌آزمایی کند به آن داده نشده است.
رضایت به سابقه نیاز دارد، نه به چک‌باکس
یک کلید تنظیمات در حساب فروشنده یک سابقهٔ رضایت نیست. هیچ اتصال به‌ازای‌هر‌تراکنش، هیچ دامنه، و هیچ انقضایی ندارد. می‌گوید کاربری زمانی چیزی را فعال کرده؛ نمی‌گوید این سفارش مجاز به انجام چه کاری بوده است.
واگذاری باید یک دامنهٔ امضاشده تولید کند. دست‌کم دامنه باید این‌ها را مقید کند:
- فروشنده یا ردهٔ فروشنده‌ای که به آن اعمال می‌شود
- رده یا دستهٔ کالایی که عامل می‌تواند خریداری کند
- سقف هزینه، به‌ازای هر تراکنش و به‌ازای هر دوره
- انقضا، که پس از آن دامنه بی‌اثر است
- هویت عاملی که این واگذاری را در اختیار دارد
دامنه همراه سفارش سفر می‌کند. وقتی اختلافی پیش می‌آید، فروشنده می‌تواند آن را با تطبیق دامنه با سفارش حل کند، نه با بازسازی نشست از لاگ‌ها. این تمایز مهم است چون بازسازی نشست کار پزشکی‌قانونی است: کند است، احتمالی است، و به‌جای پاسخ، بحث تولید می‌کند.
دامنه حالت شکست را هم تغییر می‌دهد. عاملی که از سقفش فراتر می‌رود با یک قاعده رد می‌شود، نه با یک heuristic تقلب. عاملی که خارج از ردهٔ کالایی‌اش خرید می‌کند با یک قاعده رد می‌شود. آن‌گاه سیستم تقلب فروشنده آزاد است که به‌دنبال نفوذ واقعی بگردد، نه شکل کلی خودکارسازی.
دفتر کل کجا زندگی می‌کند
شبکه‌های پرداخت از قبل مسیرهای مجوزدهی را اداره می‌کنند که ادعاهای ساختاریافته را بین پذیرنده، صادرکننده و فروشنده حمل می‌کنند. دامنهٔ واگذاری یک ادعای اضافی روی همان پیام است، نه یک شبکهٔ جدید. پرسش عملی این نیست که آیا مسیری وجود دارد، بلکه این است که مسیر راستی‌آزمایی چه شکلی است.
فروشندگان باید یک واگذاری را بدون اعتماد به ادعای فروشندهٔ عامل راستی‌آزمایی کنند. یعنی دامنه باید توسط چیزی امضا شده باشد که فروشنده بتواند مستقلاً بررسی کند، و نتیجهٔ راستی‌آزمایی باید در کنار مجوز ثبت شود، نه در سیستم فروشندهٔ عامل نگه داشته شود. اگر تنها راه تأیید واگذاری فراخوانی API عامل باشد، فروشنده یک مسئلهٔ اعتماد را با مسئلهٔ دیگری جایگزین کرده است.
این بده‌بستان واقعی است و ارزش دارد صادقانه بیان شود. افزودن یک دامنهٔ امضاشده به پیام مجوز، پیچیدگی payload را افزایش می‌دهد، هماهنگی میان طرف‌هایی را می‌طلبد که چرخه‌های انتشار مشترک ندارند، و ردهٔ جدیدی از شکست ایجاد می‌کند: سفارش معتبری که رد می‌شود چون راستی‌آزمایی دامنه timeout خورده یا چون کلید امضا چرخیده است. فروشندگان به رفتار تعریف‌شده‌ای برای شکست راستی‌آزمایی نیاز خواهند داشت، و پیش‌فرض ایمن غالباً رد کردن خواهد بود. این یک هزینه است، و از هزینهٔ رسیدگی به هر سفارش عامل به‌عنوان یک پروندهٔ تقلب بالقوه کمتر است.
مرجوعی‌ها و chargebackها به همان سابقه نیاز دارند. بدون آن، فرایند اختلاف به heuristic تنزل می‌کند: فروشنده استدلال می‌کند که نشست خودکار به نظر می‌رسید، مشتری استدلال می‌کند که خرید را مجاز کرده، و هیچ
75.jpg)
این برای سازندگان عامل چه معنایی دارد
اعتبارهای هزینهٔ دامنه‌دار پیش‌نیاز تجارت‌اند، نه مزیت رقابتی. عاملی که نمی‌تواند دامنهٔ واگذاری‌اش را ارائه دهد، توسط هر فروشندهٔ جدی به‌عنوان یک ربات تلقی می‌شود، چون از سمت فروشنده از یکی قابل تشخیص نیست. این قفل شدن خصومت با عامل‌ها نیست؛ نبود ادعایی است که فروشندگان بتوانند راستی‌آزمایی کنند.
این جابه‌جا می‌کند که تلاش مهندسی کجا می‌رود. مسائل جالب دیگر فقط برنامه‌ریزی وظیفه و استفاده از ابزار نیستند. شامل این‌ها می‌شوند:
- چگونه یک دامنه صادر و به یک قصد کاربر مشخص مقید می‌شود
- چگونه یک عامل اثبات می‌کند که در لحظهٔ خرید درون دامنه عمل می‌کند
- چگونه دامنه وقتی کاربر نظرش را تغییر می‌دهد باطل می‌شود
- چگونه تحویل جزئی، بازپرداخت‌ها و جانشینی‌ها مدیریت می‌شوند وقتی دامنهٔ اصلی دیگر با سفارش حاصل مطابقت ندارد
هیچ‌یک از این‌ها با یک لایهٔ خودکارسازی مرورگر بهتر حل نمی‌شود. این‌ها مسائل مجوزدهی‌اند، و ایجاب می‌کنند که عامل در یک پروتکل مجوزدهی مشارکت کند، نه اینکه صرفاً یک فرم پرداخت را پر کند.
یک اثر مرتبهٔ دوم هم وجود دارد. وقتی دامنه‌ها وجود داشته باشند، فروشندگان می‌توانند ترافیک عامل را متفاوت قیمت‌گذاری و مسیریابی کنند، چون سفارش‌های واگذارشده ریسک متفاوتی از نشست‌های ناشناس دارند. این یک تصمیم تجاری است، اما تنها زمانی در دسترس است که ادعای زیربنایی وجود داشته باشد. بدون آن، تنها اهرم دکمهٔ مسدود کردن است.
عدم تطابق، بازگو شده
خرده‌فروشانی که عامل‌های خرید را مسدود می‌کنند، به یک عدم تطابق مجوزدهی واکنش نشان می‌دهند: پرداخت عامل‌محور یک اعتبار پرداخت معتبر با سابقهٔ رضایت متناظر صفر تولید می‌کند. سیستم‌های موجودی، قیمت‌گذاری و تحویل مشکل نیستند. مشکل این است که یک خرید و یک نفوذ، شواهد یکسانی را به سیستم‌هایی ارائه می‌دهند که تصمیم می‌گیرند سفارشی را بپذیرند یا نه.
راه‌حل این نیست که از فروشندگان بخواهیم بیشتر به عامل‌ها اعتماد کنند. این است که به عامل‌ها چیزی برای ارائه بدهیم: یک واگذاری امضاشده، دامنه‌دار و منقضی‌شونده که همراه سفارش سفر می‌کند و بدون اعتماد به فروشندهٔ عامل قابل راستی‌آزمایی است. تا وقتی این وجود نداشته باشد، مسدود کردن پیش‌فرض عقلانی می‌ماند، و عامل‌هایی که اول عرضه می‌شوند آن‌هایی خواهند بود که می‌توانند اثبات کنند مجاز به انجام چه کاری بودند.