Müşteriniz ödemenin gönderildiğini söylüyor. Bakiyeniz ise aksini.

Bu noktada “ödemem kayıp” demek, herhangi bir inceleme için yeterli bilgi değildir. İşe yarar bir ödeme destek başvurusu daha net sorulara yanıt vermelidir: Ne olması gerekiyordu? Gerçekte ne oldu? Hangi ödeme yolu kullanıldı? İşlemi hangi referans tanımlıyor? En son nerede onaylandı? Bir sonraki adımı kim atabilir?

Amaç desteğe daha fazla ekran görüntüsü göndermek değil. Amaç, kayıp bir ödemeyi takip edilebilir tek bir vakaya dönüştürmek.

Ödemeniz gerçekten kayıp değil de beklemede, incelemede, bekletiliyor veya gecikmiş görünüyorsa, önce bu ödeme durumunun aslında ne anlama gelebileceğini belirleyin. Ödeme uluslararası bir havaleyse MT103 ve UETR ile havale takibi sürecini kullanın. Bir ACH ödemesi sadece gecikmemiş de iade edilmişse, ACH iade kodu size yeni bir destek mesajından daha fazlasını söyleyebilir.

Bunlar farklı sorunlardır. Hepsini genel bir “ödeme kayıp” sorunu gibi ele almak, elinizde zaten olabilecek bilgileri boşa harcar.

Önce “kayıp”ın gerçekte ne anlama geldiğini belirleyin

“Gönderildi”, “işleniyor”, “tamamlandı”, “iade edildi” ve “alındı” birbirinin yerine kullanılamaz.

Kesin durum adları 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 tarafın gerçekte neyi kanıtlayabildiğini kayda geçirin.

Bir durum etiketi bir ipucudur. İncelemenin kendisi değildir.

Talebi oluşturmadan önce bir ödeme zaman çizelgesi hazırlayın

Destek ekibi ödeme geçmişinizi altı ekran görüntüsü ve bir sohbet kaydından yeniden kurmak zorunda kalmamalı.

Önce zaman çizelgesini yazın.

Her önemli olay için şunları kaydedin:

• kesin tarih;

• kesin saat;

• saat dilimi;

• işlemi kimin yaptığı;

• o anda görünen ödeme durumu;

• varsa referans veya vaka numarası;

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

Düzenli bir zaman çizelgesi şöyle görünebilir:

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

Bu, “üç gün oldu ve hâlâ hiçbir şey almadım” demekten çok daha işe yarar.

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

Kayıp ödeme kanıt paketine neler girer?

Güçlü bir paket, ödemenin ticari nedenini gerçek işlemle birbirine bağlar.

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

fatura veya ödeme talebi → ödeyen → tutar ve para birimi → ödeme yolu → işlem referansı → güncel durum → atılmış adımlar

İşe yarar en küçük paket genellikle şunları içerir.

1. Fatura veya ödeme talebi

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

İşe yarar alanlar şunlardır:

• fatura numarası;

• ödeyen veya müşteri adı;

• alıcı adı;

• tutar;

• para birimi;

• fatura tarihi;

• son ödeme tarihi;

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

Ödeme bir işverenden, platformdan veya faturasız başka bir düzenlemeden geldiyse; göndereni beklenen ödemeyle ilişkilendiren ödeme dökümünü, havale kaydını, ödeme bildirimini veya ilgili başka bir belgeyi kullanın.

Destek özellikle istemedikçe genellikle müşteri sözleşmesinin tamamını göndermeniz gerekmez.

2. Kesin tutar ve para birimi

“Yaklaşık $1,000” yazmayın.

Yazın:

Şunu yazın:

Gönderen bir tutar ödediyse ama siz kesintiler veya döviz çevrimi sonrası başka bir tutar bekliyorsanız, ikisini ayrı ayrı kaydedin.

Örneğin:

• Başlatılan tutar: USD 1,000

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

• Varış noktasında beklenen para birimi: USD

• Hesaba gerçekten geçen tutar: USD 0

Ücretleri, döviz kesintilerini, aracı banka masraflarını ve gerçekten kayıp bir ödemeyi sessizce aynı sorun gibi ele almayın.

3. Ödeyen onayı

Yalnızca “gönderildi” diyen bir WhatsApp mesajı değil, banka veya ödeme sağlayıcısının oluşturduğu bir kanıt isteyin.

Ödeyen tarafındaki işe yarar kanıt şunları içerebilir:

• gönderen adı;

• alıcı adı veya hesap bilgileri;

• tutar;

• para birimi;

• başlatma tarihi;

• transfer durumu;

• işlem/referans numarası;

