Machine Payments Protocol op Solana

Het Machine Payments Protocol (MPP) past HTTP-authenticatiesemantiek toe op betalingen. Een server stuurt een challenge terug op een onbetaald verzoek, een client levert een betaalcredential aan en de server geeft een ontvangstbewijs terug nadat hij de betaling heeft geaccepteerd.

MPP scheidt drie aspecten:

  • Een intent beschrijft de commerciële interactie, zoals een eenmalige charge of een gemeten session.
  • Een betaalmethode beschrijft hoe waarde wordt verplaatst. De Solana-methode ondersteunt native SOL en SPL-tokens voor charges.
  • Een HTTP-transport draagt challenges, credentials, ontvangstbewijzen en fouten.

MPP wordt gepubliceerd als een reeks Internet-Drafts. Beschouw de actuele specificaties als de bron van waarheid en verwacht dat details veranderen zolang de drafts nog in ontwikkeling zijn.

HTTP-uitwisseling

MPP gebruikt standaard HTTP-authenticatievelden in plaats van protocolspecifieke betaalheaders:

BerichtHTTP-representatie
Betaalchallenge402 Payment Required met WWW-Authenticate: Payment ...
BetaalcredentialOpnieuw verzonden verzoek met Authorization: Payment ...
Succesvol ontvangstbewijsResource-respons met Payment-Receipt: ...
Ongeldige betaalgegevensProblem Details-body met application/problem+json
MPP Charge Flow

Een challenge bevat een door de server gegenereerde ID, realm, methode, intent, gecodeerd betaalverzoek en vervaltijd. De credential herhaalt de challenge en voegt het methodespecifieke betaalbewijs toe. De server moet beide onderdelen verifiëren; een geldige overdracht die bij een andere challenge hoort, mag de resource niet ontgrendelen.

Eenmalige Solana-charges

De Solana-charge-intent ondersteunt twee credentialtypen:

  • Pull-modus gebruikt een ondertekende transactie. De client ondertekent de overdracht en stuurt de transactie naar de server. De server verifieert, voegt optioneel een handtekening van de fee payer toe, broadcast, bevestigt en geeft de transactiehandtekening terug in zijn ontvangstbewijs.
  • Push-modus gebruikt een transactiehandtekening. De client broadcast eerst en stuurt daarna de bevestigde handtekening naar de server. De server haalt de transactie op en verifieert die voordat de resource wordt teruggegeven.

Pull-modus maakt door de server gesponsorde transactiekosten en retrylogica aan serverzijde mogelijk. Push-modus is nuttig wanneer een wallet vereist dat de client zijn eigen transactie indient, maar kan geen gebruikmaken van sponsoring van de kosten door de server.

Zie voor de normatieve velden en verificatieregels de Solana charge-specificatie.

Een MPP-charge toevoegen aan een Express-API

De Solana Pay Kit biedt een actuele TypeScript-integratie voor MPP en x402. Installeer deze samen met Express:

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

Dit minimale voorbeeld gebruikt de gehoste Surfpool-sandbox en de openbare demo-ontvanger van het pakket. Het is uitsluitend bedoeld voor lokale ontwikkeling:

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

Voer het uit en vergelijk een onbetaald verzoek met een verzoek dat rekening houdt met betalingen:

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

De route handler wordt pas uitgevoerd nadat de middleware de betaling heeft geaccepteerd.

Vervang elke sandbox-standaardwaarde in productie

Configureer een expliciet netwerk, een merchant-ontvanger, een dedicated RPC, een stabiel challenge-binding secret, een productie-signer en een duurzame replay store. Stuur echte betalingen nooit naar de demo-signer van een pakket.

Gemeten sessies

Gebruik een Solana MPP-session wanneer een client veel kleine, samenhangende betalingen gaat doen. Een sessie opent een onchain betaalkanaal met een maximale storting en gebruikt vervolgens cumulatieve ondertekende vouchers naarmate het gebruik toeneemt. De server kan vouchers offchain verifiëren en later het hoogste geaccepteerde bedrag afwikkelen.

Dit is nuttig voor inferentie die per token wordt gemeten, downloads die per byte worden gemeten, live data en herhaalde toolaanroepen. Het is niet hetzelfde als het sturen van een aparte onchain betaling voor elke gebeurtenis.

MPP Session Lifecycle

Noem een sessie een sessiebetaling, betaalkanaal of begrensde herhaalde autorisatie. Noem het alleen een gestreamde betaling wanneer de service en het betalingscontract daadwerkelijk een stroom aan gebruik meten.

Verificatie in productie

Voor elke Solana-charge moet de server minimaal het volgende verifiëren:

  • De challenge is authentiek, niet verlopen, gebonden aan dit verzoek en bedoeld voor deze realm.
  • De transactie gebruikt het verwachte netwerk, de verwachte asset of mint, ontvanger, het verwachte bedrag en token program.
  • Instructies voor de fee payer of voor de associated token account zijn expliciet toegestaan en kunnen de server-signer niet leegtrekken.
  • De transactie is geslaagd op het vereiste commitment-niveau.
  • De transactiehandtekening is nog niet verbruikt.
  • De replay-controle en de consume-bewerking zijn atomair over alle serverinstanties.

Bewaar voor sessies ook de kanaalstatus, het geaccepteerde cumulatieve bedrag en de settlement watermark in een gedeelde store. Documenteer hoe clients ongebruikte middelen terugkrijgen als de server niet meer beschikbaar is.

Gerelateerde bronnen

Is this page helpful?

Inhoudsopgave

Pagina Bewerken
© 2026 Solana Foundation. Alle rechten voorbehouden.