Bir mağaza, müşterinin seçtiği ürünü hemen raftan alıp gönderemeyebilir. Ürün kişiye göre hazırlanıyor, belirli malzemeler siparişle temin ediliyor ya da üretim başlamadan önce iş planı oluşturuluyorsa işletme başlangıçta bir tutar alıp kalan bedeli daha sonra isteyebilir. Bu düzen müşteriye açık anlatılmadığında, ödeme sayfasındaki tutar toplam fiyat sanılabilir; işletme de üretime başlama, kalan tutarı isteme ve sevkiyata izin verme adımlarını farklı kayıtlarla takip eder. E-ticaret sitesinde ön ödeme, üretim ve kalan tutar tek bir belirsiz “ödendi” etiketi altında bırakılmamalıdır. Bu rehber, siparişin hangi aşamada hangi tutarla ilerlediğini görünür kılan bir akış kurmaya odaklanıyor. Buradaki örnekler geneldir; Sarıyer’deki herhangi bir işletme, mağaza veya satış uygulaması hakkında iddia içermez.

Önce satış kuralını ve üretim başlangıcını tanımlayın

Tek bir ürünün siparişinde bile “ön ödeme” farklı anlamlara gelebilir. Bir işletme üretim kapasitesini ayırmak için ilk tutarı alabilir; başka bir işletme özel malzeme siparişini ancak ödeme doğrulandıktan sonra verebilir. İlk iş, müşteriden hangi kararı istediğinizi ve üretim ekibinin hangi kanıtı beklediğini yazmaktır. Ön ödeme oranını ezbere belirlemek yerine işletme; maliyet, tedarik, işçilik ve kendi satış koşulları üzerinden karar vermelidir. Sitenin görevi ticari koşulu uydurmak değil, işletmenin onayladığı koşulu doğru yerde göstermektir.

Bu akış, her müşteriye özel fiyat teklifi oluşturmakla aynı değildir. Önce miktar, ölçü veya kapsam netleşip ardından müşteriye teklif sunuluyorsa teklif hazırlama ve onay adımları siparişten önce gelir. Bu tür bir sürecin siparişe nasıl bağlandığını kişisel sipariş teklifi rehberinde bulabilirsiniz. Buradaki konu, kabul edilmiş satış koşullarında toplam tutarın birden fazla ödeme anına bölünmesi ve her tahsilatın üretim ile sevkiyat kararına nasıl bağlandığıdır.

Ödeme planını ürün sayfasında ve sipariş özetinde açıklayın

Müşteri ödeme adımına geldiğinde yalnız bugün ödeyeceği rakamı değil, toplam bedeli ve kalan tutarın ne zaman isteneceğini de görmelidir. “Sipariş onayında şu tutar, üretim tamamlandığında kalan tutar” gibi bir açıklama, iki ödemenin hangi olaya bağlandığını anlatır. Vade veya teslim takvimi işletme tarafından henüz belirlenmemişse ekranda kesin gün sözü vermeyin; belirsizliğin hangi bilgi netleşince giderileceğini açıklayın. Vergi, gönderim veya ilave iş bedeli gibi kalemler varsa bunların hesaba nasıl katılacağını işletme belirlemeli ve müşteri toplamı görmeden onay vermemelidir.

Ödeme planını yalnızca küçük bir dipnotta göstermek, sepet özetinde ilk tutarı toplam gibi sunmak veya kalan tutarı siparişten sonra sürpriz olarak bildirmek güveni zedeler. Ürün sayfası, sepet, sipariş onayı ve daha sonra gönderilen ödeme bildirimi aynı tanımları kullanmalıdır. Ön ödeme “alındı” olarak görünüyorsa bunun siparişin tamamının ödendiği anlamına gelmediği; kalan tutarın açık olduğu belirtilmelidir. İşletmenin tahsilat ve faturalama koşulları hukuki veya muhasebesel değerlendirme gerektiriyorsa, bu kararlar ilgili uzmanlarla netleştirilmeli; tasarım metni onların yerine geçmemelidir.

