Yanlış ağ, yanlış token: müşterinin ödemesi nereye gitti?

Ödeme sayfası adresi Polygon'da gösterdi, müşteri borsasının çekim formunda BNB Smart Chain'i seçti. Başka bir gün fatura USDT istedi, cüzdandan USDC çıktı. Yanlış ağdan ya da yanlış tokenla gelen ödeme Paymos'ta yok olmaz; üç sondan birine varır. Faturanın kabul ettiği başka bir ağdan gelen aynı token faturayı kendiliğinden, bire bir öder. Paymos'un o ağda kabul ettiği başka bir token destek talebi ve kurtarma ücreti olmadan, yalnızca olağan işlem komisyonu düşülerek bakiyenize geçer; fatura ise ödenmeden süresini doldurur. Kendiliğinden gelmeyen iki şey kalıyor: faturanın kabul etmediği token ya da ağla yapılan transfer ve ağın minimum tutarının altındaki ödeme.

Hangisiyle karşı karşıya olduğunuz, müşteriye ne diyeceğinizi de sipariş sisteminizin sıradaki adımını da belirler. Tutar tutmadığında olanlar eksik ve fazla ödeme yazısında anlatılıyor. Bu yazı fatura adresine ulaşan ama faturayı ödemeyen parayı anlatıyor: ona ne olur, size nasıl haber verilir, sunucunuz hangi olayı alır.

Müşteri başka bir ağdan öderse ne olur?

Paymos'un o tokeni kabul ettiği ağların neredeyse hepsinde ödeme faturaya bire bir sayılır.

Hatayı mümkün kılan adres. 0x ile başlayan adres, Ethereum Sanal Makinesi (EVM) üzerinde çalışan her ağda aynı dizedir. MetaMask yardım merkezi bunu açıkça yazıyor: kurtarma ifadesi "generates the same address across all EVM-compatible networks". Baştaki örnekte transfer tam da bu yüzden aynı adrese ulaştı, yalnızca başka bir zincirde.

Transfer faturaya, ağ doğru seçilmiş gibi sayılır. Fatura kapanır, uç noktanıza doğru ağda gelecek olayların aynısı düşer, sipariş de her zamanki yolundan çıkar — ne sizin ne müşterinin yapacak bir şeyi var. Hangi ağda hangi tokenin kabul edildiği ağlar sayfasında.

Paymos tokeni o ağda kabul ettiği hâlde ödeme faturaya sayılmazsa para, ağın minimumunun altında kalmadığı sürece fatura dışında bakiyenize geçer; fatura da süresi dolunca kapanır. Bu transfer tek başına ya da daha önce ödenenlerle birlikte fatura tutarını karşılarsa uç noktanıza ardından invoice.paid_late gelir. Faturanın durumu değişmez, paid_late_at tutara ne zaman ulaşıldığını gösterir; siparişi gönderip göndermeyeceğinize siz karar verirsiniz.

Tron, TON ve Solana'nın adres biçimi kendine özgü ve başka ağın cüzdanı böyle bir adresi alıcı olarak kabul etmez. Faturaya kadar ulaşan ağ hataları bu yüzden EVM zincirleri arasında yaşanır.

Müşteri yanlış tokenla öderse para nereye gider?

Bakiyenize — Paymos o tokeni geldiği ağda kabul ediyorsa. Destek talebi açmanız gerekmez, kurtarma ücreti de yok: düşülen tek şey, tamamlanan her ödemeden alınan olağan işlem komisyonu. Oranı fiyat sayfasında.

USDT ile fiyatlanmış faturaya gelen USDC, bakiyeye USDC olarak geçer: gönderilen tutar, eksi bu komisyon. Hiçbir şey dönüştürülmez, tutarı fatura tutarına benzetmek için kur da uygulanmaz. Faturayı bu transfer ödemez; başka bir token sonradan da fatura tutarına sayılmaz, bu yüzden ardından invoice.paid_late da gelmez. Alacak yanlış tokenla gelen ödeme olarak işaretlenir ve arkasındaki sipariş sizin kararınızı bekler.

Belirleyici olan token tek başına değil, token ile ağın çifti. Aynı tokenin her ağdaki kopyası ayrı kontrattır ve her ihraççı kendi ağ listesini tutar: USDC için Circle, USDT için Tether. Paymos'ta geçerli çiftler /tokens/usdt ve /tokens/usdc sayfalarında duruyor. İşletme için hangi dolar tokeninin daha uygun olduğu ise USDT, USDC ve DAI karşılaştırmasının konusu.

