Çoğu işletme sahibi, sipariş ile ödemenin birbirine bağlanmasını çözülmüş bir problem sanır. "Müşteri ödeme yapar, sistem siparişi bulur, kod gider; burada ne olabilir ki?" Ama e-pin satışında günlük yüzlerce işlem, birbirini kovalayan sekmeler, yarıda bırakılan ödemeler ve gecikmeli bildirimler devreye girdiğinde bu basit cümle dağılır. Panelde "ödeme var, sipariş yok" satırları birikmeye başlar ve destek ekibi günün yarısını elle eşleştirmeye harcar.
İşin ilginç tarafı, bu sorunun nedeni neredeyse hiçbir zaman ödeme sağlayıcısı değildir. Neden, senin tarafında kurulan referans mantığıdır. Bir epin satış scripti içinde sipariş ile ödeme arasındaki köprüyü hangi alan üzerinden kurduğun, o köprünün ne kadar tekil ve ne kadar değişmez olduğu her şeyi belirler. Bu yazıda o köprüyü, sahada onlarca kurulumda gördüğüm hatalarla birlikte sökeceğim ve sağlam kurgunun nasıl göründüğünü göstereceğim.
Köprüyü hangi alan üzerinden kuruyorsun? Sepet numarasıyla ödeme aynı şey değil
Eşleştirmenin temeli, ödeme sağlayıcısına gönderdiğin ve geri aldığın tek bir değişmez referanstır. Bu referansı sipariş kimliği yapmak ilk bakışta mantıklı görünür ama tehlikelidir: müşteri aynı sipariş için ödemeyi iptal eder, yeniden dener, üçüncü kez farklı yöntemle gider. Aynı referansla üç ayrı ödeme girişimi doğar ve sağlayıcı tarafında "bu referans zaten kullanıldı" hatası alırsın; ya da daha kötüsü, hangi girişimin başarılı olduğunu ayırt edemezsin.
Doğru kurguda iki katman vardır: sipariş ve ödeme girişimi. Referansı ödeme girişimi üretir, sipariş ise girişimin işaret ettiği hedeftir. Her yeni denemede yeni bir girişim kaydı, yeni bir referans açılır; sipariş aynı kalır. Böylece bir siparişin beş girişimi olabilir, ama yalnızca biri başarıya ulaşır ve hangisi olduğu tereddütsüz bilinir. Ciddi bir e-pin satış yazılımı bu iki katmanı ayrı tablolarda tutar.
Referansı nasıl üretmeli? Artan sayılar neden seni ifşa eder?
Referansı sıradan artan bir sayıdan üretmek iki sorun doğurur. Birincisi ticari: dışarıdan bakan biri günlük işlem hacmini kolayca tahmin eder. İkincisi teknik: farklı sunucularda ya da eşzamanlı isteklerde aynı sayıyı iki kez üretme riski vardır. Referansın taşıması gereken nitelikler nettir; tekil olmalı, tahmin edilemez olmalı, sağlayıcının kabul ettiği karakter ve uzunluk sınırına uymalı ve bir kez üretildikten sonra asla değişmemeli.
Pratikte işe yarayan yaklaşım, kısa bir ön ek ile rastgele bir gövdeyi birleştirmek ve bu değeri veritabanında benzersiz bir sütuna yazmaktır. Yazma işlemi başarısızsa yeniden üret. Bu tek satırlık kural, eşleştirme sorunlarının büyük kısmını doğmadan öldürür. Ayrıca referansı asla tarayıcıdan gelen veriye göre yeniden hesaplamaya çalışmamalısın; bir dijital ürün satış scripti içinde referans yalnızca sunucu tarafında doğar ve sadece okunur.
| Eşleştirme yöntemi | Çalışma mantığı | Zayıf noktası | Önerilir mi |
|---|---|---|---|
| Sipariş kimliği doğrudan referans | Sipariş numarası aynen gönderilir | Tekrar denemede çakışır | Hayır |
| Kullanıcı kimliği + tutar | İkili kombinasyonla bulunur | Aynı tutarda iki sipariş karışır | Hayır |
| Oturum anahtarı | Oturum üzerinden ilişkilendirilir | Oturum düşerse ödeme sahipsiz | Hayır |
| Girişim tablosu + tekil referans | Her deneme ayrı kayıt | Bir tablo daha yönetmek | Evet |
| Sağlayıcı işlem numarası ile çapraz kayıt | İki yönlü bağ kurulur | Kurulum disiplini gerektirir | Evet |
Aynı anda gelen iki istek: yarış durumu siparişini nasıl ikizler?
Müşteri ödeme ekranında "ödemeyi tamamla" düğmesine iki kez bastı. Ya da sağlayıcı bildirimi gönderdi, yanıt gecikti, tekrar gönderdi. İki istek neredeyse aynı milisaniyede sistemine ulaştı. Her ikisi de siparişi "beklemede" görür, her ikisi de "o zaman kapatayım" der ve iki kez stok düşer, iki kez kod teslim edilir. Bu, kod başına zarar demektir ve genelde aylar sonra stok sayımında fark edilir.
Çözümün adı kilitli tek hareket. Siparişi kapatan işlem, kaydı okurken aynı zamanda kilitlemeli ve tüm adımları (durum güncelleme, stok düşme, kod rezervasyonu, bakiye hareketi) tek bir veritabanı hareketi içinde bitirmeli. İkinci istek bu kilidi bekler, sırası geldiğinde siparişin artık kapalı olduğunu görür ve hiçbir şey yapmadan çıkar. Ek bir güvence olarak sağlayıcının işlem numarasını da benzersiz sütuna yazmayı dene; yazamıyorsan o bildirim daha önce işlenmiştir.
Sahipsiz kalan ödemelerin kök nedenleri
- Referans tekil değil veya yeniden kullanılmış 40%
- Ödeme girişimi kaydı hiç açılmamış 30%
- Oturum veya sepete bağlı eşleştirme 20%
- Gecikmiş bildirim, sipariş silinmiş 10%
Ödeme başlamadan kayıt açmıyorsan, sahipsiz ödemeyi zaten üretmiş oldun
En sık rastladığım tasarım hatası şudur: kullanıcı ödeme sayfasına yönlendirilir ama sistemde henüz hiçbir kayıt yoktur. Sipariş, bildirim geldiğinde oluşturulmaya çalışılır. Bildirimde eksik bir alan varsa, ürün o arada stoktan kalktıysa ya da fiyat değiştiyse sipariş oluşmaz; para hesapta, müşteri ortada kalır.
Doğru sıra tersidir: önce kayıt, sonra yönlendirme. Kullanıcı ödemeye gitmeden sipariş "ödeme bekliyor" durumunda yazılır, fiyat ve ürün bilgisi o anda dondurulur, ödeme girişimi ve referansı üretilir, ancak ondan sonra yönlendirme yapılır. Böylece hangi bildirim gelirse gelsin karşılığında mutlaka bir kayıt bulunur. Bu tek değişiklik, bir epin yazılım kurulumunda destek yükünü belirgin şekilde düşürür.
Sipariş kaydında ürünün o anki fiyatını ve para birimini ayrı sütunlara yaz. Ürün fiyatı sonradan değişse bile eşleştirme sağlam kalır; bildirimdeki tutarı karşılaştıracağın referans değer bu dondurulmuş fiyattır.
Gecikmiş bildirimi ne yapacaksın? Sipariş kapandıktan sonra gelen ödeme
Bildirim her zaman zamanında gelmez. Bazen sipariş zaman aşımına uğrayıp iptal edildikten dakikalar, hatta saatler sonra ulaşır. Burada iki yanlış refleks vardır: birincisi bildirimi sessizce çöpe atmak, ikincisi iptal edilmiş siparişi zorla yeniden açıp kod teslim etmek. İkisi de kötüdür; biri müşteriyi mağdur eder, diğeri stok ve muhasebe tutarsızlığı yaratır.
Sağlıklı yaklaşım, gecikmiş bildirimi ayrı bir durumda karşılamaktır: ödeme kaydı "tahsil edildi" olarak işlenir, sipariş ise "gecikmiş tahsilat, inceleme bekliyor" durumuna alınır ve yöneticiye bildirim gider. Stok hâlâ varsa tek tuşla teslim edilir; yoksa müşteriye bakiye olarak yansıtılır veya iade başlatılır. Karar insanda kalır ama hiçbir para izsiz kaybolmaz. Pinova'nın sipariş akışında bu durumlar hazır tanımlıdır; özellik listesinde tüm sipariş durumlarını görebilirsin.
Mutabakat: her gece sorulması gereken beş soru
Eşleştirme mantığı ne kadar iyi olsa da, günü kapatırken sağlayıcı raporuyla kendi kayıtlarını karşılaştırmayan hiçbir sistem güvenilir değildir. Aşağıdaki kontrol listesini günlük ya da haftalık otomatik bir işe bağla; farkı sabah kahvenle birlikte gör.
| # | Mutabakat kontrolü | Nasıl bakılır | Fark varsa aksiyon |
|---|---|---|---|
| 1 | Sağlayıcı tahsilatı = sistem tahsilatı | Günlük toplam tutar karşılaştırması | İşlem bazlı karşılaştırmaya in |
| 2 | Her tahsilatın bir siparişi var | Sahipsiz ödeme sorgusu | Referanstan sipariş bul, eşle |
| 3 | Her kapalı siparişin tahsilatı var | Ödemesiz kapalı sipariş sorgusu | Elle kapatma kaydını denetle |
| 4 | Teslim edilen kod sayısı = satılan adet | Stok hareket dökümü | Çift teslim izini ara |
| 5 | İade ve iptaller iki tarafta aynı | İade listesi karşılaştırması | Muhasebe kaydını düzelt |
| 6 | Beklemede kalan sipariş sayısı normal | Süre aşımı eşiğiyle karşılaştır | Ödeme akışında darboğaz ara |
| 7 | Girişim/başarı oranı istikrarlı | Son 7 günün eğilimi | Ani düşüşte sağlayıcıyla konuş |
Eşleştirmeyi baştan doğru kurulmuş bir altyapıyla çöz
Pinova; ödeme girişimi katmanı, tekil referans üretimi, kilitli sipariş kapatma ve günlük mutabakat ekranlarıyla gelen lisanslı bir dijital ürün satış yazılımıdır.
Sipariş numarasını referans olarak kullanmak neden sakıncalı?
Çünkü bir sipariş için birden fazla ödeme denemesi olabilir. Aynı referansla ikinci deneme yapıldığında sağlayıcı çakışma verir veya hangi denemenin başarılı olduğu belirsizleşir.
Sahipsiz ödemeyi nasıl bulup eşleştirebilirim?
Sağlayıcı panelindeki işlem numarası ve referansla kendi kayıtlarını tara. Referans varsa girişim kaydı bulunur ve sipariş oradan erişilir; referans hiç üretilmemişse tutar, saat ve müşteri bilgisiyle elle eşleştirilir.
Aynı sipariş iki kez teslim edildiyse ne yapmalıyım?
Önce stok hareketinden çift teslimi doğrula, ardından sipariş kapatma akışına kilit ve tekillik kontrolü ekle. Düzeltmeden önce nedeni bulmazsan olay tekrarlar.
Mutabakatı otomatikleştirmek mümkün mü?
Evet. Sağlayıcının rapor ucu varsa günlük tahsilat listesi çekilip kendi kayıtlarınla karşılaştırılabilir; fark oluştuğunda yöneticiye bildirim gönderilir.
Sipariş ile ödemeyi birbirine bağlayan mantık, dışarıdan görünmeyen ama işletmenin sinir sistemi olan katmandır. Bu katmanı kendi başına kurmak yerine hazır ve sahada denenmiş bir kurguyla yola çıkmak istiyorsan, sipariş durumlarını ve ödeme girişim kayıtlarını canlı demo ekranlarında inceleyebilir, sana uygun sürümü paket sayfasından seçebilirsin.