Sipariş kaydında tutarları ve hareketleri birbirinden ayırın

Tek bir “ödeme durumu” alanı bu tür siparişleri açıklamak için yetersiz kalabilir. Sipariş kaydında toplam bedel, ödenen tutar, kalan tutar, planlanan ödeme aşaması ve her tahsilatın sonucu ayrı izlenmelidir. Her ödeme hareketi ilgili siparişe bağlanmalı; hangi aşama için başlatıldığı, ne zaman denendiği, hangi sonuçla kapandığı ve gerektiğinde hangi işlem numarasıyla doğrulandığı görülebilmelidir. Böylece destek çalışanı müşterinin gönderdiği ekran görüntüsüne bakıp siparişin tamamını ödendi varsaymak zorunda kalmaz.

Yeni tahsilat isteği oluşturmakla ödeme sağlayıcısından kesinleşmiş sonuç almak aynı olay değildir. Ağ gecikmesi, kullanıcının sayfayı yenilemesi veya bildirimin birden fazla işlenmesi gibi durumlarda sistem aynı tutarı iki kere kaydetmemelidir. Uygulamanın hangi olayları nasıl tekrar denediği seçilen altyapı ve ödeme kuruluşunun güncel belgeleriyle doğrulanmalıdır; bu yazı hiçbir sağlayıcının ortak veya değişmez davranışını varsaymaz. Başarılı yanıt, sipariş durumu ve ödeme kayıtlarının neden ayrı tutulduğunu ödeme entegrasyonu rehberi daha ayrıntılı ele alıyor.

İşletme havale veya başka bir manuel yöntem kabul ediyorsa, müşterinin bildirdiği transfer ile hesaba gerçekten yansıyan hareketi ayrı tutun. Kayıtta tutar, tarih, sipariş ve kontrolü yapan sorumlu bulunabilir; ekran görüntüsü tek başına tahsilat teyidi yerine geçmemelidir. Böylece otomatik ödeme ile elle kontrol edilen ödeme aynı sürecin içinde izlenirken kanıt ve sorumluluk kaybolmaz.

Üretim ve tahsilat durumlarına ayrı adlar verin

Üretim durumu ile ödeme durumu tek bir çizelgeye sıkıştırılırsa ekipler siparişin nerede beklediğini yanlış anlayabilir. Üretim; hazırlık bekliyor, malzeme ayrıldı, iş başladı, kalite kontrolünde veya paketlemeye hazır gibi işletmenin gerçek adımlarını anlatabilir. Ödeme tarafında ise ilk tutar bekleniyor, ilk tutar doğrulandı, kalan tutar istendi, kalan ödeme bekleniyor ve toplam tahsilat doğrulandı gibi durumlar bulunabilir. Her mağaza aynı aşamaları kullanmak zorunda değildir. Ama hangi durumun hangi gerçek olayla başlayıp biteceği önceden kararlaştırılmalıdır.

Sevkiyata geçiş için hangi koşulların gerektiği de işletme kuralıdır. Örneğin bazı ürünler son kontrol tamamlanınca, bazıları da son tutar doğrulanınca paketlemeye geçebilir. Bu kural müşteriye önceden açıklanmalı ve yönetim ekranında da aynı sırayla gösterilmelidir. Son ödemenin istendiğini görmek, ödemenin alındığını kanıtlamaz; ödeme beklerken kargo etiketi oluşturmak veya “yola çıktı” mesajı göndermek de doğru değildir. Üretim adımı tamamlanmış fakat ödeme sonucu henüz teyit edilmemişse, ekip hem hangi işi tamamladığını hem de siparişin neden beklediğini ayrı görebilmelidir.

Değişiklik, gecikme ve iptal durumlarında iz bırakın