Para bakiyede, sipariş neden iptal oldu?

Fatura süresini doldurdu, sunucunuz da süre dolumuna göre davrandı. Entegrasyonunuzda değiştirmeniz gereken tek yer burası.

Fatura dışında bakiyeye geçen paranın kendi webhook'u yok: olay kataloğundaki dokuz fatura olayından hiçbiri alacağı anlatmaz. Paranın ıskaladığı fatura ise pencereyi sonuna kadar bekler ve onun için invoice.expired gider. Dokümantasyondaki karşılığı: "Fatura, uygun bir ödeme alınmadan süresi doldu". Cümle doğru, ama bakiyenizde duran paradan hiç söz etmiyor.

Bugün yeniden okunacak işleyici bu yüzden süre dolumu işleyicisi. Ürünü stoğa geri koymak, rezervasyonu bırakmak, siparişi iptal etmek, müşteriye "ödemeniz gelmedi" diye yazmak: bu vakada her biri parası ödenmiş siparişe uygulanır.

// invoice.expired: fatura ödenmedi demek.
// Adresine kimsenin para göndermediği anlamına gelmez.
if ($event['event_type'] === 'invoice.expired') {
    $orders->holdForReview($event['data']['invoice_id']); // iptal yok, stoğa iade yok
}

Süresi dolan siparişi bir insan bakana kadar bekletmek, sıradan süre dolumlarında da daha güvenli varsayılandır. Webhook'un neden iki kez geldiğini anlatan yazıdaki gerekçe burada başka bir kapıdan giriyor.

Bekletilen siparişe sonradan ikinci bir sinyal gelebilir. Faturanın tokeniyle gelen para, ister geç gönderilmiş ister başka ağdan gelmiş olsun, sonunda tutarı karşılarsa aynı fatura için invoice.paid_late gelir. Durum expired kalır, yani olay tek başına hiçbir şeyi değiştirmez. Onu bekletilen siparişe not olarak ekleyin; siparişi inceleyen kişi de bir kez daha baksın. Başka bir token bu olayı hiç tetiklemez.

Bakiyeye geçen tutardan nasıl haberiniz olur?

Bildirim alacakla birlikte çıkar: e-postayla, paneldeki zil simgesinde ve iletişim bağlıysa Telegram'da. Transfer çıkışı bildirimleriyle aynı yere gelir. İçinde bakiyeye geçen net tutar, ayrı satırda komisyon, token, ağ, neden ve panele giden bağlantı var.

Bakiye sayfasında bu alacaklar Hareketler sekmesinde, transfer çıkışlarınızla aynı tabloda durur; tür filtresi ikisini ayırır. Her satırda paranın faturalı mı faturasız mı geldiği ve durumun ne olduğu yazar: yanlış token, yanlış ağ, süreden sonra gelen ödeme, zaten kapalı fatura ya da faturası olmayan adres. Tutar + işaretiyle görünür ve bakiyeye geçeni gösterir.

Satıra tıklayınca ayrıntılar açılır: Gelen, Komisyon, Bakiyeye geçen, adresin ait olduğu Fatura ya da Fatura yok, Gönderen, İşlem ve kısa bir açıklama. Alacağın arkasındaki transfer hiç görülmediyse satırda Gönderen bilinmiyor ve İşlem bilinmiyor yazar; sonradan bulunan ayrıntılar aynı satıra eklenir.

Alacakların kendisi için ne webhook var ne API çağrısı; entegrasyon onları panelden ve e-postadan öğrenir. Bu paranın yol açabileceği tek olay, yukarıda anlatılan invoice.paid_late.

Siparişe ne olacak, paraya ne olacak?

Karar sizin; vermek için gereken her şey de önünüzde. Hangisini seçerseniz seçin fatura, invoice.paid_late gelmiş olsa bile expired kalır. Seçtiğiniz, siparişin akıbeti.

Siparişi göndermek, onu kendi sisteminizde elle kapatmak demek. Ödemenin kanıtı burada fatura durumu değil, alacak satırı. Satırın ayrıntılarını siparişin üzerine kopyalayın; ekibiniz bir sonraki mutabakatta oraya bakacak.

