Hata Çözüm Merkezi
WooCommerce webhook çalışmıyor: Sipariş ERP’ye neden ulaşmıyor?
Mağazada sipariş var, ERP’de yoksa önce bildirimin hangi adımda kaldığını bulun. Webhook’u yeniden açmak veya bütün siparişleri tekrar göndermek tek başına çözüm değildir.
Kısa cevap: Olayın oluşmasını, arka plan işini, HTTP teslimatını ve ERP’nin siparişi kabul etmesini ayrı kontrol edin. Aynı mağaza ve sipariş kimliği için bu dört kanıtı birleştirmeden tekrar gönderime başlamayın. Başarılı bir HTTP yanıtı, ERP’de geçerli sipariş kaydı bulunduğunu kanıtlamaz.
Bu rehber WooCommerce’in dış sisteme gönderdiği sipariş bildirimleri içindir. Ödeme kuruluşunun mağazaya gönderdiği ödeme bildirimi ayrı yönde çalışır; birinin başarılı olması diğerini doğrulamaz. Örneğin Stripe bağlantısının webhook ayarları ödeme entegrasyonuna aittir. Mağazanın REST API’sini çağırırken yetki hatası alıyorsanız WooCommerce REST API 401 rehberini kullanın.
Bildirim hangi adımda kalmış?
Önce tek bir gerçek sorunu, sipariş kimliği ve saat dilimi belirtilmiş zaman aralığıyla sınırlandırın. Aşağıdaki tablo teşhis sırası önerisidir; tek bir log satırından kesin kök neden çıkarılmaz.
| Görülen durum | Aranacak kanıt | Sonraki karar |
|---|---|---|
| Sipariş var; teslimat kaydı yok | Webhook durumu, seçilen olay ve aynı siparişe ait arka plan işi | Olay hiç oluşmadı mı, iş bekliyor mu, kayıtlar silinmiş mi ayırın. Log yokluğu tek başına “gönderilmedi” demek değildir. |
| İş bekliyor veya başarısız | İşin zamanı, son hata kaydı ve kuyruk gecikmesi | Önce işleyicinin neden ilerlemediğini bulun. Tüm kuyruğu topluca çalıştırmayın veya silmeyin. |
| Teslimatta zaman aşımı, 4xx veya 5xx | Hedef URL, durum kodu; aynı zamanda alıcıdaki kabul kaydı | Adres/erişim hatasını işlem hatasından ayırın. Zaman aşımında ERP’ye yazılmış olma ihtimalini kontrol edin. |
| HTTP başarılı; ERP siparişi bulunamıyor | Alıcının kalıcı kabul kaydı, iş durumu ve ERP belge numarası | Ürün, cari, vergi veya depo eşleştirme hatasını inceleyin. Aynı siparişi tekrar oluşturmaya geçmeyin. |
| Webhook devre dışı | Son başarılı teslimat, sonraki hatalar ve etkilenen sipariş aralığı | Nedeni giderin, sınırlı kontrol yapın; geçmiş eksikleri ayrıca uzlaştırın. |
WooCommerce’te hangi ekranlara bakılmalı?
Ayarlar → Gelişmiş → Webhook’lar bölümünde durum, konu ve teslimat adresini kontrol edin. İlk etkin kayıtta gönderilen ping, gerçek bir siparişin ERP’ye işlendiği testi değildir. Durum → Günlükler bölümünde webhooks-delivery kaynağını inceleyin. WooCommerce ardışık teslimat hatalarından sonra webhook’u devre dışı bırakabilir; eşik kurulumdaki sürüm ve filtrelerle değişebilir. Resmî webhook yönetimi ve hata davranışı.
Durum → Zamanlanmış Eylemler ekranında bekleyen ve başarısız işleri, ilgili zaman aralığıyla inceleyin. Arka plan işlerinin gecikmesi teslimatı da geciktirebilir. WooCommerce zamanlanmış eylemler belgesi bu ekranı ve WP-Cron ilişkisini açıklar. Mevcut çekirdek kodda varsayılan asenkron teslimat işi woocommerce_deliver_webhook_async adını kullanır; eklentiler akışı değiştirebilir. Resmî kuyruk uygulaması.
Kayıtların saklama süresini ve saat dilimini karşılaştırın. Genel bir sağlık kontrolünün başarılı olması, belirli sipariş işinin çalıştığını göstermez. Deneme için canlı müşteriye yeni ödeme, e-posta, fatura veya sevkiyat başlatabilecek bir sipariş üretmeyin; yan etkileri sınırlandırılmış test ortamını tercih edin.
İmza hatasında güvenliği kapatmadan ne kontrol edilir?
Varsayılan WooCommerce imzası, gönderilen gövdenin HMAC-SHA256 sonucunun Base64 biçimidir ve X-WC-Webhook-Signature başlığında taşınır. Alıcı, JSON’u yeniden biçimlendirip hesaplamak yerine gelen ham gövdeyi kullanmalı; gizli değer eşleşmesini yetkili ortamda kontrol etmelidir. İmza algoritması filtreyle değiştirilebilir. Resmî imza ve teslimat uygulaması.
Karşılaştırmayı uygun sabit zamanlı doğrulamayla yapın; eksik veya geçersiz imzayı sipariş işleme yetkisi saymayın. Ping akışını sipariş akışından ayırın. Sorunu çözmek için imza kontrolünü veya güvenlik duvarını topluca kapatmayın. Destek kaydında sırları, müşteri bilgilerini ve tam sipariş gövdesini paylaşmayın; arındırılmış hata kodu, zaman ve işlem kimliği yeterli olabilir.
HTTP 200 döndü; neden ERP’de sipariş yok?
Alıcı yalnızca isteği gördüğünde başarı dönüyorsa sonraki iş kaybolabilir. Önerdiğimiz tasarımda başarı yanıtı, doğrulanmış bildirimin kalıcı olarak kabul edilmesi veya işlemin tamamlanmasıyla ilişkilendirilir. Kuyruk kullanılıyorsa “alındı”, “işleniyor”, “ERP kabul etti” ve “inceleme gerekiyor” durumları ayrılır; hata sorumlusu bellidir. Bu davranış entegrasyonda uygulanmalıdır, WooCommerce’in tek başına sağladığı bir garanti değildir.
İzleme için teslimat kimliği yararlıdır; iş kaydını tekilleştirmek için mağaza ve sipariş kimliğini de kullanın. Aynı siparişin oluşturma ve güncelleme bildirimleri aynı işlem değildir. Güncellemeleri yok saymak yerine iş kuralına uygun uygulayın; eski bir bildirimin yeni durumu geri almasını önleyin. Ayrıntılı sahiplik ve kabul kararları ERP entegrasyonu planlama rehberinde yer alır.
Örnek: İki eksik bildirim nasıl uzlaştırılır?
Örnek senaryo — müşteri verisi değildir: Bir kesinti aralığında mağazadaki 4101 ve 4102 numaralı siparişlerin teslimat sonucu belirsiz. Bu örnekte siparişler ERP’ye aktarılmaya uygun durumda; gerçek projede ödeme, iptal ve iade kuralları ayrıca uygulanır.
| Sipariş | ERP kontrolü | Kontrollü işlem |
|---|---|---|
| Mağaza A / 4101 | Dış referansla eşleşen ERP kaydı var; satırlar ve tutar uyumlu | Yeni sipariş açmayın. Mevcut belgeyi aktarım kaydına bağlayın; sonucu “ERP kabul etti” olarak uzlaştırın. |
| Mağaza A / 4102 | Yetkili sorguda eşleşme yok; devam eden iş olmadığı doğrulandı | Güncel sipariş durumunu ve eşleştirmeleri doğrulayın. Tekilleştirme korumasıyla tek kontrollü aktarım yapıp ERP kabulünü kontrol edin. |
| Her iki siparişten biri için sonuç belirsiz | ERP’ye erişilemiyor veya kayıtlar çelişiyor | Otomatik tekrar döngüsünü durdurun; sorumlu kişinin incelemesini bekleyin. Belirsizliği “başarısız” varsaymayın. |
Tekilleştirme, aynı anda çalışan iki işin ayrı ayrı “yok” görüp sipariş açmasını da engellemelidir. ERP’nin benzersiz dış referans desteği veya entegrasyonun atomik işlem koruması proje sırasında doğrulanır. Deneme sayısı, bekleme aralığı, toplam işleme süresi ve bildirim sorumlusu sınırlandırılır. Kuyruktaki işin başarıyla bitmesiyle ERP kaydının kabulünü ayrı doğrulayın.
Webhook’u yeniden etkinleştirmenin eski bildirimleri eksiksiz yeniden oynatacağını varsaymayın. Etkilenen zaman aralığını kaydedip mağaza siparişleriyle ERP kayıtlarını uzlaştırın. Yalnız doğrulanmış eksikler kontrollü aktarılır; bütün geçmişi yeniden göndermek stok, fatura ve sevkiyat işlemlerini çoğaltabilir.
Ne zaman entegrasyon desteği gerekir?
Teslimat başarılı görünmesine rağmen iş kabulü izlenemiyorsa, eski olaylar güncel veriyi değiştiriyorsa veya kesinti sonrası hangi siparişin eksik olduğu bulunamıyorsa sorun tek bir ayar olmayabilir. Kabul kaydı, tekilleştirme ve uzlaştırma akışını birlikte tasarlamak gerekir.
Kaynak kontrolü ve içerik güncellemesi: 18 Ekim 2026. Çekirdek kod bağlantıları geliştirme dalına aittir; kurulumun WooCommerce sürümü, eklentileri ve filtreleri ayrıca doğrulanır. Senaryo ve karar tabloları mimari öneridir; müşteri sonucu, çalıştırılmış WooCommerce kurulumu testi veya üretici ortaklığı iddiası değildir.
Sipariş akışını birlikte netleştirelim
ERP’ye kabul ve hata sonrası toparlanma kapsamını özel yazılım geliştirme hizmetimizle değerlendirebiliriz.
İhtiyacınızı konuşalım →