एजेंट-रेडी चेकआउट: जब AI ग्राहक की ओर से ख़रीदे, तब पेमेंट, टोकन और भरोसा

मंगलवार सुबह 9:12 बजे एक छोटी इलेक्ट्रॉनिक्स दुकान की मालकिन के पास एक ग्राहक के AI assistant की ओर से एक order आता है: एक लैपटॉप चार्जर, 49 डॉलर, payment उस token से जो ग्राहक के बैंक ने सिर्फ़ इसी दुकान के लिए जारी किया और जो 30 मिनट तक मान्य है। न कार्ड नंबर, न account, न browser session।

उनके fraud नियम इंसानों के हिसाब से कसे हैं। उन्हें दिखता है नया device, mouse की कोई हरकत नहीं, और दो सेकंड में पूरा हुआ checkout। वे order को ज़्यादा जोखिम वाला मानकर ठुकरा देते हैं। उसी सुबह एक ऐसी request, जो सिर्फ़ header में ख़ुद को agent बताती है, उनके "जाने-पहचाने भरोसेमंद automation" वाले नियम से निकल जाती है। असली बिक्री लौट गई, और एक bot अंदर आ गया। (यह एक काल्पनिक परिदृश्य है, कोई असली दुकान नहीं।)

हल नियम को ढीला करना नहीं है, और कड़ा करना भी नहीं। agent को बेचने वाला checkout तीन सवाल क्रम से पूछता है: कौन माँग रहा है, agent को क्या ख़रीदने की इजाज़त थी, और यह order ख़ास तौर पर कितना जोखिम भरा है? इस लेख का बाक़ी हिस्सा इन सवालों के पीछे के पुर्ज़े समझाता है।

इस सीरीज़ के पहले भाग में सवाल था कि क्या कोई AI agent आपका स्टोर ढूँढकर समझ सकता है। दूसरे भाग में सवाल था कि क्या assistant उसे सुझाएगा। इस भाग का सवाल तय करता है कि पैसा किसे मिलेगा: जब agent ख़रीदने को तैयार हो, तो क्या आपका checkout सुरक्षित तरीक़े से "हाँ" कह सकता है? 2026 का हर गंभीर प्रोग्राम कार्ड की जगह एक सीमित, रद्द किया जा सकने वाला credential देता है, साथ में एक signed रिकॉर्ड कि ग्राहक ने क्या-क्या इजाज़त दी थी। आगे आप देखेंगे कि सितंबर 2026 की शुरुआत में हर प्रोग्राम किस हाल में था, और अंत में आपके checkout में अभी क्या ठीक करना है, उसकी चेकलिस्ट।

यह "AI agent को बेचना" सीरीज़ का भाग 3 है, कुल 3 में से। पहला भाग: agentिक कॉमर्स: जब अगला ग्राहक AI agent हो, तब कैसे बेचें। दूसरा भाग: ऑनलाइन स्टोर के लिए GEO।

कार्ड देखे बिना agent कैसे payment करता है

ऑनलाइन payment करते समय हम form में 16 अंकों का नंबर डालते हैं। agent भी ऐसा करता तो वह नंबर मॉडल provider के system, log और memory में रह जाता। इंडस्ट्री का जवाब यह है कि agent को असली कार्ड की जगह एक प्रतिनिधि दिया जाए।

इस प्रतिनिधि का नाम है tokenाइज़्ड credential। असली कार्ड बैंक या wallet के पास ही रहता है। agent को ऐसा token मिलता है जो एक तय मर्चेंट, एक अधिकतम रक़म और थोड़े समय के लिए ही मान्य है, और जिसे ग्राहक जब चाहे रद्द कर सकता है। token लीक हो भी जाए, तो हाथ लगती है लगभग इस्तेमाल हो चुकी एक अनुमति-पर्ची, कार्ड नहीं।

token कोई नई चीज़ नहीं हैं। कार्ड network मोबाइल wallet और सेव किए गए कार्ड के पीछे बरसों से network token चला रहे हैं। नया यह है कि token के साथ नियम जोड़ दिए गए हैं: agent कौन है, क्या ख़रीद सकता है और कितनी देर तक।

सितंबर 2026 में प्रोग्राम किस हाल में थे

कई प्रोग्राम एक-दूसरे पर चढ़े हुए हैं, और वे browserों की तरह प्रतिद्वंद्वी नहीं हैं। कुछ तय करते हैं कि agent स्टोर से कैसे बात करे, कुछ इजाज़त का सबूत देते हैं, और कुछ payment को मंज़ूरी देते हैं। सितंबर 2026 की शुरुआत तक का सार्वजनिक रिकॉर्ड यह है:

