AI-translated from English; not yet reviewed by a fluent editor. # Zahlungen mit Anchor Browser und AgentCore: Wie ein Agent eine x402-Paywall passiert > Anchor Browser kann eine x402-kostenpflichtige Seite oder einen API-Aufruf über AgentCore payments erneut anfragen, wenn ein Entwickler die Sitzung aktiviert und ein autorisiertes Zahlungsinstrument mit Budget konfiguriert. By BIG CHANGE Editorial Published: 2026-10-14T05:55:23.177Z Updated: 2026-10-14T05:55:23.177Z Canonical: https://bigchange.ai/blog/anchor-browser-agentcore-x402-payments ![A payment card and blank purchase order sit on a track beside an adjustable mechanical stop with an orange knob.](https://bigchange.ai/api/media/file/payment-authority-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. Delegating a purchase still requires a boundary around payment authority. The intact card, order and adjustable stop are a conceptual illustration, not a depiction of a specific product. AWS und Anchor Browser haben eine [Integration dokumentiert](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) mit der ein Browser-Agent während seiner bestehenden Sitzung für eine durch x402 geschützte Seite oder API bezahlen kann. Der Browser kann auf eine HTTP-402-Zahlungsaufforderung reagieren, einen signierten Zahlungsnachweis von Amazon Bedrock AgentCore payments erhalten und die Anfrage wiederholen. Für Entwickler ist entscheidend, wo diese Arbeit stattfindet: Der Browser verarbeitet Herausforderung und Wiederholung, während ein separat konfigurierter Zahlungsdienst die Ausgabeberechtigung prüft. ## Die wesentliche Änderung - **Was sich geändert hat:**Eine kostenpflichtige Webanfrage kann nach einer x402-Herausforderung innerhalb der Browser-Sitzung des Agenten abgeschlossen werden, ohne einen Wallet-Schlüssel oder Zahlungsheader in den Automatisierungscode aufzunehmen. Der Entwickler muss Zahlungen für diese Sitzung ausdrücklich aktivieren. - **Warum das wichtig ist:**Agenten, die Daten oder Inhalte mit Abrechnung pro Anfrage nutzen, können denselben Arbeitsablauf fortsetzen. Zahlungsinstrument, Identitätsberechtigungen und Ausgabenlimit liegen außerhalb der Seite und der Agent-Laufzeit. Damit wandert die tatsächliche Kaufentscheidung in eine Infrastruktur, die der Betreiber konfigurieren und überwachen muss. - **Worauf zu achten ist:**Die entscheidende Grenze ist die ursprüngliche 402-Antwort. Eine fehlerhafte Herausforderung, ein inkompatibles Zahlungsnetz, ein ausgeschöpftes Budget oder eine abgelehnte Zahlung lässt die Ressource für die Automatisierung unzugänglich; Entwickler müssen diese Antwort weiterhin behandeln. ## Was der Browser auf einer kostenpflichtigen Seite tut Das [Tutorial von AWS und Anchor](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) beschreibt den Ablauf für eine Dokumentnavigation, `fetch` oder XMLHttpRequest innerhalb einer Anchor-Browser-Sitzung. Der Händler sendet HTTP `402 Payment Required` mit einer Zahlungsaufforderung zurück. Anchor liest die Bedingungen und sucht nach einer Methode, die mit dem an die Sitzung gebundenen Zahlungsinstrument kompatibel ist. AgentCore prüft das verbleibende Sitzungsbudget und nutzt den konfigurierten Wallet-Anbieter zum Signieren eines Nachweises. Der Browser fügt diesen Nachweis zur **ursprünglichen Anfrage** hinzu und wiederholt sie einmal: mit `PAYMENT-SIGNATURE` für x402 v2 oder `X-PAYMENT` für v1. Der Händler prüft und verbucht die Zahlung, bevor er die Ressource zurückgibt. Das ist ein dokumentierter Ablauf, kein Test eines kostenpflichtigen Endpunkts durch BIG CHANGE. AWS zufolge behält der Browser während Zahlung und Wiederholung den Sitzungskontext bei. Bestehende Playwright-, Puppeteer- und Chrome-DevTools-Protocol-Abläufe können weiterhin über den Browser navigieren oder APIs aufrufen, ohne selbst Zahlungsheader zu erstellen. Eine erfolgreiche Zahlung macht auch nicht jede Paywall lesbar: Die Website muss eine unterstützte x402-Herausforderung bereitstellen, und der Händler entscheidet weiterhin, ob er den Nachweis akzeptiert und die Antwort ausliefert. ## Was Entwickler aktivieren müssen Der Schalter im Browser ist ausdrücklich zu setzen. In [der Sitzungsanfrage des Tutorials](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) ist `session.x402` standardmäßig auf `false` gesetzt; der Wert `true` erlaubt **echte Zahlungen** mit dem konfigurierten Instrument. Zum Erstellen der Browser-Sitzung ist außerdem ein Anchor-API-Schlüssel erforderlich. Das Flag stellt die letzte Verbindung zur Zahlungsberechtigung her, ersetzt aber nicht deren Einrichtung. Der [Leitfaden zu AgentCore payments von AWS](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) beschreibt die zugrunde liegenden Ressourcen. Payment Manager definiert die Zahlungskonfiguration des AWS-Kontos und verwendet eine IAM-Rolle sowie einen Authorizer. Payment Connector verbindet mit Coinbase Developer Platform oder Stripe Privy. Payment Credential Provider verwahrt die Anbieter-Zugangsdaten über AgentCore Identity. Payment Instrument bestimmt Wallet und Netzwerk für den Kauf. Die Browser-Sitzung ist mit einer AgentCore Payment Session mit Ausgabenlimit und Ablaufzeit verknüpft. Der [Schnellstart](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) von AWS verlangt außerdem, dass das Instrument gedeckt ist und der Nutzer dem Agenten vor dem Bezahlen eine delegierte Signierberechtigung erteilt. Das sind getrennte Kontrollen. IAM regelt den Zugriff auf den Dienst; die Wallet-Freigabe des Nutzers erlaubt das Signieren; das Instrument legt Geldquelle und Netzwerk fest; das Sitzungslimit begrenzt die Ausgaben über einen Zeitraum. AWS zufolge verweigert AgentCore weitere Zahlungen, wenn die Sitzung abläuft oder ihr Limit erreicht ist. Der Observability-Dienst zeigt Zahlungsversuche und Ergebnisse in CloudWatch. Die Integration hält Anbieter-Geheimnisse aus Browser und Agent-Laufzeit heraus; der Betreiber muss dennoch Instrument und Limit passend zur Aufgabe auswählen. ## Wo der automatisierte Ablauf endet Anchors dokumentiertes Fehlerverhalten ist konkret: Ist die 402-Herausforderung fehlerhaft, wird kein kompatibles Netzwerk angeboten, ist das Budget ausgeschöpft oder lehnt AgentCore die Zahlung ab, gibt der Browser die **ursprüngliche 402-Antwort** unverändert an die Seite zurück. Automatisierungen sollten daher auch bei aktivierter Sitzung mit einer 402-Antwort rechnen. Der [Fehlerbehebungsleitfaden von AWS](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) nennt weitere Konfigurationsprobleme, darunter fehlende IAM-Berechtigungen, eine inaktive delegierte Signierfreigabe, ungültige Anbieter-Zugangsdaten und bei Coinbase ein fehlendes Marketplace-Abonnement. Der Schalter `session.x402` gilt für Zahlungen an Ressourcen Dritter. AWS zufolge bezahlt er weder die Anchor-Browser-Sitzung noch ersetzt er Anchor-Credits. Das Tutorial erwähnt Ausgaben- und Zeitlimits der Sitzung, verweist für konkrete Grenzen aber auf die technische Dokumentation von Anchor; diese Details lagen für diesen Artikel nicht vor. Die Kosten einer konkreten Drittanbieteranfrage hängen von der Herausforderung des Händlers und der tatsächlichen Abwicklung ab. Wir haben weder eine Rechnung noch eine Transaktion von Anfang bis Ende überprüft; der Artikel kann daher keinen allgemeinen Preis für eine aktivierte Sitzung nennen. Für Entwickler fällt die praktische Entscheidung an, bevor der Agent eine kostenpflichtige URL erreicht: ein gedecktes, autorisiertes Instrument verbinden, ein Budget für die Browser-Sitzung festlegen und x402 nur dann aktivieren, wenn Käufe beabsichtigt sind. Der Browser kann Zahlungsprotokollcode aus dem Navigationspfad entfernen. Die Verantwortung des Betreibers für Ausgabeberechtigung, fehlgeschlagene Anfragen und die Prüfung des tatsächlich vom Händler berechneten Betrags bleibt bestehen. Diese Berechtigungsfrage zieht sich auch durch unsere [umfassendere Untersuchung der Zahlungsoptionen für KI-Agenten](https://bigchange.ai/blog/ai-agent-payments-stablecoins-bank-deposits). ## Quellen und weiterführende Lektüre - [AWS und Anchor Browser, „Building agents that transact with Anchor Browser and AgentCore payments“](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) (13. Oktober 2026). Das Integrationstutorial dokumentiert die optionale Browser-Aktivierung, die x402-Herausforderung, versionsspezifische Zahlungsheader und die unveränderte Rückgabe der ursprünglichen 402-Antwort bei den beschriebenen Fehlern. Es beschreibt den vorgesehenen Ablauf; wir haben keine kostenpflichtige Sitzung getestet. - [AWS, „How AgentCore payments works“](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) (Entwicklerleitfaden, abgerufen am 14. Oktober 2026). Erläutert Payment Manager, Anbieter-Connectoren, Identitätszugangsdaten, Instrumente, Ausgabensitzungen und Observability. Dies ist das allgemeine Servicedesign neben dem browserspezifischen Tutorial. - [AWS, „AgentCore payments quick start“](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) (Entwicklerleitfaden, abgerufen am 14. Oktober 2026). Beschreibt die Einrichtung von Anbieter-Zugangsdaten, eines gedeckten und autorisierten Instruments sowie einer Zahlungssitzung. Beispielbudgets und -dauern sind Illustrationen, keine verifizierten Anchor-Standardwerte. - [AWS, „Troubleshooting AgentCore payments“](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) (Entwicklerleitfaden, abgerufen am 14. Oktober 2026). Listet IAM-, Anbieter-, Wallet-Freigabe-, Abonnement- und x402-Payload-Fehler, die Zahlungen verhindern können. Wir haben diese Fehler nicht reproduziert. ## Sources - [AWS Machine Learning Blog, Building agents that transact with Anchor Browser and AgentCore payments](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) — Zentrales Integrationstutorial. Dokumentiert den Standardwert von session.x402 und die Aktivierung echter Zahlungen, den Ablauf zwischen Browser und AgentCore, den einmaligen Wiederholungsversuch sowie die unveränderte Rückgabe der ursprünglichen 402-Antwort bei den aufgeführten Fehlern. Das sind vom Anbieter beschriebene Funktionen; BIG CHANGE hat keine kostenpflichtige Sitzung ausgeführt. Eine separate Aussage über zusammengefasste Anchor-Credits und Abrechnung wurde nicht unabhängig mit den Dokumenten zur AgentCore-Wallet-Finanzierung abgeglichen und wird nicht als allgemeines Abrechnungsmodell wiederholt. - [AWS, How AgentCore payments works](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) — Gepflegte Referenz zu Architektur und Kontrollen des Dienstes. Definiert Payment Manager, Connector, Identity Credential Provider, Instrument, Sitzungsgrenzen und Ablauf, Wallet-Freigabe des Nutzers, Zahlungsablauf und Observability. Der allgemeine x402-Ablauf verwendet X-PAYMENT; das Anchor-spezifische Tutorial unterscheidet den PAYMENT-SIGNATURE-Header von x402 v2. - [AWS, AgentCore payments quick start](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) — Einrichtungsweg und Voraussetzungen, darunter die Verbindung zu Coinbase oder Stripe Privy, ein gedecktes Instrument, delegierte Signierberechtigung und eine zeitlich begrenzte Zahlungssitzung. Beispielbeträge und -dauern sind keine Anchor-Standardwerte oder -Obergrenzen. - [AWS, Troubleshooting AgentCore payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) — Dokumentiert Berechtigungs-, Abonnement-, Wallet-Freigabe-, Zugangsdaten- und x402-Payload-Fehler. Dienstseitige Fehler ergänzen das im Anchor-Browser-Tutorial beschriebene Verhalten, die ursprüngliche 402-Antwort zurückzugeben; hier wurde kein Fehlerpfad getestet.