Yanlış Ağdan Kripto Ödemelerini Önleme: Satıcılar İçin Olay Müdahale Rehberi

Bir işlem blok zincirinde onaylanmış olsa bile işletmenizin talep ettiği ödeme sayılmayabilir. Müşteri doğru tutardaki doğru tokeni yanlış ağdan, beklenen adrese farklı bir tokeni, eksik tutarı veya ilgisiz bir adrese para göndermiş olabilir. Destek ekibiniz, bir aktarımın gerçekleştiğini gösteren kanıt ile siparişin doğru şekilde ödendiğini gösteren kanıtı birbirinden ayırmalıdır.

Bu, cüzdandan para kurtarma eğitimi değil, satıcılara yönelik bir operasyon rehberidir. Önleme, kanıt toplama, blok gezgini üzerinden doğrulama, olay sınıflandırma, yeni ödeme talebi oluşturma, mükerrer ödemeleri önleme ve müşteri iletişimini kapsar. Daha kısa olan yanlış ağdan ödeme yapanlar için SSS müşteriler açısından yararlıdır; bu rehber ise destek yanıtının ardında satıcının ne yapması gerektiğini açıklar.

Onaylanmış işlem, kabul edilmiş ödeme anlamına gelmez

Blok zinciri, bir işlemi kendi ağ kurallarına göre onaylar. Ödeme süreciniz ise yalnızca gözlemlenen aktarım taleple eşleştiğinde ve işletmenizin belirlediği kabul durumuna ulaştığında ödemeyi kabul eder.

Normal bir ödemede aşağıdaki alanların tümünü doğrulayın:

Circle'ın blok zinciri onayları başvuru kaynağı, işlemlerin beklemede durumuyla başladığını, onay sürecinin blok zincirine göre değiştiğini ve yakın tarihli blokların yeniden düzenlemelerden etkilenebildiğini açıklar. Bu nedenle işlem kimliği, cüzdan ekran görüntüsü veya “başarılı” sayfası araştırılması gereken bir kanıttır; tek başına siparişi tamamlama yetkisi vermez.

Başlıca olay türlerini birbirinden ayırın

Müşteriler çoğu zaman her uyumsuzluğu “yanlış ağ” diye tanımlar. Çözüm seçmeden önce olguları sınıflandırın.

Tanıdık bir kısaltmanın varlığın doğru olduğunu kanıtladığını varsaymayın. Circle, USDC'yi birden fazla blok zincirinde ihraç edilen dijital dolar olarak tanımlarken Tether, Tether tokenlerini destekleyen protokollerin güncel listesini yayımlar. Bu ihraççı listeleri Yolfi'nin, cüzdanınızın veya işletmenizin neleri desteklediğini belirlemez. Yalnızca canlı Yolfi yapılandırmanızda gösterilen varlık ve ağ birleşimlerini sunun.

Müşteri imzalamadan önce olayı önleyin

Yanlış ağ olaylarına karşı en iyi süreç destek aşamasında değil, ödeme akışında başlar.

Varlığı ve ağı tek bir ödeme yöntemi olarak ele alın

Bir seçeneği yalnızca “USDC” veya “USDT” diye adlandırmayın. Seçim, inceleme ekranı, QR talimatları, cüzdana yönlendirme, makbuz, destek kayıtları ve mutabakat dışa aktarımlarının tamamında “USDC - [seçilen ağ]” gibi birleşik bir etiket kullanın.

USDC ile ödeme alma rehberi ile USDT ile ödeme alma rehberi, ağ seçiminin neden ödeme yönteminin bir parçası olduğunu açıklar. Herkese açık talimatlarınızda, ihraççının tokeni sunduğu tüm ağları değil, yalnızca ödeme akışında o anda kullanılabilen birleşimleri listeleyin.

Kritik bilgileri karar anında yineleyin

Cüzdanda imza atılmadan önce şunları gösterin:

• varlığın tam adı ve simgesi;
• ağın tam adı;
• kesin tutar;
• kopyalama düğmeleriyle birlikte hedef adres;
• sipariş veya ödeme referansı;
• varsa son kullanma zamanı veya süre kuralı;
• adres benzer görünse bile başka bir ağ seçilmemesi gerektiğine dair uyarı;
• gönderimden sonra ödeme durumu sayfasına dönülmesini isteyen bir ileti.

