Müşteriniz ödemenin gönderildiğini söylüyor ancak bakiyeniz aksini gösteriyor.

Böyle bir durumda, "ödemem kayıp" demek sorunu araştırmak için yeterli bir bilgi değildir. Ödeme destek ekibine iletilecek faydalı bir bildirimde şu soruların net bir şekilde yanıtlanması gerekir: Ne olması gerekiyordu? Gerçekte ne oldu? Hangi ödeme yöntemi kullanıldı? İşlemi hangi referans numarası tanımlıyor? En son nerede onaylandı? Bir sonraki adımı kimin atması gerekiyor?

Buradaki amaç, destek ekibine daha fazla ekran görüntüsü göndermek değil, kayıp bir ödemeyi takip edilebilir bir vakaya dönüştürmektir.

Ödemeniz gerçekten kaybolmak yerine beklemede, inceleme altında, bloke edilmiş veya gecikmiş olarak görünüyorsa öncelikle bu ödeme durumunun gerçekte ne anlama gelebileceğini belirleyin. Ödeme uluslararası bir havaleyse MT103 ve UETR için havale takip adımlarını kullanın. Bir ACH ödemesi gecikmek yerine iade edildiyse ACH iade kodu size yeni bir destek mesajından daha fazla bilgi verebilir.

Bunların her biri farklı sorunlardır. Hepsine tek bir genel "ödeme kayıp" sorunu gibi yaklaşmak, halihazırda elinizde olan bilgileri boşa harcar.

İlk olarak, "kayıp" ifadesinin tam olarak ne anlama geldiğini sınıflandırın

"Gönderildi", "işleniyor", "tamamlandı", "iade edildi" ve "alındı" ifadeleri birbiriyle aynı şey değildir.

Tam durum tanımları bankaya, platforma ve ödeme sağlayıcısına göre değişir. Bu yüzden bir durumun her yerde aynı anlama geldiğini varsaymayın. Bunun yerine, her iki tarafın da gerçekten neyi kanıtlayabildiğini belgeleyin.

Durum etiketi sadece bir ipucudur, araştırmanın kendisi değildir.

Destek talebi açmadan önce bir ödeme zaman çizelgesi oluşturun

Destek ekibi, altı ekran görüntüsü ve bir sohbet geçmişinden ödeme geçmişinizi yeniden oluşturmaya çalışmak zorunda kalmamalıdır.

Önce zaman çizelgesini yazın.

Önemli her olay için şunları kaydedin:

• net tarih;

• net saat;

• saat dilimi;

• işlemi kimin yaptığı;

• o andaki ödeme durumu;

• varsa referans veya talep numarası;

• sonrasında neyin değiştiği.

Net bir zaman çizelgesi şuna benzeyebilir:

24 Ağustos, 14:05 WAT — Müşteri USD ödemesini başlattı.
24 August, 14:09 WAT — Müşteri banka onayını ve ödeme referansını gönderdi.
25 August, 10:20 WAT — Alıcı hesapta görünen gelen bir bakiye yok.
25 August, 16:40 WAT — Alıcı sağlayıcı hesabı kontrol etti; ödeme hâlâ hesaba geçmedi.
26 August, 09:15 WAT — Müşteri, gönderen bankadan takip talep etti.
26 August, 13:30 WAT — UETR alındı ve vakaya eklendi.

Bu, "üç gün oldu ve hâlâ hiçbir şey almadım" demekten çok daha faydalıdır.

Tarihleri yuvarlamayın veya hafızanıza güvenmeyin. Gönderen, banka, sağlayıcı ve alıcı farklı ülkelerdeyse mutlaka saat dilimini de belirtin.

Kayıp ödeme kanıt paketinde neler olmalı?

Güçlü bir paket, ödemenin ticari nedeni ile gerçek işlem arasında bir bağ kurar.

Bunu bir kanıt zinciri olarak düşünün:

fatura veya ödeme talebi → ödeyen → tutar ve para birimi → ödeme kanalı → işlem referansı → mevcut durum → halihazırda atılan adımlar