Üretim başladıktan sonra müşteri ölçü, renk veya kapsam değişikliği isteyebilir. Bu istek fiyatı ve kalan tutarı etkiliyorsa eski ödeme planını sessizce değiştirmeyin. Önce değişiklik talebini alın, yeni kapsamı ve tutarı işletme içinde doğrulayın, müşteriye güncel özeti sunun ve onaydan sonra sipariş kaydının yeni sürümünü oluşturun. Eski toplamın üzerine yalnızca yeni rakamı yazmak, hangi bedelin hangi karara dayandığını kaybettirir. Sipariş özeti, önceki ve yeni koşulları yetkili çalışanların ayırt edebileceği biçimde korumalıdır.

Üretim gecikmesi, tedarik sorunu veya siparişten vazgeçme isteğinde de müşterinin talebi, işletmenin kararı, ödeme kuruluşundaki işlem ve geri ödeme durumu birbirine karıştırılmamalıdır. Her olay için geçerli politika işletme ve ilgili uzmanlarca belirlenir; bu rehber yasal hak, süre veya otomatik iade kuralı tarif etmez. Ödeme sonrası tam iptal ve stok rezervinin nasıl ele alınabileceği için sipariş iptali rehberine bakın. Buradaki dar fark, iptalden önce üretim ve kalan ödeme aşamasında hangi kayıtların güncel tutulacağıdır.

Müşteriye sadece gerçekleşen aşamayı bildirin

Bildirim metni, sipariş durumuyla aynı gerçeği anlatmalıdır. “Ön ödeme talebiniz alındı” ile “ön ödeme doğrulandı” ayrı mesajlardır; “üretim tamamlandı” da kalan bedelin tahsil edildiği anlamına gelmez. Müşteriye her mesajda toplam tutarın ne kadarının ödendiğini, hangi aşamanın sırada olduğunu ve beklenen sonraki hareketin kimden geldiğini sade bir dille göstermek yardımcı olur. Yeni bir ödeme isteği oluşturulduğunda bağlantının hangi siparişe ait olduğu ve tutarın neden istendiği de açık olmalıdır.

Çalışanların ekranında görünen bilgi ile müşterinin aldığı e-posta veya sayfa özeti çelişirse, destek ekibi doğru durumu elle araştırmak zorunda kalır. E-posta bildirimi tek başına ödeme kanıtı değildir; sipariş ve tahsilat kayıtlarının son durumu esas alınmalıdır. Durum sözlüğünü az sayıda, herkesin anlayacağı adla kurun; “hazır” gibi hem üretim hem ödeme için kullanılabilecek belirsiz ifadeleri ayırın. Bildirimin gönderilememesi, tekrar gönderilmesi veya yanlış adrese yönelmesi ihtimallerini de yayından önce kontrollü örneklerde deneyin.

Uçtan uca kabul testinde istisnaları da deneyin

İlk deneme, tüm ödemelerin sorunsuz tamamlandığı tek bir siparişle sınırlı kalmamalıdır. Bir testte ilk ödeme beklemede kalsın; başka birinde onaylanmış tutar doğru siparişe bağlansın; bir diğerinde kalan tutar yanlış veya eksik olsun. Müşterinin ikinci kez düğmeye basması, ödeme yanıtının geç gelmesi, sipariş tutarının onaylı değişiklikle güncellenmesi ve üretimin tamamlanıp son tutarın beklemesi gibi durumlarda hem müşteri ekranını hem ekip kaydını inceleyin. Her senaryoda hangi olayın ödeme, üretim ve sevkiyat durumunu değiştirmesi gerektiğini önceden yazın.

Canlıya geçmeden önce test siparişlerinin gerçek müşteriye bildirim göndermediğini, gerçek üretimi veya kargoyu başlatmadığını ve deneme tahsilatlarının işletme kayıtlarına yanlışlıkla girmediğini doğrulayın. Testi tamamlayan kişi yalnızca “sayfa açıldı” notu bırakmasın; hangi sipariş kimliğiyle hangi sonucu gördüğünü ve düzeltilmesi gereken noktayı kaydetsin. Kabul ölçütleri, satın alma denemesi, ödeme sonucu ve sipariş hazırlığını birlikte kontrol eden e-ticaret yayın testi rehberindeki yaklaşım gibi tekrarlanabilir olmalıdır. Proje kapsamı için e-ticaret yazılımı ve entegrasyon hizmetini inceleyebilirsiniz.

