Solana Pay Spesifikasyonu v1

Özet

Ödemeleri ve diğer kullanım senaryolarını etkinleştirmek için URL'ler içinde Solana işlem taleplerini kodlamak için standart bir protokol.

Bu standart, BIP 21 ve EIP 681 standartlarından ilham alır.

Motivasyon

Yerel SOL transferleri, SPL Token transferleri ve Solana işlemleri için standart bir URL protokolü, Solana ekosistemindeki uygulamalar ve cüzdanlar arasında daha iyi bir kullanıcı deneyimi sağlar.

Bu URL'ler QR kodlarında veya NFC etiketlerinde kodlanabilir ya da ödeme talebinde bulunmak ve işlemleri oluşturmak için kullanıcılar ve uygulamalar arasında gönderilebilir.

Uygulamalar, satılan mal veya hizmetleri teslim etmeden veya nesnelere ya da etkinliklere erişim vermeden önce bir işlemin onaylandığından ve geçerli olduğundan emin olmalıdır.

Mobil cüzdanlar, ortamda Solana Pay URL'leriyle karşılaşıldığında kusursuz ve güvenli bir deneyim sağlamak için URL şemasını işleyecek şekilde kayıt olmalıdır.

Bu sorunları çözmek için basit bir yaklaşımı standartlaştırarak, geliştiricilerin daha üst düzey soyutlamalara odaklanabilmesi için uygulamaların ve cüzdanların temel uyumluluğunu sağlarız.

Spesifikasyon: Transfer Talebi

Bir Solana Pay transfer talebi URL'si, SOL veya SPL Token transferi için etkileşimsiz bir talebi tanımlar.

solana:<recipient>
?amount=<amount>
&spl-token=<spl-token>
&reference=<reference>
&label=<label>
&message=<message>
&memo=<memo>

Talep etkileşimsizdir çünkü URL'deki parametreler, bir cüzdan tarafından doğrudan bir işlem oluşturmak için kullanılır.

Alıcı

Yol adı olarak tek bir recipient alanı gereklidir. Değer, yerel bir SOL hesabının base58 kodlu genel anahtarı olmalıdır. Associated token account'lar kullanılmamalıdır.

Bunun yerine, bir SPL Token transferi talep etmek için, alıcının ilişkili token adresinin türetilmesi gereken bir SPL Token mint'ini belirtmek amacıyla spl-token alanı kullanılmalıdır.

Miktar

İsteğe bağlı bir sorgu parametresi olarak tek bir amount alanına izin verilir. Değer, "kullanıcı" birimlerinde negatif olmayan bir tam sayı veya ondalık sayı olmalıdır. SOL için bu, lamport değil SOL anlamına gelir. Token'lar için uiAmountString kullanın, amount değil.

0 geçerli bir değerdir. Değer 1'dan küçük bir ondalık sayıysa, .'den önce başta bir 0 bulunmalıdır. Bilimsel gösterim yasaktır.

