Değişiklik günlüğü

Ödeme onayı, müşterinin seçtiği token ve ağda ödemeyi açamadığında artık tek bir 503 dönüyor: payment_method_unavailable. Bu kod no_available_address, address_lease_failed, bridge_unavailable ve collection_disabled kodlarının yerini alıyor.

Üçünün de anlattığı durum aynıydı: bu token bu ağda şu anda ödeme kabul edemiyor, yeniden denemek ya da başka bir seçim yapmak genelde işe yarıyor. Üç isim bunun üstüne kendi altyapımızı tarif ediyordu — ve bunu sizin ödeme sayfanızdaki alıcının tarayıcısına gönderiyordu. Mesajlar da öyleydi; artık her neden için aynı.

Hiçbir şey ikiye ayrılmıyor: eski üç kodun size farklı adımlar attıracağı bir durum yoktu. Nedenler bizim tarafımızda kayıt altında kalmaya devam ediyor; destek için gerekli olan yer orası.

Entegrasyonunuz eski üç dizeden herhangi birine göre dallanıyorsa şimdi değiştirin. Bu kodlar artık gönderilmiyor ve eskisiyle yenisinin birlikte geldiği bir geçiş dönemi yok. Hata zarfındaki type bağlantısı yeni ismi izliyor; eski bir çapaya kaydedilmiş bağlantı açılmayacak.

Tam liste Hata kodları sayfasında.

Hedef ağ ödeme yapamadığında ödeme çıkışının döndürdüğü 503 artık withdrawal_network_unavailable. Önceki adı hot_wallet_insufficient_liquidity idi.

Ne zaman tetiklendiği değişmedi: aynı uç nokta, aynı 503, aynı durum — bu token bu ağda şu anda gerçekleştirilemiyor, başka bir ağda ya da biraz sonra genellikle oluyor. Değişen, adı ve mesajı: ikisi de sizin tarafınızı değil bizim tarafımızı anlatıyordu.

Entegrasyonunuz eski dizeye göre dallanıyorsa şimdi değiştirin. Eski kod artık gönderilmiyor ve ikisinin birlikte gittiği bir geçiş dönemi yok. Hata zarfındaki type bağlantısı yeni adı izler; eski çapaya kaydedilmiş bir bağlantı açılmaz.

Tam liste Hata kodları sayfasında.

Paneldeki tutarlar artık tek bakışta okunacak uzunlukta. Tam değeri görmek isteyen imleci üzerine getiriyor. Bakiye sütunu da hizasını koruyor: her satır farklı sayıda ondalığa uzamıyor.

Kaç ondalık gösterileceği hepsine uygulanan tek bir kural değil, varlık başına ayrı bir karar. Dolara sabitlenmiş bir token birkaç ondalıkla okunuyor; altına dayalı XAUT'ta ondalık sayısı artıyor, çünkü ölçü ikisinde de aynı: ekranda görünen en küçük basamak bir sente yakın kalsın.

Defterde hiçbir şey yuvarlanmıyor. Kısa biçim yalnızca gösterim; altında her zaman tam rakam duruyor.

Tek alıcıya ödeme ile toplu ödeme ayrı ekranlardaydı. Artık ikisi de aynı pencerede: tek bir çekimi mi yoksa bir listeyi mi göndereceğinizi seçiyor, hepsini burada gözden geçirip yolluyorsunuz. Adres listesinin onayı da başka bir yere gitmiyor, aynı pencerede veriliyor.

Tamamlanmış bir çekim listeden tekrarlanabiliyor. Böylece aynı alıcıya düzenli transfer, daha önce kullandığınız ve onayladığınız adresi yeniden yazmak anlamına gelmiyor.

Alıcı etiketi listede görünüyor. Bir listenin kaç alıcı taşıyabileceği ise göndermeden önce belli: pencere, hesap sınırından yolda olan ödemeleri düşüyor ve kalan sayıyı etiketin yanına yazıyor. Sınır, sonradan gelen bir ret olarak değil, doldurduğunuz ekranda duruyor.

Ödeme kanalları, webhook'ları ve yatırma akışı sekiz resmi istemcinin hepsine girdi: .NET, Go, Java, PHP, Python, Ruby, Rust ve TypeScript. İmzalama, yeniden denemeler ve tipli hatalar kütüphanenin işi; README'ler bir metot listesi değil, kanalı açmaktan yatırmayı okumaya kadar akışın tamamını anlatıyor.

Akış okuyucusu sekizinde de aynı şekilde davranıyor: erken durmuyor. İmlecini saklayan bir istemci, tamamlanmış her yatırmayı tam olarak bir kez görüyor.

Bir kanalın token listesi artık çıplak sembol döndürmüyor. Her kayıt kendi minimum_deposit değerini taşıyor: o yoldan hesaba geçecek en küçük transfer.

Alt sınır tek başına tokenın değil, token ile ağın ortak özelliği. Aynı sembol, bulunduğu her ağda başka bir tabana oturuyor; birinde geçen tutar diğerinde geçmeyebiliyor.

Değer her okumada canlı geliyor. Yanıttan alın, koda gömmeyin ve adresin yanında gösterin: sınırın altındaki bir transfer hesaba geçmiyor, otomatik olarak da iade edilmiyor.

Bir proje artık ağ-sembol çifti değil, token sembolü kabul ediyor. Yeni bir ağ eklemek, o ağdaki tokenları tek tek yeniden onaylamak anlamına gelmiyor.

Proje açarken tek bir soru soruluyor: ödeme bu projeye nereden gelecek? Beş yanıt var — kendi arka ucunuz API'yi çağırır, ödeme bir Telegram botunun içinde tamamlanır, ödeme sayfasını mağaza eklentisi üstlenir, kasiyer yüz yüze Terminal'den tahsil eder ya da sayfanıza gömülen bir parça çalışır.

Yanıt, projenin geri kalanını belirliyor. Telegram botu olarak bağlanan bir projenin barındırılan ödeme sayfası olmuyor, bağlantıları doğrudan sohbete açılıyor; eklentiyle çalışan bir proje hiç kullanmayacağı gömme parçasını önünüze getirmiyor.

Soru bir kez soruluyor ve yanıtı sonradan düzenlenmiyor. Başkasına ihtiyaç duyan proje, başka bir projedir.

