E-Ticaret Sitesinde Siparişler Neden Panele Düşmez?

E-ticaret siparişleri neden panele düşmez?

Siparişlerin panele düşmemesi tek bir hata türü değildir. Müşterinin ödeme ekranında “başarılı” görmesi, siparişin mağaza veritabanına kaydedildiği anlamına gelmeyebilir. Pazaryeri panelinde görünen siparişin entegrasyon paneline aktarılması için de doğru mağaza hesabı, yetkili API bilgileri, uygun tarih ve durum filtreleri, çalışan görev kuyruğu ve başarılı veritabanı kaydı gerekir.

İlk soru şudur: Sipariş kaynak sistemde gerçekten oluşmuş mu? Kaynak mağaza veya pazaryeri panelinde sipariş yoksa yerel entegrasyon panelini incelemek doğru başlangıç değildir. Kaynakta sipariş varsa, sipariş numarası ve paket kimliği üzerinden API isteği, kuyruk kaydı ve veritabanı işlemi izlenmelidir.

Siparişin hangi sistemde oluştuğunu doğrulayın

E-ticaret akışında en az üç ayrı kayıt olabilir: ödeme sağlayıcısındaki işlem, mağazadaki sipariş ve entegrasyon panelindeki sipariş. Bunların numaraları her zaman aynı değildir. Ödeme sağlayıcısı işlem kimliği, mağaza sipariş numarası ve pazaryeri paket kimliği ayrı alanlarda saklanmalıdır.

• Müşterinin ekran görüntüsündeki sipariş numarası nedir?
• Ödeme sağlayıcısında işlem başarılı mı, beklemede mi, iptal mi?
• Kaynak mağaza veya pazaryeri panelinde sipariş görünüyor mu?
• Kaynak sistem siparişi paketlere böldü mü?
• Yerel entegrasyon panelinde aynı dış sipariş kimliği aranmış mı?

Trendyol siparişleri paket bazında sunar. Resmî Sipariş Paketlerini Çekme servisinde ana sipariş numarası ile paket kimliği farklı alanlardır. Yüksek hacimli taramalarda Trendyol’un cursor tabanlı getShipmentPackagesStream servisi daha güvenilir bir çekim akışı sağlar.

Ödeme başarılı sonucu ile sipariş kaydını ayırın

Karttan tahsilat yapılması ve siparişin kaydedilmesi iki ayrı işlemdir. Ödeme sağlayıcısından başarı cevabı geldikten sonra uygulama sipariş kaydını oluştururken hata alabilir. Ağ kesintisi, veritabanı kilidi, zorunlu müşteri alanı, stok kontrolü veya sepet satırındaki bozuk veri sipariş oluşturmayı durdurabilir.

Bu nedenle ödeme callback kaydında yalnızca “başarılı” bilgisi değil; işlem kimliği, tutar, para birimi, sepet kimliği, müşteri kimliği, callback zamanı ve sipariş oluşturma sonucu birlikte tutulmalıdır. Tahsilat başarılı fakat sipariş kaydı yoksa otomatik mutabakat görevi eksik siparişi tespit etmelidir.

Webhook ve periyodik API çekimini birlikte kontrol edin

Bazı sistemler yeni siparişi webhook ile bildirir; bazıları periyodik API sorgusuyla çekilir. Sadece webhook kullanılıyorsa geçici ağ hatasında bildirim kaçabilir. Sadece periyodik çekim kullanılıyorsa yanlış tarih aralığı veya görev durması siparişleri görünmez hâle getirebilir.

Webhook kontrolü

• Endpoint dışarıdan erişilebilir mi?
• HTTPS sertifikası geçerli mi?
• İstek doğru HTTP koduyla cevaplanıyor mu?
• İmza veya yetkilendirme doğrulaması başarısız mı?
• Webhook olayı ham gövdesiyle kaydediliyor mu?
• Başarısız bildirimler yeniden deneniyor mu?

Periyodik çekim kontrolü

• Cron veya scheduler son ne zaman çalıştı?
• Görev kilidi açık kaldığı için yeni çalışma engelleniyor mu?
• API rate limit veya 429 cevabı alınıyor mu?
• Son başarılı zaman damgası yanlış ilerletilmiş mi?
• Sayfalama tamamlanmadan görev sona ermiş mi?

Tarih, durum ve sayfalama filtreleri siparişi dışarıda bırakabilir

“API sipariş döndürmüyor” denilen birçok durumda servis çalışır; ancak filtre yanlış olduğu için aranan kayıt gelmez. Başlangıç ve bitiş zamanı milisaniye beklenirken saniye gönderilmesi, sunucunun UTC kullanması, yalnızca belirli sipariş durumlarının sorgulanması veya ilk sayfanın tekrar tekrar çekilmesi yaygın hatalardır.

