Kripto ödeme mutabakatı neden çift taraflı kayıt ister?

Para ile sipariş aynı anda hareket etmez. Kripto ödeme mutabakatını zorlaştıran da bu: ay sonunda Bakiye sayfasıyla sipariş tablosu tutmaz, çünkü bakiyede üç satır vardır ve sipariş tablosunda tek fatura.

Ödeme altyapısı iki kayıt okur. Biri zincirin kaydıdır ve kimsenin denetiminde değildir; diğeri altyapının kendi defteridir. Paymos'ta o defter çift taraflıdır: her hareket, değerin çıktığı hesapla ulaştığı hesaba birlikte yazılır ve satıcı bakiyesi, birinin güncel tuttuğu sayı değil defterden okunan pozisyondur.

Fazladan sütun asıl tuhaf günlerde işe yarar. Alıcı tek faturayı üç transferle kapatır. Ödeme penceresi kapandıktan sonra fatura adresine para düşer, ya da USDT faturasına USDC gelir, ya da sabah iptal edilmiş faturanın adresine transfer ulaşır. Oluşturulan ödeme çıkışı, zincire hiçbir şey çıkmadan iptal edilir. Hepsi parayı kımıldatır ve hiçbiri bağlı olduğu siparişi kımıldatmaz; tek toplam olarak tutulan bakiyenin bu farkı yazacak yeri yoktur.

Çift taraflı kayıt tam olarak neyi tutar?

Hareketleri ve her hareketin dokunduğu iki hesabı.

Tek taraflı sistem tutarı saklar ve üstüne yazar. Çift taraflı sistem değişimi saklar: değerin çıktığı hesap, ulaştığı hesap, tek işlemde ve kaydedilmeden önce denkleşmek zorunda. Bakiye böylece birinin güncellediği alan olmaktan çıkar, geçmişten türetilen pozisyona döner.

Yöntem kriptoya özgü değil; muhasebeden tanıdık olan kayıt düzeninin ta kendisi. Üzerine kuran ödeme ekipleri de var: Modern Treasury'nin mühendislik günlüğü defterin üzerine ekleme yapılan ve değiştirilmeyen bir kayıt üzerinde durduğunu, geçmiş korunduğu için önceki her durumun yeniden kurulabileceğini yazıyor.

Ödeme altyapısında farklı olan, defterin neyi tuttuğu. Burada satıcının her varlığı kendi hesabına yazılır; USDT ile USDC ayrı hesaplardır. Yazılan işlem değişmez, en az iki taraf taşır ve token bazında denkleşir; denkleşmeyen kayıt sonradan düzeltilmek üzere kaydedilmez, en baştan reddedilir.

Tek fatura neden birden fazla kayıt üretir?

Komisyon her transferde, o transferin getirdiği tutar üzerinden hesaplandığı için.

Satıcı bakiyesi bu yüzden tek faturanın ömrü boyunca birkaç kez kımıldar. Üç transfer, üç alacak ve üç komisyon kaydı demektir; her biri, geçtiği anda önünde duran tutara göre fiyatlanır. Kullanılan oran, fatura oluşturulurken ona sabitlenen orandır — fiyat listesi sonradan ne yaparsa yapsın o fatura onunla kapanır.

Yani tek gelen para bile üç sayıdır: gelen, komisyonun aldığı, satıcıda kalan. Yuvarlama tek yöne çalışır. Komisyon tokenin en küçük birimine aşağı yuvarlanır, artan satıcıda kalır ve gerçek oran her büyüklükteki transferde ilan edilen oranın altında ya da ona eşit çıkar. O hassasiyette fiyatlanamayacak kadar küçük tutardan hiç komisyon alınmaz.

Kendi ekstresini okuyan satıcıyı şaşırtan yer burası. Alacaklar faturalarla bire bir hizalanmaz; transferlerle hizalanır. Komisyonu kimin ödediği ise bambaşka bir ayardır.

Tutar tutmadığında ne olur?