Kullanıcılara ağ değiştirmenin tokenleri taşıdığını söylemeyin. Cüzdanda seçili ağı değiştirmek, cüzdanın hangi zinciri görüntüleyip onunla etkileşime girdiğini değiştirir; mevcut bakiyeyi zincirler arasında aktarmaz. Ayrı bir köprü işlemi veya borsadan çekim, kendine özgü riskleri ve destek sınırları olan farklı bir işlemdir.

Gereksiz seçenekleri azaltın

Yalnızca müşterilerinizin kullandığı ve ekibinizin destekleyebileceği seçenekleri etkinleştirin. Eklenen her birleşim; yeni bir mutabakat adresi, token tanımlayıcısı, blok gezgini, onay kuralı ve istisna yolu demektir. Canlı yapılandırmanızdaki seçenekleri gözden geçirin ve Yolfi'nin ağlara özel sayfaları için blok zinciri dizinini kullanın.

Etkinleştirilen her birleşim için düşük tutarlı gerçek bir deneme yapın. Ödeme sayfasındaki etiketi, hedef adresi, cüzdan iletisini, blok gezgini kaydını, durum değişimini, bildirimi veya webhook'u, mutabakat kaydını ve siparişin tamamlanma biçimini doğrulayın.

Olay kanıt dosyası oluşturun

Gerekli bilgilerin tamamını tek seferde isteyin. Tekrarlanan talepler gecikmeyi artırır ve müşteriyi onaylanmamış çözümler denemeye iter.

Müşteriden istenecek kanıtlar

• ödeme linkinin URL'si veya ödeme referans kimliği;
• sipariş, fatura veya hesap referansı;
• işlem kimliği ve varsa blok gezgini bağlantısı;
• müşterinin gönderdiğini düşündüğü varlık ve tutar;
• gerçekte seçtiği ağ;
• gönderen cüzdan adresi;
• aktarımın yaklaşık zamanı.

Satıcı tarafındaki kanıtlar

• ilk talepte gösterilen varlık, ağ, tutar ve hedef;
• talebin oluşturulma, sona erme, algılanma ve durum zaman damgaları;
• istenen birleşim için yapılandırılmış mutabakat adresi;
• ilgili ödeme bildirimleri, webhook kimlikleri ve işleme sonuçları;
• kullanılan ağdan alınan ve bağımsız olarak denetlenen blok gezgini sonucu;
• müşteri iletileri ve ekibinizin verdiği talimatlar;
• aynı siparişle ilişkilendirilmiş önceki ve yeni ödeme referansları;
• daha önce gerçekleştirilen sipariş tamamlama, hesaba alacak kaydetme, iade veya erişim işlemleri.

Ekran görüntüsü değiştirilmiş, güncelliğini yitirmiş veya yanlış ağdan alınmış olabilir. İşlemi bulmak için görüntüden yararlanın, ardından işlemi bağımsız olarak doğrulayın.

Aktarımı doğru blok gezgininde doğrulayın

Müşterinin kullandığını söylediği ağdan başlayın ancak bunu blok gezginindeki verilerle doğrulayın. MetaMask'in yanlış hedefe gönderim rehberi de ne olduğunu belirlemeden önce işlem durumunun ve blok gezgininin kontrol edilmesini önerir.

1. Gerçekte kullanılan ağ için güvenilir bir blok gezgini açın.
2. İşlem özetinin tamamını arayın. Bağlantının görünen metnine güvenmeyin; blok gezgini alan adını kurum içi prosedürünüze göre doğrulayın.
3. İşlemin beklemede, başarılı, başarısız, bırakılmış veya başka bir işlemle değiştirilmiş olup olmadığını kontrol edin.
4. Gönderen ve hedef adresleri karakter karakter doğrulayın.
5. Aktarılan varlığı doğrulayın. Token aktarımında yalnızca simgeyi değil, sözleşmeyi veya mint adresini kontrol edin.
6. Aktarım olayındaki ham token tutarını doğrulayın. Ondalık hassasiyeti ayrıca resmî sözleşme veya mint adresinden ya da güvenilir blok gezgini meta verilerinden kontrol edin.
7. Bloku, zaman damgasını, mevcut onay sayısını veya kesinleşme durumunu ve ilgili günlükleri kaydedin.
8. Her alanı ilk ödeme talebiyle karşılaştırın.
9. Aynı ağdaki mutabakat cüzdanınızı veya cüzdan izleme kaydınızı kontrol edin.
10. İşlem kimliğinin daha önce kabul edilmediğinden ya da başka bir yerde kullanılmadığından emin olmak için kurum içi kayıtları arayın.