प्रोग्राम	क्या कवर करता है	status, सितंबर 2026
Agentic Commerce Protocol (OpenAI और Stripe)	agent checkout कैसे शुरू करता है और विक्रेता को payment token कैसे देता है	सितंबर 2025 में ओपन स्टैंडर्ड के रूप में जारी। ChatGPT के भीतर का Instant Checkout मार्च 2026 में बंद हुआ बताया गया, पर प्रोटोकॉल चल रहा है; स्पेक का ताज़ा संस्करण अप्रैल 2026 का है
Stripe Shared Payment Tokens और Agentic Commerce Suite	किसी एक विक्रेता, रक़म और समय तक सीमित token	दिसंबर 2025 में शुरू; दूसरे payment provider प्रोटोकॉल के delegated payment स्पेसिफ़िकेशन से जुड़ सकते हैं
Agent Payments Protocol, AP2 (Google)	signed mandate, जो साबित करते हैं कि ग्राहक ने क्या मंज़ूर किया था	सितंबर 2025 में घोषित; अप्रैल 2026 में मानकीकरण के लिए FIDO Alliance को सौंपा गया
Universal Commerce Protocol और Universal Cart (Google)	कैटlog और checkout का स्टैंडर्ड, साथ में Search और Gemini में एक cart	स्टैंडर्ड जनवरी 2026 में घोषित; cart मई 2026 में घोषित, गर्मियों में अमेरिका में रोलआउट की बात के साथ। योजना बनाने से पहले मौजूदा उपलब्धता जाँच लें
Visa Intelligent Commerce और Trusted Agent Protocol	agent token, और भरोसेमंद agent की पहचान के लिए signed request	अक्टूबर 2025 में मर्चेंट और प्रोसेसर पार्टनरों के साथ घोषित; developer सैंडबॉक्स खुला है
Mastercard Agent Pay	मौजूदा कार्ड tokenाइज़ेशन पर agentic token	मार्च 2026 से एशिया-प्रशांत में पहले लाइव agent payment की ख़बर; इसका Verifiable Intent फ़्रेमवर्क FIDO Alliance को दिया गया

किसी एक पंक्ति से ज़्यादा दो बातें मायने रखती हैं। पहली, जिस प्रोग्राम ने पूरी ख़रीदारी चैट विंडो के अंदर लाने की कोशिश की, उसने क़दम पीछे खींचे, जबकि उसके नीचे का ढाँचा आगे बढ़ता रहा। दूसरी, अब मानक संस्थाएँ इसमें शामिल हैं: अप्रैल 2026 में FIDO Alliance ने वर्किंग ग्रुप बनाने की घोषणा की, agent ऑथेंटिकेशन और agent-शुरू कॉमर्स के लिए, Google और Mastercard के योगदान से शुरुआत करते हुए। आम तौर पर इसका मतलब होता है कि मैदान एक मानक की ओर बढ़ रहा है।

मात्रा अभी छोटी है। ऐसा checkout बनाइए जो agent को स्वीकार कर सके; किसी agent पर टिकी कमाई की लाइन के भरोसे योजना मत बनाइए।

mandate: क्या मंज़ूर हुआ था, इसका signed रिकॉर्ड

token कहता है "इस credential से चार्ज किया जा सकता है"। पर वह यह नहीं बताता कि क्यों। यह कमी mandate पूरी करता है। यह ग्राहक की इजाज़त का signed रिकॉर्ड है, और AP2 इसे तीन हिस्सों में बाँटता है:

• Intent mandate: ग्राहक ने क्या माँगा और सीमाएँ क्या हैं, जैसे "रनिंग शूज़, 120 डॉलर से कम, शुक्रवार तक डिलीवरी"।
• Cart mandate: agent ने ठीक जो cart बनाया, क़ीमतों समेत, signed, ताकि बाद में कोई लाइन बदली न जा सके।
• Payment mandate: payment network को भेजी गई मंज़ूरी, जिसमें दर्ज होता है कि इसमें agent शामिल था।

इसे signed परचेज़ order की तरह समझिए। ग्राहक बजट मंज़ूर करता है, agent order भरता है, और हस्ताक्षर दोनों को जोड़े रखते हैं। महीनों बाद dispute आए, तो "क्या ग्राहक सचमुच इसके लिए राज़ी था?" सवाल के पीछे एक दस्तावेज़ होता है।

