Machine Payments Protocol auf Solana

Das Machine Payments Protocol (MPP) überträgt die Semantik der HTTP- Authentifizierung auf Zahlungen. Ein Server fordert bei einer unbezahlten Anfrage eine Zahlung an (Challenge), ein Client sendet ein Zahlungs-Credential zurück, und der Server liefert einen Beleg (Receipt), nachdem er die Zahlung akzeptiert hat.

MPP trennt drei Aspekte:

• Ein Intent beschreibt die kommerzielle Interaktion, etwa eine einmalige charge oder eine nutzungsbasierte session.
• Eine Zahlungsmethode beschreibt, wie Werte übertragen werden. Die Solana-Methode unterstützt natives SOL und SPL-Token für Charges.
• Ein HTTP-Transport überträgt Challenges, Credentials, Receipts und Fehler.

MPP wird als Reihe von Internet-Drafts veröffentlicht. Betrachte die aktuellen Spezifikationen als maßgebliche Quelle und rechne damit, dass sich Details weiterentwickeln, solange die Drafts in Arbeit sind.

HTTP-Austausch

MPP verwendet standardmäßige HTTP-Authentifizierungsfelder statt protokollspezifischer Zahlungs-Header:

Eine Challenge enthält eine vom Server generierte ID, Realm, Methode, Intent, codierte Zahlungsanforderung und Ablaufzeit. Das Credential greift die Challenge auf und ergänzt den methodenspezifischen Zahlungsnachweis. Der Server muss beides verifizieren; eine gültige Überweisung, die zu einer anderen Challenge gehört, darf die Ressource nicht freischalten.

Einmalige Solana-Charges

Der Solana-Intent charge unterstützt zwei Credential-Typen:

• Der Pull-Modus verwendet eine signierte Transaktion. Der Client signiert die Überweisung und sendet die Transaktion an den Server. Der Server verifiziert sie, fügt optional eine Fee-Payer-Signatur hinzu, überträgt sie ins Netzwerk, bestätigt sie und gibt die Transaktions- signatur in seinem Receipt zurück.
• Der Push-Modus verwendet eine Transaktionssignatur. Der Client überträgt zuerst ins Netzwerk und sendet dann die bestätigte Signatur an den Server. Der Server ruft die Transaktion ab und verifiziert sie, bevor er die Ressource zurückgibt.

Der Pull-Modus ermöglicht vom Server übernommene Transaktions-Fees und serverseitige Wiederholungslogik. Der Push-Modus ist nützlich, wenn eine Wallet verlangt, dass der Client seine eigene Transaktion einreicht, kann aber kein Fee-Sponsoring durch den Server nutzen.

Die verbindlichen Felder und Verifizierungsregeln findest du in der Spezifikation zur Solana-Charge.

Eine MPP-Charge zu einer Express-API hinzufügen

Das Solana Pay Kit bietet eine aktuelle TypeScript-Integration für MPP und x402. Installiere es zusammen mit Express:

pnpm add @solana/pay-kit @solana/kit@^6.9.0 express
pnpm add --save-dev @types/express tsx

Dieses minimale Beispiel verwendet die gehostete Surfpool-Sandbox und den öffentlichen Demo-Empfänger des Pakets. Es ist ausschließlich für die lokale Entwicklung gedacht:

import express from "express";
import { createPayKit, usd } from "@solana/pay-kit";

const pay = await createPayKit({
  accept: ["mpp"],
  rpcUrl: "https://402.surfnet.dev:8899"
});

const app = express();

app.get("/report", pay.express(usd("0.01")), (_req, res) => {
  res.json({ report: "Paid report" });
});

app.listen(4567, () => {
  console.log("Paid API listening on http://127.0.0.1:4567");
});

Führe es aus und vergleiche eine unbezahlte Anfrage mit einer zahlungsfähigen Anfrage:

pnpm tsx server.ts
curl -i http://127.0.0.1:4567/report
pay --sandbox curl http://127.0.0.1:4567/report

Der Route-Handler wird erst ausgeführt, nachdem die Middleware die Zahlung akzeptiert hat.

Nutzungsbasierte Sessions

Verwende eine Solana-MPP-session, wenn ein Client viele kleine, zusammenhängende Zahlungen tätigt. Eine Session eröffnet einen Onchain-Zahlungskanal mit einer maximalen Einzahlung und verwendet dann kumulative signierte Voucher, während die Nutzung wächst. Der Server kann Voucher offchain verifizieren und den höchsten akzeptierten Betrag später abrechnen.

Das eignet sich für token-basierte Inferenz, bytebasierte Downloads, Live-Daten und wiederholte Tool-Aufrufe. Es ist nicht dasselbe wie eine separate Onchain- Zahlung für jedes einzelne Ereignis.

Bezeichne eine Session als Session-Zahlung, Zahlungskanal oder gedeckelte wiederholte Autorisierung. Nenne sie nur dann eine gestreamte Zahlung, wenn der Dienst und der Zahlungs- vertrag tatsächlich einen Nutzungsstrom abrechnen.

Verifizierung in der Produktion

Bei jeder Solana-Charge muss der Server mindestens Folgendes verifizieren:

• Die Challenge ist authentisch, nicht abgelaufen, an diese Anfrage gebunden und für diesen Realm bestimmt.
• Die Transaktion verwendet das erwartete Netzwerk, Asset bzw. Mint, den Empfänger, den Betrag und das token program.
• Alle Anweisungen für Fee-Payer oder associated token account sind ausdrücklich erlaubt und können den Signer des Servers nicht leeren.
• Die Transaktion war auf dem erforderlichen Commitment-Level erfolgreich.
• Die Transaktionssignatur wurde noch nicht verbraucht.
• Die Replay-Prüfung und der Verbrauchsvorgang sind über alle Serverinstanzen hinweg atomar.

Speichere bei Sessions außerdem den Kanalstatus, den akzeptierten kumulativen Betrag und den Abrechnungs-Watermark in einem gemeinsamen Speicher. Dokumentiere, wie Clients nicht genutzte Gelder zurückerhalten, falls der Server nicht mehr verfügbar ist.

Weiterführende Ressourcen

• MPP-Spezifikationen
• MPP-Protokolldokumentation
• Solana Pay Kit
• Überblick über Agentic Payments
• Produktionsreife