Mga pagbabayad ng Anchor Browser at AgentCore: kung paano nalalampasan ng isang ahente ang x402 paywall

Ang AWS at Anchor Browser ay nag-dokumento ng integrasyon na nagbibigay-daan sa browser agent na magbayad para sa page o API na protektado ng x402 habang ginagamit ang kasalukuyang session nito. Makasasagot ang browser sa HTTP 402 payment challenge, makakakuha ng nilagdaang patunay ng bayad mula sa Amazon Bedrock AgentCore payments, at muling susubok sa request. Para sa developer, ang mahalagang pagbabago ay kung saan ginagawa ang gawaing iyon: hinahawakan ng browser ang challenge at retry, habang sinusuri ng hiwalay na naka-configure na payment service ang awtoridad na gumastos.

Ang malaking pagbabago

• Ano ang nagbago:Maaaring makumpleto ang isang bayad na web request sa browser session ng agent matapos ang x402 challenge, nang hindi inilalagay ang wallet key o payment header sa automation code. Dapat tahasang paganahin ng developer ang mga pagbabayad para sa session na iyon.
• Bakit mahalaga:Maaaring ipagpatuloy ng mga agent na gumagamit ng data o content na binabayaran kada request ang parehong workflow, habang nasa labas ng page at agent runtime ang instrumento sa pagbabayad, mga pahintulot ng pagkakakilanlan, at limitasyon sa paggastos. Napupunta ang tunay na desisyon sa pagbili sa imprastrakturang kailangang i-configure at subaybayan ng operator.
• Ano ang dapat bantayan:Ang mahalagang hangganan ay ang orihinal na 402 response. Kapag mali ang pagkakabuo ng challenge, hindi tugma ang payment network, naubos ang budget, o tinanggihan ang bayad, mananatiling hindi magagamit ng automation ang resource; kailangan pa ring pangasiwaan ng mga developer ang response na iyon.

Ano ang ginagawa ng browser sa bayad na page

Inilalarawan ng tutorial ng AWS at Anchor ang daloy para sa document navigation, fetch o XMLHttpRequest sa loob ng Anchor Browser session. Ibinabalik ng merchant ang HTTP 402 Payment Required na may payment challenge. Binabasa ng Anchor ang mga tuntunin at naghahanap ng paraang tugma sa instrumento sa pagbabayad na naka-link sa session. Sinusuri ng AgentCore ang natitirang budget ng session at ginagamit ang naka-configure na wallet provider upang lumagda sa patunay. Idinadagdag ng browser ang patunay sa orihinal na request at isang beses itong inuulit, gamit ang PAYMENT-SIGNATURE para sa x402 v2 o X-PAYMENT para sa v1. Bine-verify at sine-settle ng merchant ang bayad bago ibalik ang resource.

Dokumentadong pagkakasunod-sunod ito, hindi pagsubok ng BIG CHANGE sa bayad na endpoint. Ayon sa AWS, pinananatili ng browser ang konteksto ng session habang nagbabayad at umuulit ng request. Maaaring magpatuloy ang umiiral na Playwright, Puppeteer, at Chrome DevTools Protocol workflow sa pag-navigate o pagtawag sa API sa pamamagitan ng browser nang hindi sila mismo bumubuo ng payment header. Hindi nangangahulugan ang matagumpay na bayad na mababasa na ang bawat paywall: kailangang magpakita ang site ng suportadong x402 challenge, at merchant pa rin ang magpapasya kung tatanggapin ang patunay at ihahatid ang response.

Ano ang kailangang paganahin ng developer

Tahasan ang switch ng browser. Sa session request ng tutorial, session.x402 ang default na value ay false; kapag itinakda ito sa true pinahihintulutan ang mga totoong pagbabayad mula sa naka-configure na instrumento. Kailangan din ang Anchor API key upang gumawa ng browser session. Huling koneksyon ang flag na ito sa awtoridad sa pagbabayad, hindi kapalit ng pag-set up sa awtoridad na iyon.

Inilalarawan ng gabay sa AgentCore payments ng AWS ang mga batayang resource. Itinatakda ng Payment Manager ang configuration ng pagbabayad ng AWS account at gumagamit ito ng IAM role at authorizer. Ikinokonekta ito ng Payment Connector sa Coinbase Developer Platform o Stripe Privy. Hawak ng Payment Credential Provider ang mga kredensyal ng provider sa pamamagitan ng AgentCore Identity. Tinutukoy ng Payment Instrument ang wallet at network na gagamitin sa pagbili. Iniuugnay ang browser session sa AgentCore Payment Session na may limitasyon sa paggastos at expiration. Inaatas din ng quick start ng AWS na may pondo ang instrumento at bigyan ng user ang agent ng delegated signing permission bago ito makapagbayad.