Yüz yüze tahsilatın adresi de sadeleşti: /pos kalıcı olarak /terminal adresine yönleniyor. Kasiyerin telefonuna kaydettiği eski bağlantı çalışmaya devam ediyor.

Ödeme kanalı, tek bir ödeyene ait kalıcı bir yatırma kimliği. Desteklenen her ağda birer kalıcı adres taşıyor ve o adreslere gelen her transfer bir yatırmaya dönüşüp bakiyenize geçiyor. Faturadan ayrıldığı yer burası: tutar yok, süre yok, kapanış durumu yok.

Kanalı kendi external_id değerinizle açıyorsunuz, yani saklamanız gereken ikinci bir kimlik çıkmıyor. Proje ile dış kimlik çifti idempotency anahtarı: aynı çağrıyı her ödemede tekrarlayın, ikinci kanal açılmıyor, mevcut kanal dönüyor.

Yatırmalar ayrı bir akıştan okunuyor — yalnızca onaylananlar, eskiden yeniye, her zaman ilerleyen bir imleçle. İmlecini saklayan taraf, tamamlanmış her ödemeyi tam olarak bir kez görüyor; boş bir sayfa akışın bittiği anlamına gelmiyor, orada da devam edecek bir imleç veriliyor. Kanal bloklanıp yeniden açılabiliyor, test ortamında yatırma simüle edilebiliyor. Başlangıç: Kanal oluşturma.

Almanca ve İspanyolca bugün açıldı. Liste böylece altı dile tamamlanıyor: İngilizce, Rusça, Türkçe, Basitleştirilmiş Çince, Almanca ve İspanyolca. Türkçe ile Basitleştirilmiş Çince 20 Temmuz 2026'dan beri yayındaydı; sona kalan iki dil bugün eklendi.

Yeni diller de her katmanda geçerli: tanıtım sayfaları, ödeyenin karşısına çıkan ödeme ekranı, Panel, e-posta ve Telegram bildirimleri, mağaza eklentileri. Almanya'ya ya da İspanyolca konuşulan pazarlara satan bir satıcı için değişen yer ödeme ekranı — alıcı sayfayı kendi dilinde açıyor, İngilizceye düşmüyor.

Dil seçici ödeme ekranının kendisinde duruyor. Sayfası yanlış dilde açılan bir ödeyen, faturayı kapatıp baştan başlamak yerine dili tek dokunuşla değiştiriyor.

Satışınız zaten Telegram'da geçiyorsa, ödeyeni oradan çıkarmaya gerek yok. Telegram botu olarak bağlanan bir projede fatura, sayfa adresi yerine bir deep link dönüyor: bağlantı bir sohbet açıyor ve ödeyen ne göndereceğini, hangi ağı kullanacağını orada seçiyor.

Yatırma adımı tek ekran — üretilen QR kod, kopyalama düğmeli adres ve son kullanma süresi yan yana. Ödeyenin Paymos hesabı açması gerekmiyor.

Durum değişiklikleri aynı sohbete düşüyor. Ödemesini yapıp Telegram'ı kapatan biri, faturanın nasıl sonuçlandığını sohbete döndüğünde görüyor. Kurulum: Telegram ödemesi.

Bir satıcıyı yönlendirin, oluşturduğu Paymos işlem komisyonundan pay alın. Dört kademe %20 ile %40 arasında; yükseltmeler 5 ve 20 aktif satıcıda geliyor, en üst kademe ise eşikle değil talep üzerine veriliyor.

Pay, yönlendirdiğiniz satıcının tahsil ettiği her faturada, tahsil edildiği anda hesabınıza işleniyor — ayda bir değil, ödeme takvimine bağlı değil, bir alt sınır dolduğunda değil. Hacimde de toplam komisyonda da tavan yok. Kademe değişikliği yalnızca sonradan yönlendirdiğiniz satıcılara değil, portföyün tamamına uygulanıyor.

Komisyon, Paymos komisyonunun üstüne eklenmiyor, içinden ayrılıyor; yönlendirilen satıcı da diğer satıcılarla aynı tutarı ödüyor.

Linkiniz ve güncel kademeniz Partner programı sayfasında.

Analitik sayfası üç soruyu yanıtlıyor: ne kadar para girdi, faturaların ne kadarı ödendi, ödeyenler ödemeyi ne kadar sürede yaptı.

Dönüşüm yalnızca olgun kohort üzerinden hesaplanıyor: sonucu zaten gözlemlenebilen faturalar. Yirmi dakika önce oluşturulmuş bir fatura başarısız olmuş sayılmaz; onu ödenmemiş kabul etmek oranı boş yere aşağı çeker ve her taze saati bir olay gibi gösterir.

Ödeme süresi ortalama değil, dağılım olarak veriliyor: 0–5 dk, 5–10, 10–15, 15–20 ve 20 dk ve üzeri. Hacim token, ağ ve proje bazında ayrışıyor — her birinde ilk beş, tam liste değil. Fatura hareketliliği ise seçtiğiniz saat diliminde, haftanın günü ve saat bazında gruplanıyor.

Analitik sayfasından açın.

Ayrıcalıklı işlemler; aktörü, işlemi, hedefi, sonucu ve zamanıyla kaydediliyor. Satıcı tarafı da operatör tarafı da tek bir izde.

Her kayıt işlemi açıkça adlandırıyor — merchant.add_whitelisted_address, operator.engage_freeze — ve aktörün o andaki kimliğini, rolü dahil, anlık görüntü olarak saklıyor. Gelecek ay verilen bir terfi, mart ayında bir Viewer'ın ne yaptığını yeniden yazmıyor.

Maskeleme okuma anında değil, yazma anında yapılıyor. Secret'lar, token'lar, hash'ler ve imzalar kayıt saklanmadan önce ayıklanıyor; audit trail böylece sonradan bir kimlik bilgisinin sızdığı yer hâline gelemiyor.

Satıcının gördüğü kendi hesabının geçmişi: cihaz ve IP bilgisiyle birlikte giriş etkinliği. Platformun tamamını kapsayan iz operatöre özel kalıyor — içinde başka satıcıların işlemleri var ve bunu güvenli biçimde açmanın bir yolu yok.