Faydalı bir pakette en azından şunlar yer almalıdır:

1. Fatura veya ödeme talebi

Neyin ödenmesi gerektiğini açıklayan belgeyi ekleyin.

Faydalı alanlar şunlardır:

• fatura numarası;

• ödeyen veya müşteri adı;

• alıcı adı;

• tutar;

• para birimi;

• fatura tarihi;

• vade tarihi;

• müşteriye ilk verdiğiniz ödeme bilgileri.

Ödeme bir işverenden, platformdan veya fatura kesilmeyen başka bir anlaşmadan geldiyse gönderen ile beklenen ödeme arasında bağ kuran ilgili ödeme ekstresini, havale kaydını, ödeme bildirimini veya diğer belgeleri kullanın.

Destek ekibi özellikle istemediği sürece genellikle tüm müşteri sözleşmesini göndermenize gerek yoktur.

2. Net tutar ve para birimi

"Yaklaşık 1.000 ABD Doları" yazmayın.

Şöyle yazın:

1.000,00 USD

Gönderen belirli bir tutar ödediyse ancak siz kesintiler veya döviz çevrimi sonrası farklı bir tutar bekliyorduysanız, her ikisini de ayrı ayrı kaydedin.

Örneğin:

• Başlatılan tutar: 1.000 USD

• Alıcı hesaba ulaşması beklenen tutar: bilinmiyor

• Hedefteki beklenen para birimi: USD

• Gerçekten yansıyan tutar: 0 USD

Kesintileri, kur farklarını, aracı banka ücretlerini ve gerçekten kayıp bir ödemeyi aynı sorunmuş gibi değerlendirmeyin.

3. Ödeyen onayı

Sadece "gönderildi" yazan bir WhatsApp mesajı değil, banka veya ödeme sağlayıcısı tarafından oluşturulmuş resmi bir kanıt isteyin.

Ödeyen tarafındaki faydalı kanıtlar şunları içerebilir:

• gönderen adı;

• alıcı adı veya hesap bilgileri;

• tutar;

• para birimi;

• başlangıç tarihi;

• transfer durumu;

• işlem/referans kimliği;

• ödeme yöntemi/kanalı;

• banka veya sağlayıcı adı.

Göndericinin ekran görüntüsü yardımcı olabilir ancak nadiren davanın tamamını çözer.

4. İşlem veya ödeme referansı

Bu genellikle paketteki en yararlı alandır.

Doğru tanımlayıcı, kullanılan kanala bağlıdır:

Elinizde gerçek referans metni varsa, sistemlerde aranabilir bu referans yerine ekran görüntüsü göndermeyin.

5. Ödeme için kullanılan alıcı bilgileri

Kullandıklarını düşündüğünüz bilgileri değil, ödeyen kişinin gerçekte kullandığı bilgileri kaydedin.

Kanala bağlı olarak bunlar şunları içerebilir:

• hesap sahibi adı;

• hesap numarası veya IBAN;

• yönlendirme (routing) bilgileri;

• banka adı;

• cüzdan adresi;

• token;

• blokzincir ağı;

• sağlayıcıya özel alıcı tanımlayıcısı.

Bunları ilk başta verdiğiniz bilgilerle karşılaştırın.

Bunu birinden parayı tekrar göndermesini istemeden önce yapın.

6. Her iki taraftaki güncel durum

Gönderenin ne gördüğünü ve alıcının ne gördüğünü yazın.

Örneğin:

Bu, en yaygın iletişim sorunlarından birini önler: her iki tarafın da farklı aşamaları tanımlamak için "tamamlandı" kelimesini kullanması.

7. Halihazırda atılan adımlar

Destek ekibine şimdiye kadar neler yapıldığını anlatın.

Örnekler:

• gönderen alıcı bilgilerini doğruladı;

• alıcı işlem geçmişini kontrol etti;

• gönderen bankayla iletişime geçildi;

• alıcı bankayla iletişime geçildi;

• takip talep edildi;

• iade kodu alındı;

• önceki destek talebi açıldı;