Mağaza, satıcı ve tenant eşlemesini doğrulayın

Birden fazla mağaza veya müşteri hesabı yöneten sistemlerde sipariş kaynağındaki satıcı kimliği yerel tenant ile eşleşmelidir. API anahtarı doğru olsa bile cevap başka mağazaya aitse sipariş yanlış hesaba yazılabilir veya “tenant bulunamadı” nedeniyle tamamen atlanabilir.

• Satıcı ID ile yerel mağaza kaydı aynı mı?
• API anahtarı başka mağazadan kopyalanmış olabilir mi?
• Mağaza pasif veya paket yetkisi kapalı mı?
• Siparişin business unit veya satış modeli destekleniyor mu?
• Şube ve depo eşlemesi zorunlu olup eksik mi?

Kuyruk ve veritabanı hatalarını sipariş bazında izleyin

API’den veri alınması son adım değildir. Sipariş çoğu sistemde kuyruk üzerinden işlenir. Kuyruk worker’ı durmuşsa ham sipariş kaydı bulunabilir fakat sipariş tablosu boş kalır. Worker çalışsa bile ürün, müşteri, adres veya vergi alanındaki doğrulama hatası işlemi geri alabilir.

Log kaydında dış sipariş kimliği mutlaka bulunmalıdır. Sadece “SQLSTATE error” veya “validation failed” yazan genel log, hangi siparişin kaybolduğunu göstermediği için teşhisi zorlaştırır.

1. Ham API cevabında siparişi bulun.
2. Import job kimliğini ve kuyruk durumunu bulun.
3. Worker logunda aynı dış sipariş kimliğini arayın.
4. Veritabanı transaction rollback nedenini inceleyin.
5. Başarısız job yeniden denendiğinde çift kayıt oluşmadığını doğrulayın.

Mükerrer kayıt koruması gerçek siparişi engelleyebilir

İdempotency kontrolü aynı siparişin iki kez eklenmesini önler. Ancak yanlış alan kullanılırsa farklı paketler aynı sipariş sanılabilir. Örneğin yalnızca ana sipariş numarasına bakmak, aynı sipariş altındaki yeni paket veya bölünmüş gönderiyi atlayabilir. Tersi durumda paket kimliği değiştiğinde aynı sipariş tekrar eklenebilir.

Eşsiz anahtar; kaynak platform, satıcı hesabı, dış sipariş numarası, paket kimliği ve gerekiyorsa sipariş satırı kimliğinin birlikte değerlendirilmesiyle tasarlanmalıdır.

Siparişin panele düşmemesi neden–çözüm tablosu

Adım adım sipariş teşhis akışı

1. Müşteriden sipariş numarası, saat ve ödeme bilgisini alın.
2. Kaynak mağaza veya pazaryeri panelinde siparişi doğrulayın.
3. Aynı zaman aralığını API üzerinden elle sorgulayın.
4. Ham API cevabını dosya veya log kaydında saklayın.
5. Mağaza/tenant eşlemesini kontrol edin.
6. Import job, kuyruk worker ve başarısız işler listesini inceleyin.
7. Veritabanı doğrulama ve unique constraint hatalarını kontrol edin.
8. Siparişi güvenli yeniden işleme kuyruğuna alın.
9. Stok, ödeme ve müşteri bildiriminin tutarlı olduğunu doğrulayın.

Hangi durumda teknik destek gerekir?

• Tahsilat yapıldığı hâlde sipariş kaydı oluşmuyorsa
• Kaynak panelde görünen sipariş API sorgusunda bulunamıyorsa
• Kuyruk sürekli başarısız oluyor veya worker kendiliğinden duruyorsa
• Aynı sipariş bazen iki kez, bazen hiç kaydolmuyorsa
• Birden fazla mağaza ve tenant eşlemesinde siparişler karışıyorsa
• Eksik siparişler stok ve fatura sürecini etkiliyorsa

Sık sorulan sorular

Sipariş birkaç dakika sonra panele düşüyorsa sorun var mı?

Periyodik çekim kullanan sistemlerde kısa gecikme normal olabilir. Ancak beklenen gecikme süresi tanımlı olmalı; bu sürenin aşılması alarm üretmelidir.

Webhook kaçarsa sipariş tamamen kaybolur mu?

Sağlam tasarımda hayır. Periyodik mutabakat görevi webhook ile gelmeyen siparişleri daha sonra kaynak API’den bulmalıdır.

Eksik siparişi elle eklemek yeterli midir?

Tek siparişi geçici olarak çözer; fakat ödeme, stok, kargo ve fatura bağlantıları doğru kurulmadıysa operasyonel tutarsızlık devam eder.