USDT ödeme webhooku neden sadece retry ile başarılı olabilir

Ödeme completed olduğu halde merchant uygulaması ikinci denemede güncelleniyorsa sorun genellikle endpoint erişilebilirliği, imza doğrulama, timeout veya idempotent olmayan teslimattadır.

USDT kabul etmeye başlayın API dokümanlarını oku

Şunlar için: Webhook retry
Şunlar için: Callback debug
Şunlar için: İdempotent teslimat

Webhook retry teşhisi

Webhook retry diagnosis

1. Confirm the order status is already completed
2. Open the webhook delivery log for the order
3. Check first attempt HTTP status, timeout, and response body
4. Verify raw body signature before parsing JSON
5. Make fulfillment idempotent by order ID and tx hash
6. Fix the endpoint, then resend or wait for the next retry

Webhook retry teşhis akışı

İlk callbacki başarısız olan completed USDT siparişlerini debug eden geliştiriciler için uygundur.

01
Siparişin BoltUtil içinde completed olduğunu doğrulayın.
02
Başarısız ilk deneme ile başarılı retryı karşılaştırın: status, latency, timeout ve response body.
03
JSON parse etmeden önce raw body ile HMAC doğrulayın.
04
External order ID ve tx hash ile idempotent teslimat yapıp sonra webhooku yeniden gönderin.

Emanetsiz tahsilat

Fonlar doğrudan merchant cüzdanına gider. BoltUtil zinciri izler ve bildirim gönderir, fon tutmaz.

Üç USDT ağı

TRC20, ERC20 ve BEP20 USDT ödemelerini tek sipariş API ve birleşik webhook payload ile kabul edin.

Webhook otomasyonu

Ödeme tespit edilip onaylandığında backend imzalı callback alır ve sipariş otomatik işlenir.

Entegrasyon notları

Canlıdan önce önemli noktalar

The first attempt often exposes a cold path

Cold serverless functions, sleeping containers, DNS delays, or lazy database connections can make the first webhook exceed the timeout while the retry succeeds.

Signature validation must use the raw body

If middleware parses, formats, or reorders JSON before HMAC verification, the first callback may be rejected even though the payload is valid.

A retry is expected behavior, not a duplicate payment

Merchants should store processed order IDs and transaction hashes, then return a successful response for already-processed callbacks.

Canlıya çıkmadan önce sorulan sorular

Bu yanıtlar geliştiricilerin, kurucuların ve destek ekiplerinin gerçek USDT ödemelerini almadan önce ödeme döngüsünü anlamasına yardımcı olur.

Retry, USDT ödemenin geç algılandığı anlamına mı gelir? +

Şart değil. Sipariş completed ise scanner çalışmıştır; retry merchant callback teslimatıyla ilgilidir.

Webhook endpointim ne döndürmeli? +

İmzayı doğrulayıp olayı kalıcı kaydettikten sonra 2xx döndürün. Redirect ve uzun bloklayıcı işlerden kaçının.

Retry sırasında çift teslimatı nasıl önlerim? +

İşlenen external order ID ve tx hash değerlerini saklayın; tekrar gelen geçerli callback başarı dönmeli ama ikinci kez teslim etmemeli.

İlgili kaynaklar

/docs/webhook-signature

Daha net bir USDT ödeme akışı başlatın

Müşterilerden ödeme ekran görüntüsü istemeden sipariş oluşturun, transferleri izleyin ve backendinizi bilgilendirin.

Ücretsiz hesap oluştur