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