Machine Payments Protocol sur Solana

Le Machine Payments Protocol (MPP) applique la sémantique d'authentification HTTP aux paiements. Un serveur lance un défi en réponse à une requête non payée, un client renvoie un identifiant de paiement, et le serveur renvoie un reçu après avoir accepté le paiement.

Le MPP distingue trois aspects :

• Une intention (intent) décrit l'interaction commerciale, comme un paiement ponctuel charge ou une session à la consommation.
• Une méthode de paiement décrit la façon dont la valeur circule. La méthode Solana prend en charge les SOL natifs et les jetons SPL pour les paiements ponctuels.
• Un transport HTTP véhicule les défis, les identifiants, les reçus et les erreurs.

Le MPP est publié sous la forme d'un ensemble d'Internet-Drafts. Considérez les spécifications actuelles comme la source de référence et attendez-vous à ce que les détails évoluent tant que les drafts sont en cours de rédaction.

Échange HTTP

Le MPP utilise les champs d'authentification HTTP standard plutôt que des en-têtes de paiement propres au protocole :

Un défi comprend un ID généré par le serveur, un realm, une méthode, une intention, une demande de paiement encodée et une date d'expiration. L'identifiant reprend le défi et y ajoute la preuve de paiement propre à la méthode. Le serveur doit vérifier ces deux éléments : un transfert valide appartenant à un autre défi ne doit pas déverrouiller la ressource.

Paiements ponctuels sur Solana

L'intention charge de Solana prend en charge deux types d'identifiants :

• Le mode pull utilise une transaction signée. Le client signe le transfert et envoie la transaction au serveur. Le serveur la vérifie, ajoute éventuellement une signature de payeur des frais, la diffuse, la confirme, puis renvoie la signature de la transaction dans son reçu.
• Le mode push utilise une signature de transaction. Le client diffuse d'abord la transaction, puis envoie la signature confirmée au serveur. Le serveur récupère et vérifie la transaction avant de renvoyer la ressource.

Le mode pull permet la prise en charge des frais de transaction par le serveur et une logique de nouvelle tentative côté serveur. Le mode push est utile lorsqu'un portefeuille exige que le client soumette lui-même la transaction, mais il ne peut pas bénéficier de la prise en charge des frais par le serveur.

Pour connaître les champs normatifs et les règles de vérification, consultez la spécification du paiement ponctuel Solana.

Ajouter un paiement MPP à une API Express

Le Solana Pay Kit fournit une intégration TypeScript à jour pour MPP et x402. Installez-le avec Express :

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

Cet exemple minimal utilise le bac à sable Surfpool hébergé et le destinataire de démonstration public du package. Il est réservé au développement local :

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");
});

Exécutez-le et comparez une requête non payée avec une requête compatible avec le paiement :

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

Le gestionnaire de route ne s'exécute qu'une fois que le middleware a accepté le paiement.

Sessions à la consommation

Utilisez une session MPP Solana lorsqu'un client effectuera de nombreux petits paiements liés entre eux. Une session ouvre un canal de paiement onchain avec un dépôt maximal, puis utilise des bons signés cumulatifs à mesure que la consommation augmente. Le serveur peut vérifier les bons offchain et régler plus tard le montant accepté le plus élevé.

C'est utile pour l'inférence facturée au jeton, les téléchargements facturés à l'octet, les données en direct et les appels d'outils répétés. Ce n'est pas la même chose que d'envoyer un paiement onchain distinct pour chaque événement.

Parlez de paiement de session, de canal de paiement ou d'autorisation répétée plafonnée. Ne parlez de paiement en flux continu que lorsque le service et le contrat de paiement mesurent réellement un flux d'utilisation.

Vérification en production

Pour chaque paiement ponctuel Solana, le serveur doit au minimum vérifier que :

• Le défi est authentique, non expiré, lié à cette requête et destiné à ce realm.
• La transaction utilise le réseau, l'actif ou le mint, le destinataire, le montant et le programme de jetons attendus.
• Toute instruction de payeur des frais ou de compte de jeton associé est explicitement autorisée et ne peut pas vider le signataire du serveur.
• La transaction a abouti au niveau de commitment requis.
• La signature de la transaction n'a pas déjà été consommée.
• La vérification de rejeu et l'opération de consommation sont atomiques sur toutes les instances du serveur.

Pour les sessions, conservez également l'état du canal, le montant cumulatif accepté et le repère de règlement dans un magasin partagé. Documentez la manière dont les clients récupèrent les fonds inutilisés si le serveur devient indisponible.

Ressources associées

• Spécifications du MPP
• Documentation du protocole MPP
• Solana Pay Kit
• Présentation des paiements agentiques
• Préparation à la production