आपके checkout के लिए इसका मतलब

क्रिप्टोग्राफ़ी आपको नहीं लिखनी; हस्ताक्षर आपका payment provider या platform जाँचता है। आपका काम उस data को स्थिर रखना है जिस पर हस्ताक्षर टिके हैं: आप जो cart लौटाते हैं और जिस cart पर चार्ज करते हैं, दोनों एक होने चाहिए, क़ीमत, टैक्स, shipping और करेंसी तक। quote देने के बाद चुपचाप टोटल बदल देने से यह कड़ी टूट जाती है।

गड़बड़ हुई तो नुक़सान किसका

इस पर अभी किसी ने अंतिम फ़ैसला नहीं किया। कार्ड के नियम screen के सामने बैठे इंसान के लिए बने थे। agent कुछ ऐसा ख़रीद ले जो ग्राहक नहीं चाहता था, तो वह fraud हो सकता है, विक्रेता की चूक हो सकती है या अधिकृत ख़रीदारी। सभी प्रोग्राम में ग्राहक, agent provider और विक्रेता के बीच ज़िम्मेदारी साफ़ बाँटने वाला कोई प्रकाशित नियम मेरी जानकारी में नहीं है। जब तक आपके payment provider की शर्तें कुछ और न कहें, मानकर चलिए कि नुक़सान विक्रेता का है।

network इस पर काम कर रहे हैं। signed agent पहचान और mandate इसलिए हैं कि इश्यूअर "कार्डधारक की मंज़ूरी से agent के ज़रिए" और "fraud" में फ़र्क़ कर सके। इसे दिशा समझिए, गारंटी नहीं। agent लेन-देन चालू करने से पहले अपने payment provider की शर्तें पढ़ लें।

एक काल्पनिक उदाहरण: ग्राहक agent से कहता है "मेरे लैपटॉप के लिए एक चार्जर ख़रीद दो"। agent ग़लत कनेक्टर वाला मॉडल ख़रीद लेता है, और ग्राहक चार्ज पर dispute करता है। अगर आपकी लिस्टिंग में कनेक्टर का प्रकार साफ़ लिखा था और cart mandate में दर्ज है कि उस वक़्त क्या दिखाया गया था, तो आपका सबूत मज़बूत है। लिस्टिंग धुँधली थी, तो dispute जीतना मुश्किल है और ग़लती काफ़ी हद तक आपकी मानी जाएगी।

agent के दौर में fraud signal और dispute

ज़्यादातर fraud system चुपचाप इंसानी व्यवहार पर टिके होते हैं: mouse की चाल, टाइपिंग की रफ़्तार, पहले देखा हुआ device, ब्राउज़िंग हिस्ट्री। agent के पास इनमें से कुछ नहीं होता। इसलिए वैध agent का order bot हमले जैसा दिख सकता है, और असली bot agent का चोला पहन सकता है।

अपने नियम चार तरह से अपडेट कीजिए:

• agent संदर्भ को signal मानिए, छूट नहीं। वैध mandate वाला सत्यापित agent जोखिम घटाता है। सिर्फ़ "मैं agent हूँ" कहने वाली असत्यापित request जोखिम बढ़ाती है।
• सबूत अपने-आप सहेजिए। mandate या token का रेफ़रेंस, quote किया गया cart, डिलीवरी की पुष्टि और order की तारीख़ पर लागू नीति का पाठ रखिए।
• हर mandate पर वेलॉसिटी देखिए। एक जोड़ी जूतों के mandate से पंद्रह order नहीं आने चाहिए।
• report में agent के order अलग रखिए। order का स्रोत दर्ज न हो तो return और dispute की दरों की तुलना नहीं हो सकती।

सब जोड़ दें तो एक agent order का फ़ैसला ऐसा दिखता है। पहचान सबसे पहले आती है, क्योंकि उसके बिना बाक़ी दोनों जाँचें बेमानी हैं। mandate न हो या जोखिम स्कोर ऊँचा निकले, तो सीधे ठुकराना ज़रूरी नहीं: ग्राहक से मंज़ूरी माँगी जा सकती है, और इससे संदिग्ध order पक्का order बन जाता है।

अच्छे agent का स्वागत, बुरे bot पर रोक