• talep edilen belge sağlandı;

• yeniden gönderme denemesi yapılmadı.

Bu sayede konuyu devralan bir sonraki kişi araştırmaya ilk adımdan başlamak zorunda kalmaz.

Uluslararası müşteri ödemeleri gelirinizin düzenli bir parçasıysa, walllet.com şu anda USD, EUR ve GBP alıcı bilgilerini, geliri USD olarak tutmayı ve gerektiğinde naira cinsine çevirmeyi desteklemektedir.

Freelancer para akışının tamamını görün →

Ekran görüntüsü bağlam sunar. Referans ise takip edilebilir veridir.

Ekran görüntüsü şunları gösterebilir:

• gönderenin belirli bir durumu gördüğünü;

• ödemenin bir uygulamada göründüğünü;

• tutardan düşüş yapıldığını;

• bir hata oluştuğunu;

• ekranda görünen ödeme bilgilerinin beklediğinizle eşleştiğini.

Ancak ekran görüntüsü, başka bir kurumun işlemi aramak için ihtiyaç duyduğu alanı yine de içermeyebilir.

Bu yüzden "müşterim bana bir ekran görüntüsü gönderdi" demek kanıt toplama sürecinin sonu değildir.

Ekran görüntüsünde işlem referansı görünmüyorsa, asıl ödeme onayını veya makbuzunu isteyin.

Görünüyorsa, referansı metin olarak da kopyalayın. Bir destek temsilcisini resimdeki uzun bir tanımlayıcıyı manuel olarak yazmak zorunda bırakmayın.

2026'daki bir SWIFT ödemesi için UETR'ye öncelik verin

UETR, bir ödemeyi Swift zinciri boyunca izlemek için kullanılan uçtan uca tanımlayıcıdır. Swift bunu, kurumların bir ödemeyi bulmasını ve ödeme zinciri boyunca durum değişikliklerini izlemesini sağlayan referans olarak tanımlar.

Eski "sadece MT103 isteyin" tavsiyesine yönelik önemli bir 2026 güncellemesi de var.

Swift'in geleneksel MT ödeme talimatları ile sınır ötesi ödemeler için ISO 20022 arasındaki geçiş dönemi 22 Kasım 2025'te sona erdi. Güncel sınır ötesi bankalar arası ödeme talimatları artık ISO 20022 formatında iletiliyor; Swift, geçiş sürecinde belirli MT talimatları için sınırlı dönüştürme desteği sunmaya devam ediyor.

Bu durum, talebinizin odağını sadece belge adıyla sınırlamamanız gerektiği anlamına gelir.

Kayıp bir SWIFT ödemesi için şunları isteyin:

• UETR kodunu;

• bankanın güncel ödeme onayını veya havale kaydını;

• varsa güncel takip veya araştırma referansını;

• ödeme tarihini;

• tutar ve para birimini;

• kullanılan alıcı bilgilerini.

Bir banka müşteri arayüzünde hâlâ "MT103" terimini kullanabilir veya MT tarzı bir belge sunabilir. Bir diğeri ise ISO 20022 ödeme kaydına bağlı belgeler verebilir. Tek bir PDF formatında ısrar etmektense takip edilebilir tanımlayıcıya odaklanmak çok daha önemlidir.

Şunu da unutmayın: Sadece bir UETR koduna sahip olmak, paranın hesabınıza geçtiğini tek başına kanıtlamaz. Bu kod, kurumlara ödemeyi takip etmeleri için ortak bir tanımlayıcı sağlar.

ACH için iade ile gecikme farklı şeylerdir

Bir müşteri ACH ile ödeme yaptıysa ve ödeme iade edildiyse, duruma "hâlâ yolda" gözüyle bakmayın.

Öncelikle iade bilgisini bulun.

İade kodu hesap bilgileri, hesap durumu, yetkilendirme veya kanala özel diğer sorunları tanımlayabilir. Atılacak doğru adım bu koda bağlıdır.