Magkakahiwalay na kontrol ang mga ito. Pinamamahalaan ng IAM ang access sa serbisyo; pinahihintulutan ng wallet grant ng user ang pagpirma; itinatakda ng instrumento ang pinagmumulan ng pondo at network; at nililimitahan ng session cap ang paggastos sa loob ng panahon. Ayon sa AWS, tumatanggi ang AgentCore sa mga susunod na bayad kapag nag-expire ang session o naabot ang limitasyon nito. Ipinapakita ng observability service sa CloudWatch ang mga pagtatangka at resulta ng pagbabayad. Inilalayo ng integrasyon sa browser at agent runtime ang mga lihim ng provider, ngunit kailangan pa ring pumili ng operator ng instrument at cap na angkop sa trabaho.

Kung saan humihinto ang awtomatikong daloy

Tiyak ang inilalarawang failure behavior ng Anchor: kung mali ang 402 challenge, walang iniaalok na tugmang network, naubos ang budget, o tinanggihan ng AgentCore ang bayad, ibinabalik ng browser ang orihinal na 402 sa page nang walang pagbabago. Kaya dapat ituring ng automation na posibleng resulta pa rin ang 402 kahit naka-enable ang session. Tinutukoy ng troubleshooting guide ng AWS ang iba pang problema sa configuration, kabilang ang nawawalang IAM permission, hindi aktibong delegated signing grant, di-wastong provider credential, at nawawalang Marketplace subscription para sa Coinbase.

Para sa mga pagbabayad sa third-party resource ang switch na session.x402. Ayon sa AWS, hindi nito binabayaran ang Anchor Browser session o pinapalitan ang Anchor credits. Binabanggit ng tutorial ang paggastos at oras ng session ngunit itinuturo sa teknikal na dokumentasyon ng Anchor ang mga tiyak na limitasyon; hindi available sa artikulong ito ang mga detalyeng iyon. Nakadepende ang singil sa isang third-party request sa challenge ng merchant at sa aktuwal na settlement. Hindi namin na-verify ang end-to-end na invoice o transaksyon, kaya walang maibibigay na pangkalahatang presyo para sa naka-enable na session.

Para sa mga developer, dapat gawin ang praktikal na pasya bago makarating ang agent sa bayad na URL: ikonekta ang pinondohan at awtorisadong instrumento, magtakda ng budget para sa browser session, at paganahin lamang ang x402 kapag nilalayong bumili. Maaaring alisin ng browser ang payment protocol code sa navigation path. Hindi nito inaalis ang pananagutan ng operator sa awtoridad sa paggastos, mga nabigong request, o pagtiyak kung magkano talaga ang siningil ng merchant. Lumilitaw din ang tanong ng awtoridad sa mas malawak naming pagsusuri sa mga pagpipilian sa pagbabayad ng AI agent.

Mga source at karagdagang babasahin

• AWS at Anchor Browser, “Building agents that transact with Anchor Browser and AgentCore payments” (Oktubre 13, 2026). Inilalarawan ng integration tutorial ang opt-in ng browser, x402 challenge, mga payment header ayon sa bersyon, at pagbabalik ng orihinal na 402 kapag nabigo. Nilalarawan nito ang nilalayong daloy; hindi kami sumubok ng bayad na session.
• AWS, “How AgentCore payments works” (gabay para sa developer, binuksan noong Oktubre 14, 2026). Ipinapaliwanag nito ang Payment Manager, mga provider connector, credential ng pagkakakilanlan, instrumento, session ng paggastos, at observability. Pangkalahatang disenyo ito ng serbisyo, kasama ng tutorial na partikular sa browser.
• AWS, “AgentCore payments quick start” (gabay para sa developer, binuksan noong Oktubre 14, 2026). Ibinibigay nito ang setup para sa provider credential, pinondohan at awtorisadong instrumento, at payment session. Halimbawa lamang ang mga budget at tagal, hindi beripikadong default ng Anchor.
• AWS, “Troubleshooting AgentCore payments” (gabay para sa developer, binuksan noong Oktubre 14, 2026). Inililista nito ang mga error sa IAM, provider, wallet grant, subscription, at x402 payload na maaaring pumigil sa pagbabayad. Hindi namin muling ginawa ang mga error na ito.