# Müşterilerim artık ödeme yapamıyor, siparişi de bitiremiyor

> Tıkanan bir ödeme günlerle değil saatlerle ölçülür. İyi haber, zincirin kısa olması ve her halkanın kendine özgü bir imzayla kopmasıdır — ödemeden önceki sipariş adımları da dâhil, çünkü birçok sipariş gerçekte orada durur. Kötü haber, ilk refleksin — bankayı aramanın — neredeyse her zaman yanlış giriş noktası olmasıdır, çünkü arıza nadiren oradadır.

- Source canonique : [https://allaux.fr/tr/problemes/mes-clients-ne-peuvent-plus-payer](https://allaux.fr/tr/problemes/mes-clients-ne-peuvent-plus-payer)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Hangi halkanın koptuğunu görmek için bir euroluk deneme siparişi verin. Ödeme yöntemi artık ödeme adımında görünmüyorsa neden modül değil bir kısıttır: PrestaShop’ta Ödeme > Tercihler, para birimi, ülke ve müşteri grubuna göre süzer. Ödeme çıkıyor ama sipariş geri dönmüyorsa sorun dönüş adresidir: ağ geçidinin ham yanıtı için WooCommerce > Durum > Günlükler ya da var/logs/ dizinini okuyun.

## Zincirin beş halkası

Çevrimiçi bir ödeme birbirinden ayrı beş aşamadan geçer. Ödeme modülü sunulan yöntemler arasında görünmelidir. Ardından isteği oluşturup müşteriyi yönlendirmeli ya da giriş formunu göstermelidir. Ödeme sağlayıcısı işlemi bankayla yürütür. Müşteriyi mağazaya geri döndürür. Son olarak tarayıcıdan bağımsız teknik bir çağrıyla siteyi bilgilendirir ve siparişin kaydedilmesini tetikleyen bu çağrıdır.

Her aşamanın kendi belirtisi vardır. Görünmeyen ödeme yöntemi: modül devre dışı kalmıştır ya da bir görüntüleme koşulu artık sağlanmıyordur. Yönlendirilip eli boş dönen müşteri: dönüş yanlış yapılandırılmıştır. Sipariş kaydedilmeden çekilen tutar: teknik bildirim ulaşmıyordur. Bu sonuncusu en pahalı olanıdır, çünkü bir müşteri şikâyet edene kadar görünmez kalır.

## Müşterinizin anlattığı

- «Son adımda hiçbir ödeme yöntemi yok»: modül görünmüyordur — devre dışı, güncelleme sonrası uyumsuz ya da ülke, para birimi veya tutara göre kısıtlı.
- «Dönüyor sonra sepete geri geliyor»: sağlayıcıya yönlendirme başarısızdır, çoğu zaman süresi dolmuş bir kimlik anahtarı yüzünden.
- «Kartım reddedildi»: işlem bankaya ulaşmıştır, başarısızlık sitenin ötesindedir.
- «Param çekildi ama onay almadım»: dönüş bildirimi işlenmemiştir, sipariş beklemede kalmıştır.

## Tıkanma ödemenin öncesindeyse

Ödemeyi suçlamadan önce müşterilerin oraya ulaştığını doğrulamak gerekir. Adres ya da teslimat adımında tıkanan bir sipariş süreci, hiçbir ödeme modülü sorunlu olmadan tam olarak aynı şikâyeti üretir: «sipariş veremiyorum». Durmaların yoğunlaştığı adım neredeyse her zaman nedeni adlandırır.

Sepette: içerik güncellenmiyor ya da kayboluyor — oturum veya çerez sorunu, ya da hiçbir zaman önbelleğe alınmaması gereken bir sayfanın önbelleğe alınması.

Hesap oluşturmada: aşırı katı alan doğrulaması, hiç ulaşmayan onay e-postası ya da herkesi reddeden robot koruması.

Adres adımında: bazı ülkelere uymayan biçim denetimi ya da temanın görünmez kıldığı zorunlu alan.

Teslimat adımında: ağırlık, ülke ya da sepet tutarı için hiçbir yöntem sunulmuyor — bu bir arıza değil kargo kuralıdır.

Özet adımında: kötü yerleştirilmiş koşul onay kutusu ya da yalnızca ikinci tıklamada tepki veren onay butonu.

Son bir ayrım, olmayan bir arızayı aramayı önler. Vazgeçiş dağılır: teslimat adımına ulaşan yüz ziyaretçiden bir kısmı devam eder, bir kısmı ayrılır; bu fiyat, süre ya da açıklıkla çalışılır. Teknik tıkanma ise dağılmaz: kimse geçemez ya da yalnızca belirli bir profildeki ziyaretçiler geçer — bir ülke, bir tarayıcı, bir teslimat yöntemi, bir tutar. Bir adımdan diğerine geçiş oranı belirlenebilir bir tarihte aniden düştüyse bu tekniktir; yavaşça aşınıyorsa ticaridir.

## Kötü ayarlanmış bir onay bandı tüm süreci tıkar

> Bir bant, sipariş sürecinin ve ödeme modülünün dayandığı betikler dâhil tüm betiklerin yüklenmesini geciktirdiğinde, ziyaretçi tıklayana kadar butonlar tepkisiz kalır. Davranış o zaman ziyaretçinin seçimine bağlı olur ve oturum açmış bir yönetici hesabından yeniden üretilemeyen, görünüşte rastgele bir tıkanma ortaya çıkar.

## Beş kontrolle ayrıştırmak

1. **Müşteri gibi test siparişi verin** — Sonuna kadar, çıkış yapmış hâlde, gizli sekmede, mobilde ve masaüstünde, mümkünse sağlayıcının test kipiyle. Oturum açmış bir yönetici hesabı herkesi tıkayan kuralları atlar ve durduğu kesin nokta tüm raporlardan değerlidir.
2. **Tarayıcı konsolunu açın** — Bir betik hatası, ekranda hiçbir mesaj göstermeden bir butonu devre dışı bırakır. Yanıt vermeyen onay butonunun en sık nedeni budur ve sunucu tarafında hiçbir iz bırakmaz.
3. **Sağlayıcının panosuna bakın** — Başarısız olanlar ve nedenleri dâhil alınan işlemleri listeler. Bir işlem orada varsa ama mağazada yoksa arıza bildirimdedir.
4. **Anahtarları ve kipi kontrol edin** — Test kipinde kalmış bir mağaza hiçbir tahsilat yapmaz. Canlıda test anahtarları ya da tersi, sistematik ret üretir.
5. **Görüntüleme kısıtlarını kontrol edin** — Teslimat ülkesi, para birimi, müşteri grubu, asgari tutar, seçilen kargo: her biri hiçbir hata mesajı olmadan bir ödeme yöntemini gizleyebilir.

## Siparişsiz tahsil edilen ödemeler görünmez

> Dönüş bildirimi başarısız olduğunda para çekilir ve sipariş mağazada görünmez kalır. Sağlayıcının işlem sayısını aynı günün sipariş sayısıyla karşılaştırmak bunu hızla saptamanın tek yoludur. Ödeme konusunda en ufak bir şüphe doğduğunda bu fark kontrol edilmelidir.

## Doğru sayfadan devam edin

- **PrestaShop'ta ödeme sorunu** — Modül modül, PrestaShop'a özgü nedenler. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement))
- **WooCommerce'de ödeme sorunu** — WordPress tarafındaki karşılığı ve kendine özgü noktaları. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement))
- **Ödeme webhook'u yapılandırmak** — Sorun teknik dönüş bildirimindeyse. ([/guides/configurer-webhook-paiement](/guides/configurer-webhook-paiement))
- **Ödeme geçidi nedir** — Bir işlemde her tarafın tam rolü. ([/glossaire/passerelle-de-paiement](/glossaire/passerelle-de-paiement))
- **Sipariş süreci nedir** — Standart adımlar ve her birinin geçmeden önce gerçekte neyi denetlediği. ([/glossaire/tunnel-de-commande](/glossaire/tunnel-de-commande))