İlk başarısızlığın nedeni anlaşılmadan müşteriden körü körüne parayı tekrar göndermesini istemeyin. Aksi takdirde, ikinci ödeme ilk hatayı tekrarlayabilir veya mükerrer ödeme sorununa yol açabilir.

Stabil kripto paralar (stablecoin) için kanıtı blokzincir kaydından oluşturun

Stabil kripto para ödemelerinin farklı bir kanıt izi vardır.

Genellikle şunları kaydetmek istersiniz:

• USDT veya USDC gibi token türü;

• blokzincir ağı;

• işlem karması (tx hash);

• gönderici adresi;

• hedef adres;

• tutar;

• işlemin zaman damgası;

• zincir üzerindeki durum.

İşlem karması (hash), "müşterim USDT'nin cüzdanından çıktığını söylüyor" demekten çok daha faydalıdır.

Müşteri ödemelerini düzenli olarak bu şekilde alıyorsanız, adres paylaşmadan önce freelancer'lar için stabil kripto para ödeme kontrol listesini kullanın. Token-ağ-adres uyuşmazlığını önlemek, ödeme gönderildikten sonra bunu araştırmaktan çok daha kolaydır.

Bir işlem zincir üzerinde doğru adrese onaylandıysa ancak saklama (custodial) hizmeti sunan bir platform bunu dahili bakiyenize yansıtmadıysa, blokzincir kanıtı ile platform bakiye sorunu iki ayrı katmandır. Alıcı platforma, güvenli destek kanalı üzerinden işlem karmasını ve kesin ağ bilgilerini iletin.

Gönderen bankayla ilk kim iletişime geçmeli?

İşe ilk olarak gönderici ilişkisini yöneten kişiyle başlayın.

Müşteriniz banka havalesini kendi bankasından veya ödeme sağlayıcısından başlattıysa, gönderici tarafındaki ödeme onayını veya takibini talep etmek için genellikle en iyi konumda olan kişi odur.

Alıcı olarak siz de takip edilebilir bilgileri kendi bankanıza veya alıcı sağlayıcınıza iletebilirsiniz.

Pratik bir iş paylaşımı şu şekilde görünür:

Ödeyen:
"Bu ödemeyi ben başlattım. Lütfen güncel durumunu ve takip tanımlayıcısını sağlayın."

Alıcı:
"Ödeme tanımlayıcısı, tutar, tarih, para birimi, gönderen ve alıcı bilgileri burada. Bu ödemenin size ulaşıp ulaşmadığını onaylayabilir misiniz yoksa daha fazla araştırma mı gerekiyor?"

Bu, iki kuruma da ortak bir referans vermeden "Kayıp paramı bulabilir misiniz?" diye sormaktan çok daha etkilidir.

Gönderen kurum ödemenin alıcı bankaya ulaştığını onaylarsa, kanıt paketi bu durum eklenerek alıcı tarafa taşınabilir.

Gönderen kurum ödemenin iade edildiğini, reddedildiğini, iptal edildiğini veya hiç serbest bırakılmadığını söylerse, sonraki işlem gönderen tarafta kalır.

Hassas her ekran görüntüsünün iki versiyonunu oluşturun

Kimliği doğrulanmış bir destek portalı ile herkese açık bir Telegram grubu, Reddit başlığı veya sosyal medya gönderisi için aynı ekran görüntüsünü kullanmayın.

İki versiyon oluşturun.

Destek için güvenli versiyon

Yalnızca sağlayıcının resmi, kimliği doğrulanmış destek kanalı aracılığıyla kullanın.

Araştırmacının gerçekten ihtiyaç duyduğu bilgileri saklayın. Bunlar şunları içerebilir:

• işlem referansı;

• tutar ve para birimi;

• ilgili hesap bilgileri;

• ödeyen ve alıcı adları;

• ödeme tarihi;

• durum;

• talep edilen destekleyici belgeler.

İlgisiz bilgileri kapatın (sansürleyin).

Herkese açık güvenli versiyon

İdeal olarak, finansal belgeleri hiçbir zaman herkese açık olarak paylaşmayın.