कई स्टोर bot की समस्या का जवाब सबको एक साथ ब्लॉक करके देते हैं। जब हर ऑटोमेटेड विज़िटर स्क्रैपर होता था, तब यह चल जाता था। अब कुछ ऑटोमेटेड विज़िटर ख़रीदार के प्रतिनिधि हैं, और उन्हें ब्लॉक करने का मतलब है order खोना।

काम का तरीक़ा है ट्राइएज। सबसे पहले देखिए कि request के साथ जाँचने लायक़ पहचान है या नहीं। Visa का Trusted Agent Protocol और Web Bot Auth प्रस्ताव, दोनों HTTP message signature का इस्तेमाल करते हैं: agent हर request पर प्राइवेट की से हस्ताक्षर करता है, और आप प्रकाशित पब्लिक की से हस्ताक्षर मिला लेते हैं। अक्टूबर 2025 में Cloudflare ने Visa और Mastercard के साथ इस तरीक़े के समर्थन की घोषणा की।

तीन लेन

• सत्यापित agent: हस्ताक्षर मिल गया। product, cart और checkout की अनुमति दीजिए, सामान्य रेट लिमिट के साथ।
• स्क्रैपर: पहचान नहीं, पर व्यवहार सिर्फ़ पढ़ने का। पब्लिक पेज दीजिए, रेट सीमित कीजिए, और cart व checkout के endpoint से दूर रखिए।
• संदिग्ध fraud: पहचान नहीं और व्यवहार असामान्य, जैसे कार्ड टेस्टिंग या एक पते से कई cart। चुनौती दीजिए या ब्लॉक कीजिए।

robots के नियम और bot-सुरक्षा की सेटिंग भी दोबारा देखिए। checkout पर "browser के अलावा सारे user agent ब्लॉक" जैसा नियम शायद आज ही वैध agentों को लौटा रहा हो।

पुष्टि, रसीदें और return

इंसान साइट पर ख़रीदे तो उसे कन्फ़र्मेशन पेज दिखता है। agent ख़रीदे तो ग्राहक वही देखता है जो agent बताता है, इसलिए आपकी पुष्टि इंसानों के साथ-साथ software के पढ़ने लायक़ भी होनी चाहिए।

• मशीन के पढ़ने लायक़ कन्फ़र्मेशन: order नंबर, आइटम, टोटल, टैक्स, डिलीवरी का अनुमान और स्टेटस link, order पूरा करने वाले उसी रिस्पॉन्स में।
• email रसीद ग्राहक को ही जाए। यह मानकर मत बैठिए कि agent फ़ॉरवर्ड कर देगा। ग्राहक का असली पता इस्तेमाल कीजिए, ऐसा रिले पता नहीं जिस तक बाद में पहुँच न हो।
• तय ढाँचे में स्टेटस: paid, packed, shipped, delivered, tracking link के साथ, ताकि "मेरा order कहाँ है?" का ऐसा जवाब हो जो agent ख़ुद ला सके।
• ऐसे return जो agent शुरू कर सके: कारण कोड के साथ दर्ज return request, पात्रता की जाँच और ऐसा refund तरीक़ा जो मूल payment में वापस जाए।

refund में ख़ास सावधानी चाहिए। मूल payment सीमित token से हुआ था तो हाथ से transfer करने के बजाय अपने provider के ज़रिए उसी payment माध्यम में लौटाइए।

आपके checkout में अभी क्या ठीक करें

इसके लिए इसी तिमाही में सारे प्रोटोकॉल अपनाना ज़रूरी नहीं। ज़रूरत है ऐसे साफ़-सुथरे checkout की, जिसमें बाद में कोई एक अपनाना छोटा प्रोजेक्ट बन जाए। सूची को क्रम से पूरा कीजिए।

