Ödeme çıkışı ne zaman varır, bunu kim belirler?

Satıcı "ne kadar sürer" diye soruyor ve tek bir rakam bekliyor. İki tane var, üstelik ikisi de aynı tarafın elinde değil.

Kart tarafında bu sorunun cevabı takvimdir — gün sonu, valör, blokaj — ve satıcı cevabı gün olarak öğrenmeye alışmıştır. Burada takvim yok. Onun yerine iki ayrı saat var ve yalnızca birincisi ödeme altyapısının işlettiği saat.

Birincinin söylenecek süresi yok. Ödeme çıkışı, talep düştüğü anda başlatılır: toplu işlem penceresi, ödeme takvimi, onay kuyruğu, tahsilattan alıkonan rezerv — hiçbiri yok. Bu bir hız rekoru değil, kuyruğun yokluğu. Farklı bir iddia, üstelik daha dayanıklı olanı.

İkinci yarı zincirin kendi işi. Satıcının seçtiği ağla ve o ağın o öğleden sonra taşıdığı yükle ilerler; Paymos'un zamanlaması değildir. Burada hiçbir sayfa onun için süre yazmıyor, gerekçesi de yazının geri kalanı.

Talep düştükten sonra ne oluyor?

Kullanılabilir bakiyeden iki rakam çıkıyor, ardından işlem yola koyuluyor.

Tutar ile seçilen rotanın ağ ücreti birlikte beklemeye taşınır. Bakiye sayfasının Kullanılabilir ile Beklemede satırlarını ayrı tutması, bir sonraki çıkışı da yalnızca birincisinin finanse etmesi bu yüzden.

Beklemede satırı da platform blokajı değil. Orada duran şey sizin yolda olan çıkışlarınız; tahsilattan alıkonan pay, dönen rezerv ya da bekletme süresi yok. Çıkış tamamlanınca satır kapanır, gitmezse rakam kullanılabilire geri döner.

Sonra gönderilir. Aradaki boşlukta bekleyen bir şey yok, çünkü kaçırılacak gün sonu ve onayını bekleyecek kimse yok. Hedef ağı satıcı çıkışı oluştururken seçer, o varlık için açık rotalar arasından; geçici olarak kullanılamayan varlık-ağ rotası seçicide hiç görünmez ve kuyruğa alınmak yerine kapıda reddedilir. Bakiyeden bu sırada hiçbir şey alınmaz.

Neden hiçbir yerde süre yazmıyor?

Çünkü o saati başlatan da durduran da biz değiliz.

Yayımdan sonra varış, ağın özelliğidir: blok üretimi, kesinlik kuralı, o an taşıdığı yük. Buraya rakam yazmak, başkasının altyapısını kendi taahhüdümüz diye satmak olurdu.

Karışması kolay, çünkü satıcı iki bekleme değil tek bekleme yaşıyor: bakiyede eksilen rakamla cüzdanda artan rakam arasındaki boşluk tek parça görünür. "Bir dakikanın altında ödeme çıkışı" diye ilan veren sağlayıcı da o boşluğun işletmediği yarısını taahhüt diye satıyordur. Dürüstçe söyleyebileceği şey yalnızca ilk yarı: kendi tarafında bekleyen hiçbir şey yok.

Ayrım da yalnızca yoğun günde para ediyor, yani satıcının bu soruyu sorduğu günde. Kuyruğun yokluğunu söylemiş olan o öğleden sonra aynı cümleyi kurmaya devam eder; dakika söylemiş olan, müşterisine ağ yükü anlatmaya başlar.

"Onaylandı" her zincirde aynı şeyi anlatmıyor

Her protokol kesinliği kendisi tanımlıyor ve tanımlar birbirine yakın bile değil.

Tron'da ölçü saat değil, blok üreten sayısı. Bir blok, 27 aktif süper temsilciden en az 19 farklısı o yükseklikte ya da üstünde blok ürettiğinde katılaşmış sayılır; katılaşmış blok da artık çatal seçimine tabi değildir, yani bir çatalla değiştirilemez.