Bir topluluktan genel tavsiye almanız gerekiyorsa şunları kaldırın:

• tam banka hesap numaraları;

• gerekli olmayan durumlarda IBAN'lar;

• tam kart numaraları;

• CVV;

• şifreler;

• PIN kodları;

• tek kullanımlık kodlar;

• pasaport veya kimlik görselleri;

• BVN veya NIN;

• tam ekstreler;

• ilgisi olmayan diğer işlemler;

• e-posta adresleri ve telefon numaraları;

• açık olması gerekmeyen ödeme referansları;

• API kimlik bilgileri;

• cüzdan özel anahtarları (private key);

• kurtarma kelimeleri (seed phrase).

Bir kurtarma kelimesi veya özel anahtar asla destek ekibine gönderilmemelidir.

Karartma işlemi, alıcının ihtiyaç duymadığı şeyleri kaldırmalıdır, ihtiyaç duyduğu kanıtları yok etmemelidir.

Tek bir araştırmayı beş farklı talebe bölmeyin

Birden fazla destek talebi açmak kanıtlarınızı, zaman çizelgenizi ve güncellemelerinizi ayrı sohbetlere bölebilir.

Sağlayıcı aksini istemedikçe, kendi kayıtlarınız için tek bir ana vaka üzerinden ilerleyin.

Şunları kaydedin:

• talep numarası;

• açılış tarihi;

• kanal;

• son yanıt;

• talep edilen belgeler;

• sağlanan belgeler;

• sağlayıcının belirttiği bir sonraki işlem tarihi.

Bir şeyler değiştiğinde, mevcut talebi yeni kanıtlarla güncelleyin.

Bu, daha hızlı bir çözüm sunmayı garantilemez. Sadece vakanın tek ve tutarlı bir versiyonunu korur.

Sorun çözülmeden bir vaka kapatılırsa, yeniden açarken veya üst mercilere iletirken orijinal talep numarasını belirtin.

Sırf ilki zor bulunuyor diye bir ödemeyi tekrar göndermeyin

Kayıp bir transfer "tekrar deneme" baskısı yaratır.

Bu durum ikinci bir sorun yaratabilir.

Yeniden göndermeden önce, ilk denemeye ne olduğunu kesinleştirin.

Yeniden gönderim, orijinal ödemenin durumu net olarak şu şekildeyse daha kolay gerekçelendirilir:

• reddedildi;

• iade edildi;

• iptal edildi;

• mutabakat öncesi başarısız oldu;

• veya sorumlu sağlayıcı tarafından artık alıcıya ulaşamayacağı onaylandı.

İlk ödeme hâlâ işleniyorsa, araştırılıyorsa veya kanallardan birindeyse, ikinci bir ödeme göndermek mükerrer ödemeye yol açabilir.

Aynı kural, bir sorun başladıktan sonra yapılan küçük "test" denemeleri için de geçerlidir. Bir test ödemesi, rota belirsiz olduğunda büyük bir transferden önce yararlıdır; çözülmemiş bir ödeme halihazırda işlemdeyken otomatik olarak doğru sorun giderme adımı değildir.

Kopyalanabilir kayıp ödeme destek talebi şablonu

Araştırmacıya başlamak için yeterli yapıyı sağlayan tek bir mesaj kullanın.

Konu: Kayıp ödeme — [tutar + para birimi] — [ödeme tarihi] — [referans]

Merhaba,

Hesabıma geçmeyen bir ödemeyi bildirmek istiyorum.

Beklenen ödeme

Tutar: [tutar]
Para birimi: [para birimi]
Ödeyen: [ad/şirket]
Alıcı: [ad]
Ödeme yöntemi: [SWIFT / ACH / platform / yerel transfer / stablecoin / diğer]
Ödeme başlangıcı: [tarih, saat, saat dilimi]

Güncel durum

Gönderen tarafındaki durum: [durum]
Alıcı tarafındaki durum: [durum]

Ödeme tanımlayıcıları