• ödeme yolu;

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

Gönderenin ekran görüntüsü yardımcı olabilir. Ama nadiren vakanın tamamıdır.

4. İşlem veya ödeme referansı

Bu genellikle paketteki en işe yarar alandır.

Doğru numara ödeme yoluna bağlıdır:

Gerçek referans metni elinizdeyse, makinede aranabilir bir referansın yerine ekran görüntüsü koymayın.

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

Ödeyenin kullandığını düşündüğünüz bilgileri değil, gerçekten kullandığı bilgileri kaydedin.

Ödeme yoluna göre bunlar şunları içerebilir:

• hesap sahibinin adı;

• hesap numarası veya IBAN;

• yönlendirme (routing) bilgileri;

• banka adı;

• cüzdan adresi;

• token;

• blokzincir ağı;

• sağlayıcıya özel alıcı numarası.

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

Bunu kimseden parayı yeniden göndermesini istemeden önce yapın.

6. İki 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: iki tarafın da farklı aşamaları anlatmak için “tamamlandı” kelimesini kullanması.

7. Atılmış adımlar

Desteğe şimdiye kadar neler yapıldığını söyleyin.

Ö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 talep açıldı;

• istenen belge sağlandı;

• yeniden gönderim denenmedi.

Böylece bir sonraki kişi incelemeye en baştan başlamaz.

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

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

Ekran görüntüsü bağlamdır. Referans takip edilebilir veridir.

Bir ekran görüntüsü şunları gösterebilir:

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

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

• bir tutarın hesaptan düşüldüğünü;

• bir hata çıktığını;

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

Ancak bir ekran görüntüsü, başka bir kurumun işlemi araması için gereken alanı yine de içermeyebilir.

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

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

Referans görünüyorsa, onu ayrıca metin olarak da kopyalayın. Bir temsilcinin uzun bir numarayı görselden elle yazmasını beklemeyin.

2026'da bir SWIFT ödemesi için önceliği UETR'ye verin

UETR, bir ödemeyi Swift zinciri boyunca takip etmek için kullanılan uçtan uca numaradı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 iste” tavsiyesine dair 2026'da önemli bir güncelleme de var.

Swift'te sınır ötesi ödemeler için geleneksel MT ödeme talimatları ile ISO 20022'nin birlikte kullanıldığı 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 bazı MT talimatları için sınırlı bir acil durum dönüşümü sürdürüyor.

Bu, talebinizin tamamını belge adına dayandırmamanız gerektiği anlamına gelir.

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

• UETR;

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

• varsa güncel takip veya inceleme referansı;

• ödeme tarihi;

• tutar ve para birimi;

• kullanılan alıcı bilgileri.

Bir banka, müşteriye dönük süreçlerinde hâlâ “MT103” terimini kullanabilir veya MT tarzı bir gösterim sunabilir. Bir başkası ISO 20022 ödeme kaydına bağlı belgeler verebilir. Takip edilebilir numara, belirli bir PDF formatında ısrar etmekten daha önemlidir.

Şunu da unutmayın: bir UETR'ye sahip olmak tek başına paranın hesabınıza geçtiğini kanıtlamaz. Kurumlara ödemeyi takip etmek için ortak bir numara sağlar.

ACH'de iade, gecikmeyle aynı şey değildir

Bir müşteri ACH ile ödediyse ve ödeme iade edildiyse, vakayı “hâlâ yolda” gibi ele almayın.

Önce iade bilgisini bulun.

Bir iade kodu; hesap bilgileri, hesap durumu, yetkilendirme veya o yola özgü başka bir sorunu gösterebilir. Doğru sonraki adım bu koda bağlıdır.

İlk başarısızlık anlaşılmadan müşteriden körü körüne yeniden göndermesini istemeyin. Aksi halde ikinci ödeme aynı hatayı tekrarlayabilir veya mükerrer ödeme sorunu yaratabilir.

Stablecoin'lerde kanıtı blokzincir kaydından oluşturun

Bir stablecoin ödemesinin kanıt izi farklıdır.

Genellikle şunları kaydetmek istersiniz:

• USDT veya USDC gibi token;

• blokzincir ağı;

• işlem hash'i;

• gönderen adres;

• hedef adres;

• tutar;

• işlem zaman damgası;

• zincir üstü durum.

İşlem hash'i, “müşterim USDT'nin cüzdanından çıktığını söylüyor” demekten çok daha işe yarar.

Müşteri ödemelerini düzenli olarak bu şekilde alıyorsanız, bir adres paylaşmadan önce freelancer'lar için stablecoin ödeme kontrol listesini kullanın. Token-ağ-adres uyumsuzluğunu önlemek, ödeme gönderildikten sonra incelemekten çok daha kolaydır.

