x402 und MPP ermöglichen es Software, für Web-Dienste zu bezahlen, aber Clients benötigen Unterstützung für das gewählte Protokoll und die Zahlungsmethode. Vergleiche den Abrechnungs-Workflow, die unterstützte Implementierung und den Rückgewinnungspfad, bevor du dich entscheidest.
Eine Festpreis-Anfrage und eine metered Browser-Session benötigen unterschiedliche Buchhaltung. Weder der Protokollname noch eine Stablecoin-Option verraten dir, ob dein Merchant-Stack beides unterstützt.
Wo die Zahlungsanfrage erscheint
x402 nutzt HTTP 402-Antworten, um die Zahlungsanforderungen einer Ressource zu kommunizieren. Ein kompatibler Client liefert eine Payment-Payload, und der Verkäufer verifiziert und begleicht diese unter dem ausgewählten Schema. V2 spezifiziert die zahlungsbezogenen Header für diesen Austausch. x402 HTTP-Flow.
MPP definiert ebenfalls eine HTTP-Zahlungsherausforderung und eine Client-Antwort, wobei Belege den erfolgreichen Zahlungsvorgang dokumentieren. Sein Design trennt die angeforderte Zahlungsabsicht von der Zahlungsmethode, die zur Erfüllung verwendet wird. Machine Payments Protocol.
Diese gemeinsamen Ziele begründen keine Kompatibilität auf Wire-Ebene. Ein Client und ein Server müssen dasselbe Protokoll, dieselbe Version und dieselbe Methode unterstützen. Ein Dienst, der beides anbietet, muss beide korrekt implementieren, anstatt anzunehmen, dass ein Header einfach in den anderen umbenannt werden kann.
Ein Agent-Framework kann mehrere Zahlungsclients unterstützen. Das ist eine Entscheidung bei der Produktintegration, die mit Test- und Wartungskosten verbunden ist. Der Agent benötigt immer noch eine Policy, die entscheidet, welche Angebote er annehmen darf.
Wähle einen Abrechnungspfad vor einem Protokoll
Eine einzelne bezahlte Anfrage und eine laufende metered Session benötigen unterschiedliche Autorisierung und Buchhaltung.
Ein Protokoll und ein Prozessor unterscheiden sich
Das Protokoll beschreibt, wie die Teilnehmer kommunizieren. Eine Merchant-Integration liefert eine funktionierende Möglichkeit, eine Zahlung zu verifizieren, Geld zu bewegen und dies zu protokollieren. Handelsgebühren, die Teilnahmeberechtigung von Kunden und der Betriebssupport können von dieser Integration abhängen.
Stripe hat MPP gemeinsam mit Tempo verfasst und beschreibt eine Integration über seine PaymentIntents-API. Die Ankündigung umfasst Stablecoin- und Fiat-Zahlungsoptionen, wobei Shared Payment Tokens für unterstützte konventionelle Zahlungsmethoden verwendet werden. Stripe MPP-Ankündigung.
x402 unterstützt ebenfalls verschiedene Facilitator-Pfade. Ein Merchant kann einen Managed Service nutzen, seinen eigenen Facilitator betreiben oder Abrechnungsfunktionen innerhalb seines eigenen Servers ausführen. Die unterstützten Schemata und Netzwerke hängen von den gewählten Komponenten ab. x402-Facilitator-Pfade.
Dies ist wichtig beim Vergleich der Gebühren. Eine Spezifikation kann offen sein, während die komfortable Managed-Route für den Betrieb des Dienstes Gebühren erhebt. Ein „gasfreies“ Käufer-Erlebnis kann beinhalten, dass eine andere Partei die Netzwerkkosten übernimmt. Das vollständige Angebot sollte diese Parteien identifizieren.
Sessions verändern das Abrechnungsproblem
Eine Session ermöglicht es einem Dienst, eine kommerzielle Beziehung über eine Sequenz von Interaktionen hinweg aufrechtzuerhalten. Dies kann für Streaming-Outputs, gemietete Infrastruktur oder die wiederholte Nutzung von Tools geeignet sein. Der Kunde benötigt eine Ausgabenobergrenze, eine Möglichkeit, die Nutzung zu stoppen, und eine Aufzeichnung der akkumulierten Gebühren.
MPP bietet einen sessionsorientierten Zahlungspfad in seinem dokumentierten Method-Ökosystem. Dies sollte nicht auf jede Merchant-Implementierung verallgemeinert werden, die jedes Session-Feature unterstützt. Die Unterstützung von Methoden muss auf der Client- und Serverseite überprüft werden. MPP-Session-Dokumentation.
x402 ist nicht auf eine feste Gebühr für jeden HTTP-Aufruf beschränkt. Sein aktuelles Scheme-Set umfasst „exact“, „up-to“, „batch settlement“ und „auth-capture“. Ein Vergleich, der die Aggregation nur MPP zuschreibt, übersieht einen Teil des aktuellen x402-Designs. x402-Zahlungsschemata.
Die praktische Frage ist, wie die Messsysteme deines Dienstes funktionieren. Die Abrechnung eines einzelnen Datenelements ist leicht zu definieren. Die Abrechnung einer offenen Forschungs-Session erfordert Regeln für abgebrochene Aufrufe, nicht genutztes Budget und Operationen mit variablen Kosten.
Vergleich des vollständigen Kaufs des Kunden
| Frage | x402-Pfad | MPP-Pfad |
|---|---|---|
| Wie fordert der Server die Zahlung an? | HTTP 402 mit Scheme und Zahlungsanforderungen | HTTP-Payment-Challenge mit Intent- und Method-Informationen |
| Welche Abrechnungsformen solltest du prüfen? | Unterstützung für Exact, Up-to, Batch Settlement und Auth-Capture | Einmalige Gebühren und methodenspezifische Sessions |
| Wer führt die Zahlungsoperationen aus? | Ausgewählter Facilitator oder serverseitige Implementierung | Ausgewählte Zahlungsmethode und Service-Integration |
| Muss der Käufer eine bestimmte Chain nutzen? | Abhängig von den akzeptierten Scheme/Network-Paaren | Abhängig von der gewählten Methode, nicht allein vom MPP-Namen |
| Was benötigt zusätzliche Produktarbeit? | Budget-Policy, Lieferung, Discovery und Belege | Budget-Policy, Lieferung, Discovery und Belege |
Die Tabelle beschreibt Design-Fragen Stand 13. Oktober 2026. Sie garantiert nicht, dass jedes SDK oder jeder Prozessor jede Option unterstützt. Eine Integrationsprüfung sollte die tatsächlichen Versionen und unterstützten Routen festlegen.
Für eine Wetterabfrage zu einem Festpreis benötigen beide Routen ein klares Angebot und einen rückforderbaren Kauf. Für einen pro Minute gemieteten Browser: Beende die Sitzung vorzeitig und prüfe die endgültige Belastung sowie die nicht genutzte Autorisierung. Dieser Test zeigt auf, ob die Integration das Abrechnungsverhalten unterstützt, das der Kunde erwartet.
MPP dokumentiert auch Adapter für bestehende x402-Services. Diese können den Integrationsaufwand reduzieren, während die zugrunde liegenden Protokollunterschiede erhalten bleiben; sie machen nicht jeden Client automatisch mit jeder Methode kompatibel. MPP mit x402 verwenden.
Die Fehlerfälle entscheiden über den Arbeitsaufwand
Betrachte eine Zahlungsautorisierung, die kurz vor einem Netzwerk-Timeout akzeptiert wurde. Der Käufer weiß nicht, ob der Verkäufer die Anfrage erfüllt hat. Ein erneuter Versuch mit einer neuen Zahlung kann die Belastung duplizieren; ein erneuter Versuch ohne ausreichende Informationen kann dazu führen, dass der Auftrag ungelöst bleibt.
Die Integration benötigt eine stabile Kaufidentität und einen Abstimmungspfad. Ein Protokollbeleg kann helfen, das Zahlungsergebnis zu beschreiben, aber der Ressourcenservice muss es dennoch mit der gelieferten Arbeit verknüpfen. x402-Zahlungsidentifikatoren.
Betrachte eine Sitzung mit einem hängengebliebenen Client und einem Verkäufer, der weiterhin Gebühren erhebt. Die Ausgabenbegrenzung sollte auch dann durchsetzbar bleiben, wenn der Agent die Verbindung verliert. „Der Agent wird die Sitzung schließen“ ist ein schwacher Schutz, wenn der Agent abgestürzt ist.
Dies sind normale Geschäftsabläufe, keine exotischen Angriffe. Deren Test bietet einen besseren Beleg für die Einsatzbereitschaft als das Zählen erfolgreicher Anfragen in einer sauberen Demonstration.
Eine Zahlungsmethode beurteilt das Angebot nicht
Ein Agent kann erfolgreich auf einem minderwertigen Datensatz ausgeben. Er kann dieselbe Antwort von mehreren Diensten kaufen oder einen Preis akzeptieren, der höher ist als der Wert der Aufgabe. Der Zahlungsmechanismus wird nicht entscheiden, ob der Kauf verschwenderisch war.
Diese Entscheidung gehört zur Richtlinie des Agenten und zum Prozess der Dienstleistungsauswahl. Der Wallet-Artikel trennt Transaktionslimits von breiteren Aufgabenbudgets. Der Identitätsartikel untersucht die Beweise, die ein Agent verwenden kann, wenn er einen anderen Agenten oder Dienst beurteilt.
Für Händler können vorhersehbare Antwortqualität und Preisgestaltung wichtiger sein als ein winziger Unterschied beim Zahlungsaufwand. Der Kunde sollte bestimmen können, was er erhalten wird, bevor er bezahlt. Der Verkäufer-Leitfaden konzentriert sich auf dieses Angebot.
Wähle die unterstützte Route, dann vergleiche
Notiere das Zahlungsasset, die Methode, die Abrechnungseinheit und die maximale Exposition. Kläre, wer die Abrechnung einreicht und wie der Verkäufer eine fehlgeschlagene Lieferung protokolliert. Teste dann den Pfad mit denselben Einschränkungen unter beiden Kandidaten-Integrationen.
Ein Händler, der bereits eine Zahlungsplattform nutzt, schätzt möglicherweise deren Buchhaltung und Support. Ein Dienst, der sich an Stablecoin-native Clients richtet, bevorzugt möglicherweise einen anderen Betriebspfad. Keine der Präferenzen macht das zugrunde liegende Protokoll universell besser.
Der finanzielle Vergleich ist der nächste Schritt. Unser Mikrozahlungsrechner zeigt, wie die Abrechnungsfrequenz das Ergebnis verändern kann, selbst wenn der Kunde denselben Preis pro Anfrage zahlt.
Ein nützlicher Kompatibilitätstest
Nimm einen Endpunkt mit Festpreis und eine metered Session. Halte für jede Kandidaten-Integration die Client-Version, die Merchant-Version, die akzeptierte Methode, die maximale Autorisierung und das Abbruchverhalten fest.
Ein Client, der den Festpreis-Test besteht, hat diese Route nachgewiesen. Er hat jedoch kein Streaming, keinen Session-Abschluss oder jede vom Protokoll beworbene Methode nachgewiesen. Umgekehrt stellt ein Adapter, der eine x402-Zahlung abwickelt, keine allgemeine Kompatibilität mit jedem x402-Schema her. Die unterstützte Schnittmenge ist das Produkt, das du bereitstellen kannst. MPP-Integration mit x402.