Eksik veya fazla ödenmiş kripto faturalar nasıl yönetilir?

Eksik ödenen fatura otomatik teslim edilmemeli, fazla ödenen fatura da otomatik iadeye yol açmamalıdır. Önce işlemin ağını, gerçek token sözleşmesini, alıcısını, durumunu ve tutarını doğrulayın. Ardından farkı kaydeden yazılı bir satıcı politikası uygulayın.

GramPayBot’ta beklenen tutar tamdır. Daha düşük transfer partial, daha yüksek transfer overpaid olarak sınıflandırılır; ikisi de sessizce normal paid durumuna dönüşmez.

Hızlı karar tablosu

Doğrulanan sonuç	Fatura kararı	Sonraki adım
Tutar tam eşit	Onaydan sonra normal eşleşebilir	Paid sonrası teslim
Gelen tutar düşük	Eksik/kısmi ödeme	Açığı kaydedip alıcıya talimat verin
Gelen tutar yüksek	Fazla ödeme	Kabul, kredi veya iade kararı verin
Birden çok transfer var	Manuel mutabakat gerekir	Her hash’i doğrulayın
Ağ, token veya alıcı yanlış	Bu faturanın ödemesi değil	Yanlış rota sürecini izleyin

Yanlış ağ kullanıldıysa yanlış ağ inceleme ve kurtarma rehberini izleyin. Tutar farkı süresi dolmuş veya yenilenmiş bir faturayla ilgiliyse yeni ödeme istemeden önce ödenmemiş, geç ve süresi dolmuş fatura akışını uygulayın.

BTCPay Server kısmi ve fazla ödemeyi normal settled faturadan ayırır. Stripe’ın kısmi ödeme belgeleri de kalan tutarı ve fazla bakiyeyi ayrı izler. Bu örnekler sizin politikanızı belirlemez; tutar istisnalarının neden ayrı durum gerektirdiğini gösterir.

Eksik ödemenin yaygın nedenleri

• tam sayı kopyalanmak yerine yuvarlama yapılması;
• borsa veya cüzdan ücretinin yanlış anlaşılması;
• test ödemesinin otomatik toplanacağının sanılması;
• eski talimat veya süresi dolmuş faturanın kullanılması;
• token ondalıklarının yanlış işlenmesi;
• aynı siparişi birden fazla kişinin ödemesi;
• anlaşmazlık nedeniyle tutarın kasıtlı eksik gönderilmesi.

Çekim ücretleri sağlayıcıya göre değişir. Binance, kripto çekim ücretlerinin dinamik olduğunu ve çekim sayfasında gösterildiğini belirtir. “Ağ ücreti her zaman alıcı tutarından düşer” gibi evrensel bir kural yoktur. Alıcı son önizlemede satıcının tam tutarı alacağını kontrol etmelidir.

Fazla ödemenin yaygın nedenleri

Fiat fiyatının token tutarı sanılması, ağ ücretinin alıcı tutarına eklenmesi, faturanın iki kez ödenmesi, testten sonra tam tutarın yeniden gönderilmesi ve ondalık hataları sık görülür.

Arayüz ondalık sayı gösterse de zincir, tutarı tamsayı taban birimlerinde taşır. Circle’ın resmi USDC örneği altı ondalık basamaklı tutar kullanımını gösterir. Entegrasyon floating-point yaklaşık değerlerle değil, belirli atomic unit dönüşümleriyle karşılaştırma yapmalıdır.

Çözmeden önce transferi doğrulayın

1. Hash’i fatura ağının explorer’ında açın.
2. İşlemin başarılı ve yeterince onaylı olduğunu doğrulayın.
3. Sembol yerine sözleşme veya mint’i kontrol edin.
4. Tam alıcı adresini faturayla karşılaştırın.
5. Token transfer olayı veya balance change içindeki miktarı okuyun.
6. Checkout’taki tüm basamaklarla karşılaştırın.
7. Başka transferin bu fatura ya da siparişe atanıp atanmadığını kontrol edin.
8. Blok zamanını fatura süresiyle karşılaştırın.

Sözleşme yanlışsa sorun yalnızca eksik veya fazla tutar değildir; varlık yanlıştır. USDT ve USDC sözleşme doğrulama rehberini kullanın.

Doğrulamadan sonra kabul edilen her hash’i tam olarak bir fatura ve siparişle ilişkilendirin. Kripto ödemelerini müşteri siparişleriyle eşleştirme rehberi bu ilişkiyi ekran görüntüsü veya chat username kullanmadan korumayı açıklar.

GramPayBot’un tam tutar davranışı

GramPayBot beklenen ağ, token, alıcı ve tutarı ödeme öncesinde belirler. Mevcut checkout tutarında virgülden sonra en fazla dört basamak bulunur ve ayırt edici bir son ek kullanılabilir. 180.0134 USDT gösteriliyorsa yuvarlanmış 180 USDT değil, tüm sayı gönderilmelidir. USDT veya USDC zincirde altı taban-birim ondalığı kullanabilir; bu, GramPayBot’un altı basamaklı fatura son eki gösterdiği anlamına gelmez.

Tam onaylı transfer faturayı ödeyebilir; düşük transfer partial, yüksek transfer overpaid olur; birden çok uygun veya önceden kullanılmış transfer temiz eşleşme sayılmaz. Normal matcher, rastgele ikinci işlemi ilkine ekleyip “top-up” yapmaz. Alıcıya özel bir çözüm sunmadan yeniden göndermesini söylemeyin.