Bir işlem zincir üstünde doğru adrese onaylanmış ama emanetçi (custodial) bir platform iç bakiyenize yansıtmamışsa, blokzincir kanıtı ile platformun hesaba geçirme sorunu iki ayrı katmandır. Alıcı platforma işlem hash'ini ve kesin ağ bilgilerini güvenli destek kanalı üzerinden verin.

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

Gönderen taraftaki ilişkiyi kim yönetiyorsa onunla başlayın.

Banka transferini müşteriniz kendi bankasından veya ödeme sağlayıcısından başlattıysa, gönderen taraftaki ödeme onayını veya takibi talep etmek için genellikle en uygun kişi odur.

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

Pratik bir devir şöyle görünür:

Ödeyen:
“Bu ödemeyi ben başlattım. Lütfen güncel durumunu ve takip numarasını iletin.”

Alıcı:
“Ödeme numarası, tutar, tarih, para birimi, gönderen ve alıcı bilgileri burada. Bu ödemenin sizin tarafınıza ulaşıp ulaşmadığını veya ek inceleme gerekip gerekmediğini teyit edebilir misiniz?”

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

Gönderen kurum ödemenin alıcı bankaya ulaştığını teyit ederse, kanıt paketi bu durum bilgisiyle birlikte alıcı tarafa geçebilir.

Gönderen kurum ödemenin iade edildiğini, reddedildiğini, iptal edildiğini veya hiç gönderilmediğini söylerse, bir sonraki adım gönderen tarafta kalır.

Her hassas ekran görüntüsünün iki versiyonunu hazırlayın

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

İki versiyon hazırlayın.

Destek için güvenli versiyon

Yalnızca sağlayıcının resmi ve kimliği doğrulanmış destek kanalında kullanın.

İnceleyen kişinin gerçekten ihtiyaç duyduğu bilgileri tutun; bunlar şunları içerebilir:

• işlem referansı;

• tutar ve para birimi;

• ilgili hesap bilgileri;

• ödeyen ve alıcı adları;

• ödeme tarihi;

• durum;

• istenen destekleyici belgeler.

İlgisiz bilgileri karartın.

Herkese açık güvenli sürüm

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

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

• tam banka hesap numaraları;

• gerekmediği yerlerde IBAN'lar;

• tam kart numaraları;

• CVV;

• şifreler;

• PIN'ler;

• tek kullanımlık kodlar;

• pasaport veya kimlik görselleri;

• BVN veya NIN;

• tam hesap dökümleri;

• ilgisiz işlemler;

• e-posta adresleri ve telefon numaraları;

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

• API kimlik bilgileri;

• cüzdan özel anahtarları;

• seed veya kurtarma ifadeleri.

Bir seed ifadesi veya özel anahtar asla desteğe gönderilmemelidir.

Karartma, alıcının ihtiyaç duymadığı bilgileri kaldırmalı; ihtiyaç duyduğu kanıtı yok etmemelidir.

Tek bir incelemeyi beş talebe dağıtmayın

Birkaç talep açmak kanıtlarınızı, zaman çizelgenizi ve güncellemelerinizi ayrı yazışmalara bölebilir.

Sağlayıcı yenisini açmanızı istemedikçe kendi kayıtlarınız için tek bir ana vaka tutun.

Kaydedin:

• talep numarası;

• açılış tarihi;

• kanal;

• son yanıt;

• istenen belgeler;

• gönderilen belgeler;

• sağlayıcı belirttiyse vaat edilen sonraki adım.

Bir şey değiştiğinde mevcut vakayı yeni kanıtla güncelleyin.

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

Sorun çözülmeden bir vaka kapatılırsa, yeniden açarken veya üst seviyeye taşırken orijinal vaka numarasına atıfta bulunun.

İlk ödeme zor bulunuyor diye ödemeyi yeniden göndermeyin

Kayıp bir transfer, “tekrar dene” baskısı yaratır.

Bu ikinci bir sorun doğurabilir.

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

Orijinal ödeme açıkça şu durumlardaysa yeniden göndermek daha kolay gerekçelendirilir:

• reddedildi;

• iade edildi;

• iptal edildi;

• mutabakattan önce başarısız oldu;

• sorumlu sağlayıcı tarafından artık alıcıya ulaşamayacağı başka bir şekilde teyit edildi.

İlk ödeme hâlâ işleniyorsa, inceleniyorsa veya yolda bir yerdeyse, ikinci bir ödeme göndermek mükerrer ödeme yaratabilir.

