Machine Payments Protocol (MPP), HTTP kimlik doğrulama semantiğini ödemelere uygular. Sunucu ödenmemiş bir isteğe challenge ile yanıt verir, istemci bir ödeme kimlik bilgisi (credential) gönderir ve sunucu ödemeyi kabul ettikten sonra bir makbuz döndürür.
MPP üç konuyu birbirinden ayırır:
- Bir intent (amaç), tek seferlik bir
chargeveya ölçümlü birsessiongibi ticari etkileşimi tanımlar. - Bir ödeme yöntemi, değerin nasıl aktarıldığını tanımlar. Solana yöntemi, ücretler (charge) için yerel SOL ve SPL token'larını destekler.
- Bir HTTP taşıma katmanı (transport) challenge'ları, kimlik bilgilerini, makbuzları ve hataları taşır.
MPP, bir dizi Internet-Draft olarak yayımlanır. Güncel spesifikasyonları tek doğru kaynak olarak kabul edin ve taslaklar üzerinde çalışma sürdüğü için ayrıntıların değişebileceğini unutmayın.
HTTP alışverişi
MPP, protokole özgü ödeme başlıkları yerine standart HTTP kimlik doğrulama alanlarını kullanır:
| Mesaj | HTTP gösterimi |
|---|---|
| Ödeme challenge'ı | WWW-Authenticate: Payment ... ile 402 Payment Required |
| Ödeme kimlik bilgisi | Authorization: Payment ... ile yeniden denenen istek |
| Başarılı makbuz | Payment-Receipt: ... ile kaynak yanıtı |
| Geçersiz ödeme ayrıntıları | application/problem+json kullanan Problem Details gövdesi |
Bir challenge; sunucu tarafından oluşturulan bir kimliği, realm'i, yöntemi, intent'i, kodlanmış ödeme isteğini ve son kullanma süresini içerir. Kimlik bilgisi (credential) challenge'ı geri yansıtır ve yönteme özgü ödeme kanıtını ekler. Sunucu her iki parçayı da doğrulamalıdır; farklı bir challenge'a ait geçerli bir transfer kaynağın kilidini açmamalıdır.
Solana'da tek seferlik ücretler
Solana charge intent'i iki kimlik bilgisi türünü destekler:
- Pull modu, imzalı bir işlem kullanır. İstemci transferi imzalar ve işlemi sunucuya gönderir. Sunucu işlemi doğrular, isteğe bağlı olarak bir ücret ödeyen (fee-payer) imzası ekler, işlemi yayınlar, onaylar ve işlem imzasını makbuzunda döndürür.
- Push modu, bir işlem imzası kullanır. İstemci önce işlemi yayınlar, ardından onaylanmış imzayı sunucuya gönderir. Sunucu, kaynağı döndürmeden önce işlemi getirir ve doğrular.
Pull modu, sunucu tarafından karşılanan işlem ücretlerini ve sunucu tarafında yeniden deneme mantığını mümkün kılar. Push modu, bir cüzdanın istemcinin kendi işlemini göndermesini gerektirdiği durumlarda kullanışlıdır; ancak sunucu tarafından ücret sponsorluğu kullanılamaz.
Normatif alanlar ve doğrulama kuralları için Solana charge spesifikasyonuna bakın.
Bir Express API'sine MPP ücreti ekleme
Solana Pay Kit, MPP ve x402 için güncel bir TypeScript entegrasyonu sunar. Express ile birlikte kurun:
pnpm add @solana/pay-kit @solana/kit@^6.9.0 expresspnpm add --save-dev @types/express tsx
Bu en küçük örnek, barındırılan Surfpool sandbox'ını ve paketin herkese açık demo alıcısını kullanır. Yalnızca yerel geliştirme içindir:
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");});
Çalıştırın ve ödenmemiş bir isteği ödeme farkındalığı olan bir istekle karşılaştırın:
pnpm tsx server.tscurl -i http://127.0.0.1:4567/reportpay --sandbox curl http://127.0.0.1:4567/report
Route handler yalnızca middleware ödemeyi kabul ettikten sonra çalışır.
Üretimde tüm sandbox varsayılanlarını değiştirin
Açık bir ağ, satıcı alıcısı, özel bir RPC, kararlı bir challenge-bağlama sırrı (secret), üretim imzalayıcısı ve kalıcı bir tekrar saldırısı (replay) deposu yapılandırın. Gerçek ödemeleri asla bir paketin demo imzalayıcısına yönlendirmeyin.
Ölçümlü oturumlar
Bir istemci birçok küçük ve birbiriyle ilişkili ödeme yapacağında Solana MPP session kullanın. Bir oturum, azami depozitoyla zincir üstü (onchain) bir ödeme kanalı açar, ardından kullanım arttıkça kümülatif imzalı voucher'lar kullanır. Sunucu voucher'ları zincir dışında (offchain) doğrulayabilir ve kabul edilen en yüksek tutarı daha sonra yerleştirebilir (settle).
Bu, token ölçümlü çıkarım (inference), bayt ölçümlü indirmeler, canlı veriler ve tekrarlanan araç çağrıları için kullanışlıdır. Her olay için ayrı bir zincir üstü ödeme göndermekle aynı şey değildir.
Bir oturumu oturum ödemesi, ödeme kanalı veya üst sınırlı tekrarlayan yetkilendirme olarak adlandırın. Yalnızca hizmet ve ödeme sözleşmesi gerçekten kesintisiz bir kullanım akışını ölçüyorsa buna akış halinde ödeme (streamed payment) deyin.
Üretim doğrulaması
Her Solana ücreti için sunucu en azından şunları doğrulamalıdır:
- Challenge'ın gerçek olduğu, süresinin dolmadığı, bu isteğe bağlı olduğu ve bu realm için amaçlandığı.
- İşlemin beklenen ağı, varlığı veya mint'i, alıcıyı, tutarı ve token program'ı kullandığı.
- Herhangi bir ücret ödeyen (fee-payer) veya associated token account talimatının açıkça izin verilmiş olduğu ve sunucu imzalayıcısını boşaltamayacağı.
- İşlemin gereken onay (commitment) düzeyinde başarılı olduğu.
- İşlem imzasının daha önce tüketilmemiş olduğu.
- Tekrar saldırısı (replay) kontrolü ve tüketme işleminin tüm sunucu örnekleri arasında atomik olduğu.
Oturumlarda ayrıca kanal durumunu, kabul edilen kümülatif tutarı ve yerleştirme filigranını (settlement watermark) paylaşımlı bir depoda kalıcı olarak saklayın. Sunucu kullanılamaz hale gelirse istemcilerin kullanılmayan fonları nasıl geri alacağını belgelendirin.
İlgili kaynaklar
Is this page helpful?