Alacak parayı takip eder, fatura ise kendi kuralını izler; tutar tutmadığında bu iki kural farklı cevaba varabilir ve bakiyede yazan sayı, faturanın durumunu doğrulamaz.

Fazla ödemede fazlası da tamamıyla yazılır. Hiçbir şey alıkonmaz, kendiliğinden geri de gitmez. Fatura ödendi olarak kapanır ve bildirilen olay invoice.paid değil invoice.paid_over olur, böylece sipariş sistemi ikisini tutar aritmetiği yapmadan ayırır.

Eksik ödeme projenin toleransına çarpar. Tolerans %0 ile %2 arasında bir kaydırıcıdır, %0,1'lik adımlarla oynar, yeni proje %0,1 ile açılır. Toleranstan az eksik kalan ödeme faturayı yine kapatır ve satıcı fiilen geleni alır; eksiği kapatmak için tutar uydurulmaz. Kaydırıcıyı sıfıra çekince eşleşme yeniden tam olur.

Bundan büyük eksikler fatura tipine göre ayrışır. Tek ödeme bekleyen fatura eksik ödendi olur. Birden fazla ödeme bekleyen fatura, alıcı kalanı gönderirken açık kalabilir; tek sayının anlatamadığı durum tam olarak budur — para gerçekten yazıldı, sipariş bitmedi.

Faturayı kapatmayan para nereye yazılır?

Satıcının bakiyesine yazılır: işlem komisyonu düşülür, nedeni yanına kaydedilir ve fatura olduğu yerde kalır.

Fatura adreslerine uygunsuz anlarda transfer ulaşır: ödeme penceresi kapandıktan bir saat sonra, aynı gün ödenmiş ya da iptal edilmiş faturaya, USDT ile fiyatlanmış faturaya USDC olarak, üzerinde hiç fatura olmayan adrese. Hepsinde para satıcıya yazılır.

Kımıldamayan taraf faturanın kendisi. Ödendi işaretlenmez ve webhook çıkmaz, çünkü bu tür alacağın kendine ait olayı yok. Yalnızca olay akışını dinleyen entegrasyon bunu hiç duymaz.

Göründüğü yer Bakiye sayfası. Orada kendi bloğunda durur: neden, tutar, komisyon, varsa fatura, biliniyorsa gönderen adres ve işlem hash'i. Bilinmiyorsa Gönderen bilinmiyor yazar; para kaynak ağda eşleşen transfer olmadan geldiyse durum budur. Aynı bildirim e-postaya, panele ve bağlıysa Telegram'a düşer. Bir kısmını geri göndermek ticari karardır ve satıcıda kalır, çünkü iade birinin göndermesi gereken sıradan bir transferdir.

Ödeme çıkışı neden önce beklemeye geçer?

Çünkü talep ile zincire çıkan işlem arasında para ne harcanabilir ne gitmiştir.

Çıkış isteyince tutar, gideceği rotanın ağ ücretiyle birlikte kullanılabilir bakiyeden çıkar ve beklemeye park eder. Bakiye sayfası bu yüzden iki rakamı ayrı gösterir; bir sonraki çıkışı yalnızca kullanılabilir tutar fonlar. Tahsilattan alıkonan bir şey yok: rezerv ya da dönen rezerv uygulanmıyor, beklemedeki tutar satıcının kendi yoldaki çıkışlarından oluşur.

Bakiye sayfasında üçüncü bir rakam daha duruyor: davet kazançları. Kendi bakiyesinde tutulur ve ödeme çıkışı akışı onu taşımaz, çünkü her çıkış yalnızca kullanılabilir bakiyeden fonlanır. Defterinizde de ayrı kalem olarak durması gerekir; nasıl biriktiğini ayrı bir yazı anlatıyor.

Ödeme çıkışının yedi durumu var ve üçü nihai. Her yükte is_final de geliyor, böylece entegratör o listeyi elle güncel tutmak zorunda kalmıyor. Nihai olmayanlardan birini tanımak işe yarar: ağın henüz onaylamadığı çıkış panelde Onaylanmadı okunur ve tutarı Beklemede altında durur.