Sağlayıcı/banka referansı: [referans]
Varsa UETR / ACH takibi / işlem karması (tx hash): [tanımlayıcı]

Zaman çizelgesi

[tarih/saat] — [olay]
[tarih/saat] — [olay]
[tarih/saat] — [olay]

Ekli kanıtlar

[fatura/ödeme talebi]
[ödeyen onayı]
[ödeme makbuzu/havale kaydı]
[karartılmış ekran görüntüsü]
[varsa takip veya iade belgesi]

Halihazırda atılan adımlar

[işlem] — [sonuç]
[işlem] — [sonuç]

Lütfen şunları onaylayın:

1. bu ödemenin güncel durumunu;

2. yukarıdaki referansın bunu izlemek için yeterli olup olmadığını;

3. bir sonraki işlemin başka bir banka, sağlayıcı veya tarafa ait olup olmadığını;

4. benden başka hangi ek kanıtları talep ettiğinizi.

Daha hassas hesap veya kimlik bilgileri gerekiyorsa, lütfen hangi güvenli kanalı kullanmam gerektiğini bana bildirin.

Teşekkürler.

Destek talebinin neyi söylemediğine dikkat edin:

“Çok Acil!!! Param kayboldu. Lütfen hemen çözün.”

Durum gerçekten acil olabilir. Ancak bu yine de ödemeyi tanımlamaz.

Vaka için basit bir klasör yapısı kullanın

Araştırma tek bir konuşmadan daha uzun sürerse, kanıtları sohbet geçmişinizin dışında saklayın.

Örneğin:

kayip-odeme-2026-08/

├── 00-vaka-ozeti.txt

├── 01-fatura.pdf

├── 02-odeyen-onayi.pdf

├── 03-odeme-referansi.txt

├── 04-zaman-cizelgesi.txt

├── 05-takip-belgesi.pdf

├── 06-destek-icin-guvenli-ekran-goruntuleri/

└── 07-destek-yazismalari/

Belgeler değiştikçe dosya adlarında tarihleri kullanın.

Orijinal kanıtın üzerine yoğun şekilde sansürlenmiş bir kopyasını kaydetmeyin. Orijinalini gizli tutun, ardından paylaşmak için ayrı bir sürüm oluşturun.

En iyi kanıt paketi, ödeme kaybolmadan önce başlar

Araştırılması en kolay kayıp ödeme, kayıtları zaten mevcut olandır.

Bir sonraki uluslararası müşteri ödemesinden önce:

1. ödeme bilgilerini yazılı ve tekrar kullanılabilir bir formatta gönderin;

2. ödeyen kişinin doğru alıcı bilgilerine sahip olduğunu onaylayın;

3. para birimi ve rota üzerinde anlaşın;

4. faturayı saklayın;

5. ödeme onayını kaydedin;

6. işlem referansını oluşur oluşmaz kaydedin;

7. para ulaştığında nihai alıcı kaydını saklayın.

Farklı pazarlardaki müşterilerin size nasıl ödeme yapacağına karar veriyorsanız, ABD, İngiltere ve AB müşteri ödemeleri iş akışı ödeme başlatılmadan önce mevcut kanalların nasıl farklılaştığını açıklar.

Amaç sadece bürokrasi yaratmak değildir.

Her ödemenin daha sonra hesap verilebilir olmasını sağlamaktır.

Davayı daha gürültülü değil, daha aranabilir hale getirin

Tek bir pakette tutar, para birimi, ödeyen, alıcı, yöntem, tarihler, durum, ödeme referansı, destekleyici belgeler ve halihazırda atılan adımlar yer aldığında, kayıp bir ödeme araştırmasını devretmek çok daha kolay hale gelir.

Her bankayı, aracıyı, platformu, incelemeyi veya destek kuyruğunu kontrol edemezsiniz.

Ancak bir sonraki kişinin belirsiz bir şikayet mi yoksa gerçekten tanımlayabileceği bir vaka mı alacağını kontrol edebilirsiniz.

walllet.com ile küresel olarak ödeme alın, USD olarak biriktirin ve naira olarak nakde çevirin