Circle'ın EVM ağlarında USDC aktarımına yönelik hızlı başlangıç rehberi, zincir seçme, aktarımı gönderme, işlem kimliği alma ve blok gezgininde kontrol etme adımlarının birbirinden ayrı olduğunu gösterir. Ayrıca gönderenin işlem ücreti için o ağın yerel tokenine ihtiyaç duyduğunu belirtir. Bunu aktarım işleyişine bir örnek olarak değerlendirin; Yolfi hesabınızda kullanılabilen birleşimlerin listesi olarak görmeyin.

Para kurtarma sözü vermek yerine karar ağacı kullanın

Dalları sırasıyla izleyin.

1. Belirtilen ağda geçerli bir işlem var mı?

• Hayır veya hâlâ beklemede: siparişi tamamlamayın. Siz işlemi izlerken ya da cüzdan sağlayıcısı bekleyen işlemi ele alırken müşteriden yeniden ödeme yapmamasını isteyin.
• Başarısız veya geri alınmış: bu işlemle başarılı bir ödeme gerçekleşmemiştir. Yeni bir ödeme talebi oluşturmadan önce müşterinin cüzdanındaki ve blok gezginindeki durumu doğrulayın.
• Başarılı: alanları eşleştirme adımına geçin.

2. Ağ, varlık, hedef, tutar ve onay politikasıyla eşleşiyor mu?

• Evet: normal kabul sürecinden geçirin ve siparişin yalnızca bir kez tamamlanmasını sağlayan denetimi uygulayın.
• Hayır: istisna incelemesine alın. Bir değer bir yere aktarıldı diye elle ödendi olarak işaretlemeyin.

3. Satıcı, kullanılan ağdaki hedefi kontrol ediyor mu?

• Belirlenemedi: paranın alındığını veya kurtarılabileceğini iddia etmeyin. Konuyu, bu adresten sorumlu cüzdan sahibine ya da saklama hizmeti sağlayıcısına iletin.
• Evet: ilgili varlığın tam olarak bu adreste bulunduğunu ve cüzdan, güvenlik, muhasebe ve mevzuata uyum prosedürleriniz kapsamında güvenle yönetilebildiğini doğrulayın. Adresin kontrolünüzde olması, ilk siparişin otomatik olarak doğru ödendiği anlamına gelmez.
• Hayır: işletmenizin kontrol etmediği bir adresteki parayı taşıyamayacağını açıklayın. Ethereum.org'un destek SSS'si, Ethereum işlemlerinin merkezi bir işletmeci tarafından geri alınamayacağını belirtir; hedefi bilinen bir hizmet kontrol ediyorsa doğru başvuru noktası o hizmetin destek ekibi olabilir.

4. Bir düzeltme yöntemi onaylandı mı?

Olası sonuçlar arasında aktarımı elle kabul etmek, doğru bir yeni ödeme istemek, erişilebilen parayı yeni bir işlemle geri göndermek, belgeli bir alacak kaydetmek veya kurtarma talebini reddetmek bulunur. Doğru sonuç; ağa, adres kontrolüne, tokene, saklama düzenine, teknik olanaklara, maliyetlere, risk kontrollerine ve işletme politikasına bağlıdır.

Paranın “her zaman kayıp” veya “her zaman kurtarılabilir” olduğunu asla söylemeyin. MetaMask, aynı cüzdan adresine başka bir EVM uyumlu ağdan erişilebildiği yaygın bir durumu belgelese de kurtarmanın garanti edilemediği durumları da açıklar. Bu rehber, bir satıcının, borsanın, akıllı sözleşmenin, çoklu imzalı cüzdanın veya ödeme sisteminin belirli bir aktarıma erişebileceğini ya da onu iade edebileceğini kanıtlamaz.

Yeni ödeme linklerini güvenli biçimde oluşturun

İlk talep kabul edilemiyorsa ve politikanız yeni bir denemeye izin veriyorsa yeni bir Yolfi ödeme linki oluşturun. Geçmişi değiştirmeyin veya müşteriye yalnızca “tekrar deneyin” demeyin.

Yeni talep:

