# Piyasadaki hiçbir çözüm uymadığında bir ödeme eklentisi

> Sanal cüzdan, alacak bakiyesi sistemi, kendi taksitli ödeme yöntemi: piyasadaki eklentiler ihtiyacı tam olarak karşılamadığında geliştirdiğim ödeme eklentisi türü budur.

- Source canonique : [https://allaux.fr/tr/expertises/module-paiement-sur-mesure-prestashop](https://allaux.fr/tr/expertises/module-paiement-sur-mesure-prestashop)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Tipik ihtiyaç

Piyasadaki ödeme eklentileri standart durumları iyi karşılar: banka kartı, PayPal, havale. Özel bir eklentiye ihtiyaç, ödeme mantığı bu klasik durumların dışına çıktığında ortaya çıkar: müşteri şirket tarafından beslenen bir sanal cüzdan sistemi, birden fazla siparişte kısmen kullanılabilen bir alacak bakiyesi mekanizması, işletmeye özgü kurallara sahip taksitli bir ödeme, ya da müzakere edilmiş koşullarına göre yalnızca belirli kurumsal hesaplara ayrılmış bir ödeme yöntemi. Bunlar, hiçbir genel eklentinin öngöremeyeceği özel ihtiyaçlardır.

## Bu tür bir ihtiyaca nasıl müdahale ediyorum

Bir ödeme eklentisi para ve sipariş onayıyla doğrudan ilgilidir: bir hatanın, karşılanmayan siparişler veya yanlış muhasebeleştirilen ödemeler şeklinde pahalıya mal olabileceği bir alandır. Her zaman ilgili ödemenin tüm yaşam döngüsünü net biçimde çerçevelemekle başlarım: tutar hangi anda rezerve edilir, tahsil edilir, iade edilebilir hale gelir ve buradan hangi sipariş durumları doğmalıdır.

Geliştirme, PrestaShop'un yerleşik ödeme sistemini atlamak yerine ona dayanır; böylece eklenti, ekosistemin geri kalanıyla (faturalama, iade yönetimi, istatistikler) uyumlu kalır. Uç durumların yönetimine özel önem verilir: işlem sırasında ödeme kesintiye uğrarsa, sepet onaylandıktan sonra bir cüzdanın bakiyesi yetersiz hale gelirse, ya da iki sipariş neredeyse aynı anda aynı alacak bakiyesini kullanmaya çalışırsa ne olur. Bu nadir durumlar, kötü yönetildiğinde istatistiksel olarak en pahalıya mal olan durumlardır.

## Fiyatlandırmayı etkileyen faktörler

- **İş mantığının karmaşıklığı** — Basitçe düşülen bir bakiye ile üst limitler, bağlı hesaplar veya otomatik atama kuralları içeren bir sistemin hiçbir ortak yanı yoktur.
- **Dış bir sistemle bağlantı** — Yönetim panelinden elle beslenen bir cüzdan, dış bir yönetim sistemiyle senkronize edilen bir bakiyeden daha basittir.
- **İzlenebilirlik gereksinimleri** — Muhasebe nedenleriyle istenen ayrıntılı bir hareket geçmişi, tasarım ve yönetim panelinde görüntüleme açısından ek bir iş yükü getirir.
- **Beklenen işlem hacmi** — Nadiren kullanılan bir mekanizma, ana ödeme kanalı olması hedeflenen bir ödeme yönteminden farklı şekilde ele alınır.

## Başlamadan önce sorulması gereken sorular

> Kısmi başarısızlık durumunda beklenen davranış tanımlanmış mı? Bir bakiyeyi kimler görüntüleyebilmeli veya değiştirebilmeli, hangi izlenebilirlikle? Eklentinin mevcut bir muhasebe sistemiyle uyumlu kalması gerekiyor mu?

## FAQ

### Özel bir ödeme eklentisi düzenleyici yükümlülüklerle uyumlu mu?

Eklenti, halihazırda mevcut olan ödeme yöntemlerinin (kart, havale) belirlediği çerçeveye entegre olur; onaylı bir banka ödeme geçidinin yerini asla almaz, ancak onun etrafında bir iş mantığı kurar.

### Sanal cüzdan klasik ödeme yöntemleriyle birleştirilebilir mi?

Evet, hatta en yaygın kullanım budur: öncelikle cüzdan bakiyesi kullanılır, kalan tutar kart ödemesiyle tamamlanır.

### Eklenti iadeleri nasıl yönetiyor?

İade süreci, tutarın cüzdana mı, alacak bakiyesine mi yoksa orijinal ödeme yöntemine mi döneceğine göre tutarlı bir mekanizmayla daha tasarım aşamasında çerçevelenir.

### Bu tür bir eklenti PrestaShop güncellemelerine dayanıklı mı?

Çekirdek üzerinde değişiklik yapmak yerine yerleşik hook'lara ve ödeme sistemine dayanarak, eklenti güncellemeler arasında uyumlu kalır; büyük sürüm geçişlerinde bir kontrol yapılması koşuluyla.