AWS आणि Anchor Browser यांनी एकत्रीकरणाचे दस्तऐवजीकरण केले आहे. विद्यमान सत्रात ब्राउझर एजंटला x402-संरक्षित पृष्ठ किंवा API साठी पैसे देता येतात. ब्राउझर HTTP 402 पेमेंट आव्हानाला प्रतिसाद देतो, Amazon Bedrock AgentCore payments कडून स्वाक्षरी केलेला पेमेंट पुरावा मिळवतो आणि विनंती पुन्हा करतो. विकसकासाठी महत्त्वाचा बदल म्हणजे हे काम कुठे होते: ब्राउझर आव्हान आणि पुनःप्रयत्न हाताळतो, तर स्वतंत्रपणे कॉन्फिगर केलेली पेमेंट सेवा खर्चाची परवानगी तपासते.

मोठा बदल

  • काय बदलले:x402 आव्हानानंतर शुल्कित वेब विनंती एजंटच्या ब्राउझर सत्रात पूर्ण होऊ शकते; ऑटोमेशन कोडमध्ये वॉलेट की किंवा पेमेंट हेडर ठेवण्याची गरज नाही. विकसकाने त्या सत्रासाठी पेमेंट स्पष्टपणे सक्षम करावे.
  • हे का महत्त्वाचे:प्रति-विनंती शुल्क असलेला डेटा किंवा मजकूर वापरणारे एजंट तोच कार्यप्रवाह पुढे चालू ठेवू शकतात. पेमेंट साधन, ओळख-अधिकार आणि खर्च मर्यादा पृष्ठ व एजंट रनटाइमच्या बाहेर असतात. त्यामुळे प्रत्यक्ष खरेदीचा निर्णय ऑपरेटरने कॉन्फिगर आणि निरीक्षण करावयाच्या पायाभूत सुविधांकडे जातो.
  • काय पाहावे:महत्त्वाची सीमा म्हणजे मूळ 402 प्रतिसाद. चुकीचे आव्हान, विसंगत पेमेंट नेटवर्क, संपलेले बजेट किंवा नाकारलेले पेमेंट यामुळे ऑटोमेशनसाठी संसाधन उपलब्ध राहत नाही; विकसकांनी तरीही हा प्रतिसाद हाताळावा.

शुल्कित पृष्ठावर ब्राउझर काय करतो

AWS आणि Anchor चे ट्युटोरियल Anchor Browser सत्रातील दस्तऐवज नेव्हिगेशन, fetch किंवा XMLHttpRequest साठीचा प्रवाह सांगते. व्यापारी पेमेंट आव्हानासह HTTP 402 Payment Required परत करतो. Anchor अटी वाचतो आणि सत्राशी जोडलेल्या पेमेंट साधनाशी सुसंगत पद्धत शोधतो. AgentCore सत्राचे उरलेले बजेट तपासतो आणि कॉन्फिगर केलेल्या वॉलेट प्रदात्याद्वारे पुराव्यावर स्वाक्षरी करतो. ब्राउझर तो पुरावा मूळ विनंतीत जोडतो आणि एकदाच पुन्हा प्रयत्न करतो: x402 v2 साठी PAYMENT-SIGNATURE किंवा v1 साठी X-PAYMENT वापरतो. संसाधन परत देण्यापूर्वी व्यापारी पेमेंट पडताळून सेटल करतो.

हा दस्तऐवजीकृत क्रम आहे; BIG CHANGE ने शुल्कित एंडपॉइंटची चाचणी केलेली नाही. AWS नुसार पेमेंट आणि पुनःप्रयत्नादरम्यान ब्राउझर सत्राचा संदर्भ कायम ठेवतो. विद्यमान Playwright, Puppeteer आणि Chrome DevTools Protocol कार्यप्रवाह पेमेंट हेडर स्वतः तयार न करता ब्राउझरमधून नेव्हिगेशन किंवा API कॉल करू शकतात. यशस्वी पेमेंटमुळे प्रत्येक पेवॉल वाचता येईलच असे नाही: साइटने समर्थित x402 आव्हान द्यावे लागते आणि पुरावा स्वीकारून प्रतिसाद देण्याचा निर्णय व्यापारी घेतो.

विकसकाने काय सक्षम करावे

ब्राउझरचा स्विच स्पष्ट आहे. ट्युटोरियलच्या सत्र-विनंतीत, session.x402 चे डीफॉल्ट मूल्य false आहे; ते true केल्याने कॉन्फिगर केलेल्या साधनातून प्रत्यक्ष पेमेंट अधिकृत होते. ब्राउझर सत्र तयार करण्यासाठी Anchor API कीही आवश्यक आहे. हा फ्लॅग पेमेंट अधिकाराशी जोडणारा शेवटचा दुवा आहे; अधिकाराची स्थापना यामुळे बदलत नाही.

AWS चे AgentCore पेमेंट मार्गदर्शक मूळ संसाधने स्पष्ट करते. Payment Manager AWS खात्याची पेमेंट संरचना ठरवतो आणि IAM भूमिका व authorizer वापरतो. Payment Connector Coinbase Developer Platform किंवा Stripe Privy शी जोडतो. Payment Credential Provider AgentCore Identity द्वारे प्रदात्याची प्रमाणपत्रे ठेवतो. Payment Instrument खरेदीसाठी वॉलेट आणि नेटवर्क ओळखतो. ब्राउझर सत्र खर्च मर्यादा आणि समाप्ती असलेल्या AgentCore Payment Session शी जोडलेले असते. AWS चे द्रुत प्रारंभ मार्गदर्शन साधनात निधी असणे आणि एजंटला प्रतिनिधीकृत स्वाक्षरी परवानगी देणेही आवश्यक सांगते.