1. aynı sipariş veya fatura kimliğini korumalı;
2. yeni ve benzersiz bir ödeme referans kimliği almalı;
3. canlı akışta gösterilen varlığı, ağı, tutarı ve hedefi tam olarak belirtmeli;
4. önceki talebin yerini aldığını ya da önceki talebin incelemede olduğunu kaydetmeli;
5. ilk işlemin ayrı bir olay olarak kalacağını açıklamalı;
6. müşteriye iki linki birden ödememesini söylemeli;
7. varsa son kullanma kuralını korumalı;
8. sipariş tamamlanmadan önce her iki talebi de mükerrer ödeme denetimine yönlendirmelidir.

Müşteriden kaydı tutulmayan bir farkı göndermesini, sohbetten kopyalanan bir adrese yeniden ödeme yapmasını veya gönderimden sonra ağ değiştirerek ilk paranın taşınacağını düşünmesini istemeyin.

Mükerrer ödeme ve sipariş tamamlamayı önleyin

Gecikmiş bir işlem, yeni talep oluşturulduktan sonra onaylanabilir. Müşteri de destek yanıtını beklerken iki kez gönderim yapabilir. Sürecinizi her iki duruma karşı hazırlayın.

İşletme düzeyinde tek bir sipariş kimliğini, birden fazla değiştirilemez ödeme denemesiyle birlikte kullanın. Şu denetimleri uygulayın:

• bir işlem kimliği en fazla bir kez kabul edilebilmeli;
• tek bir ödeme denemesi birden fazla siparişi tamamlayamamalı;
• tek bir sipariş, teslimatı veya erişimi yalnızca bir kez başlatabilmeli;
• ilk talep ile yeni talep bağlantılı kalmalı;
• sipariş tamamlanmadan hemen önce tüm açık denemeler kontrol edilmeli;
• geç onaylar ve fazla alınan ödemeler incelemeye girmeli;
• webhook ve bildirim işlemleri tekrarlandığında ek sonuç doğurmamalı;
• iadeler için ayrı onay, hedef doğrulaması ve işlem kayıtları gerekmelidir.

İki aktarım da başarılı olursa bunlardan birini silmeyin, sessizce başka bir satın alma işlemine uygulamayın veya yeni bir destek iletisinde verilen adrese otomatik olarak para göndermeyin. Mükerrer sipariş tamamlamayı engelleyin ve belgelenmiş alacak ya da iade politikasını uygulayın.

Satıcı desteği ve güvenlik kuralları belirleyin

İlk kademe destek ekibine kullanacağı metni ve konuyu üst ekibe aktarma sınırlarını verin.

Destek ekibi, herkese açık işlem verilerini, ödeme referanslarını, sipariş ayrıntılarını ve gizli bilgileri açığa çıkarmayan ekran görüntülerini isteyebilir. Destek ekibi; kurtarma sözcüklerini, kurtarma ifadesini, özel anahtarı, cüzdan şifresini, tek kullanımlık kodu veya müşterinin cihazını uzaktan kontrol etmeyi asla istememelidir. Kurtarma ifadesine veya özel anahtara sahip olan kişi cüzdanı kontrol edebilir.

Şuna benzer bir metin kullanın:

[ağ] üzerinde bir işlem gönderildiğini görebiliyoruz. İşlemdeki varlığın, hedefin, tutarın ve onay durumunun [referans] numaralı ödeme talebiyle eşleşip eşleşmediğini kontrol ediyoruz. Yeni ve onaylanmış bir link gönderene veya sonraki adımı doğrulayana kadar lütfen başka bir ödeme yapmayın. Sizden kurtarma ifadenizi ya da özel anahtarınızı istemeyeceğiz.

İlk yanıt, kanıt incelemesi, üst ekibe aktarma, onay ve müşteriyi bilgilendirme için süre sınırları belirleyin. Erişim ve işlem yapılabilirliği kesinleşmeden paranın kurtarılacağı bir tarih vadetmeyin.

Yolfi, saklama hizmeti sunmayan bir hizmettir: ödemeler Yolfi'de tutulmak yerine satıcının yapılandırılmış cüzdanına gönderilir. Bu nedenle doğru cüzdan yapılandırması, erişim sahipliği ve satıcı tarafındaki olay politikası büyük önem taşır.

Satıcılar için olay kontrol listesi

Ödeme almaya başlamadan önce

• Her adımda varlığı ve ağı birlikte gösterin.
• Yalnızca canlı Yolfi yapılandırmasında bulunan birleşimleri etkinleştirin.
• Her mutabakat adresini ve token tanımlayıcısını doğrulayın.
• Etkinleştirilen her yolu baştan sona deneyin.
• Onay, uyumsuzluk, mükerrer ödeme, iade ve üst ekibe aktarma kurallarını belirleyin.
• Destek ekibine cüzdan sırlarını asla istememesi gerektiğini öğretin.