Sık Sorulan Sorular

Ön ödeme alınca sipariş tamamen ödenmiş sayılır mı?

Hayır; siparişin toplam tutarı ile o ana kadar doğrulanmış tahsilat farklı bilgilerdir. Ekran ve bildirim, ilk tutarın alındığını, kalan miktarı ve bir sonraki ödeme koşulunu ayrı göstermelidir. İşletmenin muhasebe ve satış kayıtları da aynı ayrımı korumalıdır.

Kalan tutar hangi aşamada müşteriden istenmeli?

Bu, ürünün gerçek üretim ve teslim işine göre işletmenin belirleyeceği bir kuraldır. Malzeme temini, üretim başlangıcı, kalite kontrolü veya sevkiyat öncesi gibi olaylardan hangisinin tetikleyici olduğu önceden yazılmalı; müşteri sipariş vermeden bu koşulu görebilmelidir.

İlk ödeme oranı için hazır bir yüzde kullanabilir miyim?

Tek bir oran bütün ürün, maliyet ve teslim koşullarına uymaz. Oran ve zamanlama işletmenin onaylı ticari koşullarından çıkarılmalı, ödeme sağlayıcısının ve seçilen altyapının bunu destekleyip desteklemediği güncel belgelerden doğrulanmalıdır. Bu içerik oran veya finansal tavsiye vermez.

Ödeme sayfasındaki başarılı mesaj üretime başlamak için yeterli midir?

Başarı mesajının neyi doğruladığını ayrıca kontrol edin. Sipariş kaydı, sağlayıcı işlem sonucu ve işletmenin tahsilat kuralı aynı anlama gelmeyebilir. Üretime geçiş için gereken kesin olay işletme ve yazılım ekibi tarafından belirlenmeli; yalnız tarayıcıda görünen metne dayanılmamalıdır.

Müşteri ürün kapsamını değiştirmek isterse kalan tutar nasıl güncellenir?

Önce talep kaydedilir; yeni ürün kapsamı, tutar ve teslim koşulu işletme tarafından doğrulanır. Müşteriye yeni sipariş özeti sunulur ve onay geldikten sonra ödeme planı sürümlenir. Eski koşulların kaydı korunmalı, ödenen para yeni toplamla karıştırılmamalıdır.

Üretim bittiğinde kalan ödeme henüz gelmediyse ne gösterilmelidir?

Üretimin tamamlandığı ve tahsilatın beklediği ayrı durumlar olarak gösterilmelidir. Müşteriye sıradaki adım ve sevkiyat koşulu açıklanabilir; ancak ödeme doğrulanmadan teslimat başladı veya tamamlandı izlenimi verilmemelidir. İşletmenin onayladığı istisna kuralı varsa ayrıca belirtilmelidir.

İptal ya da geri ödeme isteği bu akışta nasıl ele alınır?

Talebin alındığını, kararın verildiğini ve ödeme kuruluşundaki hareketin tamamlandığını ayrı kaydedin. Geçerli politika, süre ve tutar için işletmenin yetkili uzmanlarına başvurun; bir isteği otomatik olarak onaylandı ya da geri ödendi saymayın. Müşteriye yalnızca gerçekleşmiş aşamayı bildirin.

Bu akışı yayından önce nasıl sınayabilirim?

Bekleyen ilk ödeme, doğrulanmış ilk tutar, üretim tamamlanması, kalan ödeme ve sevkiyat öncesi kontrol içeren test senaryoları hazırlayın. Tekrar tıklama ve geç yanıtı da deneyin. Her adımda müşteri görünümünü, ekip kaydını ve bildirimleri birlikte kontrol edip bulguları kaydedin.