Bir değer sağlanmazsa, cüzdan kullanıcıdan miktarı istemelidir. Ondalık basamak sayısı SOL (9) veya SPL Token (mint'e özgü) için desteklenen sayıyı aşarsa, cüzdan URL'yi hatalı biçimlendirilmiş olarak reddetmelidir.

SPL Token

İsteğe bağlı bir sorgu parametresi olarak tek bir spl-token alanına izin verilir. Değer, bir SPL Token mint account'unun base58 kodlu genel anahtarı olmalıdır.

Alan sağlanırsa, Associated Token Account konvansiyonu kullanılmalı ve cüzdan, işlemin son talimatı olarak bir TokenProgram.Transfer veya TokenProgram.TransferChecked talimatı içermelidir.

Alan sağlanmazsa, URL yerel bir SOL transferini tanımlar ve cüzdan bunun yerine işlemin son talimatı olarak bir SystemProgram.Transfer talimatı içermelidir.

Cüzdan, ATA adresini recipient ve spl-token alanlarından türetmelidir. Yardımcı token account'lara transferler desteklenmez.

Referans

İsteğe bağlı sorgu parametreleri olarak birden fazla reference alanına izin verilir. Değerler, base58 kodlu 32 baytlık diziler olmalıdır. Bunlar genel anahtarlar olabilir veya olmayabilir, eğri üzerinde veya dışında olabilir ve Solana'daki hesaplarla karşılık gelebilir veya gelmeyebilir.

Değerler sağlanmışsa, cüzdan bunları ödeme işlemindeki SystemProgram.Transfer veya TokenProgram.Transfer/TokenProgram.TransferChecked talimatına sağlanan sırayla salt okunur, imzalayıcı olmayan anahtarlar olarak dahil etmelidir. Değerler, ödeme talebine özgü olabilir veya olmayabilir ve Solana'daki bir hesaba karşılık gelebilir veya gelmeyebilir.

Solana doğrulayıcıları işlemleri bu hesap anahtarlarına göre indekslediğinden, reference değerleri istemci kimlikleri (nihai ödeme işlemi bilinmeden önce kullanılabilir kimlikler) olarak kullanılabilir. İşlemler bu şekilde bulmak için getSignaturesForAddress RPC yöntemi kullanılabilir.

Etiket

İsteğe bağlı bir sorgu parametresi olarak tek bir label alanına izin verilir. Değer, transfer talebinin kaynağını açıklayan URL kodlamalı bir UTF-8 dizesi olmalıdır.

Örneğin, bu talebi yapan bir markanın, mağazanın, uygulamanın veya kişinin adı olabilir. Cüzdan, değerin URL kodunu çözmeli ve kod çözülmüş değeri kullanıcıya göstermelidir.

Mesaj

İsteğe bağlı bir sorgu parametresi olarak tek bir message alanına izin verilir. Değer, transfer talebinin niteliğini açıklayan URL kodlamalı bir UTF-8 dizesi olmalıdır.

Örneğin, bu satın alınan bir ürünün adı, bir sipariş kimliği veya bir teşekkür notu olabilir. Cüzdan, değerin URL kodunu çözmeli ve kod çözülmüş değeri kullanıcıya göstermelidir.

Not

İsteğe bağlı bir sorgu parametresi olarak tek bir memo alanına izin verilir. Değer, ödeme işlemindeki bir SPL Memo talimatına dahil edilmesi gereken URL kodlamalı bir UTF-8 dizesi olmalıdır.

Cüzdan, değerin URL kodunu çözmeli ve kod çözülmüş değeri kullanıcıya göstermelidir. Not, doğrulayıcılar tarafından kaydedilecektir ve özel veya hassas bilgiler içermemelidir.

Alan sağlanırsa, cüzdan işlemdeki diğer talimatlarla belirsizliği önlemek için SOL veya SPL Token transfer talimatından hemen önce, işlemin sondan ikinci talimatı olarak bir MemoProgram talimatı içermelidir.

Örnekler

1 SOL için transfer talebini açıklayan URL

solana:mvines9iiHiQTysrwkJjGf2gb9Ex9jXJX8ns3qwf2kN?amount=1&label=Michael&message=Thanks%20for%20all%20the%20fish&memo=OrderId12345

0.01 USDC için transfer talebini açıklayan URL

solana:mvines9iiHiQTysrwkJjGf2gb9Ex9jXJX8ns3qwf2kN?amount=0.01&spl-token=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

SOL için transfer talebini açıklayan URL (kullanıcıdan miktar sorulur)

solana:mvines9iiHiQTysrwkJjGf2gb9Ex9jXJX8ns3qwf2kN?label=Michael

Spesifikasyon: İşlem Talebi

Bir Solana Pay işlem talebi URL'si, herhangi bir Solana işlemi için etkileşimli bir talep tanımlar.

solana:<link>

Talep etkileşimlidir çünkü URL'deki parametreler cüzdan tarafından bir işlem oluşturmak üzere HTTP isteği yapmak için kullanılır.

Bağlantı

Yol adı olarak tek bir link alanı gereklidir. Değer, koşullu olarak URL ile kodlanmış mutlak bir HTTPS URL'si olmalıdır.

URL sorgu parametreleri içeriyorsa, URL ile kodlanmış olmalıdır. Bu spesifikasyona protokol sorgu parametreleri eklenebilir. Değerin URL ile kodlanması, protokol parametreleriyle çakışmayı önler.

URL sorgu parametreleri içermiyorsa, URL ile kodlanmamalıdır. Bu daha kısa bir URL ve daha az yoğun bir QR kodu üretir.

Her iki durumda da, cüzdan değeri URL ile çözmelidir. Bunun, değer URL ile kodlanmamışsa hiçbir etkisi yoktur. Çözülmüş değer mutlak bir HTTPS URL'si değilse, cüzdan bunu hatalı biçimlendirilmiş olarak reddetmelidir.

GET İsteği

Cüzdan, URL'ye bir HTTP GET JSON isteği yapmalıdır. İstek, cüzdanı veya kullanıcıyı tanımlamamalıdır.

Cüzdan, bir Accept-Encoding başlığı ile istek yapmalı ve uygulama HTTP sıkıştırması için bir Content-Encoding başlığı ile yanıt vermelidir.

Cüzdan, istek yapılırken URL'nin alan adını görüntülemelidir.

GET Yanıtı

Cüzdan, HTTP istemci hatası, sunucu hatası ve yönlendirme yanıtlarını işlemelidir. Uygulama bunlarla veya aşağıdaki gövdeye sahip bir HTTP OK JSON yanıtıyla yanıt vermelidir:

{ "label": "<label>", "icon": "<icon>" }

<label> değeri, işlem isteğinin kaynağını açıklayan bir UTF-8 dizesi olmalıdır. Örneğin, bu isteği yapan bir markanın, mağazanın, uygulamanın veya kişinin adı olabilir.

<icon> değeri, bir simge görüntüsünün mutlak bir HTTP veya HTTPS URL'si olmalıdır. Dosya bir SVG, PNG veya WebP görüntüsü olmalıdır, aksi takdirde cüzdan bunu hatalı biçimlendirilmiş olarak reddetmelidir.

Cüzdan, HTTP önbellekleme yanıt başlıklarının talimatı dışında yanıtı önbelleğe almamalıdır.

Cüzdan, etiketi görüntülemeli ve simge görüntüsünü kullanıcıya göstermelidir.

POST İsteği

Cüzdan, aşağıdaki gövdeye sahip bir HTTP POST JSON isteğini URL'ye yapmalıdır:

{ "account": "<account>" }

<account> değeri, işlemi imzalayabilecek bir hesabın base58 kodlu genel anahtarı olmalıdır.

Cüzdan, isteği bir Accept-Encoding başlığıyla yapmalı ve uygulama HTTP sıkıştırması için bir Content-Encoding başlığıyla yanıt vermelidir.

Cüzdan, istek yapılırken URL'nin alan adını görüntülemelidir. Eğer bir GET isteği yapıldıysa, cüzdan ayrıca yanıttaki etiketi görüntülemeli ve simge görüntüsünü göstermelidir.

POST Yanıtı

Cüzdan, HTTP istemci hatası, sunucu hatası ve yönlendirme yanıtlarını işlemelidir. Uygulama bunlarla veya aşağıdaki gövdeye sahip bir HTTP OK JSON yanıtıyla yanıt vermelidir:

{ "transaction": "<transaction>" }

<transaction> değeri, base64 ile kodlanmış bir serileştirilmiş işlem olmalıdır. Cüzdan, işlemi base64 ile çözmeli ve serileştirmesini geri almalıdır.

Uygulama, kısmen veya tamamen imzalanmış bir işlemle yanıt verebilir. Cüzdan, işlemi güvenilmez olarak doğrulamalıdır.

Boş İmzalar

Eğer işlemin signatures boşsa:

  • Uygulama, feePayer değerini istekteki account değerine veya sıfır değerine (new PublicKey(0) veya new PublicKey("11111111111111111111111111111111")) ayarlamalıdır.
  • Uygulama, recentBlockhash değerini en son blok hash değerine veya sıfır değerine (new PublicKey(0).toBase58() veya "11111111111111111111111111111111") ayarlamalıdır.
  • Cüzdan, işlemdeki feePayer değerini yok saymalı ve feePayer değerini istekteki account değerine ayarlamalıdır.
  • Cüzdan, işlemdeki recentBlockhash değerini yok saymalı ve recentBlockhash değerini en son blok hash değerine ayarlamalıdır.

Boş Olmayan İmzalar

Eğer işlemin signatures boş değilse:

Cüzdan, işlemi yalnızca istekteki account ile imzalamalı ve bunu yalnızca istekteki account için bir imza bekleniyorsa yapmalıdır.

İstekteki account için bir imza dışında herhangi bir imza bekleniyorsa, cüzdan işlemi kötü niyetli olarak reddetmelidir.

İsteğe Bağlı Mesaj Alanı

Uygulama ayrıca yanıt gövdesinde isteğe bağlı bir message alanı içerebilir:

{ "message": "<message>", "transaction": "<transaction>" }

<message> değeri, işlem yanıtının doğasını açıklayan bir UTF-8 dizesi olmalıdır.

Örneğin, bu satın alınan bir ürünün adı, satın alma işlemine uygulanan bir indirim veya bir teşekkür notu olabilir. Cüzdan, bu değeri kullanıcıya göstermelidir.

Cüzdan ve uygulama, gelecekteki spesifikasyonlar tarafından eklenebilecek istek gövdesinde ve yanıt gövdesinde ek alanlara izin vermelidir.

Örnekler

İşlem isteğini tanımlayan URL

solana:https://example.com/solana-pay

Sorgu parametreleriyle işlem isteğini tanımlayan URL

solana:https%3A%2F%2Fexample.com%2Fsolana-pay%3Forder%3D12345

GET İstek Örneği

GET /solana-pay?order=12345 HTTP/1.1
Host: example.com
Connection: close
Accept: application/json
Accept-Encoding: br, gzip, deflate

GET Yanıt Örneği

HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Content-Length: 62
Content-Encoding: gzip
{"label":"Michael Vines","icon":"https://example.com/icon.svg"}

POST İstek Örneği

POST /solana-pay?order=12345 HTTP/1.1
Host: example.com
Connection: close
Accept: application/json
Accept-Encoding: br, gzip, deflate
Content-Type: application/json
Content-Length: 57
{"account":"mvines9iiHiQTysrwkJjGf2gb9Ex9jXJX8ns3qwf2kN"}

POST Yanıt Örneği

HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Content-Length: 298
Content-Encoding: gzip
{"message":"Thanks for all the fish","transaction":"AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAECC4JMKqNplIXybGb/GhK1ofdVWeuEjXnQor7gi0Y2hMcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQECAAAMAgAAAAAAAAAAAAAA"}

Uzantılar

Uygulamalar ve cüzdanlarla uyumluluğu sağlarken yeni kullanım senaryolarını etkinleştirmek için bu spesifikasyona ek formatlar ve alanlar dahil edilebilir.

Uygulama ve cüzdan geliştiricilerinden geri bildirim almak için spesifikasyonda değişiklik önerilerinde bulunmak üzere lütfen bir GitHub sorunu açın.

Böyle bir önerinin gerçek bir örneği.

Ayrıca Bakınız

Is this page helpful?

Yönetici

© 2026 Solana Vakfı.
Tüm hakları saklıdır.
Bağlanın