हे वेगवेगळे नियंत्रण आहेत. IAM सेवा प्रवेश नियंत्रित करतो; वापरकर्त्याची वॉलेट परवानगी स्वाक्षरीस अनुमती देते; साधन निधीचा स्रोत व नेटवर्क ठरवते; आणि सत्र मर्यादा कालावधीतला खर्च बांधते. सत्र संपल्यावर किंवा मर्यादा गाठल्यावर AgentCore पुढील पेमेंट नाकारतो, असे AWS सांगते. निरीक्षण सेवा CloudWatch मध्ये प्रयत्न व परिणाम दाखवते. एकत्रीकरणामुळे प्रदात्याची रहस्ये ब्राउझर व एजंट रनटाइमच्या बाहेर राहतात; तरीही ऑपरेटरला कामानुसार साधन आणि मर्यादा निवडावी लागते.

स्वयंचलित प्रवाह कुठे थांबतो

Anchor ने अपयशाची विशिष्ट वागणूक नोंदवली आहे: 402 आव्हान चुकीचे असल्यास, सुसंगत नेटवर्क न दिल्यास, बजेट संपल्यास किंवा AgentCore ने पेमेंट नाकारल्यास ब्राउझर मूळ 402 पृष्ठाला तसाच परत करतो. म्हणून सक्षम सत्रातही ऑटोमेशनने 402 येऊ शकतो असे गृहीत धरावे. AWS चे समस्या-निवारण मार्गदर्शक IAM परवानगी नसणे, निष्क्रिय प्रतिनिधीकृत स्वाक्षरी मंजुरी, चुकीची प्रदाता प्रमाणपत्रे आणि Coinbase साठी Marketplace सदस्यत्व नसणे यांसारख्या इतर कॉन्फिगरेशन त्रुटी दाखवते.

हा session.x402 स्विच तृतीय-पक्ष संसाधनांच्या पेमेंटसाठी आहे. AWS नुसार तो Anchor ब्राउझर सत्रासाठी पैसे देत नाही किंवा Anchor क्रेडिटची जागा घेत नाही. ट्युटोरियल सत्रातील खर्च आणि वेळेची मर्यादा सांगते, पण ठोस मर्यादांसाठी Anchor तांत्रिक दस्तऐवजांकडे निर्देश करते; या लेखासाठी ते तपशील उपलब्ध नव्हते. प्रत्येक तृतीय-पक्ष विनंतीचा खर्च व्यापाऱ्याचे आव्हान आणि प्रत्यक्ष सेटलमेंटवर अवलंबून असतो. आम्ही संपूर्ण बिल किंवा व्यवहार पडताळला नाही, त्यामुळे सक्षम सत्राची सार्वत्रिक किंमत लेख सांगू शकत नाही.

विकसकांसाठी व्यावहारिक निर्णय एजंट शुल्कित URL वर पोहोचण्यापूर्वी घ्यायचा असतो: निधी असलेले अधिकृत साधन जोडणे, ब्राउझर सत्रासाठी बजेट ठरवणे आणि खरेदी अपेक्षित असेल तेव्हाच x402 सक्षम करणे. ब्राउझर नेव्हिगेशनमधील पेमेंट प्रोटोकॉल कोड काढू शकतो; पण खर्च अधिकार, अपयशी विनंत्या किंवा व्यापाऱ्याने प्रत्यक्ष किती आकारले हे तपासण्याची ऑपरेटरची जबाबदारी काढत नाही. अधिकाराचा हा प्रश्न आमच्या AI एजंटच्या पेमेंट पर्यायांच्या विस्तृत परीक्षणातही येतो.

स्रोत आणि पुढील वाचन

  • AWS आणि Anchor Browser, “Building agents that transact with Anchor Browser and AgentCore payments” (13 ऑक्टोबर 2026). एकत्रीकरण ट्युटोरियल ब्राउझरचा पर्याय, x402 आव्हान, आवृत्तीनुसार पेमेंट हेडर आणि अपयशात मूळ 402 परत करण्याची वागणूक सांगते. हे अपेक्षित प्रवाहाचे वर्णन आहे; आम्ही शुल्कित सत्र तपासले नाही.
  • AWS, “How AgentCore payments works” (विकसक मार्गदर्शक, 14 ऑक्टोबर 2026 रोजी पाहिले). Payment Manager, प्रदाता कनेक्टर, ओळख प्रमाणपत्रे, साधने, खर्च सत्रे आणि निरीक्षण स्पष्ट करते. ब्राउझर-विशिष्ट ट्युटोरियलसोबत ही सामान्य सेवा रचना आहे.
  • AWS, “AgentCore payments quick start” (विकसक मार्गदर्शक, 14 ऑक्टोबर 2026 रोजी पाहिले). प्रदाता प्रमाणपत्रे, निधी व मंजुरी असलेले साधन आणि पेमेंट सत्रासाठी सेटअप पायऱ्या देते. नमुना बजेट व कालावधी हे उदाहरण आहेत; पडताळलेले Anchor डीफॉल्ट नाहीत.
  • AWS, “Troubleshooting AgentCore payments” (विकसक मार्गदर्शक, 14 ऑक्टोबर 2026 रोजी पाहिले). पेमेंट रोखू शकणाऱ्या IAM, प्रदाता, वॉलेट परवानगी, सदस्यत्व आणि x402 पेलोड त्रुटी दाखवते. आम्ही या त्रुटी पुनरुत्पादित केल्या नाहीत.