İşlem algılama, zincir onayı, sipariş ilişkilendirme ve hizmet teslimi ayrı adımlardır. Doğru zinciri, varlığı, alıcıyı ve tutarı doğrulayın; belgelenmiş bir kabul politikası uygulayın ve mutabakatı idempotent hale getirin. Tek başına bir işlem referansı, ekran görüntüsü veya tarayıcı düğmesi belirli bir siparişin ödendiğini kanıtlayamaz.
Zincir olayını sipariş olayından ayırın
Bir cüzdanın transfer gönderildiğini bildirmesi, kendi eylemine ilişkin bir kanıttır; tam bir ödeme kararı değildir. Alıcı arka uç, amaçlanan ağı gözlemlemeli, gerçek transferi doğrulamalı ve bunu bir siparişle ilişkilendirmelidir. Ancak bundan sonra sipariş kabul politikasını uygulayabilir. Altyapı teslimi, ödeme kabulünden sonraki bir başka operasyonel adımdır.
Bu geçişleri hem kodda hem de müşteri dilinde açık tutun. Bir ekran, siparişi ödenmiş saymadan bekleme, algılandı veya onaylanıyor durumunu gösterebilir. Tarayıcının kabul edilen tutarı sağlamasına veya yetkili bir durumu geçersiz kılmasına izin vermeyin. Sunucu tarafından oluşturulan teklifi ve talimatlarını saklayın; böylece sonraki mutabakat, değişen bir sepet yerine özgün siparişe göre değerlendirilebilir.
Zincire özgü güven kuralları kullanın
Farklı ağlar işlem güvenilirliğini farklı şekilde tanımlar. Bitcoin geliştirici kılavuzu, düğümlerin en fazla birikmiş iş kanıtına sahip zinciri nasıl seçtiğini ve rakip blokların nasıl oluşabileceğini açıklar. Bu nedenle yakın zamanda görülen bir işlem, onay derinliği ve olası zincir değişiklikleri için bir politikaya ihtiyaç duyar. Her varlık ve ticari risk için uygun tek bir onay sayısı yoktur.
Ethereum'ın hisse kanıtı belgeleri kontrol noktası kesinliğini açıklarken, Solana işlenmiş, onaylanmış ve kesinleşmiş taahhüt durumlarını belgeler. Bu terimleri gelişigüzel tek bir evrensel blok sayısına çevirmeyin. Ağa özgü kuralı, bilgi kaynağını ve belirsizlik sırasındaki davranışı kaydedin. Operatör, ilgisiz bir ödeme sayfasından bir sayı kopyalamak yerine kabul eşiklerini ödeme ve teslim riskine göre belirlemelidir.
Gerçek transfer yükünü doğrulayın
Doğru zincirde alıcıyı, varlığı ve tutarı belirleyin. Token ödemeleri, yalnızca bir adrese başarılı bir işlem değil, amaçlanan token kimliğini gerektirir. Zincirin modeline göre ilgili yürütme başarısını ve transfer kanıtını doğrulayın. Tarayıcı tarafından sağlanan biçimlendirilmiş bir ondalık sayıya güvenmek yerine tamsayı tutarları varlığın uygun hassasiyetinde ayrıştırın.
Bir ödeme talimatı özgün rotasına bağlı kalmalıdır. Başka bir ağdaki transfer, aynı sembole sahip farklı bir token veya ilgisiz bir işlem referansı bunu karşılamamalıdır. Doğrulama kaydı, nelerin kontrol edildiğini açıklamalı ve kararın incelenmesi için gereken kanıtı saklamalıdır. Bu kılavuz, belirli bir hizmet uygulamasını değil, genel ödeme mutabakatı ilkelerini açıklar.
Sipariş ilişkilendirmesini net hale getirin
Sabit alıcı adresleri, benzer tutarlarda birkaç sipariş alabilir. Eşleşen bir transferin varlığı, hangi müşterinin veya siparişin alacaklandırılması gerektiğini kanıtlamaz. Canlı ödemeleri kabul etmeden önce ilişkilendirme yöntemini tanımlayın ve çakışmaların ele alınmasını dahil edin. Kullanıcı tarafından sağlanan bir işlem referansı yine de aynı transferin başka bir yere atanmadığının doğrulanmasını gerektirir.
Aynı rotada, çakışan bir zaman aralığında aynı tutarda iki fatura olduğunu düşünün. Bir izleyici tek bir transfer görür. Her ikisini otomatik olarak ödenmiş işaretlemek yanlıştır; yeterli kanıt olmadan birini seçmek de güvensizdir. Operatörün politikası geçerli bir ilişkilendirme kurabilene kadar transferi atanmamış veya incelemede tutun. Belirsiz bir eşleşme, ele alınması gereken bir durumdur; kesinlik uydurmak için bir neden değildir.
Geç ve değişen kanıtlara tolerans gösteren durumlar tanımlayın
Bir ödeme süreci, zincir kanıtının bir siparişi kabul etme kararından ayrı olduğu az sayıda net durumdan yararlanır. Bu örnek tablo, belirli bir hizmetin durum adlarını açıklamak yerine olası aşamaları açıklar. Her geçişin doğrulanmış bir nedeni olmalı ve ödeme kabulü altyapı tesliminden ayrı kalmalıdır.
Geç, kısmi ve fazla transferleri, teklif süresinin dolmasını ve geçici olarak kullanılamayan zincir verilerini dahil edin. Sürenin dolması gerçek bir transferi ortadan kaldırmaz. Geç bir ödeme, otomatik kabul veya reddetme yerine inceleme gerektirebilir. Daha önce gözlemlenen bir zincir olayı değişirse, her izleyici bildirimini geri döndürülemez gerçek olarak ele almak yerine durumu belgelenmiş politika uyarınca yeniden değerlendirin.
| Örnek durum | Anlam | Sonraki karar |
|---|---|---|
| Bekliyor | Doğrulanmış uygun transfer yok | Geçerli faturayı gözlemlemeye devam edin |
| Algılandı | İlgili transfer gözlemlendi | Zincir güvenilirliğini ve ilişkilendirmeyi kontrol edin |
| Onaylanıyor | Kabul kuralı henüz karşılanmadı | Politika karara izin verene kadar gözlemleyin |
| İnceleme | Geç, kısmi veya belirsiz kanıt | Operatör politikası uyarınca çözün |
| Kabul edildi | Doğrulanmış ve mutabık kılınmış ödeme | Ayrı teslim iş akışına geçin |
Yeniden denemeleri güvenli ve gözlemlenebilir yapın
İzleyiciler ve mutabakat işleri, kesintiye uğrayan bağlantılardan veya süreç yeniden başlatmalarından sonra yeniden deneyecektir. Yinelenen alacaklandırmaları önlemek için zincir ve uygun işlem veya transfer tanımlayıcısı gibi kararlı bir transfer kimliği kullanın. İlerlemeyi ve kararları kalıcı hale getirin; böylece aynı olay, ikinci bir hizmet sağlanmadan veya kabul edilen bir teklif değiştirilmeden yeniden işlenebilir.
Bilinmeyen bir sonucu başarısız bir işlemden ayırt edin. Bir aşağı akış isteği zaman aşımına uğrarsa, yeniden göndermeden önce yetkili sonucunu inceleyin. Kabul edilen ve belirsiz eylemlerin dayanıklı kayıtlarını tutun. Sipariş tokenlarına ve iç kanıtlara erişimi kısıtlarken itiraz edilen bir ödemeyi araştırmak için yeterli bilgiyi saklayın. Buradaki güvenilirlik, ödeme sayfasındaki akıcı bir animasyon değil, yinelenebilir kararlarla ilgilidir.
Bekleyen bir siparişin hâlâ neye ihtiyaç duyduğunu bilin
Bir sipariş, transfer gözlemlenmediği, gerekli zincir güvenilirliğine ulaşılmadığı veya faturayla ilişkilendirmesinin incelenmesi gerektiği için beklemede kalabilir. Faturayı ve genel işlem referansını saklayın, belirtilen kabul kurallarını kontrol edin ve siparişin amaçlanan yardım sürecini kullanın. Gecikmiş bir durum güncellemesi, tek başına başka bir ödeme göndermek için bir neden değildir.
Gerçek sipariş için talimatları ve doğrulanmış durumu izleyin. Ödeme onayı, mutabık kılınan transferin kabulünü belirtmeli; hizmet tesliminin ise ayrı bir durumu olmalıdır. Özel erişim tokenlarını ve cüzdan sırlarını yardım taleplerinin dışında tutun.
Pratik kontrol listeniz.
- Sunucu tarafından oluşturulan değiştirilemez bir teklifi kalıcı hale getirin.
- Zinciri, alıcıyı, varlığı ve tamsayı tutarı doğrulayın.
- Zincire özgü kabul kurallarını belgeleyin.
- Sabit adres çakışmalarını tahmin yürütmeden ele alın.
- Yinelenen alacaklandırmaları ve güvensiz yeniden deneme gönderimlerini önleyin.
- Geç, kısmi, yanlış rota ve değişen kanıt durumlarını test edin.
Önemli olan ayrıntılar.
Ödemeyi onaylamak için bir işlem karması yeterli mi?+
Hayır. Transferi amaçlanan zincirde, yükü ve güvenilirliğiyle doğrulayın, ardından siparişe ait olduğunu ve daha önce alacaklandırılmadığını tespit edin.
Her ağ aynı onay eşiğini kullanabilir mi?+
Hayır. Ağlar farklı güvenilirlik ve kesinlik modelleri sunar. Operatör, her rotaya uygun bir kabul politikası tanımlamalı ve test etmelidir.
Onaylanmış ödeme, sunucunun sağlandığı anlamına gelir mi?+
Hayır. Ödeme kabulü ve teslim ayrı iş akışı olaylarıdır. Sağlama durumunu kendi yetkili sürecinden bildirin.
Kaynağa gidin.
Bu kaynaklar, bu kılavuzdaki teknik kavramları destekler. Bir üretim sistemini değiştirmeden önce güncel belgeleri izleyin.
- Bitcoin geliştirici kılavuzu: Blokzinciri davranışı developer.bitcoin.org
- Ethereum: Hisse kanıtı ve kesinlik ethereum.org
- Solana: RPC durum taahhüdü solana.com
SwissOctet tarafından editoryal rehberlik. Örnekler açıklayıcıdır. Hizmet spesifikasyonları, mevcut seçenekler ve sözleşme koşulları ayrıca doğrulanmalıdır.