فرض کنید به یک دستیار هوش مصنوعی میگویید: «برای پنجشنبه یک بلیت رفتوبرگشت پیدا کن. پرواز صبح باشد، قیمت از ۱۵ میلیون تومان بیشتر نشود و فقط از این سه شرکت خرید کن. اگر همه شرایط برقرار بود، پرداخت را انجام بده.»
این درخواست چند کار را در یک جمله کنار هم قرار میدهد. عامل باید گزینهها را پیدا کند، قیمت و شرایط را بسنجد، یکی را انتخاب کند و وارد فرایند پرداخت شود. ممکن است در پایان از شما تأیید بگیرد یا بر اساس اختیاری که از قبل تعیین کردهاید، خرید را تکمیل کند.
تا همین اواخر، بیشتر دستیارهای هوش مصنوعی در مرحله پیشنهاد متوقف میشدند. اکنون شبکههای پرداخت، شرکتهای فناوری و ارائهدهندگان خدمات مالی در حال ساخت زیرساختی هستند که به عامل اجازه میدهد وارد بخش اجرایی خرید شود. این مسیر هنوز در مرحله شکلگیری است. نمونههای واقعی و آزمایشی وجود دارند، استانداردهای متعددی در حال توسعهاند و بعضی تجربههای اولیه نیز پس از اجرا تغییر مسیر دادهاند.
در موج نخست، تسویه همچنان عمدتاً بر ریلهای موجود انجام میشود. تغییر اصلی در لایههای بالاتر رخ میدهد: قصد کاربر چگونه به دستور قابلاجرا تبدیل میشود، عامل چه اختیاری دارد، فروشنده چگونه آن را میشناسد و چه مدرکی از مجوز کاربر باقی میماند.
پرداخت عاملمحور چیست؟
پرداخت عاملمحور (Agentic Payment) تراکنشی است که یک عامل هوش مصنوعی آن را از طرف فرد یا سازمان آماده یا آغاز میکند. عامل هدف را دریافت میکند، چند مرحله را پیش میبرد و در محدوده اختیار تعریفشده عمل میکند. میزان استقلال عامل میتواند از پیشنهاد یک گزینه تا تکمیل خرید متفاوت باشد.
این مفهوم بخشی از تجارت عاملمحور (Agentic Commerce) است. تجارت عاملمحور کل سفر خرید را پوشش میدهد: کشف نیاز، جستوجوی محصول، مقایسه، انتخاب، پرداخت، پیگیری سفارش و گاهی مرجوعکردن کالا. پرداخت عاملمحور روی بخشی تمرکز دارد که قصد خرید به تعهد مالی و انتقال پول میرسد.
سه سطح رایج را میتوان از هم جدا کرد:
در پرداخت دورهای یا برداشت خودکار، زمان، مبلغ یا دریافتکننده معمولاً از پیش تعریف شده است. در پرداخت تفویضشده، عامل میتواند هدف را تفسیر کند، شرایط متغیر را بسنجد و از میان چند مسیر تصمیم بگیرد. همین قدرت تصمیمگیری به کنترلهای دقیقتری نیاز دارد.
از خواسته کاربر تا ثبت یک تراکنش چه اتفاقی میافتد؟
یک پرداخت عاملمحور را میتوان در هفت مرحله دید. این مراحل ممکن است در محصولات مختلف شکل متفاوتی داشته باشند، اما پرسشهای اصلی تقریباً ثابتاند.
۱. قصد کاربر ثبت میشود
کاربر یک هدف را بیان میکند: خرید بلیت، تمدید یک خدمت، سفارش مواد اولیه یا پرداخت صورتحساب. این هدف باید به شرایط روشن تبدیل شود. مبلغ، بازه زمانی، نوع کالا، فروشندگان مجاز و شرایط نیازمند تأیید از جمله این محدودیتها هستند.
۲. حدود اختیار تعیین میشود
عامل باید بداند کدام تصمیمها را میتواند مستقلاً بگیرد و در چه نقطهای باید کار را متوقف کند. برای مثال، خرید تا سقف مشخص مجاز است، تغییر تاریخ پرواز یا انتخاب فروشندهای خارج از فهرست به تأیید دوباره نیاز دارد.
۳. عامل گزینهها را پیدا و ارزیابی میکند
عامل به داده محصول، قیمت، موجودی، شرایط ارسال، سیاست بازگشت و اطلاعات فروشنده نیاز دارد. هرچه این دادهها ساختیافتهتر و بهروزتر باشند، احتمال تصمیم ناقص یا اشتباه کمتر میشود.
۴. فروشنده هویت عامل را بررسی میکند
رفتار یک عامل خرید میتواند از نگاه وبسایت فروشنده شبیه فعالیت یک ربات مخرب باشد. فروشنده باید تشخیص دهد عامل معتبر است، از طرف چه کسی عمل میکند و چه مجوزی دارد. Visa در «پروتکل عامل مورد اعتماد» (Trusted Agent Protocol) از امضای دیجیتال برای اثبات هویت عامل و ارتباط آن با مجوز کاربر استفاده میکند. مستندات Visa
۵. ابزار پرداخت بهصورت محدود در اختیار فرایند قرار میگیرد
دادن اطلاعات کامل کارت یا حساب به عامل، دامنه خطر را افزایش میدهد. یکی از رویکردهای در حال توسعه، استفاده از توکن پرداخت محدود است. در مستندات Stripe، «توکن پرداخت مشترک» (Shared Payment Token) میتواند به فروشنده دسترسی محدود به روش پرداخت مشتری بدهد. این توکن برای فروشنده مشخص، حداکثر مبلغ، ارز و زمان انقضا تنظیم میشود. مستندات Stripe
۶. پرداخت روی ریل مالی انجام میشود
پس از تأیید هویت و اختیار، تراکنش میتواند از مسیر کارت، حساب، کیف پول یا دیگر ریلهای پشتیبانیشده عبور کند. در این مرحله بسیاری از سازوکارهای شناختهشده پرداخت، مانند کنترل تقلب، احراز هویت تکمیلی و پذیرش یا رد تراکنش، همچنان کاربرد دارند.
۷. رسید و سابقه تصمیم باقی میماند
رسید مالی، نتیجه تراکنش را ثبت میکند. رسیدگی به اختلاف به اطلاعات بیشتری نیاز دارد: قصد کاربر، حدود اختیار، گزینه انتخابشده و مجوز پرداخت. ارتباط این اطلاعات با نتیجه تراکنش، ردپایی قابلحسابرسی ایجاد میکند.
زیرساختهای تازه هرکدام چه مسئلهای را حل میکنند؟
نامهای اختصاری فراوان میتوانند تصویر موضوع را پیچیده کنند. هر کدام از پروتکلها و ابزارهای کنونی، بخشی از سفر خرید را هدف گرفتهاند:
این فهرست نشان میدهد هنوز یک استاندارد مسلط شکل نگرفته است. در عین حال، اجزای مسئله تا حد زیادی روشن شدهاند: عامل باید شناخته شود، قصد کاربر باید قابل اثبات باشد، دسترسی به ابزار پرداخت باید محدود بماند و نتیجه هر اقدام باید ثبت شود.
جهان از آزمایش پرداخت عاملمحور به کجا رسیده است؟
تا اوت ۲۰۲۶، شواهد عمومی تصویری ترکیبی ارائه میکنند. تراکنشهای واقعی انجام شدهاند و ابزارهای فنی در دسترس توسعهدهندگان قرار گرفتهاند. بسیاری از تجربهها همچنان در پایلوت، نسخه محدود یا مرحله توسعه استاندارد قرار دارند.
پرداخت در محیط گفتوگویی و بازگشت به وبسایت فروشنده
OpenAI در سپتامبر ۲۰۲۵ «خرید فوری» (Instant Checkout) را با همکاری Stripe معرفی کرد. کاربر میتوانست در ChatGPT محصول را پیدا کند و پس از تأیید مبلغ، اطلاعات ارسال و روش پرداخت، خرید را در همان محیط تکمیل کند. در طراحی اولیه، کاربر هر مرحله را صریحاً تأیید میکرد و توکن پرداخت برای مبلغ و فروشنده مشخص صادر میشد. معرفی اولیه OpenAI
این مسیر ثابت نماند. OpenAI در مارس ۲۰۲۶ اعلام کرد نسخه اولیه خرید فوری انعطاف مورد انتظار را برای فروشندگان فراهم نکرده است. تمرکز جدید بر کشف محصول و هدایت کاربر به تجربه پرداخت متعلق به فروشنده قرار گرفت. در وضعیت فعلی اعلامشده، کاربران محصول را در ChatGPT پیدا و ارزیابی میکنند و خرید در وبسایت یا اپلیکیشن فروشنده تکمیل میشود. بهروزرسانی OpenAI
این تغییر مسیر یک نکته مهم دارد: موفقیت این مدل به چند عامل وابسته است. کوتاهشدن مسیر خرید، کنترل فروشنده بر تجربه مشتری، عملیات سفارش، بازگشت کالا و رابطه پس از خرید همگی بر طراحی اثر میگذارند.
تراکنشهای واقعی در محیط کنترلشده
Visa در دسامبر ۲۰۲۵ اعلام کرد با شرکای خود صدها تراکنش آغازشده بهوسیله عامل را در محیطهای کنترلشده اجرا کرده است. بیش از ۳۰ شریک در محیط آزمایشی Visa Intelligent Commerce مشغول توسعه بودند و بیش از ۲۰ عامل یا فراهمکننده عامل با این برنامه یکپارچه میشدند. نمونهها شامل خرید کالا برای مصرفکننده و پرداخت صورتحساب سازمانی در همکاری با Ramp بود. این برنامهها در نسخه بتای بسته اجرا شده بودند. گزارش Visa
Mastercard نیز در نوامبر ۲۰۲۵ نخستین تراکنش Agent Pay خارج از آمریکا را در یک پایلوت در امارات انجام داد. سناریوی اعلامشده به مشتری اجازه میداد از عامل برای جستوجو، مقایسه و خرید، از جمله رزرو بلیت سینما، استفاده کند. گزارش Mastercard
این نمونهها امکان فنی پرداخت عاملمحور را نشان میدهند. شواهد پذیرش گسترده به دادههای بیشتری درباره تعداد کاربران، حجم تراکنش، دسترسی عمومی و عملکرد خارج از محیط پایلوت نیاز دارد.
برآوردها چه میگویند و چگونه باید آنها را خواند؟
بزرگترین عددی که در گزارشهای این حوزه تکرار میشود، برآورد مککینزی است. این مؤسسه در اکتبر ۲۰۲۵ برآورد کرد که تا سال ۲۰۳۰، عاملهای هوش مصنوعی میتوانند در ۳ تا ۵ تریلیون دلار از تجارت مصرفی جهان نقش هماهنگکننده داشته باشند. برآورد بازار آمریکا نیز تا یک تریلیون دلار درآمد هدایتشده از طریق تجارت عاملمحور ذکر شده است. گزارش McKinsey
عبارت «نقش هماهنگکننده» برای فهم این عدد مهم است. این رقم به ارزش تجارتی اشاره دارد که عامل در بخشی از مسیر آن حضور دارد. نقش عامل میتواند از کشف محصول و مقایسه تا آمادهسازی سبد و اجرای تراکنش امتداد پیدا کند. بخشی از این تجارت همچنان با تأیید مستقیم انسان انجام خواهد شد.
پژوهش Visa در سال ۲۰۲۵ نیز سرنخی از نگرش مصرفکنندگان ارائه میکند. این نظرسنجی آنلاین میان ۳۷۰۰ فرد ۱۸ تا ۶۵ ساله در آمریکا، استرالیا و نیوزیلند انجام شد. حدود یکسوم پاسخدهندگان انتظار داشتند بهطور منظم از دستیارهای خرید هوش مصنوعی استفاده کنند. نزدیک به ۹ نفر از هر ۱۰ نفر خواهان شفافیت درباره شیوه تصمیمگیری عامل بودند و حدود نیمی گفته بودند در صورت از دستدادن کنترل، استفاده را متوقف میکنند. گزارش اعتماد مصرفکننده Visa
دامنه این نتایج به سه بازار و نمونهای از خریداران آنلاین دارای کارت محدود میماند. منبع گزارش نیز یک شبکه پرداخت فعال در همین بازار است. دادهها برای شناخت انتظارهای اولیه مفیدند و دامنه اعتبار آنها همان جامعه بررسیشده است.
در مجموع، برآوردها از ظرفیت اقتصادی بزرگ سخن میگویند و شواهد عملی از مرحله آغازین بازار حکایت دارند. فاصله میان این دو، به کیفیت تجربه، اعتماد مصرفکننده، آمادگی فروشندگان، قواعد حقوقی و همکاری بازیگران زیرساختی وابسته است.
مسئله اصلی بانکها و شرکتهای پرداخت چیست؟
در پرداخت دیجیتال رایج، بانک و پذیرنده معمولاً با کاربر، ابزار پرداخت و تراکنش سروکار دارند. ورود عامل یک بازیگر عملیاتی تازه به این رابطه اضافه میکند. این بازیگر میتواند اطلاعات را جمع کند، تصمیم بگیرد و دستور پرداخت را به جریان بیندازد. چند پرسش در این وضعیت اهمیت بیشتری پیدا میکنند. این پرسشها ادامه همان بحثی هستند که در حاکمیت هوش مصنوعی سازمانی و مسئولیت خطا نیز مطرح میشود.
هویت عامل
پذیرنده و صادرکننده باید بدانند کدام عامل درخواست را ارسال کرده، چه سازمانی آن را اداره میکند و اعتبار آن چگونه بررسی شده است. مفهوم «شناخت عامل» یا Know Your Agent در حال شکلگیری است، اما دامنه و قواعد مشترک آن هنوز تثبیت نشده است.
اثبات اختیار
اعتبار ابزار پرداخت باید با مدرکی از مجوز عامل همراه باشد. ارتباط میان هویت کاربر، دستور او، محدودیتهای تعیینشده و تراکنش نهایی باید روشن و قابل بررسی باشد. استانداردهایی مانند AP2 و Verifiable Intent برای ایجاد چنین سابقهای توسعه یافتهاند.
کنترل پیش از پرداخت
محدودیت مبلغ، زمان، فروشنده، نوع کالا و تعداد تراکنش باید به قواعد قابلاجرا تبدیل شوند. رویداد خارج از این حدود باید متوقف شود یا به کاربر و مدیر مربوط ارجاع داده شود. سطح کنترل نیز باید با ریسک خرید تناسب داشته باشد. تمدید یک خدمت کمهزینه و خرید یک محصول مالی به کنترلهای متفاوتی نیاز دارند.
تقلب و دستکاری عامل
سامانههای کشف تقلب معمولاً بر الگوهای رفتاری انسان و ابزار پرداخت تمرکز دارند. عامل معتبر میتواند با سرعت و الگوی متفاوتی عمل کند. از سوی دیگر، داده یا محتوای مخرب ممکن است تصمیم عامل را منحرف کند و آن را به سمت فروشنده، کالا یا پرداخت نامناسب ببرد. کنترل ریسک باید هویت عامل، سابقه مجوز و زمینه تصمیم را نیز در نظر بگیرد.
مسئولیت و امکان اعتراض
در صورت خرید اشتباه باید مشخص باشد خطا در کدام بخش رخ داده است: دستور مبهم کاربر، تصمیم عامل، داده نادرست فروشنده، اجرای ارائهدهنده پرداخت یا ضعف کنترل بانک. حل چنین اختلافی به ثبت نتیجه تراکنش، مسیر تصمیم و مجوز نیاز دارد.
حریم خصوصی و حداقلسازی داده
عامل برای شخصیسازی خرید ممکن است به سابقه مالی، موقعیت مکانی، تقویم، ترجیحات و اطلاعات رفتاری دسترسی پیدا کند. مقاله پژوهشی بانک تسویههای بینالمللی درباره هوش مصنوعی در نظام مالی، تمرکز داده نزد تعداد محدودی از شرکتهای بزرگ فناوری را یکی از عوامل تشدید نگرانیهای حریم خصوصی و امنیت سایبری میداند. مقاله BIS
در طراحی پرداخت عاملمحور، هر طرف باید تنها داده لازم برای نقش خود را دریافت کند. توکنهای محدود و افشای انتخابی اطلاعات، دو راهکار فنی در حال توسعه برای کاهش دامنه دسترسیاند.
پرداخت سازمانی و ماشینبهماشین چه مسیری را باز میکند؟
در خرید مصرفکننده، یک عامل میتواند بلیت، کالا یا خدمت را بر اساس ترجیحات فرد تهیه کند. در سازمان، دامنه کاربرد به تدارکات، پرداخت صورتحساب، خرید خدمات ابری، تمدید اشتراکها و تسویه هزینههای عملیاتی گسترش پیدا میکند.
برای مثال، عامل یک کسبوکار میتواند مصرف زیرساخت پردازشی را پایش کند و در محدوده بودجه، منابع لازم را بخرد. عامل لجستیکی میتواند هزینه حمل، دسترسی به محل بارگیری یا داده پایش زنجیره سرد را همزمان با حرکت محموله پرداخت کند. در این سناریوها، تعداد تراکنشها میتواند زیاد، مبلغ هر تراکنش کوچک و فاصله زمانی بسیار کوتاه باشد.
Mastercard در ژوئن ۲۰۲۶ خدمت Agent Pay for Machines را برای پرداختهای برنامهپذیر، پیوسته و ماشینبهماشین معرفی کرد. این خدمت بر تعیین هویت عامل، اعمال سقفها و قواعد، انجام تراکنش و تسویه روی چند نوع ریل پرداخت تمرکز دارد. شرکت در زمان معرفی اعلام کرد هنوز با شرکا در حال اعتبارسنجی کاربردهای اولویتدار و تدوین قواعد مشترک است. Mastercard
پرداخت سازمانی نیازمند پیوند اختیار عامل با سیاست خرید، مرکز هزینه، بودجه، تأییدکنندگان، قرارداد و کنترلهای مالی است. در اینجا مجوز فردی جای خود را به اختیار نهادی میدهد و هر اقدام باید با قواعد سازمان سازگار باشد.
صنعت مالی ایران چگونه این روند را بررسی کند؟
داده عمومی کافی برای سنجش میزان استفاده از پرداخت عاملمحور در ایران وجود ندارد. تفاوت زیرساخت پرداخت، مقررات، مدل احراز هویت و دسترسی به پلتفرمهای جهانی نیز انتقال مستقیم برآوردهای خارجی را نامعتبر میکند. بااینحال، میتوان آمادگی را با چند پرسش مشخص ارزیابی کرد.
۱. هویت و نقش عامل چگونه تعریف میشود؟
عامل باید شناسه قابلاعتبارسنجی داشته باشد. ارائهدهنده عامل، کاربر اصلی، دامنه فعالیت و وضعیت اعتبار آن باید برای طرفهای مجاز روشن باشد.
۲. اختیار پرداخت چگونه صادر و لغو میشود؟
بانک یا ارائهدهنده پرداخت به سازوکاری نیاز دارد که سقف مبلغ، زمان، نوع خدمت و پذیرندگان مجاز را ثبت کند. کاربر باید بتواند اختیار را مشاهده، محدود یا لغو کند.
۳. دادهها و خدمات چگونه در اختیار عامل قرار میگیرند؟
عامل برای تصمیم درست به داده دقیق و بهروز نیاز دارد. رابطهای برنامهنویسی کاربردی (API)، داده محصول و خدمت، قواعد قیمتگذاری و وضعیت تراکنش باید با کنترل دسترسی و ثبت رویداد همراه باشند. زیرساختهایی مانند پلتفرم یکپارچه هوش مصنوعی نیز امکان مدیریت مدلها و دسترسی استاندارد سامانهها به قابلیتهای هوش مصنوعی را فراهم میکنند.
۴. تراکنش عامل چگونه پایش میشود؟
مدلهای کشف تقلب باید بتوانند میان عامل مجاز، اتوماسیون عادی و رفتار مخرب تفاوت بگذارند. سرعت، توالی، زمینه و سابقه مجوز عامل بخشی از داده موردنیاز این تشخیص است.
۵. پاسخگویی چگونه میان طرفها تقسیم میشود؟
بانک، پذیرنده، ارائهدهنده عامل و کاربر باید پیش از اجرای گسترده بدانند مسئولیت هر خطا، اعتراض یا بازگشت وجه بر عهده کدام طرف است. ثبت مسیر تصمیم و مجوز، پایه این پاسخگویی خواهد بود. اجرای این قواعد به سیاستها، نقشها و فرایندهای روشن در حاکمیت داده نیاز دارد.
یک پایلوت کمریسک میتواند از پرداختهای تکراری، برگشتپذیر و دارای سقف محدود آغاز شود. معیار موفقیت آن باید فراتر از تکمیل فنی تراکنش باشد. نرخ ارجاع به انسان، خطای انتخاب، تراکنش خارج از قاعده، اعتراض، زمان حل اختلاف و رضایت کاربر نیز باید سنجیده شوند.
جمعبندی: پرداخت از یک کلیک به یک اختیار تبدیل میشود
پرداخت عاملمحور نقطه آغاز تراکنش را تغییر میدهد. کاربر میتواند بهجای انتخاب و تأیید تکتک مراحل، هدف و حدود اختیار را تعریف کند. عامل نیز در همین چارچوب جستوجو، انتخاب و اجرا را پیش میبرد.
ریلهای مالی موجود همچنان بخش بزرگی از انتقال و تسویه را انجام میدهند. لایه تازه در بالای این ریلها شکل میگیرد: هویت عامل، اثبات قصد، مجوز محدود، کنترل ریسک و سابقه قابلحسابرسی. رقابت کنونی شرکتها و شبکههای پرداخت نیز بیشتر بر ساخت همین لایه متمرکز است.
نمونههای واقعی نشان میدهند امکان فنی این مدل ایجاد شده است. تغییر مسیر بعضی تجربههای اولیه و ماهیت محدود بسیاری از پایلوتها نیز یادآوری میکند که مدل نهایی هنوز تثبیت نشده است. برای بانکها و شرکتهای پرداخت، پرسش راهبردی این است: اگر یک عامل اجازه پیدا کند از طرف مشتری یا سازمان اقدام مالی انجام دهد، چه سازوکاری تضمین میکند که هر پرداخت در محدوده اختیار، قابل توضیح و قابل پیگیری باقی بماند؟