1. साफ़ order API दीजिए। cart बनाना, cart अपडेट, shipping और टैक्स quote, order पूरा करना, order स्टेटस पढ़ना, हर एक के लिए स्थिर endpoint और पढ़ने लायक़ error मैसेज।
2. quote को बाध्यकारी बनाइए। जो क़ीमत, टैक्स और shipping आप quote करते हैं, वही चार्ज हो, और एक तय समय बाद quote की मियाद ख़त्म हो।
3. गेस्ट checkout चालू रखिए। account बनाना ज़रूरी करने से उस ग्राहक का agent रुक जाता है जो कभी आपके स्टोर पर आया ही नहीं।
4. tokenाइज़्ड और delegated payment समर्थित करने वाला payment provider चुनिए। पूछिए कि वह कौन-से agent प्रोग्राम सपोर्ट करता है और उनके dispute कैसे संभालता है।
5. order का स्रोत दर्ज कीजिए। agent-मूल समेत चैनल के हिसाब से order टैग कीजिए, और token या mandate का रेफ़रेंस रखिए।
6. नीतियाँ साफ़ शब्दों में छापिए। डिलीवरी की अवधि, return की मियाद, refund का तरीक़ा, नियम की शक्ल में लिखिए, नारे की शक्ल में नहीं।
7. अच्छा और बुरा traffic अलग कीजिए। signed agent जाँचिए, बाक़ियों पर रेट लिमिट लगाइए या चुनौती दीजिए, सबको ब्लॉक मत कीजिए।
8. तय ढाँचे में पुष्टि और स्टेटस अपडेट भेजिए। वही जानकारी, इंसान के लिए एक रूप में, मशीन के लिए दूसरे में।
9. सैंडबॉक्स में test कीजिए। Visa, Stripe और दूसरे test एनवायरनमेंट देते हैं; असली पैसा चलने से पहले पूरी agent ख़रीदारी, एक refund और एक dispute चलाकर देखिए।
10. समीक्षा की तारीख़ तय कीजिए। बारह महीनों में यह मैदान कई बार बदला है; हर तिमाही प्रोग्राम की status देख लीजिए।

यह सीरीज़ आपको कहाँ छोड़ती है

तीनों भाग मिलकर एक तस्वीर बनाते हैं। agent को आपको ढूँढना होगा (पहला भाग), चुनना होगा (दूसरा भाग), और checkout सुधारने के लिए किसी इंसान को बुलाए बिना आपको payment कर पाना होगा (यह भाग)। तीनों में साझा धागा एक ही है: ऐसा data जिसके पीछे आप खड़े हो सकें, यानी सटीक product जानकारी, ठोस नीतियाँ, बाध्यकारी quote और हर ग्राहक की दी इजाज़त का रिकॉर्ड।

अब 9:12 वाली दुकान मालकिन पर लौटिए। तीनों जाँचें लगने के बाद 49 डॉलर के चार्जर वाला order दूसरे रास्ते से गुज़रता है। हस्ताक्षर मिल जाता है, mandate (एक चार्जर, अधिकतम 60 डॉलर) cart को कवर करता है, और वैध mandate जोखिम स्कोर को उनके पक्ष में झुकाता है। चार्ज उनके अपने payment provider से जाता है, और पुष्टि कुछ ही सेकंड में ग्राहक के assistant और इनबॉक्स तक पहुँच जाती है।

जो request सिर्फ़ ख़ुद को agent बता रही थी, वह पहली जाँच पर ही अटक जाती है और उनके cart तक पहुँचती ही नहीं। उनके नियम न कड़े हुए, न ढीले। वे ठोस हुए: अब वे यह नहीं देखते कि इंसान कैसे क्लिक करता, बल्कि यह कि माँगने वाला कौन है और उसे क्या करने की इजाज़त थी।

मुख्य बातें

• agent कार्ड नंबर से नहीं, सीमित और रद्द होने लायक़ token से payment करते हैं, और signed mandate में दर्ज होता है कि ग्राहक ने क्या इजाज़त दी।
• सितंबर 2026 तक यह क्षेत्र FIDO Alliance के ज़रिए साझा मानकों की ओर बढ़ रहा है; OpenAI का चैट के भीतर का Instant Checkout मार्च 2026 में बंद हुआ बताया गया, और मूल प्रोटोकॉल जारी है।
• agent ख़रीदारी की ज़िम्मेदारी तय नहीं है, इसलिए मज़बूत सबूत रखिए: quote किया cart, token या mandate का रेफ़रेंस, नीतियाँ और डिलीवरी का प्रमाण।
• ऑटोमेटेड traffic को सत्यापित पहचान से छाँटिए: सत्यापित agent को आने दीजिए, स्क्रैपर की रेट सीमित कीजिए, fraud को रोकिए।
• बाध्यकारी quote, गेस्ट checkout, साफ़ order API और तय ढाँचे वाला स्टेटस, ये सुधार हर हाल में काम आएँगे, चाहे जो प्रोटोकॉल जीते।
• हर तिमाही प्रोग्राम की status दोबारा जाँचिए, और लाइव होने से पहले सैंडबॉक्स में test कीजिए।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP system डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, data की शुद्धता और अपने सर्वर पर चलने वाले system पर।