Die Aufgabe – und ihre Grenze
MPP beschreibt maschinelle Zahlungen im Request-/Response-Fluss und trennt den allgemeinen Ablauf von konkreten Zahlungsmethoden. Das Projekt umfasst einmalige Zahlungen und Sessions. Ein aktives SDK-Ökosystem und der formale Status eines Standardisierungsdokuments sind dabei unterschiedliche Dinge.
Nicht dafür gedacht: Kein vollständiger Handelsprozess und kein verabschiedeter IETF-Standard.
Wie es sich in den Stack einfügt
- Überlappt mit x402 und L402 bei kostenpflichtigen Ressourcen.
- Zahlungsmethodenspezifische Erweiterungen benötigen eigene Unterstützung; Integration ist nicht gleich universelle Kompatibilität.
Release und Arbeitsfassung getrennt
- Veröffentlichter Stand
- Keine eigenständige Releaseversion verifiziert
- Arbeitsfassung
- draft-ryan-httpauth-payment-01
Der individuelle Internet-Draft ist abgelaufen und archiviert; letzte Revision 17. März 2026. Projektstart öffentlich am 18. März 2026. Keine globale „MPP 1.0“-Version verifiziert.
- Lizenz / Bedingungen
- Spezifikation und SDKs haben getrennte Lizenzgrundlagen; SDKs überwiegend MIT bzw. MIT OR Apache-2.0.
Originalbedingungen prüfen ↗ - Quellenprüfung
- · Kein Installations- oder Konformitätstest
Ein konkreter Ablauf
Die Schritte ordnen die Rolle des Protokolls ein. Sie sind kein ausführbarer oder getesteter Quickstart.
- Der Server beschreibt eine Zahlungsanforderung für die Ressource.
- Der Client wählt eine unterstützte Methode und erstellt den erforderlichen Nachweis.
- Der Server prüft den Nachweis; Sessions und weitere Methoden folgen ihren jeweiligen Regeln.
SDKs und Implementierungswege
Die Einträge unterscheiden Bibliotheken, Modelle und Beispiele. Paketnamen sind Upstream-Einstiege, keine hier getesteten Installationsempfehlungen. Prüfen Sie vor der Integration die exakte Version und deren Spezifikationsunterstützung.
mppx
Artefakt: TypeScript-SDK
Paket / Modul: mppx
Version & Kompatibilität: Manifest 0.13.5 beobachtet, nicht Registry-Latest bestätigt
MIT; keine Installation oder Zahlungsprüfung in diesem Hub.
pympp
Artefakt: Python-SDK
Paket / Modul: pympp
Version & Kompatibilität: Versionsstand vor Integration pinnen
MIT OR Apache-2.0.
mpp-go
Artefakt: Go-SDK
Paket / Modul: github.com/tempoxyz/mpp-go
Version & Kompatibilität: Versionsstand vor Integration pinnen
MIT-/Apache-Lizenzdateien; konkrete Dateien vor Weiterverteilung prüfen.
mpp-rs
Artefakt: Rust-SDK
Paket / Modul: mpp
Version & Kompatibilität: Versionsstand vor Integration pinnen
MIT OR Apache-2.0.
mpp-rb
Artefakt: Ruby-SDK von Stripe
Paket / Modul: mpp-rb
Version & Kompatibilität: Versionsstand vor Integration pinnen
MIT; nicht denselben Reifegrad wie andere SDKs unterstellen.
Was für den Betrieb offen bleibt
- Abgelaufener Internet-Draft bedeutet nicht eingestellte Projektentwicklung, aber auch keine IETF-Ratifikation.
- SDK-Reife, Zahlungsweg und Produktionsbedingungen pro Sprache und Methode prüfen.
Eine offene Spezifikation erteilt keine automatische Erlaubnis für Zahlungen oder Verkaufskanäle. Testmodus, Benutzerfreigabe und Produktionszulassung bleiben eigene Schritte.
Originalquellen
Redaktioneller Stand: . Ein Versionsstand gilt für die genannte Spezifikation oder Bibliothek, nicht automatisch für andere Sprachpakete. „Nicht verifiziert“ bedeutet nicht „existiert nicht“.