Aynı kural, sorun başladıktan sonra yapılan küçük “test” denemeleri için de geçerlidir. Yol belirsizken büyük bir transferden önce test ödemesi işe yarar; ancak çözülmemiş bir ödeme zaten yoldayken otomatik olarak doğru sorun giderme adımı değildir.

Kopyalanabilir kayıp ödeme destek talebi

İnceleyen kişiye başlamak için yeterli yapıyı veren tek bir mesaj kullanın.

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

Merhaba,

Hesabıma geçmeyen bir ödemeyi bildiriyorum.

Beklenen ödeme

Tutar: [tutar]
Para birimi: [para birimi]
Ödeyen: [ad/şirket]
Alıcı: [ad]
Ödeme yolu: [SWIFT / ACH / platform / yerel transfer / stablecoin / diğer]
Ödemenin başlatıldığı zaman: [tarih, saat, saat dilimi]

Güncel durum

Gönderen taraftaki durum: [durum]
Alıcı taraftaki durum: [durum]

Ödeme numaraları

Sağlayıcı/banka referansı: [referans]
UETR / ACH takip numarası / işlem hash'i (ilgiliyse): [numara]

Zaman çizelgesi

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

Ekteki kanıtlar

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

Atılmış adımlar

[adım] — [sonuç]
[adım] — [sonuç]

Lütfen şunları teyit edin:

1. bu ödemenin güncel durumu;

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

3. şu anda bir sonraki adımın başka bir banka, sağlayıcı veya tarafta olup olmadığı;

4. benden hangi ek kanıtlara ihtiyacınız olduğu.

Daha hassas hesap veya kimlik bilgilerine ihtiyacınız varsa, lütfen hangi güvenli kanalı kullanmam gerektiğini belirtin.

Teşekkürler.

Talebin neyi söylemediğine dikkat edin:

“Acil!!! Param kayıp. Lütfen hemen çözün.”

Aciliyet gerçek olabilir. Ama yine de ödemeyi tanımlamaz.

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

İnceleme birden fazla yazışma sürerse, kanıtları sohbet geçmişinizin dışında saklayın.

Örneğin:

missing-payment-2026-08/

├── 00-case-summary.txt

├── 01-invoice.pdf

├── 02-payer-confirmation.pdf

├── 03-payment-reference.txt

├── 04-timeline.txt

├── 05-trace-document.pdf

├── 06-support-safe-screenshots/

└── 07-support-correspondence/

Belgeler değiştiğinde dosya adlarında tarih kullanın.

Orijinal kanıtın üzerine yoğun şekilde karartılmış bir kopya kaydetmeyin. Orijinali kendinize saklayın, ardından paylaşım için ayrı bir versiyon oluşturun.

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

İncelenmesi en kolay kayıp ödeme, kayıtları zaten var olandır.

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

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

2. ödeyenin doğru alıcı bilgilerine sahip olduğunu teyit edin;

3. para birimi ve ödeme yolu ü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 son alım kaydını saklayın.

Farklı pazarlardaki müşterilerin size nasıl ödeme yapması gerektiğine karar veriyorsanız, ABD, Birleşik Krallık ve AB müşteri ödeme akışı rehberi, bir ödeme başlatılmadan önce mevcut ödeme yollarının nasıl farklılaştığını açıklıyor.

Amaç kendi başına evrak işi yaratmak değil.

Amaç her ödemenin daha sonra yanıtlanabilir olmasını sağlamak.

Vakayı daha gürültülü değil, aranabilir yapın

Tek bir paket tutarı, para birimini, ödeyeni, alıcıyı, ödeme yolunu, tarihleri, durumu, ödeme referansını, destekleyici belgeleri ve atılmış adımları içerdiğinde, kayıp ödeme incelemesini devretmek çok daha kolaylaşır.

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

Ama bir sonraki kişinin belirsiz bir şikâyet mi yoksa gerçekten tanımlayabileceği bir vaka mı alacağını kontrol edebilirsiniz.

walllet.com ile dünyanın her yerinden ödeme alın, USD olarak tutun ve nairaya çekin

İlgili yazılar

Ödeme Güvenliği ve Sorun Giderme: Sorunları Çözün ve Riski Azaltın

Nijerya'da Gelir Kanıtı, Fon Kanıtı ve Fon Kaynağı: Freelancer'ın Kanıt Paketi

Freelance Ödemeniz Bekletildi veya Hesabınız Kısıtlandı mı? Yol Değiştirmeden Önce Paranın Yerini Bulun

ACH Ödemesi İade mi Edildi? R01, R02, R03, R04 ve Diğer ACH İade Kodlarının Anlamı