Hesap ve para olayları artık satıcıya iki kanaldan ulaşıyor. Her bildirim aynı olaydan hem e-posta hem Telegram mesajı olarak doğuyor; Telegram'ı bağlamak posta kutusunu susturmuyor, üstüne bir teslimat yolu ekliyor.

Para hareketi kapsamda: çekim oluşturuldu, çekim tamamlandı. Yanında ekip değişiklikleri, denemeleri tükenen webhook teslimatları ve güvenlik kümesi var — 2FA açıldı veya kapatıldı, passkey eklendi veya kaldırıldı, giriş yöntemi bağlandı, beyaz listeye adres eklendi veya adres kaldırıldı, API secret'ı yenilendi, bir kimlik bilgisi iptal edildi.

Rutin kategorileri kapatmak size kalmış. Güvenlik kategorileri kapanmıyor ve onları gizleyen bir ayar yok: çekim adresinizin değiştiğini söyleyen bir bildirim, istenmeyen bir e-postaya fazlasıyla değer. SMS burada bir kanal değil.

Başarısız olan her endpoint aynı biçimde yanıt veriyor: RFC 9457 Problem Details, application/problem+json olarak.

Dallanılacak alan code — yayınlandıktan sonra anlamı değişmeyen sabit bir dize. title ve detail insanlar için yazılıyor; sürümler arasında yeniden ifade edilebilir, genişletilebilir veya yerelleştirilebilir. detail ayrıştıran bir entegrasyon, bir metin düzenlemesinde bozulan entegrasyondur. Tek alanlık doğrulama hataları field taşıyor; birkaç alan aynı anda hata verdiğinde alan bazındaki dökümü errors[] dizisi taşıyor.

type, o kodun dokümantasyondaki satırına doğrudan bağlanıyor; log'daki tanıdık olmayan bir dize böylece tek tıklık mesafeye iniyor. Tam liste /docs/errors/codes adresinde.

İdempotency anahtarı external_order_id. Faturayı oluştururken gönderin; aynı çağrı tekrarlandığında ikinci bir fatura üretilmiyor, mevcut olan dönüyor.

Üretip saklamanız gereken bir Idempotency-Key başlığı yok, çünkü asıl önemli olan zaten elinizdeki tanımlayıcı: sipariş numarası, sepet kimliği, ödeme referansı. Yeni fatura 201 Created yanıtlıyor; aynı tanımlayıcının tekrarı, orijinal faturayla birlikte 200 OK yanıtlıyor. Çekimler de aynı şekilde çalışıyor ve bu özellik asıl orada işe yarıyor: yeniden denenen bir çekim çağrısı, ikinci kez para göndermek yerine ilk çekimi döndürüyor.

Benzersizlik faturalarda proje, çekimlerde satıcı bazında. Sizin tarafınızdaki bir ağ zaman aşımı artık araştırılacak bir konu değil, yeniden denenecek bir çağrı.

Her API kimlik bilgisinin kendi beyaz listesi var: en fazla 50 kayıt, IPv4 ya da IPv6, tek adres ya da CIDR aralığı. Liste boşsa kimlik bilgisi IP kısıtlaması taşımıyor.

Çekim anahtarında bu boşluk uzun sürmüyor. Yeni oluşturulan bir çekim kimlik bilgisi, en az bir adres eklenene kadar pasif kalıyor; oluşturulduğu gün çalınan bir anahtarın çağrılabileceği bir yer olmuyor. Ödeme anahtarları IP kontrolü taşımıyor — fatura oluşturuyorlar, para hareket ettirmiyorlar.

Beyaz listeyi düzenlemek bir step-up işlemi ve audit trail'e fark olarak değil, ayarlanan listenin tamamıyla düşüyor. Para hareket ettiren bir kimlik bilgisinin önündeki duvarı genişletmek, kimin genişlettiğine dair bir kayıt bırakmalı.

Kimlik bilgileri iki türde geliyor. Ödeme anahtarı (pk_) fatura oluşturuyor ve durumunu okuyor; çekim anahtarı (rk_) çekim oluşturup iptal ediyor ve bakiyeleri okuyor.

Kapsam kontrolü rota başına değil, merkezî. Erişim seviyesi her istekte anahtarın türünden türetiliyor; bir istemci paketine sızan ödeme anahtarı, hangi yola yöneltilirse yöneltilsin para hareket ettiremiyor — istek, kontrol etmeyi hatırlayan bir rota tarafından değil, handler'a ulaşmadan reddediliyor.

API secret'ları sk_, webhook imzalama secret'ları whsec_ önekini taşıyor. Ortam da önekin içinde: pk_live_… ile pk_test_… bir config dosyasında gözle ayrılan iki ayrı şey oluyor, birbirine benzeyen iki dize değil.

Anahtarlarınızı Geliştirici → API Anahtarları altından yönetin.

TOTP her hesapta açılabiliyor: doğrulama uygulamasından gelen, otuz saniyede bir yenilenen altı haneli kod.

Girişte sorulması işin küçük yarısı. Büyük yarısı step-up: bir saat önce 2FA'dan geçmiş bir oturumu kabul etmek yerine, çalıştıkları anda taze kod isteyen kısa bir işlem listesi. Çekim adresi eklemek, adres kaldırmak, bir API anahtarının IP beyaz listesini düzenlemek ve 2FA'yı kapatmak ayrı birer kapsam; birinde alınan kod diğerini yetkilendiremiyor.

Açılması da kapatılması da, bildirim tercihleri ne derse desin e-posta ve Telegram üzerinden güvenlik bildirimi gönderiyor. Hesap güvenliği altından kurun.

Artık passkey ile giriş yapılabiliyor: Face ID, Touch ID, Windows Hello ya da bir donanım anahtarı. Akış WebAuthn ve FIDO2 üzerinde çalışıyor ve hiçbir adımında parola yok — burada oltalanacak bir parola zaten hiç olmadı.

Passkey bir anahtar çifti. Özel yarısı cihazda kalıyor ve bize hiç ulaşmıyor; sunucu açık yarısını tutuyor ve yalnızca bir kez geçerli olan bir challenge üzerindeki imzayı doğruluyor. Bizim tarafımızda çalınmaya değer bir şey, sizin tarafınızda inandırıcı bir sahte giriş sayfasına yazılacak bir şey kalmıyor.

