وقتی عامل اشتباه خرید می‌کند: زنجیرهٔ اثبات قصد و بار اختلاف روی دوش پذیرنده
در خرید عاملی، بازپرداخت و چارج‌بک همچنان بر عهدهٔ پذیرنده و PSP اوست. ماندات قصد چه چیزی را ثابت می‌کند، چه چیزی را نه، و چه مدرکی باید نگه داشت.
فهرست مطالب
پاسخ کوتاه به نگرانی اصلی فروشنده‌ها این است: در خرید عاملی هم پول را همان پذیرنده‌ای برمی‌گرداند که همیشه برمی‌گرداند. OpenAI در مشخصات پرداخت واگذارشده نوشته است خودش فروشندهٔ ثبت‌شده (merchant of record) نیست[۱]. به نوشتهٔ همین سند، تسویه، بازپرداخت، چارج‌بک و انطباق نزد پذیرنده و ارائه‌دهندهٔ خدمات پرداخت او می‌ماند[۱]. چارج‌بک یعنی برگشت وجه به دستور بانک صادرکنندهٔ کارت، وقتی مشتری تراکنش را انکار می‌کند یا به آن اعتراض دارد. پس این پروتکل‌ها مسئولیت مالی را جابه‌جا نمی‌کنند. چیزی که عوض می‌شود جنس مدرک است. تا امروز مدرک شما ورود مشتری به حساب و کلیک او بود. در خرید عاملی باید نشان دهید کاربر چه چیزی را، تا چه سقفی و تا چه زمانی اجازه داده است. و باید نشان دهید عامل در همان چارچوب خرید کرده است.
واقعیت‌های کلیدی
- به نوشتهٔ OpenAI، این شرکت فروشندهٔ ثبت‌شده نیست و تسویه، بازپرداخت، چارج‌بک و انطباق نزد پذیرنده و PSP او می‌ماند.[۱]
- توکن پرداخت واگذارشده تک‌مصرف است و با حداکثر مبلغ و زمان انقضا محدود می‌شود؛ شیء allowance شامل سقف مبلغ، ارز، شناسهٔ جلسهٔ تسویه، شناسهٔ پذیرنده و انقضاست.[۱]
- گوگل AP2 را معرفی کرد و مسترکارت، پی‌پال، امریکن اکسپرس، شاپیفای، کلادفلر و Etsy از آن حمایت کردند.[۶]
- پژوهش امنیتی AP2 نتیجه می‌گیرد امضای معتبر ماندات به‌تنهایی تضمین نمی‌کند تراکنش بازتاب قصد کاربر باشد؛ ۴۸ تهدید فهرست شده و ۸ مورد پرخطر ارزیابی شده است.[۳]
- در آزمایش با مدل‌های پیش‌فرض عامل‌های نمونهٔ AP2، سه حملهٔ متنی با نرخ ۹۰، ۵۶ و ۷۳٫۳ درصد موفق شدند.[۴]
- به گفتهٔ لیندزی واکر از Hedera AI Studio، خرید عاملی هنوز واقعیت ندارد و آنچه امروز وجود دارد خرید با کمک عامل است.[۵]
دو پروتکل که دو کار متفاوت می‌کنند
گوگل پروتکل پرداخت عامل (AP2) را در یک یادداشت وبلاگی معرفی کرد و شرکت‌هایی مثل مسترکارت، پی‌پال، امریکن اکسپرس، سیلزفورس، شاپیفای، کلادفلر و Etsy حمایت خود را از آن اعلام کردند[۶]. هستهٔ AP2 چیزی است که گوگل آن را ماندات (mandate) می‌نامد: سندهای دیجیتالِ امضاشده با رمزنگاری که نقش رسید مجوز را دارند[۶]. درخواست کاربر یک ماندات قصد می‌سازد و تأیید سبد یک ماندات سبد که قلم کالا و قیمت را قفل می‌کند[۶]. در حالت واگذارشده کاربر حاضر نیست؛ مثال خود گوگل این است که کسی به عاملش بگوید بلیت کنسرت را زیر یک سقف قیمت معین بخرد و ماندات قصد همان سقف و شرط زمان را در خود نگه دارد[۶]. به گفتهٔ گوگل، این توالی از قصد تا سبد تا پرداخت یک ردّ حسابرسی غیرقابل‌انکار می‌سازد که به پرسش مجوز و اصالت پاسخ می‌دهد[۶].
طرف دیگر ماجرا لولهٔ پرداخت است. در مشخصات OpenAI، خریدار روش پرداختش را در ChatGPT ذخیره می‌کند، اطلاعات به PSP یا والت پذیرنده می‌رود و توکنی برمی‌گردد[۱]. آن توکن تک‌مصرف است و با سقف مبلغ و زمان انقضا محدود می‌شود[۱]. در بدنهٔ درخواست، شیء allowance اجباری است و شامل حداکثر مبلغ، ارز، شناسهٔ جلسهٔ تسویه، شناسهٔ پذیرنده و زمان انقضاست[۱]. فهرست سیگنال‌های ریسک هم فیلد اجباری است و نوع، امتیاز و اقدام انجام‌شده را ثبت می‌کند[۱]. استرایپ می‌گوید توکن پرداخت مشترکی صادر می‌کند که به یک پذیرندهٔ مشخص و جمع همان سبد محدود است[۲]. به گفتهٔ استرایپ، پذیرنده سفارش را مثل هر سفارش دیگر می‌پذیرد یا رد می‌کند، مالیات فروش را خودش حساب می‌کند و تحویل و مرجوعی را خودش انجام می‌دهد[۲]. هیچ‌کدام از این دو لایه بازپرداخت و چارج‌بک را از دوش پذیرنده برنمی‌دارند[۱].
امضای معتبر، سبد اشتباه
پژوهش امنیتی تصویر را تلخ‌تر می‌کند. یک تحلیل امنیتی AP2 که تاریخ انتشارش در دسترس ما نیست، می‌گوید امضاها فقط دادهٔ تراکنش را پس از امضا سالم نگه می‌دارند[۳]. آنچه پیش از صدور مجوز شکل می‌گیرد بیرون این حفاظت می‌ماند: دادهٔ کاتالوگ، نتیجهٔ ابزارها و پیام‌های میان عامل‌ها[۳]. نتیجهٔ صریح این پژوهش روشن است: امضای معتبر ماندات به‌تنهایی تضمین نمی‌کند تراکنش بازتاب قصد کاربر باشد[۳]. همین پژوهش ۴۸ تهدید را فهرست کرده و ۸ مورد را دست‌کم در یکی از معماری‌های استقرار پرخطر ارزیابی کرده است[۳]. پژوهش دیگری نشان می‌دهد یک جملهٔ ساده در توضیح محصول، بدون هیچ دستوری، می‌تواند انتخاب عامل را عوض کند؛ سبدی که ساخته می‌شود همهٔ بررسی‌های پروتکل را رد می‌کند، ولی دیگر با خواستهٔ کاربر نمی‌خواند[۴].
عامل‌های نمونهٔ AP2 به‌صورت پیش‌فرض مدل‌های Gemini Flash-Lite را تعیین می‌کنند و در آزمایش با همین مدل‌ها سه حمله با نرخ موفقیت ۹۰، ۵۶ و ۷۳٫۳ درصد موفق شده‌اند[۴]. همان آسیب‌پذیری روی ۱۷ بیلد مدل گوگل و سه چارچوب عاملِ بی‌ارتباط هم دیده شده است[۴]. خودِ سند امنیتی AP2 جلوگیری از تزریق دستور (prompt injection) را ناممکن می‌داند و می‌گوید همهٔ مدل‌ها و عامل‌ها باید مهاجم بالقوه فرض شوند[۴]. تزریق دستور یعنی متنی که عامل می‌خواند، رفتار او را عوض کند. نکتهٔ عملی‌تر برای پذیرنده جای دیگری است: در درخت نسخهٔ ۰٫۲٫۰، عاملی که در سناریوی حضور کاربر استفاده می‌شود ماندات‌ها را بدون هیچ فیلد محدودیتی می‌سازد و تست‌های خود SDK ثبت کرده‌اند که فهرست خالی محدودیت هیچ تخلفی تولید نمی‌کند[۴]. یعنی سقفی که فکر می‌کنید در زنجیره هست، ممکن است اصلاً نوشته نشده باشد.
ریسک از خطای مدل به خطای مجوز جابه‌جا می‌شود
فاصلهٔ وعده تا واقعیت هنوز زیاد است. در گزارشی که مسترکارت منتشر کرد، برآورد ICSC و مک‌کینزی این است که خرید عاملی در خرده‌فروشی مصرفی آمریکا تا ۲۰۳۰ می‌تواند به ۱ تریلیون دلار درآمد برسد[۵]. در همان گزارش آمده گارتنر انتظار دارد عامل‌های هوش مصنوعی تا ۲۰۲۸ واسطهٔ بیش از ۱۵ تریلیون دلار هزینهٔ B2B شوند[۵]. مسترکارت هم تأکید می‌کند همهٔ حلقه‌های زنجیرهٔ تجارت باید وارد شوند، وگرنه این اتفاق نمی‌افتد[۵]. لیندزی واکر، مدیر محصول Hedera AI Studio، در کنفرانسی در سان‌فرانسیسکو گفت خرید عاملی هنوز واقعیت ندارد؛ به گفتهٔ او آنچه امروز داریم خرید با کمک عامل است و انسان همچنان در لحظهٔ خرید حاضر است و تصمیم می‌گیرد[۵].
به گفتهٔ واکر، فروشنده‌ای که نمی‌خواهد مسئول خرید انکارشده باشد باید حضور کارت را ثابت کند و با عامل هوش مصنوعی کارت هیچ‌وقت حاضر نیست[۵]. راه‌حلی که او پیشنهاد می‌کند دروازه‌های قطعی است؛ دروازه‌هایی که مدل احتمالاتی نتواند از آن‌ها عبور کند[۵]. برداشت ما این است که همین جمله کل تغییر را خلاصه می‌کند. ریسک از خطای مدل به خطای مجوز و اثبات منتقل می‌شود. مدل اشتباه می‌کند، اما چیزی که به حاشیهٔ سود می‌خورد نبودِ مدرکِ قابل‌دفاع است. اگر نرخ اختلاف در کانال عاملی بالاتر از کانال وب بماند، فشار اول روی رتبهٔ ریسک پذیرنده نزد PSP می‌افتد، نه روی سازندهٔ عامل؛ در آن حالت احتمالاً پذیرنده‌ها خودشان این کانال را محدود می‌کنند. آمازون ربات Muse متا را با استناد به محدودیت‌های شرایط استفاده مسدود کرد و پیش‌تر ربات Perplexity را هم مسدود کرده بود[۵].
چه مدرکی نگه داریم و کدام فرایند را بازطراحی کنیم
فهرست کار برای تیم محصول و مالی از خود فیلدهای پروتکل بیرون می‌آید. سقف مبلغ، ارز، شناسهٔ جلسهٔ تسویه، شناسهٔ پذیرنده و زمان انقضا را دور نریزید و کنار خود سفارش ذخیره کنید؛ همین فیلدها همان مجوزی هستند که بعداً باید نشان دهید[۱]. کلید idempotency و شناسهٔ درخواست را هم نگه دارید تا سفارش تکراری از سفارش جدید جدا شود[۱]. سیگنال‌های ریسک و اقدامی که روی آن‌ها انجام شده — مسدودشده، بررسی دستی یا تأییدشده — بخشی از پروندهٔ دفاع شما در اختلاف است[۱]. پذیرش یا رد سفارش هم همچنان دست شماست[۲]. همان نقطه بهترین جا برای گذاشتن یک دروازهٔ قطعی است: اگر مبلغ، قلم کالا یا نشانی با مجوز نخواند، سفارش رد می‌شود، نه اینکه مدل دربارهٔ آن قضاوت کند.
دو کار دیگر هم به نظر ما زود نتیجه می‌دهد. اول، سفارش‌های کانال عاملی را در داده‌هایتان برچسب جدا بزنید و نرخ مرجوعی و نرخ اختلاف آن را جدا از وب و اپ دنبال کنید؛ بدون این تفکیک نمی‌فهمید کانال جدید سودآور است یا فقط شلوغ. دوم، قواعد بازگشت کالا را برای خریدی که انسان آن را ندیده بازنویسی کنید. متن توضیح محصول هم دیگر فقط محتوای بازاریابی نیست؛ یک ادعای ساده دربارهٔ موجودی یا اصالت کالا می‌تواند انتخاب عامل را عوض کند[۴]. پس تیم محتوا هم بخشی از سطح ریسک پرداخت است.
| نقش یا سازوکار | آنچه منابع می‌گویند | جزئیات |
|---|---|---|
| پلتفرم عامل (OpenAI) | فروشندهٔ ثبت‌شده نیست | توکن را هنگام تکمیل تسویه به پذیرنده منتقل می‌کند |
| پذیرنده و PSP او | تسویه، بازپرداخت، چارج‌بک و انطباق | پردازش مثل هر تراکنش دیجیتال دیگر |
| توکن پرداخت واگذارشده | محدود به سقف مبلغ و زمان انقضا | تک‌مصرف، خارج از دامنهٔ PCI برای پذیرنده |
| Shared Payment Token استرایپ | محدود به یک پذیرندهٔ مشخص و جمع سبد | بدون افشای اعتبار پرداخت خریدار |
| سفارش و پس از فروش | پذیرش یا رد سفارش، مالیات، تحویل و مرجوعی | بر عهدهٔ پذیرنده می‌ماند |
| ماندات AP2 | رکوردهای امضاشده به‌عنوان اثبات مجوز کاربر | قصد، سبد و پرداخت یک زنجیره می‌سازند |
خط زمانی
- 2025-09-19: گزارش می‌شود گوگل پروتکل پرداخت عامل (AP2) را با زنجیرهٔ ماندات قصد، سبد و پرداخت معرفی کرده و شرکت‌های پرداخت و خرده‌فروشی از آن پشتیبانی کرده‌اند.[۶]
- 2025-09-25: OpenAI مشخصات پرداخت واگذارشده را منتشر می‌کند؛ توکن تک‌مصرف با سقف مبلغ و انقضا.[۱]
- 2026-10-01: گزارش مسترکارت و اظهارات کنفرانس هوش مصنوعی سان‌فرانسیسکو: خرید عاملی هنوز عملیاتی نیست.[۵]
برای کسب‌وکارهای ایرانی
برای فروشنده‌های ایرانی این ریل‌های پرداخت در دسترس نیستند و بحث نرخ تبدیل ارز هم اینجا موضوع ما نیست. اما درس طراحی قابل انتقال است. هر تیمی که می‌خواهد خرید یا سفارش‌گذاری را به یک دستیار بسپارد، چه برای مشتری چه برای تدارکات داخلی، باید سه چیز را بسازد: ثبت مکتوب اجازهٔ کاربر، سقف مبلغ و زمان، و یک دروازهٔ تأیید که مدل نتواند از آن رد شود. پژوهش امنیتی نشان داده مدل‌های با وزن باز و بسته هر دو در دو سوی مقاوم و آسیب‌پذیر دیده شده‌اند[۴]. یعنی انتخاب مدل جای کنترل فرایند را نمی‌گیرد. برداشت ما این است که تیم‌هایی که امروز لاگ قصد و سقف را در سفارش‌های خودکارشان ذخیره می‌کنند، بعداً برای هر استانداردی آماده‌ترند.
چه چیزی را باید دنبال کرد
- آیا در نسخه‌های بعدی AP2، عامل‌های نمونه فیلد محدودیت‌ها را به‌صورت پیش‌فرض پر می‌کنند؛ پژوهش نشان داده عامل حالت حضور انسان آن را خالی می‌سازد[۴]
- گسترش Instant Checkout از فروشندگان Etsy به فروشندگان شاپیفای که استرایپ از آن خبر داده است[۲]
- برخورد پلتفرم‌های بزرگ خرده‌فروشی با ربات‌های خرید؛ آمازون ربات Muse متا و پیش‌تر ربات Perplexity را مسدود کرده است[۵]
- اعلام قاعدهٔ روشن مسئولیت برای تراکنشی که عامل انجام می‌دهد و کارت در آن هرگز حاضر نیست؛ هنوز چنین قاعده‌ای در منابع ما دیده نمی‌شود
منابع
- Delegated Payment Spec – Agentic Commerce | OpenAI Developers — OpenAI Developers، انتشار: 2025-09-25، شواهد تازه، دسترسی: 2026-10-02
- Stripe powers Instant Checkout in ChatGPT and releases Agentic Commerce Protocol codeveloped with OpenAI — Stripe، منبع مرجع، دسترسی: 2026-10-01
- Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) — arxiv.org، منبع مرجع، دسترسی: 2026-10-02
- Signing the Transaction but Not the Decision: Whisper Attacks and a Binding Defense for AP2 — arxiv.org، منبع مرجع، دسترسی: 2026-10-02
- The tech industry is hot for shopping bots, but they're years away — Theregister، انتشار: 2026-10-01، شواهد تازه، دسترسی: 2026-10-02
- Google launches payments protocol for AI commerce, names dozens of partners — Digital Commerce 360 | Internet Retailer، انتشار: 2025-09-19، شواهد تازه، دسترسی: 2026-10-02
روش تهیه: این تحلیل با سامانه پایش خودکار khavarzadeh.com و کمک مدل‌های زبانی از منابع بالا تهیه شده و پیش از انتشار، تطابق اعداد، تاریخ‌ها و ارجاع‌ها با منابع به‌صورت خودکار کنترل شده است. واقعیت‌ها با شماره منبع مشخص شده‌اند و بقیه متن برداشت تحلیلی است. تاریخ تهیه: 2026-10-02.
نظرات
هنوز نظری ثبت نشده است؛ اولین نفر باشید.
افزودن نظر