İşlem zincire çıkmadan biterse, başarısız da olsa iptal de edilse, beklemedeki her şey geri döner — ağ ücreti anaparayla birlikte. Gitmeyen çıkış için hiçbir şey ödenmez. İptal yalnızca yürütme başlamadan çalışır; sonrasında istek reddedilir.

Zincir bir onayı geri alırsa zararı hangi hesap yazar?

Platformun kendi hesabı.

Onay derinliği burada ağa ve ödeme tutarına göre belirlenir. Mutlak kesinliği beklemek yerine bilinçli bir denge kurulur ve dar bir pencere kalır: onaylanıp yazılmış transfer, zincir yeniden düzenlenirse hâlâ düşebilir. Böyle bir günde satıcının alacağı yerinde kalır ve açık platformun hesaplarına yazılır.

Defter açısından mesele dar. Her kaydın iki tarafını da tutan altyapı, darbeyi alan hesabın adını söyleyebilir; satıcı başına tek rakam tutan altyapının ise darbeyi yazacak tek yeri vardır ve orada satıcı durur. Reorg'un gönderilmiş siparişe ne yaptığı mekaniği, beklemenin ağa göre neden değiştiği ise pencereyi açan dengeyi anlatıyor.

Webhooklardan defter kurulur mu?

Tek başına kurulmaz: olay akışı geçişleri anlatır, geçiş ise paranın kaydı değildir.

16 olay tipi faturaları, ödeme çıkışlarını ve ödeme kanalı yatırmalarını kapsıyor; her biri bir kaynağın durum değiştirdiğini duyuruyor. Bir şeyin olduğunu çabuk duymanın güvenilir yolu budur; teslimatın ne kadar ısrar ettiği de sözleşmesinde yazılı.

Eksiksizlik ayrı soru. Faturayı kapatmayan alacağın hiç olayı yok. Başarısız olan ödeme çıkışı ise webhook üretir ama e-posta ya da panel bildirimi üretmez. Webhookları toplayıp bakiye kuran taraf iki durumda da sessizce yanılır.

Panelin webhook kaydı da arşiv değil. En yeni 100 olayı gösterir, daha geriye sayfalamaz; mutabakatın dayanağı kendi teslimat tablonuzdur.

Ödeme kanalı yatırma akışı tersini varsayar. Yayın sırasına göre ve hep ilerleyen imleçle yayılır; imlecini saklayan okuyucu tamamlanmış ödemeyi atlayamaz, üstelik boş sayfa bile bitiş yerine imleç döndürür. İmlecin ömrü 24 saat, dolayısıyla günde en az bir kez sormak gerekir. Olayı "git ve oku" uyarısı sayın; defterin güveneceği yer yatırma akışı ile bakiyedir.

Kendi kaydınız neyi anahtar almalı?

Transferi. Fatura, anahtar değil nitelik olsun.

Bu tek değişiklik yukarıdakilerin çoğunu karşılar. Tek faturaya üç alacak artık aykırı durum olmaz, üzerinde fatura olmayan alacak da destek yazışmasında beklemek yerine yerini bulur. Geri alınan bekleme de yeniden kurmanız gereken çıkarma işlemi olmaktan çıkar; biri diğerini iptal eden iki satır olarak durur ve ikisi de görünür kalır.

İki küçük alışkanlık bunu tamamlıyor. Ödeme çıkışının durumu önemli olan her yerde is_final üzerinden dallanın. Bakiyeleri varlık bazında anahtarlayın, çünkü burada öyle tutuluyor: tek USDT bakiyesi, USDT'nin geldiği bütün ağları kapsar ve hangi ağdan çıkacağı sonradan, çıkış oluşturulurken belirlenir.

Aylık kontrol de tek satıra iniyor. Bakiye sayfasındaki hareketlerle kendi tablonuzdaki alacakları yan yana koyun; tablonuzda karşılığı olmayan her satırın nedeni Bakiye sayfasında yazılıdır. Eksik olan sipariş değil, kayıttır.