Bir hesaba birden fazla cihaz tanımlanabiliyor; herhangi birinin eklenmesi de kaldırılması da kapatılamayan bir güvenlik bildirimi tetikliyor. Magic link, Google ve Telegram girişleri yerinde duruyor — passkey diğerlerinin yerine geçen değil, yanına eklenen bir yol.

Hesap güvenliği altından tanımlayın.

Paymos botu artık bir destek görüşmesi taşıyor. Talepler'i açın, mesajınızı yazın; mesaj platform tarafından yanıtlayan operatörlere ulaşıyor.

Bu bir ticket kuyruğu değil, tek bir görüşme. Yanıtlar aynı sohbete düşüyor, son mesajlar ekranda kalıyor ve operatör yanıtlamadan gönderilen ikinci mesaj iletilmiyor — bot bunu, kimsenin okumadığı bir yığına sessizce eklemek yerine açıkça söylüyor.

Paymos hesabına bağlı olmak şart değil. Bağlı olmamak bir ödeyen için normal bir durum; ödemenin ortasında takılan biri hesabı olmadan da faturasını sorabiliyor. Bağlamak yalnızca botun hesap durumunu gösteren bölümleri için gerekiyor.

WooCommerce, WHMCS, OpenCart, PrestaShop, Magento 2, Shopware 6, CS-Cart ve Easy Digital Downloads için eklentiler yayında.

Bağlantı kopyala-yapıştır değil, tek tık. Mağaza bir Paymos sekmesi açıyor, satıcı isteği hâlihazırda seçili olan projesi üzerinden onaylıyor, eklenti de o projenin kimlik bilgilerini doğrudan alıyor. Ayarlar formuna hassas hiçbir şey yazılmıyor; saklanan değerler tarayıcıya geri verilmiyor. Sızan bir sürüm arşivi her satıcıda birebir aynı ve içinde tek bir anahtar yok.

Sipariş durumu, müşterinin dönüş sayfasına ulaşmasından değil, imzalı webhook'tan geliyor. Kapanan bir tarayıcı sekmesi ödenmiş bir siparişi kaybettirmemeli; bu yüzden doğruluk kaynağı callback, dönüş URL'si ise yalnızca bir nezaket.

Sekizinin de kurulum rehberi /docs altında.

Plasma USDT kabul ediyor. On üçüncü mainnet ağ; liste bugün itibarıyla burada duruyor.

Üzerindeki tek varlık USDT. Bir varlık ödeme sayfasında belirli bir ağda göründüyse, orada etkinleştirildiği için görünüyor; zincirin onu teknik olarak taşıyabiliyor olması yetmiyor. Kararı ağ ve token bazında registry veriyor, bir kontratın zincirde bulunuyor olmasından hiçbir sonuç çıkarılmıyor.

On üç ağ ve beş varlık artık tek bir fatura çağrısının arkasında. Bugün entegre olan bir satıcı, ocak ayında entegre olanla aynı isteği yazıyor: ağ listesi API'nin bir sürümü değil, veri.

TypeScript, Python, PHP, Go, .NET, Java, Ruby ve Rust için resmi istemciler yayında.

Her biri sözleşmenin bir parçasını değil tamamını kapsıyor: faturalar, çekimler, bakiyeler, sunucu saati, cursor tabanlı sayfalama, hata formatı, yeniden denemeler, istek imzalama ve webhook doğrulama. Kütüphaneye asıl değen kısım imzalama. Canonical string, zaman damgası penceresi ve base64 HMAC — üçü de elle yazıldığında ince bir hataya açık; ince hata ise elinizde başka hiçbir ipucu bırakmadan 401 olarak dönüyor.

Webhook doğrulaması, kendi kuralları olan ikinci bir imza. Bu yüzden her doğrulayıcı, JSON ayrıştırmasından önce ham istek byte'larını alıyor. Yeniden serileştirilmiş bir gövde verirseniz kontrol başarısız oluyor — olması gerektiği gibi.

Depolar, sürüm etiketleri ve çalışma zamanı gereksinimleri /docs/server-sdks adresinde.

XAUT Ethereum üzerinde kabul ediliyor. Buradaki stablecoin olmayan ilk varlık ve öyle okunmamalı.

Bir XAUT, London Good Delivery külçesindeki bir saf troy ons altını temsil ediyor; yani XAUT bakiyesi doları değil metali takip ediyor. Dolar alacağı yerine altın tutmayı tercih eden bir satıcı için mesele tam olarak bu. Bedeli de açık: iki yöne birden hareket eden bir bakiye — dolara sabitlenmiş bir tokenin işi bu değil.

Mekanik tarafta özel bir durum yok. Yalnızca Ethereum, aynı tutar bantlı onay politikası, varlık bazında aynı bakiye, çıkışta aynı whitelist. Kabul edilen küme artık dört stablecoin ve bir altın teminatlı varlık.

Sui ödeme almaya başladı; üzerindeki tek varlık USDC.

Sui ne EVM ne de listedeki bir zincirin çatallanmış hâli. Adresleri 32 byte: 0x ve ardından 64 hex karakter, yani bir EVM adresinin iki katı uzunlukta. Bu tek başına, satıcının kayıtlarında ikisini ayrı tutmaya yetiyor. Coin modeli de ERC20 bakiyesine benzemediği için yatırma tespiti ödünç alınmış bir yolu değil, kendi yolunu yürüyor.

Bunların hiçbiri satıcı tarafında görünmüyor. Sui'yi bir projede etkinleştirin, ödeme sayfasında diğerlerinin yanında beliriyor; fatura, webhook ve bakiye tıpkı başka bir ağdaki gibi davranıyor.

İki stablecoin daha kabul ediliyor: Ethereum ve Solana'da USD1, Ethereum'da DAI.

Bunlar aynı türden araç değil. USD1, USDT ve USDC gibi itibari para teminatlı. DAI ise banka mevduatıyla değil, zincir üzerindeki kripto teminatla destekleniyor — aynı dolar biriminin arkasında farklı bir teminat modeli var ve bakiyenin hangisinde tutulduğunu bilmek işe yarıyor.