## FAQ

### Sağlayıcım kendi tarafında her şeyin çalıştığını söylüyor, neye bakmalıyım?

Deneme işlemlerinin kaydında görünüp görünmediğini sorun. Görünmüyorsa istek mağazadan çıkmıyordur. Görünüyorsa sorun sitenize dönüştedir.

### Ödeme yöntemi bir güncellemeden sonra kayboldu, ilgili mi?

Büyük olasılıkla. Ödeme modülü sipariş sürecinin belirli noktalarına bağlanır; çekirdek güncellemesi bu noktaları kaldırabilir ya da yeniden adlandırabilir, modül de görünür bir hata vermeden görünmeyi bırakır.

### Modülü kaldırıp yeniden kurabilir miyim?

Önlem almadan risklidir: bazı modüller kaldırıldığında anahtarlar dâhil yapılandırmasını kaybeder. Önce ayarları not almak ve bir yedeğe sahip olmak gerekir.

### Tıkanan bir ödemeyi düzeltmek geliştirme gerektirir mi?

Nadiren. Vakaların çoğu yapılandırmadır: anahtarlar, kip, kısıtlar, bildirim adresi. Geliştirme, modül doğrudan kodundan değiştirilmişse devreye girer.

### Sipariş kaybedilip kaybedilmediğini nasıl anlarım?

Sağlayıcının işlemlerini aynı dönemde kaydedilen siparişlerle eşleştirerek. Karşılığı olmayan her işlem, ödeme yapıp hizmet almamış bir müşteridir.

### Müşterilerim buton çalışmıyor diyor, bende çalışıyor. Neden?

Çünkü tarayıcınız dosyaları zaten yüklemiştir ve oturum açmış bir yönetici hesabı aynı görüntüleme kurallarını ve kısıtlarını uygulamaz. Tıkanma yalnızca bilinmeyen bir ziyaretçinin gerçek koşullarında, çoğu zaman da yalnızca mobilde ortaya çıkar: kayan bir öğenin örttüğü buton, dokunmatik klavyeyle erişilemeyen bir alan, yüklenmesi bitmemiş ağır bir betik.