TON bütün soruyu tek blokta kapatıyor: işlem, tek bir masterchain blok onayından sonra kesinleşir ve bir shardchain işlemi masterchain bloğunda göründüğü anda geri alınamaz olur.

Tek sözcüğün altında üç ayrı nesne duruyor. Gelen tarafta ayrım bizde de kurulu: altı ağda — BSC, Polygon, Solana, TON, Avalanche ve Plasma — ödeme blok sayısına göre değil ağ kesinliğine göre tahsil edilir, geri kalanında onay politikası hem ağa hem ödemenin büyüklüğüne bağlıdır. Bunları dakikaya çevirmek herkesin yapabileceği aritmetik. Çıkan sonucun arkasında durmak başka bir taahhüt; zincir de onu kimseye vermiş değil.

Çıkış nerede durabilir, iptal penceresi ne kadar?

Yedi durumdan birinde; üçü sonun kendisi.

Telde created, signed, completed, failed, cancelled, pending_review ve cancelling. Her yük is_final taşır ve bu bayrak tam olarak completed, failed ve cancelled için doğrudur — elde güncel tutulan ad listesine göre değil, bayrağa göre dallanın.

Ortadaki durumlar bizim tarafımızdaki işi anlatıyor ve hiçbiri ilerleme çubuğu değil. Biri görünce tanınmaya değer: pending_review satıcıya Onaylanmadı diye görünür, yani ağ çıkışı henüz onaylamamıştır ve tutar beklemeden çıkmamıştır.

Bayrağa göre dallanmayı zinciri hiç beklemeden prova edebilirsiniz. Sandbox'ta tek çağrı — POST /v1/sandbox/withdrawals/{id}/simulate-completion — bekleyen çıkışı completed durumuna taşır; ortada ne imza vardır ne zincir, çıkan webhook ise gerçek çıkışın yaydığının aynısıdır.

İptal ise baştaki dar pencere. Yalnızca yürütme başlamamışken ve çıkış hâlâ created iken kabul edilir, sonrası ret. Aynı çıkışa ikinci kez iptal göndermek hata üretmez; aynı kaydı 200 ile geri verir, yani yeniden deneyen istemcinin özel bir dala ihtiyacı olmaz. Uç nokta da aynı biçimde davranır.

İptalin olmadığı şey geri çağırma. Zincire çıkmış transfer bu taraftan çözülmez; para ancak yeni bir transferle döner, onu da ilk transferi alan taraf gönderir.

Gitmeyen çıkış ne kadara mal olur?

Hiçbir şeye.

Başarısız ya da iptal biten çıkış, beklemeye alınan her şeyi geri koyar: anapara ve ağ ücreti kullanılabilir bakiyeye döner, yolda ikisinden de bir şey kesilmez. Çıkmamış transfer için kimse ücretlendirilmez. Sandbox'ta soru hiç doğmuyor, çünkü orada bekleme diye bir kayıt oluşmuyor.

Kimin haberi olacağı entegratörü yakalayan kısım. Başarısız çıkış webhookunu çıkarır — withdrawal.failed ile withdrawal.cancelled olay sözleşmesinde duruyor — buna karşılık ne e-posta gider ne panel bildirimi düşer. Sistem öğrenir, insan öğrenmez. Satıcıya gösterilen bildirim de tasarımı gereği kısa: çıkış gitmedi, bekleme serbest bırakıldı, desteğe yazabilirsiniz. Gerekçe bu üçünün hiçbirinde geçmez. Telde de yok: çekim sözleşmesinde gerekçe alanı bulunmuyor, yani "neden gitmedi" ekranı kurulacak bir ekran değil. Entegrasyonunuzun okuyacağı şey durum ile is_final.

Elli alıcıya ödemek tek alıcıdan yavaş mı?

Elli işlem oluyor, planlanmış tek toplu gönderim değil — önemli olan ayrım da bu.