Hiçbiri girişte dönüştürülmüyor. DAI ile ödenen fatura DAI bakiyesine yazılıyor ve çıkışta DAI olarak ödeniyor; arada USDT üzerinden bir sıçrama da yok, aradan alınan bir makas da. Kabul edilen stablecoin sayısı böylece dörde çıkıyor.

Onay politikası artık iki girdi okuyor: ağ ve faturanın dolar karşılığı. Aynı zincirde 40 dolarlık bir fatura ile 40.000 dolarlık bir fatura aynı sayıda bloğu beklemiyor.

Ethereum 100 dolara kadar 2, 1.000 dolara kadar 6, 10.000 dolara kadar 12, üzerindeki tutarlarda 32 onay bekliyor — en sığ uçta yaklaşık 24 saniye, en derinde yaklaşık altı dakika. Tron 2 ile başlıyor, 6'ya çıkıyor ve 19'da duruyor: 27 süper temsilcisinden 19'unun bloğu katılaştırması, ağın kendi kesinlik standardı. Arbitrum'un 40 / 120 / 240 / 800 sayıları yalnızca blokları saniyenin altında sürdüğü için aşırı görünüyor; saat olarak baktığınızda süreler Base ve Optimism ile aynı.

Kendi finality'sini taşıyan zincirler bantları atlıyor. BSC ve Polygon ağ finality'sinde, Solana finalized taahhüt düzeyinde, TON ise tek blokta onaylıyor — TON'da her masterchain bloğu zaten nihai.

Sayılar yapılandırma; yalnızca biz değiştirdiğimizde değişiyor. Onlardan türeyen süreler öyle değil: ağ tıkandığında bloklar daha yavaş geliyor. Buradaki her süreyi yaklaşık bir değer olarak okuyun, tahsilat garantisi olarak değil.

Solana canlıda. USDT, USDC ve USD1 bu ağ üzerinde tahsil ediliyor.

Solana onayları bir EVM zinciri gibi saymıyor; platform da saydığını varsaymıyor. Yatırmalar finalized taahhüt düzeyinde taranıyor ve orada görüldükleri anda onaylanıyor — tek kademe, tutar bandı yok. Solana'da finalized ne anlama geliyorsa, buradaki onaylanmış ödeme tam olarak odur.

Yatırma adresleri 0x ile başlayan dizeler değil, base58 kodlu ed25519 açık anahtarları; bir satıcının kendi kayıtlarında Solana adresini EVM adresiyle karıştırması bu yüzden mümkün değil. Bakiyeler yine varlık bazında toplanıyor: Solana'da alınan USDC ile Base'de alınan USDC tek bir rakamda birleşiyor.

Avalanche bugün ödeme almaya başladı. USDT de USDC de C-Chain üzerinde tahsil ediliyor.

Adresler ve transaction hash'leri EVM biçiminde; Ethereum ya da Base mutabakatını zaten yapan bir satıcının ayrıştıracağı yeni bir şey yok. Onay burada tutar bantlarıyla çalışmıyor: Snowman kesinliği soruyu her ödeme büyüklüğü için tek seferde kapatıyor, yani zincir bloğu nihai bildirdiğinde yatırma hesaba geçiyor. BSC ile Polygon'un gördüğü tek kademeli muamele bu; Ethereum ve rollup'ların beklediği kademeli blok sayıları değil.

Avalanche'a yapılan çekimler yalnızca satıcının whitelist'inde bulunan adreslere gidiyor. Rotanın ücreti ve alt limiti, çekim onaylanmadan önce görünüyor.

Platform artık çoklu instance çalışıyor. Blok hatları, sweep worker'ları, webhook teslimatçıları ve outbox işlemcileri PostgreSQL advisory lock'ları üzerinden koordine oluyor — herhangi bir anda, herhangi bir iş yükü için tam olarak bir instance lider.

Lider ölürse, başka bir instance bir sonraki polling döngüsünde kilidi devralıyor. Split-brain yok, mükerrer işleme yok, manuel failover yok. Worker'lar tasarım gereği idempotent yazılıyor — lider devir teslimi yüzünden aynı blok aralığı iki kez işlenirse, sonuç bir kez işlenmesiyle aynı.