Eksik ödeme iş akışı

1. Doğrulanmış açığı hesaplayın

Önce farkı token biriminde hesaplayın:

açık = tam fatura tutarı − doğrulanan gelen tutar

2. Teslimatı beklemede tutun

Tutarın büyük bölümü gelmiş olsa bile siparişi paid saymayın. Böylece bir müşteride kabul edilen aynı açığın diğerinde reddedilmesi gibi tutarsız kararlar önlenir.

3. Yazılı tek bir çözüm seçin

Şu seçeneklerden birini belirleyin:

• farkı indirim veya zarar olarak manuel kabul etmek;
• kalan bakiye için yeni, ayrı fatura oluşturmak;
• teslimi iptal edip doğrulanan tutarı iade etmek;
• destek veya uyum incelemesine aktarmak.

Bakiye isteniyorsa yeni faturayı ilk ödeme kaydıyla bağlayın. Eski faturanın iki işlemi otomatik toplayacağını söylemeyin.

4. Sonucu alıcıya bildirin

Alıcıya gelen tutarı, açığı, kararı ve yeni fatura ya da iade referansını açıkça bildirin.

Fazla ödeme iş akışı

1. Çift veya ilgisiz transferi dışlayın

Önce tek büyük transfer mi yoksa çift ödeme mi olduğunu ve hash’lerden birinin başka siparişe ait olup olmadığını kontrol edin.

2. Fatura tutarı ile fazlayı ayırın

Ardından hesaplayın:

fazla = doğrulanan gelen tutar − tam fatura tutarı

İlk fatura tutarını sonradan değiştirerek sayıları eşitlemeyin.

3. Tek bir politika uygulayın

Politikanıza göre fazlayı iade edin, müşteri kredisine alın, bilinçli bahşiş/ek satın alma olarak kabul edin veya tüm ödemeyi iade edip faturayı yeniden çıkarın.

Stripe’ın kısmi ödeme belgeleri, kalan bakiye ve fazla ödemenin neden açık kurallarla ele alınması gerektiğine geleneksel ödeme sisteminden bir örnektir.

4. İade adresini bağımsız olarak doğrulayın

Fazlayı zincirdeki göndericiye otomatik iade etmeyin. Merkezi borsa ortak bir çekim cüzdanı kullanmış olabilir. Müşteriyi asıl sipariş kanalından doğrulayın, aynı ağda iade adresini ayrıca teyit edin, ücretleri açıklayın ve yeni işlem hash’ini kaydedin.

Önceden yazılması gereken politika

• eksik ödeme toleransı ve hesabı;
• bakiye faturası kullanımı;
• ağ ücreti sonrası ekonomik iade alt sınırı;
• müşteri kredisi desteği;
• manuel kabul ve iade yetkilisi;
• çift işlemlerin ele alınması;
• istisna kayıtlarının saklama süresi.

Tolerans varsa tutarlı uygulayın; entegrasyon desteklemiyorsa otomatik tam eşleşmenin içine gizlemeyin.

Alıcıya verilecek önleyici talimat

Güncel faturayı açın, doğru token ve ağı seçin, tüm ondalık basamakları kopyalayın, borsa ücretinin alıcı tutarını düşürüp düşürmediğini kontrol edin, bir kez gönderin ve hash’i saklayın. Test transferi gönderdiyseniz veya süre dolduysa yeniden ödeme yapmadan satıcıya yazın.

Tam akış için USDT veya USDC ile fatura ödeme rehberine bakın.

İstisna kayıt şablonu

Her eksik veya fazla ödeme için şunları birlikte saklayın:

• fatura ve sipariş ID’leri;
• beklenen ağ, token, alıcı ve tam tutar;
• ilgili tüm işlem hash’leri;
• hash başına doğrulanan tutar ve onay durumu;
• token biriminde açık veya fazla;
• fatura süresi ve işlem blok zamanları;
• müşteri doğrulama yöntemi;
• çözüm, onaylayan kişi ve zaman damgaları;
• bakiye faturası, kredi veya iade referansı.

Bu kayıt, aynı işlemin iki kez sayılmasını önler ve başka bir çalışanın kararı yeniden doğrulamasını sağlar.

Sık sorulan sorular

İkinci ödeme eksik faturayı otomatik tamamlar mı?

Bunu varsaymayın. Normal matcher tek tam transfer bekler ve rastgele kısmi transferleri toplamaz. Yeni bakiye faturası veya açık satıcı talimatı bekleyin.

Checkout tutarı yuvarlanabilir mi?

Hayır. Ayırt edici ondalık basamaklar dahil tam tutarı gönderin.

Fazla ödenen fatura otomatik paid olur mu?

Hayır. Manuel inceleme gerektiren bir istisnadır.

Gönderen adrese otomatik iade yapılır mı?

Hayır. Özellikle ödeme borsadan geldiyse önce müşteriyi ve iade adresini doğrulayın.

Gerçek bir USDT transferi siparişin ödendiğini kanıtlar mı?

Tek başına kanıtlamaz. Ağ, token sözleşmesi, alıcı, tutar, ödeme penceresi ve işlem kimliği faturayla eşleşmeli; transfer de onaylanmış olmalıdır.