Ürünler yerli yerinde, kargo ücreti hesaplanıyor, sepet toplamı doğru. Müşteri "Siparişi tamamla" adımına geliyor ve kart formunun olması gereken yerde tek satırlık bir uyarı buluyor: "Üzgünüz, siparişiniz için kullanılabilir ödeme yöntemi yok gibi görünüyor. Lütfen farklı bir ödeme yöntemi deneyin veya yardım için bize ulaşın." Panele bakıyorsunuz, WooCommerce > Ayarlar > Ödemeler ekranında iyzico ya da PayTR satırı pırıl pırıl açık duruyor. Anahtarlar girilmiş, eklenti güncel, geçen hafta siparişler geliyordu.
Bu tablo, kurulum rehberlerinin bittiği yerde başlayan bir arızadır. Entegrasyonda yanlış bir şey yoktur; WooCommerce ödeme yöntemlerini sabit bir liste olarak tutmaz. Her ödeme sayfası isteğinde kayıtlı tüm yöntemleri tek tek dolaşır, her birine "bu sepet, bu adres ve bu tutar için kullanılabilir misin?" diye sorar (is_available()), hayatta kalanları woocommerce_available_payment_gateways filtresinden geçirir ve ancak ondan sonra ekrana basar. Yani listeyi boşaltan şey neredeyse hiçbir zaman "eklenti bozuldu" değildir; bu üç aşamadan birinde devreye giren bir koşuldur.
Bu yazıda arızayı olasılık sırasına göre eleyeceğiz. En başa, 2023 sonrasında Türkiye'deki mağazaların büyük kısmını vuran kırılmayı koyuyorum: WooCommerce'in blok tabanlı ödeme sayfası ile eski nesil sanal POS eklentilerinin uyumsuzluğu. Ardından kargo bölgesi eşleşmemesi, yöntem bazlı tutar/ülke/para birimi kısıtları, sanal ürünlerde gereksiz kargo talebi, eklentinin kendini kapatması (test modu, API anahtarı, alan adı lisansı) ve tema override'ı geliyor. Her başlıkta "bu bende mi?" sorusunu kesin yanıtlayan bir doğrulama adımı var.
Önce Hatayı Doğru Okuyun: Üç Ayrı Belirti, Üç Ayrı Yön#
"Ödeme yöntemi görünmüyor" cümlesi birbirinden çok farklı durumları birden anlatıyor ve hangisinde olduğunuzu bilmeden doğru yere bakamazsınız. Müşteriden ya da kendi test siparişinizden gelen ekran görüntüsünü şu tabloyla eşleştirin:
| Ekranda gördüğünüz | Muhtemel katman | İlk bakılacak yer |
|---|---|---|
| "Kullanılabilir ödeme yöntemi yok" uyarısı, bölüm boş | Yöntem is_available() ile eleniyor | Eklenti kısıtları, para birimi, tutar |
| Havale/EFT görünüyor, kart yöntemi yok | Yalnızca o eklenti eleniyor veya blok uyumsuz | Blok checkout, test modu, lisans |
| Ödeme bölümü hiç çizilmiyor | Şablon veya JavaScript hatası | Tema override, tarayıcı konsolu |
| Yanında "Bu adrese gönderim yapılamıyor" da var | Kargo bölgesi eşleşmiyor | Kargo bölgeleri |
| Sadece bazı müşterilerde oluyor | Adres veya tutar bağımlı kural | Bölge, minimum tutar, ülke kısıtı |
Havale/EFT (BACS) yönteminin görünüp kart yönteminin görünmemesi çok değerli bir ipucudur: WooCommerce'in ödeme bölümü çalışıyor, şablon basılıyor, sorun tek bir eklentide demektir. Tersine hiçbir şey, havale bile görünmüyorsa arıza tek bir eklentide değil, sepetin bütününde ya da sayfa şablonundadır.
Devam etmeden önce tarayıcı geliştirici konsolunu açın. Blok tabanlı ödeme sayfası tamamen JavaScript ile çizilir; bir tema ya da eklenti kaynaklı JS hatası ödeme bölümünü sessizce yarıda bırakabilir. Konsolda kırmızı bir Uncaught TypeError görüyorsanız, aşağıdaki sunucu tarafı kontrollerine geçmeden önce onu çözmelisiniz.
En Sık Sebep: Blok Ödeme Sayfası ile Sanal POS Eklentisi Uyumsuzluğu#
WooCommerce 8.3 sürümünden itibaren yeni kurulan mağazalarda sepet ve ödeme sayfaları kısa kod değil, blok olarak geliyor. Blok checkout ödeme yöntemlerini eski yöntemle listelemiyor: bir eklentinin blok ödeme sayfasında görünebilmesi için woocommerce_blocks_payment_method_type_registration kancasına kendini ayrıca kaydetmesi gerekiyor. Bu kaydı yapmayan bir sanal POS eklentisi, klasik kısa kod sayfasında kusursuz çalışırken blok sayfada hiç listelenmez ve tek bir hata satırı bile üretmez.
Türkiye'de bu, sessiz bir ciro kaybına dönüştü. Yerel sanal POS eklentilerinin bir kısmı, ödemeyi tamamlamak için müşteriyi bankanın 3-D Secure sayfasına gönderen "form gönderimi" mantığını kullanır; blok checkout mimarisi bu akışı uzun süre desteklemedi. Eklenti üreticisi güncelleme yayınlayana kadar tek doğru çözüm, ödeme sayfasını klasik kısa koda döndürmektir.
Ödeme sayfanız blok mu, kısa kod mu?#
Tahmin etmeyin, bakın. Sayfayı düzenleyicide açtığınızda "Ödeme" adında büyük bir blok görüyorsanız blok, tek satırda [woocommerce_checkout] yazıyorsa kısa kod kullanıyorsunuz demektir. Sunucudan kesin cevap almak için WP-CLI daha hızlıdır:
# Odeme ve sepet sayfalarinin ID'lerini WooCommerce ayarlarindan oku
wp option get woocommerce_checkout_page_id
wp option get woocommerce_cart_page_id
# Sayfa iceriginin ilk satirlarini goster: blok mu, kisa kod mu?
wp post get $(wp option get woocommerce_checkout_page_id) --field=post_content | head -5
Çıktıda <!-- wp:woocommerce/checkout satırını görüyorsanız blok checkout'tasınız. [woocommerce_checkout] görüyorsanız klasik sayfadasınız ve bu bölümü atlayıp kargo bölgelerine geçebilirsiniz.
Eklenti blok checkout'a kayıtlı mı?#
Blok sayfada hangi yöntemlerin kayıtlı olduğunu doğrudan sorabilirsiniz. Aşağıdaki kancayı geçici olarak child temanızın functions.php dosyasına ekleyin, bir kez ödeme sayfasını açın, sonra kaldırın:
// Blok odeme sayfasina kayitli olan yontemleri hata gunlugune yaz
add_action( 'woocommerce_blocks_payment_method_type_registration', function ( $registry ) {
$kayitli = array_keys( $registry->get_all_registered() );
error_log( 'Blok checkout kayitli yontemler: ' . implode( ', ', $kayitli ) );
}, 99 );
Günlüğe düşen listede sanal POS eklentinizin kimliği (iyzico, paytr vb.) yoksa teşhis kesindir: eklenti blok checkout'u desteklemiyor. Günlüğü okuyabilmek için WP_DEBUG_LOG açık olmalı; nasıl açıldığını WordPress debug log açma yazısında bulabilirsiniz.
WooCommerce'in kendi arayüzü de yardımcı olur: blok düzenleyicide ödeme bloğunu seçtiğinizde çıkan "uyumsuz eklenti" uyarısı aynı bilgiyi verir. Ancak bu uyarı yanlış pozitif üretebildiği için günlük çıktısı daha güvenilirdir.
Çözüm: sayfayı kısa koda döndürün#
Blok düzenleyicide Ödeme bloğunu seçip araç çubuğundaki "Klasik ödeme sayfasına geç" seçeneğini kullanabilirsiniz. Aynı işlemi sepet sayfası için de yapın; WooCommerce ikisinin birlikte döndürülmesini önerir, aksi halde sepetten ödemeye geçişte tutarsız davranış görülebilir.
Toplu ve geri alınabilir bir yol isterseniz:
# ONCE YEDEK: mevcut icerikleri diske al
wp post get $(wp option get woocommerce_checkout_page_id) --field=post_content > /tmp/checkout.bak
wp post get $(wp option get woocommerce_cart_page_id) --field=post_content > /tmp/cart.bak
# Klasik kisa koda dondur
wp post update $(wp option get woocommerce_checkout_page_id) --post_content='[woocommerce_checkout]'
wp post update $(wp option get woocommerce_cart_page_id) --post_content='[woocommerce_cart]'
# Onbellegi temizle ki eski HTML servis edilmesin
wp cache flush
Kısa koda döndükten sonra ödeme yöntemleri anında görünüyorsa sebep buydu ve iş bitmiştir. Bu geçici bir çözümdür: eklenti üreticisi blok desteğini yayınladığında sayfayı bloğa geri çevirebilirsiniz. Blok tema ve tam site düzenleme mimarisinin genel mantığını merak ediyorsanız WordPress FSE ve blok tema yazısı iyi bir başlangıçtır.
Kargo Bölgesi Eşleşmiyor: Adres Hiçbir Bölgeye Düşmüyor#
Ödeme yöntemleri sepetin toplam tutarına bağlıdır; kargo ücreti de bu toplamın parçasıdır. WooCommerce, kargo gerektiren bir sepette müşterinin adresine uyan hiçbir kargo yöntemi bulamazsa siparişi tamamlanamaz sayar ve ödeme bölümü ya boş kalır ya da "Bu adrese gönderim yapılamıyor" uyarısıyla birlikte kilitlenir.
Bu, tek bir müşteride ortaya çıkıp sizde asla tekrarlanmayan arızanın klasik sebebidir: siz İstanbul adresiyle test edersiniz, sorun yaşayan müşteri KKTC'den ya da bir yurt dışı adresinden sipariş vermeye çalışıyordur. Bölgeleriniz yalnızca Türkiye'yi kapsıyorsa o müşteri "Diğer bölgeler" grubuna düşer ve orada tanımlı yöntem yoksa akış durur.
Bölgeleri ve altındaki yöntemleri komut satırından hızlıca dökebilirsiniz:
# Tanimli kargo bolgeleri
wp wc shipping_zone list --user=1
# Belirli bir bolgedeki kargo yontemleri (zone_id'yi ustteki ciktidan alin)
wp wc shipping_zone_method list 1 --user=1
# "Diger bolgeler" (kapsam disi) grubu her zaman 0 kimlikli bolgedir
wp wc shipping_zone_method list 0 --user=1
Kontrol listesi: her bölgede en az bir etkin kargo yöntemi olmalı; ücretsiz kargo eşiği kullanıyorsanız eşiğin altındaki sepetler için de bir yedek yöntem bulunmalı; posta kodu aralıklarıyla daraltılmış bölgelerde aralık dışı adreslerin nereye düştüğü bilinmeli. Bölge sıralaması ve ücretlendirme mantığının tamamı için WooCommerce kargo ayarları yazısına bakın.
Sanal ve Dijital Ürünlerde Gereksiz Kargo Talebi#
İkinci sık hata, kargo gerekmeyen bir ürünün kargo istemesidir. Ürünü eklerken Sanal (virtual) kutusu işaretlenmemişse WooCommerce o ürün için kargo hesaplar; sepette yalnızca bu ürün varsa ve uygun bir kargo yöntemi yoksa yukarıdaki kilit devreye girer. Dijital ürün, danışmanlık, hosting paketi, kurs kaydı gibi kalemlerde bu ayar sık sık unutulur.
Sanal olması gerektiği hâlde olmayan ürünleri tek sorguyla bulabilirsiniz:
-- Sanal olarak isaretlenmemis yayindaki urunler
SELECT p.ID, p.post_title
FROM wp_posts p
LEFT JOIN wp_postmeta m
ON m.post_id = p.ID AND m.meta_key = '_virtual'
WHERE p.post_type = 'product'
AND p.post_status = 'publish'
AND ( m.meta_value IS NULL OR m.meta_value = 'no' )
ORDER BY p.post_title;
Varyasyonlu ürünlerde sanal işareti her varyasyon için ayrı tutulur; ana üründe işaretlemek yetmez. Müşteri belirli bir varyasyonu seçtiğinde kargo talebinin geri dönmesinin sebebi budur.
Ödeme Yönteminin Kendi Kısıtları: Tutar, Ülke, Para Birimi#
Her ödeme eklentisinin kendi ayar ekranında, çoğu zaman gözden kaçan filtreleri vardır. Bunların hepsi is_available() içinde çalışır ve koşul sağlanmadığında yöntem listeye hiç girmez:
| Kısıt | Tipik belirti | Nerede ayarlanır |
|---|---|---|
| Minimum sipariş tutarı | Küçük sepetlerde kart yok, büyükte var | Eklenti ayarları |
| Maksimum sipariş tutarı | Yüksek tutarlı sepette kaybolur | Eklenti ayarları |
| Ülke kısıtı | Yalnız yurt dışı müşteride kaybolur | Ödemeler > yöntem > ülkeler |
| Para birimi | Mağaza TRY dışına çevrilince kart yöntemleri gider | WooCommerce > Ayarlar > Genel |
| Ürün tipi | Sadece abonelik içeren sepette kaybolur | Abonelik eklentisi ayarları |
Türkiye'de en çok can yakan satır para birimidir: yerel sanal POS eklentilerinin büyük kısmı yalnızca TRY ile çalışır. Çok para birimli bir eklenti kurup mağazayı USD'ye çevirdiğinizde kart yöntemleri toptan kaybolur. Hızlı kontrol:
# Magaza para birimi ve varsayilan ulke
wp option get woocommerce_currency
wp option get woocommerce_default_country
# Tum kayitli odeme yontemleri ve etkin/pasif durumu
wp eval 'foreach ( WC()->payment_gateways()->payment_gateways() as $id => $gw ) { printf( "%-24s %-30s %s\n", $id, $gw->get_title(), $gw->enabled ); }'
Son komut eklentinin kayıtlı olup olmadığını gösterir. Liste eklentinizi hiç içermiyorsa sorun ayarlarda değil, eklentinin yüklenmesindedir: sürüm uyumsuzluğu, PHP hatası ya da devre dışı bırakılmış bir eklenti söz konusudur. Kimlik listede görünüyor ama enabled değeri no ise yöntem yalnızca kapalıdır. Vergi ayarlarının toplam tutarı beklenmedik biçimde değiştirdiği durumlar için WooCommerce KDV ve vergi ayarları yazısı da işinize yarayabilir.
Eklenti Kendini Kapatıyor: Test Modu, API Anahtarı ve Alan Adı Lisansı#
Sanal POS eklentileri, hatalı bir işlem başlatmaktansa sessizce görünmez olmayı tercih eder. Üç durumda kendilerini is_available() içinde kapatırlar:
- Test/canlı modu uyumsuzluğu. Eklenti canlı moda alınmış ama alanlarda hâlâ test anahtarları duruyorsa (ya da tersi) yöntem listeye girmez. Ayar ekranında modu ve anahtarları birlikte kontrol edin; anahtarların başındaki ve sonundaki görünmez boşluklar da doğrulamayı düşürür.
- API anahtarı doğrulanamıyor. Anahtar yanlışsa, süresi dolmuşsa ya da sunucunuz sağlayıcının uç noktasına çıkamıyorsa doğrulama başarısız olur. Sunucudan basit bir bağlantı testi bunu ayırır:
# Sunucu odeme saglayicisina cikabiliyor mu? (yalnizca baglanti/DNS testi)
curl -sS -o /dev/null -w "HTTP %{http_code} toplam %{time_total}s\n" https://api.iyzipay.com/
curl -sS -o /dev/null -w "HTTP %{http_code} toplam %{time_total}s\n" https://www.paytr.com/
Komut zaman aşımına düşüyorsa sunucunuzda giden bağlantılarda güvenlik duvarı kısıtı var demektir. Bu yalnızca ödeme yönteminin kaybolmasına değil, tamamlanan siparişlerin geri bildirim almamasına da yol açar.
- Alan adı lisans kontrolü. Ticari eklentilerin bir kısmı lisansı alan adına bağlar. Siteyi
staging.magaza.comgibi bir kopyaya taşıdığınızda,wwwvarlığını değiştirdiğinizde ya da HTTPS'e geçtiğinizde lisans eşleşmez ve eklenti kendini kapatır. Sağlayıcı panelinde kayıtlı alan adının,wp option get siteurlçıktısıyla karakter karakter aynı olduğunu doğrulayın.
Bu üç maddenin doğrulamasında eklentilerin kendi kurulum rehberleri işinizi kolaylaştırır: WooCommerce iyzico entegrasyonu ve WooCommerce PayTR entegrasyonu yazılarında hangi alanın nereden alındığı adım adım anlatılıyor.
Tema Override'ı ve Eklenti Çakışması: Yöntem Var Ama Ekrana Basılmıyor#
Bazı temalar WooCommerce şablonlarını kendi klasörlerine kopyalayarak değiştirir. checkout/form-checkout.php veya checkout/payment.php dosyasının eski bir WooCommerce sürümünden kalma kopyası temanızda duruyorsa ödeme bölümü ya eksik basılır ya hiç basılmaz. WooCommerce bunu size zaten söylüyor: WooCommerce > Durum sayfasının en altındaki "Şablonlar" bölümünde güncelliğini yitirmiş override'lar kırmızıyla listelenir.
Diskten de bakabilirsiniz:
# Aktif temanin WooCommerce sablon override'lari
find wp-content/themes/$(wp option get stylesheet)/woocommerce -type f -name '*.php' 2>/dev/null
# Odeme akisini etkileyen kritik dosyalar var mi?
ls -l wp-content/themes/$(wp option get stylesheet)/woocommerce/checkout/ 2>/dev/null
İkinci ihtimal, başka bir eklentinin woocommerce_available_payment_gateways filtresine takılıp listeyi boşaltmasıdır. Bunu yapan tipik adaylar: rol bazlı fiyatlandırma eklentileri, B2B/bayi eklentileri, "ülkeye göre ödeme yöntemi" eklentileri ve bazı kampanya eklentileri. Filtreden çıkan sonucu doğrudan gözlemleyin:
// Odeme adiminda hangi yontemlerin hayatta kaldigini gunluge yaz
add_filter( 'woocommerce_available_payment_gateways', function ( $gateways ) {
if ( ! is_admin() ) {
error_log( 'Kullanilabilir yontemler: ' . implode( ', ', array_keys( $gateways ) ) );
}
return $gateways;
}, 9999 );
Öncelik değeri 9999, filtreye bağlanan diğer tüm eklentilerden sonra çalışmayı garanti eder; yani gördüğünüz liste ekrana basılacak olan nihai listedir. Liste boşsa suçlu bir eklentidir ve klasik ikili arama yöntemiyle bulunur: eklentileri yarıya bölerek kapatıp açın. Yöntemin ayrıntısı için WordPress eklenti çakışması tespiti yazısına bakabilirsiniz.
Nasıl Doğrularım: Farklı Adresle Test Siparişi ve Durum Raporu#
Teşhisi tahmine bırakmamanın iki güvenilir yolu var.
1. Farklı adreslerle test siparişi. Havale/EFT yöntemini geçici olarak açın ve gizli pencerede, oturum açmadan üç ayrı sipariş deneyin: (a) İstanbul adresi ve kargo gerektiren fiziksel ürün, (b) aynı ürün ama yurt dışı adresi, (c) yalnızca sanal ürün içeren sepet. Hangi kombinasyonda ödeme yöntemleri kayboluyorsa, sorunun kargo/adres tarafında mı yoksa yöntem kısıtında mı olduğunu tek turda öğrenirsiniz. Sepet tutarını da değiştirmeyi unutmayın; minimum tutar kısıtı ancak böyle ortaya çıkar.
2. WooCommerce durum raporu. WooCommerce > Durum sayfasındaki "Sistem durum raporunu al" düğmesi tek bir metin bloğu üretir. Bu blokta doğrudan bakmanız gereken satırlar şunlar: WooCommerce ve WordPress sürümleri, veritabanı sürümü ile eklenti sürümü arasındaki uyumsuzluk uyarıları, aktif eklentiler listesi, "Şablonlar" bölümündeki eski override'lar ve "Sayfalar" bölümünde ödeme sayfasının doğru sayfaya bağlı olduğu bilgisi. Bu bölümde "sayfa gerekli kısa kodu veya bloğu içermiyor" uyarısı görüyorsanız birinci başlığa geri dönün.
Ödeme sayfası isteği sırasında sunucu hata günlüğünü canlı izlemek de PHP kaynaklı sessiz kesintileri anında ortaya çıkarır:
# Odeme sayfasini yenilerken WordPress hata gunlugunu canli izle
tail -f wp-content/debug.log
# Sunucu genelindeki PHP-FPM hatalari (yol dagitima gore degisir)
tail -f /var/log/php-fpm/error.log
Sorunu bulup düzelttikten sonra son bir adım kalır: önbelleği ve varsa CDN'i temizleyin. Kısa koda döndükten sonra "hâlâ görünmüyor" diyen mağazaların çoğunda gerçek sebep, ödeme sayfasının eski HTML kopyasının hâlâ servis edilmesidir. Test etmeden önce her zaman gizli pencerede ve önbellek temizlenmiş hâlde deneyin. Mağazanızın genel kurulumunu gözden geçirmek isterseniz WooCommerce başlangıç rehberi iyi bir kontrol listesi sunar.
Sıkça Sorulan Sorular#
Blok ödeme sayfasından kısa koda dönmek SEO veya siparişlerimi etkiler mi?#
Hayır. Ödeme sayfası zaten arama motorlarına kapalı olması gereken, oturuma bağlı bir sayfadır; içerik biçimini değiştirmek dizinlemeyi etkilemez. Mevcut siparişler, ödeme kayıtları ve müşteri hesapları veritabanında ayrı saklandığı için bu değişiklikten etkilenmez. Yalnızca ödeme sayfasının görsel düzeni ve tema stilleri değişir. Değişiklikten sonra bir test siparişiyle akışın uçtan uca çalıştığını doğrulamanız yeterlidir.
Havale/EFT görünüyor ama kart yöntemi görünmüyor, bu ne anlama gelir?#
Bu, sorunu tek bir eklentiye daraltan en değerli ipucudur. WooCommerce'in ödeme bölümü çalışıyor, şablon basılıyor ve en az bir yöntem koşulları sağlıyor demektir. Sıralamayı şöyle yapın: eklenti blok checkout'u destekliyor mu, test ve canlı modu ile anahtarlar uyumlu mu, mağaza para birimi TRY mi, sepet tutarı yöntemin minimum eşiğinin üstünde mi ve lisans alan adı site adresiyle birebir aynı mı.
Ödeme yöntemi sadece bazı müşterilerde kayboluyor, sebebi ne olabilir?#
Kişiye göre değişen tek şey adres ve sepet içeriğidir. Öncelikle o müşterinin il, ülke ve posta kodu bilgisinin tanımlı bir kargo bölgesine düşüp düşmediğini kontrol edin; kapsam dışı adresler "Diğer bölgeler" grubuna düşer ve orada yöntem yoksa akış kilitlenir. İkinci olarak sepet tutarını ödeme yönteminin minimum ve maksimum limitleriyle karşılaştırın. Üçüncüsü, sepette kargo gerektiren bir ürünün bulunup bulunmadığına bakın.
Ödeme sayfasında hiçbir şey görünmüyor, uyarı bile yok. Nereden başlamalıyım?#
Bu, sunucu tarafı bir eleme değil, çizim sorununun tipik belirtisidir. Önce tarayıcı konsolunu açıp JavaScript hatası olup olmadığına bakın; blok checkout tamamen JavaScript ile çizildiği için tek bir hata bölümü yarıda kesebilir. Konsol temizse temanın WooCommerce şablon override'larını kontrol edin ve durum sayfasında eski sürümde kalmış şablon uyarısı olup olmadığına bakın. Son olarak temayı geçici olarak varsayılan temaya alıp deneyin.
WooCommerce durum raporunda hangi satırlara bakmalıyım?#
Beş satır işinizi görür: WordPress ve WooCommerce sürümleri arasındaki uyumsuzluk uyarıları, veritabanı sürümünün eklenti sürümüyle eşleşmesi, "Sayfalar" bölümünde ödeme sayfasının doğru sayfaya bağlanmış olması, aynı bölümdeki "sayfa gerekli kısa kodu veya bloğu içermiyor" uyarısı ve en alttaki "Şablonlar" bölümünde kırmızı listelenen güncel olmayan tema override'ları. Bu beş noktada sorun yoksa arıza büyük olasılıkla eklenti kısıtlarındadır.
Eklentiyi güncelleyince ödeme yöntemi kayboldu, ne yapmalıyım?#
Önce sürüm notlarında blok checkout desteği ya da minimum WooCommerce/PHP sürümü değişikliği olup olmadığına bakın; yeni sürüm daha yüksek bir gereksinim getiriyor olabilir. Ödeme akışı kritik bir yol olduğu için en hızlı çözüm, eklentiyi bir önceki çalışan sürümüne geri almak ve sorunu üretim dışı bir kopyada araştırmaktır. Geri alma işleminden sonra o eklentinin otomatik güncellemesini de kapatın, aksi halde aynı sürüm birkaç saat içinde geri gelir.