Bir olay bildirildiğinde

• Siparişi tamamlamayı duraklatın ve mükerrer ödemeyi önleyin.
• İlk talebi ve müşteri bildirimini koruyun.
• Kanıt dosyasını oluşturun.
• İşlemi gerçekten kullanılan ağda doğrulayın.
• Ağı, varlığı, hedefi, tutarı, durumu ve onayları karşılaştırın.
• Paranın kurtarılabileceğini varsaymadan adres kontrolünü inceleyin.
• İşlemin daha önce kabul edilip edilmediğini ve bağlantılı denemeleri araştırın.
• Onaylanan kararı ve müşteri iletisini kaydedin.

SSS

Bir işlem onaylandığı hâlde ödeme yapılmamış sayılabilir mi?

Evet. Onay, bir ağın işlemi gerçekleştirdiğini kanıtlar. Ödemenin kabul edilmesi için ayrıca istenen ağ, varlık, hedef, tutar ve referansla eşleşmesi ve satıcının onay politikasını karşılaması gerekir.

Cüzdanda ağ değiştirmek parayı kurtarır veya taşır mı?

Hayır. Seçili ağı değiştirmek, cüzdanın hangi blok zincirini görüntüleyip onunla etkileşime girdiğini değiştirir. Tokenleri ağlar arasında taşımaz. Bazı EVM durumlarında aynı adresin sahibi kullanılan ağdaki varlıkları görebilir ancak sonraki bir aktarım veya köprü işlemi ayrı bir eylemdir; bu eylemin kullanılabilir veya uygun olacağı garanti edilmez.

Müşteriden hemen yeniden ödeme yapmasını istemeli miyiz?

Hayır. Önce ilk işlemin beklemede, başarısız, başarılı veya uyumsuz olup olmadığını belirleyin. Yeni bir deneme onaylanırsa önceki talebe bağlı yeni bir ödeme talebi oluşturun ve iki deneme için de mükerrer ödeme denetimini etkinleştirin.

Yolfi yanlış ağdan yapılan bir ödemeyi kurtarabilir mi?

Bunu varsaymayın. Saklama hizmeti sunulmayan bir akışta para, yapılandırılmış satıcı cüzdanına gider. Uygulanabilecek çözüm; gerçek hedefe, ağa, varlığa, cüzdan kontrolüne, teknik olanaklara ve satıcı politikasına bağlıdır.

Müşteri doğru ağı kullanıp yanlış tokeni gönderdiyse ne olur?

Bunu yanlış para birimi olayı olarak ele alın. Token sözleşmesini veya mint adresini, tutarı, hedefi ve cüzdana ulaşan ödemeyi doğrulayın; siparişi ödendi olarak işaretlemek yerine belgelenmiş istisna sürecini uygulayın.

İşlem hâlâ beklemedeyse ne olur?

Siparişi beklemede tutun ve tamamlamayın. Onay politikanıza göre blok gezginini ve ödeme durumunu izleyin. Bekleyen işlem sonuçlanana veya denetimli bir yeni ödeme talebi onaylanana kadar ikinci bir aktarım yapılmamasını isteyin.

Siparişi tamamlamak için ekran görüntüsü yeterli mi?

Hayır. İşlem özetiyle işlemi bulun ve doğru blok gezgininde bağımsız olarak doğrulayın. Ardından işlemi ödeme talebiyle eşleştirin ve daha önce kullanılmadığını kontrol edin.

Sonuç

Yanlış ağdan ödemeleri önlemek için varlığın, ağın, hedefin, tutarın ve onay durumunun açıkça belirtilmesi gerekir. Olayların ele alınması ise doğrulanmış işlem verileri, dikkatli cüzdan kontrolü incelemeleri, parayı kurtarma sözü vermekten kaçınma ve mükerrer ödeme önleme gerektirir.

Canlı Yolfi yapılandırmanızda gösterilen birleşimlerle başlayın, bunları deneyin ve destek ekibine tek bir karar ağacı verin. Yeni bir deneme gerektiğinde sohbet üzerinden doğaçlama yapmak yerine ilk talebe bağlı yeni bir ödeme talebi oluşturun. Amaç doğru ödemeyi kabul etmek, siparişi bir kez tamamlamak ve istisnalarla ilgili her kararı kayda almaktır.