Veritabanı, değişebilir durum için tek doğruluk kaynağı. Bellek içi önbelleklere yalnızca değişmez sorgular (token decimal'ları, ağ sabitleri) için izin veriliyor. Değişebilen her şey PostgreSQL'de yaşıyor.

Komisyon politikaları artık yalnızca satıcı bazında değil, proje bazında yapılandırılıyor. Her faturadaki platform komisyonu oluşturma anında hesaplanıyor ve faturaya sabitleniyor — müşterinin ödeme sayfasında gördüğü, zincirde tahsil edilenle aynı.

Proje başına iki ayar: platform komisyonu (satıcıdan alınan yüzde) ve müşteri markup'ı (görüntülenen tutarın üzerine eklenen ve ödeyenden alınan, platform komisyonunun yüzdesi). İkisini de sıfıra ayarlayın, satıcı her şeyi üstlenir; markup'ı %100'e çekin, müşteri komisyonun tamamını öder.

Komisyonlar, daha sonra yatırma tutarından yeniden hesaplanmıyor; faturanın kendisinde saklanıyor. Yeniden hesaplama, bizim yaşama hakkımız olmayan bir muhasebe bug'ı sınıfı.

Zincirde takılan çekimler — düşük gas, nonce çakışması, mempool'dan düşme — artık özel bir watchdog tarafından yakalanıyor ve otomatik olarak ilerletiliyor.

EVM zincirlerinde watchdog replace-by-fee kullanıyor: bir transaction yapılandırılan zaman aşımından sonra hâlâ dahil edilmediyse, aynı nonce ile daha yüksek gas fiyatıyla yeniden yayınlanıyor. Orijinal, operasyonun kimliği değişmeden mempool'da geçersiz kılınıyor.

Yayın hataları platform tarafından aksiyon alınabilir gruplara sınıflandırılıyor: revert (handler karar verir), nonce çakışması (taze nonce ile yeniden yayın), düşük fiyat (RBF artışı), yetersiz bakiye (operasyona alarm). Her sınıflandırma çekim durumunda görünüyor — neyin yanlış gittiğini tahmin etmek yok.

Ana kimlik bilgilerini paylaşmadan satıcı hesabına ekip arkadaşları davet edin. Her üye, yetkilendirme hattı seviyesinde zorlanan ince taneli izin kümesine genişleyen bir rol alıyor — UI'da gizlenmiş değil.

Çekim ve whitelist yönetimi varsayılan olarak yalnızca Owner'a açık. Admin'ler faturaları, webhook'ları, projeleri ve ekip üyeliğini yönetebiliyor; ancak açık bir yetki verilmeden para hareket ettiremiyor.

Ayarlar adresinden yönetin.

Tam bir sandbox ortamı production ile paralel çalışıyor. Aynı panel, aynı API yüzeyi; ayrı veritabanı, ayrı imza anahtarları, ayrı webhook uç noktaları — sınırın ötesine hiçbir şey geçmiyor.

Sandbox'ta mainnet'e hiç dokunmadan bir ödemeyi simüle edebilirsiniz. Simulate endpoint'ini bir stage değeriyle (paid, overpaid, underpay, cancel) çağırın; platform doğru yatırma tutarını hesaplıyor ve production'ın tetikleyeceği yaşam döngüsü olaylarının aynısını tetikliyor. Webhook'lar, imzalar, yeniden deneme takvimleri — her şey aynı.

Amacı şu: sandbox'ta entegrasyon testlerini geçen, production'da yayınlanır. "Test ortamı farklıydı" sürprizi yok. Üst bardaki ortam anahtarıyla geçiş yapın.

Barındırılan ödeme sayfası artık satıcının markasını taşıyor. Logo, stil şablonu, vurgu, arka plan ve yüzey renkleri, köşe yarıçapı — proje başına bir kez ayarlanıyor ve o projenin düzenlediği her faturaya uygulanıyor.

Widget oluşturucu aynı marka ayarları üzerine kurulu: yapılandırılan palet ve logo gömülebilir widget'a akıyor; JS snippet'ini çalıştıran bir site, bağlantı verdiği barındırılan ödeme sayfasıyla tutarlı görünüyor.

Markalamayı Ödeme formu sayfasında yapılandırın. Widget oluşturucu Low-Code SDK sayfasında.

Webhook teslimatı artık outbox deseni kullanıyor. Domain event'leri, iş durumunu değiştiren aynı veritabanı transaction'ında outbox'a yazılıyor — ya olay kalıcı olarak kaydediliyor ya da durum değişikliği hiç gerçekleşmiyor. Ayrı bir worker olayları alıp teslim ediyor.

Her payload HMAC-SHA256 ile imzalanıyor. İmza, ham body byte'ları ile bir zaman damgası header'ı üzerinden hesaplanıyor; replay koruması yerleşik — alıcılar yapılandırılan pencereden eski imzaları reddediyor. Secret, panelden endpoint başına rotasyona alınabiliyor.

Teslimat en az bir kez. Yeniden deneme takvimi 1 dakika, 2, 4, 8, 16, 32 dakika, ardından 1, 2, 4, 8 saat — toplam on bir deneme, yaklaşık 16 saate yayılıyor. Alıcıların olay ID'sine göre idempotent olması gerekiyor; ID hem payload'da hem de X-Webhook-Id header'ında yer alıyor.

POS tarzı terminal artık platformun parçası. Oluşturulan QR koduyla tek tıkla fatura — kasiyer müşteriye telefonu uzatıyor, müşteri taratıyor, ödeme satıcının bakiyesine düşüyor.

Terminal sayfası masaüstü için değil, tablet ve telefonlar için tasarlandı. Büyük tutar giriş tuş takımı, belirgin Öde düğmesi; yatırma finalize olduğunda durum gerçek zamanlı olarak onaylandıya dönüyor. Her projeye tek bir terminal adresi düşüyor ve o adres, kasanın ihtiyacı kadar telefon ya da tablette açılıyor — eşleştirilecek cihaz yok, cihaz başına kurulum yok.

/pos adresinden açın.

Public REST API production'da. Girdi JSON, çıktı JSON, OpenAPI spesifikasyonu.

Kimlik bilgileri satıcı, ortam ve anahtar tipine göre kapsamlı; yani ödeme anahtarı ile ödeme çıkışı anahtarı, erişimleri farklı iki ayrı kimlik bilgisi. İstemci paketine sızan bir ödeme anahtarı fatura oluşturur, başka bir şey yapmaz. Rate limit'ler PostgreSQL destekli sabit pencere sayaçlarıyla satıcı başına sayılıyor: çağrı hangi anahtarla gelirse gelsin tek bütçe, senkron tutulacak edge-cache durumu yok.

Auth hattı, paneli koruyanla aynı: her endpoint bir izin attribute'u taşıyor, sahiplik kimlik bilgisinin kapsamına karşı doğrulanıyor, ortam önce kontrol ediliyor. Platform production anahtarıyla sandbox verisi okumayı kesin olarak reddediyor.

Kimlik bilgilerini Geliştirici → API Anahtarları adresinden yönetin. Tam dokümantasyon /docs adresinde.

Widget oluşturucu panelde. Ödeme widget'ını görsel olarak oluşturun — renkler, logo, desteklenen ağlar, varsayılan tutar, yönlendirme davranışı — ve ayarladıkça canlı önizlemenin güncellendiğini görün.

URL durumu sayfaya kodlanıyor; yapılandırılmış bir widget tek bir link olarak paylaşılabiliyor. Dışa aktarma seçenekleri: herhangi bir site için drop-in JavaScript snippet'i veya daha sıkı layout kontrolü için açık boyutlu bir iframe. Widget kararlı bir public endpoint ile konuşuyor; biz iç değişiklikler yayınladığımızda deploy edilmiş bir entegrasyon bozulmuyor.

Oluşturucuyu Low-Code SDK sayfasında açın.

Her komut ve sorgu artık tipli bir hattan akıyor: Logging → Validation → Authorization → Retry → Transaction → Handler. Her adım istek tipine generic — bir behavior eklemek refactor değil, tek bir DI kaydı.

Yetkilendirme istek başına reflection ile çözülmüyor, başlangıçta derleniyor. Her komut, bir izin kapsamına, bir sahiplik kontrolüne ve bir ortam korumasına eşlenen tek bir attribute taşıyor. Derlenmiş tablolar, istek başına yetkilendirmeyi attribute taraması değil, sözlük araması hâline getiriyor.

Validation ilk çalışıyor; çünkü hatalı girdiyi veritabanına dokunmadan reddetmek mümkün olan en ucuz hata. Transaction, handler'dan önceki son behavior — handler'lar kendi transaction'larını açmıyor, içeriye bir tane geçiriliyor.

Barındırılan ödeme sayfası bugün yayında. Müşteriler tek bir URL'ye geliyor, ödeme yapmak istedikleri ağı seçiyor, adresi ve QR kodu görüyor; yatırma ulaştıkça sayfa canlı güncelleniyor.

Arka planda şöyle çalışıyor: ödeme sayfası, kendi SignalR kanalını çalıştıran ayrı bir Blazor host. Müşteri ağını seçtiğinde, platformun ağ bazlı havuzundan bir adres kiralanıyor ve sayfa o faturaya özel durum güncellemelerine abone oluyor. Polling yok, sayfa yenileme yok, manuel "durumu kontrol et" düğmesi yok.

Tek fatura, projenin açtığı bütün ağları kapsıyor — bir kez düzenleyin, müşteri elinde ne varsa Tron, BSC veya Polygon'da ödesin. Adresi doğuran şey bu seçim: öncesinde adres yok, sonrasında tam olarak bir tane var ve borçlanılan tutar o seçime karşı sabitleniyor.

/invoice/{invoice-id} adresinde kullanılabilir.

Satıcı paneli production'da. Sunucu tarafı rendering ve interaktif SignalR kanalıyla Blazor Server üzerine kurulu — güncellemeler polling olmadan ve ayrı bir frontend kod tabanı olmadan UI'a düşüyor.

İlk sürümde gelenler:

• Genel bakış — günlük hacim, başarı oranı, bekleyen olaylar, son yatırmalar (Genel bakış →)
• Faturalar — durum filtreleri, ağ bazında dökümler ve yatırma zaman çizelgesiyle aranabilir geçmiş (Faturalar →)
• Bakiyeler — etkin tüm ağlarda token bazında canlı bakiyeler, çekim geçmişi satır içinde (Bakiyeler →)
• Projeler — proje bazında ayarlar, etkin ağlar ve token'lar, markalama (Projeler →)
• API anahtarları — kimlik bilgileri, webhook uç noktaları, olay günlüğü (API anahtarları →)

Üst bardaki ortam değiştirici, yerinizi kaybetmeden Production ile Sandbox arasında geçiş yapıyor.

Bir fatura, ancak zincir faturanın sona erme zaman damgasını geçtiyse sonuçlandırılabiliyor. Bu, handler'lara serpiştirilmiş bir kontrol olarak değil, domain seviyesinde bir invariant olarak zorlanıyor — ihlal edilirse gürültülü şekilde başarısız oluyor.

Neden önemli: onay tabanlı finality'de bir yatırma, zincirin bakış açısından "süre dolmadan önce" düşebilir ama hat tarafından "süre dolduktan sonra" gözlemlenebilir — safça ele alındığında çift tahsilat veya sessiz fon kaybı yaratan bir race condition. Platform hem son işlenen bloğu hem de son finalize bloğu takip ediyor ve sonuçlandırma ikisini de bekliyor.

Paketteki regresyon testleri her commit'te bu invariant'ı zorluyor. Burada sessiz bir bug yayınlama lüksümüz yok.

Fatura başına adreslere gelen fonlar artık satıcı müdahalesi olmadan otomatik olarak sıcak cüzdanlarda konsolide ediliyor. Sweep arka plan worker'ı olarak çalışıyor ve bir platform operasyonu — satıcı bakiyesi, fon sweep edildiğinde değil, yatırma onaylandığı anda kredilendiriliyor.

EVM zincirlerinde sweep iki aşamalı: önce bir gas drop transaction'ı, ardından token transferi. İkisini de platform ödüyor. Tron'da platform ağ komisyonunu kendi bakiyesinden karşılıyor; satıcı hiçbir zaman bir gas kalemi görmüyor. Başarısız sweep'ler backoff ile tekrar deneniyor; watchdog takılan her şeyi yakalayıp operasyon ekibine bildiriyor.

Sonuç: satıcı bakım gerektiren bir cüzdan değil, bir bakiye alıyor.

Kur alt sistemi production'da. Kripto-fiat ve kripto-kripto dönüşümleri artık bayat sorgular yerine canlı piyasa fiyatlarına göre çözülüyor.

Birincil kaynak CoinGecko; rate limit'te endpoint başına backoff'lu round-robin HTTP havuzu üzerinden erişiliyor. Kurlar kısa TTL ile bellek içinde önbelleğe alınıyor — ödeme adımındaki fiyat çekme gecikmesini karşılayacak kadar uzun, gerçek hareketleri izleyecek kadar kısa. EUR cinsinden fatura kesen bir satıcı, USDT karşılığını ödeyenin token ve ağı seçtiği anda çözülmüş olarak alıyor; kur o faturaya çakılıyor. Piyasa hareket etmeye devam ediyor, borçlanılan tutar etmiyor.

Bayat kurlar bilinen en güncel değere düşüyor; upstream TTL penceresini aşacak kadar erişilemez kalırsa, kura bağlı operasyonlar tahmine dayalı fiyatlandırma yapmak yerine gürültülü şekilde başarısız oluyor.

USDC artık desteklediğimiz altı EVM zincirinin tamamında kabul ediliyor: Ethereum, BSC, Polygon, Arbitrum, Optimism ve Base. Token registry, ağ başına canonical kontrat adresini takip ediyor — native USDC ile köprülenmiş bir varyantı karıştırma ihtimali yok.

Satıcılar USDC'yi proje ayarları sayfasından proje bazında etkinleştirebiliyor. Her proje kendi kabul edilen token listesini taşıyor; fiyatlandırma kuralları proje başına değil, token başına uygulanıyor.

TON ağ listesine katıldı. Tron, altı EVM zinciri ve TON ile platform artık tek bir API üzerinden sekiz ağda tahsilat yapıyor.

TON'un mimarisi EVM'ye hiç benzemiyor. Akıllı kontrat cüzdanları adres başına deploy ediliyor, jetton'lar kendi kontrat çiftlerinde yaşıyor (master + kullanıcı başına cüzdan) ve finality, birkaç saniyede bir değişen validator set'leri üzerinden ilerliyor. Hattımızda özel TON RPC client'ları, jetton-cüzdan türetmesi ve TON'a özgü bir transfer parser'ı var.

TON transaction'ları, ECDSA ağlarında kullanılan secp256k1 şeması yerine Ed25519 uyumlu bir imza yolu kullanıyor; diğer Paymos rotalarıyla aynı çekim hedefi ve audit kontrolleri korunuyor.

Üç L2 rollup ağ listesine katıldı: Arbitrum One, Optimism ve Base. Üçü de EVM hattını paylaşıyor ve ön filtre ile reorg yönetimini miras alıyor.

Rollup'larda gas, L1 Ethereum'a kıyasla belirgin şekilde daha ucuz; bu da Base veya Arbitrum'da USDC tahsilatını düşük tutarlı satışlar için gerçek bir seçenek hâline getiriyor. Onay eşikleri zincir başına ayarlanıyor — Base ve Optimism, yapılandırılan onay derinliğine ulaşıldığında sequencer finality'siyle tahsil ediyor.

Projeler altında proje başına etkinleştirebilirsiniz.

Üç EVM ağı birlikte yayında: Ethereum mainnet, BNB Smart Chain ve Polygon PoS. Tek bir blok hattı üçünü de sürüyor — zincire özgü finality stratejisi ağ başına takılıyor.

Yatırma tespiti, kayan bir pencere üzerinde eth_getLogs ile çalışıyor; canonical token registry'ye karşı bloom-filter ön filtresi sayesinde yalnızca gerçekten önemsediğimiz token'ların log'larını çekiyoruz. Reorg yönetimi parent hash'ler boyunca geri yürüyor, yetim blokları işaretliyor ve yeni fork noktasından tekrar oynatıyor.

Her zincirin round-robin yük dengelemeli ve rate limit'te endpoint başına backoff'lu kendi RPC havuzu var. Yeni bir EVM zinciri eklemek kod değişikliği değil, config değişikliği.

İlk stablecoin canlıda: Tron üzerinde USDT. TRC20 USDT ile düzenlenen faturalar kabul ediliyor, blok finality'sine karşı onaylanıyor ve satıcı bakiyesine kredilendiriliyor — sweep komisyonlarını satıcının tahsil edilen tutarı değil, platform ödüyor.

Token decimal'ları, canonical registry yüklenirken doğrudan kontrattan okunuyor. Tutar matematiği, gösterim string'lerine değil token'ın native birimine göre çalışıyor; böylece yuvarlama hataları UI'dan deftere geri sızmıyor.

İlk ağ production'da. USDT-TRC20 Paymos üzerinden uçtan uca tahsil ediliyor — fatura oluşturma, yatırma tespiti, onay takibi, bakiye kredisi.

Bir ödemenin ne kadar derin onaylanması gerektiği ağ kadar tutara da bağlı; küçük bir ödeme büyüğünden daha erken kesinleşir. Blok hattı, otomatik failover'lı, kendi yönettiğimiz bir RPC havuzundan okuyor. Yatırma tespiti, her log emisyonunu taramak yerine calldata-first bir parser üzerinde çalışıyor — daha ucuz ve daha güvenilir.

Tron ilk geldi. En derin kademe, 27 süper temsilciden 19'unun bloğu katılaştırmasını bekler; 1.000 $ üzerindeki bir ödeme böylece yaklaşık bir dakikada kesinleşir.

Çekimler artık yalnızca önceden onaylanmış, satıcı kontrolündeki adreslere gidebiliyor. Boş bir whitelist, kısıtsız hedefe geri dönmek yerine giden transferleri tamamen kapatıyor.

Hassas whitelist değişiklikleri step-up kimlik doğrulama gerektiriyor ve audit trail'e yazılıyor. Çekim istekleri idempotent kalıyor; aynı isteğin tekrarlanması ikinci bir ödeme oluşturamıyor.

Operatörler ayrıca bir olay araştırılırken tüm giden transferleri durdurabilir veya tek bir varlık-ağ çiftini dondurabilir.

Çift taraflı defter artık platformdaki her hareketi kaydediyor. Yatırmalar, komisyonlar, tahsilatlar, iadeler, tersine çevirmeler — her biri, transaction commit olmadan önce defterin karşı tarafıyla dengeleniyor.

Borçlar alacaklara eşit. Kontrol, kayıtları yazan aynı veritabanı transaction'ının içinde çalışıyor; dengesiz bir kayıt deftere düşemiyor. Satıcı bakiyesi ile zincir üstü gerçeklik arasındaki sapma, bizim yaşama hakkımız olmayan bir bug sınıfı.

Defter yalnızca eklemeli. Düzeltmeler, orijinaline referans veren yeni transaction'lar olarak kaydediliyor — geçmiş bozulmadan ve tekrar oynatılabilir kalıyor.

Çekirdek domain katmanı yerinde. Private setter'lı zengin modeller, her girdiyi doğrulayan factory method'lar ve parasal her şey için value object'ler.

Money, ham decimal değil, bir token'a sabitlenmiş bir value object. Token'lar arası aritmetik derleme zamanında intent olarak yasak, çalışma zamanında da gürültülü şekilde başarısız oluyor — USDT ile TRX toplamak derlenen ya da çalışan bir şey değil.

İş operasyonları exception fırlatmak yerine Outcome<T, Error> döndürüyor. Exception'lar gerçek bug'lara ayrılmış. Beklenen hatalar pipeline'dan değer olarak akıyor.

Paymos geliştirmesi bugün başladı. Host katmanında .NET 10 ve Blazor Server, kalıcılık için EF Core 9 ile PostgreSQL, komut ve sorgu hattında MediatR kullanıyoruz.

Kod tabanı dört katmandan oluşuyor: domain, application, infrastructure ve host — katı bağımlılık tersine çevirmesiyle. Domain hiçbir şeye bağlı değil. Infrastructure, application katmanında tanımlanan portlara uyarlanıyor. Host hepsini birbirine bağlıyor.

Test-first kural, istisna değil. CI her push'ta tüm paketi çalıştırıyor.