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
chargeof een gemetensession. - 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:
| Bericht | HTTP-representatie |
|---|---|
| Betaalchallenge | 402 Payment Required met WWW-Authenticate: Payment ... |
| Betaalcredential | Opnieuw verzonden verzoek met Authorization: Payment ... |
| Succesvol ontvangstbewijs | Resource-respons met Payment-Receipt: ... |
| Ongeldige betaalgegevens | Problem Details-body met application/problem+json |
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 expresspnpm 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.tscurl -i http://127.0.0.1:4567/reportpay --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.
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?