İade ise bakiyenizden çıkan bir transfer ve tutarını, tokenini, ağını siz belirlersiniz. Kendiliğinden hiçbir şey geri gitmez, ürün de ödeyene iade sözü vermez. Gereken malzemeyi satır verir: gelen tutar, düşülen komisyon ve biliniyorsa gönderen adresi ile işlem hash'i.

Müşteriye söz vermeden önce iki şeyi netleştirin. Bakiyede gelen tutarın komisyon düşülmüş hâli duruyor, yani gönderilenin tamamını geri vermek aradaki farkı cebinizden ödemek demek. Gönderen bilinmiyorsa da iadenin gideceği bir adres yok.

Para hangi durumlarda kendiliğinden gelmez?

Üç durumda; hiçbirinde otomatik alacak oluşmaz.

Paymos'un o ağda kabul etmediği token. Tron ya da TON'da USDC, Base'de USDT gibi. Böyle bir transfer bakiyeye geçmez. Geçerli çiftlerin tamamı /tokens/usdt, /tokens/usdc ve /chains sayfalarında.

Faturanın kabul etmediği ağ. 0x ile başlayan adreste gerçekçi hata tam burada yaşanır, çünkü aynı adres her EVM zincirinde var. Ethereum'un kendi sürecinde önerilen ERC-7828 standardı, ana ağla aynı adres biçimini paylaşan yüzlerce, zamanla binlerce ikinci katman ağından söz ediyor: "hundreds, and eventually thousands, of L2s that share the same address format as Ethereum mainnet". Bu, Paymos'un kabul ettiği ağ sayısının çok üstünde. O ağlardan birinde gönderilen ödeme o zincirde, o adreste kalır.

Ağın minimum tutarının altındaki ödeme. Paymos ödeme sayfası, minimumu fatura tutarının üstünde kalan token ve ağı seçtirmez; sayfanın gösterdiği ağda tam tutarı ödeyen bu sınıra hiç takılmaz. Takılan, küçük bir kısmi transfer ya da minimumu daha yüksek bir ağa sapan ödemedir. Minimumun altındaki tutar bakiyeye geçmez ve gerisiyle destek ilgilenir.

Parayı zaten gönderen müşteri ne yapmalı?

Satıcıya yazmalı ve dört şey eklemeli: sipariş numarası, token, ağ ve işlem hash'i. Onaylanmış transferi müşteri kendi tarafından geri alamaz. Blokzincir ödemesinde istenebilecek bir ters ibraz yok, parayı gönderen cüzdan da onu geri çekemez.

Doğru adres satıcı, çünkü her sonuç satıcıda biter. Ödeme faturayı kapattıysa sipariş zaten yolundadır. Fatura dışında bakiyeye geçtiyse para satıcının elindedir ve karar onundur. Kendiliğinden gelmediyse destek önce hash'i sorar. Müşteri ödeme sayfasından Paymos desteğine de yazabilir, oradaki operatörler gerekirse satıcıyı sürece katar; istenen dört ayrıntı değişmez.

Dördünün en değerlisi hash. Onunla ödeme, tutarları ve saatleri tek tek eşleştirmeden bulunur.

Eksik ya da fazla ödemeden farkı ne?

Fark, paranın arkasında fatura olup olmamasında.

Fazla ve eksik ödeme, faturanın geçtiği durumlardır. Her birinin entegrasyonunuzun okuduğu bir durumu ve abone olduğu bir olayı var — invoice.paid_over, invoice.underpaid, invoice.underpaid_waiting — ve her birinin arkasında var olan, bir şey bekleyen sipariş durur. İkisi de tutar yazısında anlatılıyor; faturanın nasıl kesildiği ise kripto fatura rehberinde.

Fatura dışı alacak, arkasında fatura olmayan paradır. Durumu yok, kendi olayı yok. Ait gibi göründüğü siparişin süresi dolmuş, haftalar önce kapanmış ya da o sipariş hiç var olmamış olabilir.

İkisini karıştıran operatör hep aynı hatayı yapar: bakiyedeki alacağı faturaya gelmiş kısmi ödeme sanıp siparişi faturaya dayanarak gönderir. Fatura hiçbir zaman tamamlanmaz ve bir sonraki mutabakatta kimsenin birbirine bağlamadığı bir alacakla bir sipariş yan yana durur. Ayırmak için tek soru yeter: bu parayı hangi fatura bekliyor? Eksik ödemede bunun cevabı var, fatura dışı alacakta yok.