Bu turu kuran satıcı genelde pazaryeri satıcılarına, bayilerine ya da yurt dışındaki iş ortaklarına ödüyor. Hedef adresin satıcıya ait olması da gerekmiyor, beyaz listeye girmiş olması yetiyor.

Panel çıkış turu gönderir: tek diyalogda en çok 50 alıcı, tek varlık tek ağ, beyaz listeye karşı birlikte onaylanır. Tur Production özelliğidir ve Sandbox'ta prova edilemez; Merchant API'nin her çıkış yolu ise tam olarak tek alıcı alır, dolayısıyla bu biçim API'nin değil panelin.

Etrafında iki hesap limiti duruyor ve ikisi de gönderimden önce görünüyor: tek çıkışın değer tavanı, bir de aynı anda yolda olabilecek çıkış sayısı. Kalan hak, satıcı hiçbir şey yazmadan çıkış formuna döner — limit ile ret arasındaki fark burada. Hesabın boş hakkından fazlasını isteyen tur bütün olarak reddedilir, üstelik rakamlar mesajın içinde.

Bunların hiçbiri pencere değil. Elliyi havuzda toplayıp saat bekleyen hiçbir şey yok.

Hedef ağ beklemeyi değiştirir mi?

Beklemenin satıcının seçtiği tek parçası o.

Rota çıkış oluşturulurken sabitlenir ve seçenek, ödeme kabul edilen ağ listesinden dardır. Çıkış, beyaz listede hedef ister; listeye de yalnızca dört adres grubu alınır — EVM, Tron, TON ve Solana. 13 ağın 11'ine çıkış yapılmasının, NEAR ile Sui'ye ödeme gelip çıkış gitmemesinin nedeni bu. Bakiye ağ başına değil varlık başına tutulduğu için bu bir kilit değil: NEAR üzerinden gelen USDT aynı USDT bakiyesine yazılır ve oradan başka bir hedef ağla çıkar. Bir EVM adresini onaylamak bütün EVM çıkış ağlarını birden açar, çünkü liste satırı ağa göre değil adres ile gruba göre anahtarlanır. Beyaz listenin geri kalanı, sıcak cüzdanın etrafındaki kontrollerin konusu.

Maliyet de o seçimle geliyor ve konumuz değil. Ödeme çıkışından işlem komisyonu alınmaz; rotanın ağ ücreti satıcı onaylamadan önce gösterilir ve o ücret, transferin gerçekte tuttuğu maliyetin altında kalır. Rakam fiyat sayfasında.

Kendi sisteminiz bu beklemeyle ne yapmalı?

Durumu izlesin, sayacı silsin.

• is_final üzerinden dallanın. Her yükte gelir; elle güncel tutulacak durum adı listesinden sizi kurtarır.
• Webhooku kolaylık değil, çıkışın bildirim kanalı sayın. Başarısızlık başka hiçbir yere kendiliğinden düşmez. Teslimat merdivenle yeniden denendiği için, ayakta olmayan alıcı olaya geri döner.
• Kendi müşterinize durumu ve ağı gösterin, geri sayım değil. Geri sayım, başkasının zinciri hakkında verilmiş sözdür ve okuyan kişi sizi ona tutar.
• İsteğiniz zaman aşımına uğradıysa aynı external_order_id ile tekrar gönderin. Kimlik satıcı başına tekil, tekrar da ikinci transfer değil var olan kaydı döndürür — 201 değil 200.

Gelen tarafın cevabı başka ve biçimi de başka: ödeyenin beklediği şey ağa ve ödemenin büyüklüğüne göre değişen onay politikasıdır, o beklemenin neden değiştiği ayrı bir yazının konusu. Paranın ikisi arasında nerede durduğu, serbest bırakılan beklemenin defterde neden bir kaydı geri alan başka bir kayıt gibi göründüğü ise mutabakatın işi.

Bu yüzden satıcının kendi müşterisine kuracağı cümle de iki parçalı olmak zorunda: para yola çıktı, varış hedef ağın hızına bağlı. Tek rakamla kurulan cümle yoğun günde tutmuyor — üstelik o gün, tam olarak rakamın sorulduğu gün.