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.
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.
Sıkça sorulan sorular
Özel bir ödeme eklentisi düzenleyici yükümlülüklerle uyumlu mu?
Sanal cüzdan klasik ödeme yöntemleriyle birleştirilebilir mi?
Eklenti iadeleri nasıl yönetiyor?
Bu tür bir eklenti PrestaShop güncellemelerine dayanıklı mı?
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.