IdeaSoft sanal POS ve kargo entegrasyonunda iki ayrı kabul gerekir: paranın doğru işlemle eşleşmesi ve gönderimin doğru siparişe bağlanması. Panelde bağlantının görünmesi, tahsilat veya barkod sürecinin bütünüyle çalıştığını kanıtlamaz. Kuruluma sözleşme, erişim ve test sorumluluklarını belirleyerek başlayın.
Ödeme ve kargo bağlantılarını ortak sipariş kimliğiyle planlayın
IdeaSoft sanal POS ve kargo entegrasyonunda hedef yalnız bağlantı düğmesinin etkin görünmesi değildir. Müşterinin ödediği tutarın doğru siparişe bağlanması, doğru paketin hazırlanması ve hata halinde işlemin izlenebilmesi gerekir. Kurulum dosyasında her entegrasyonun hesap sahibi, ortamı, destek kanalı ve işlem sorumlusu ayrı yazılmalıdır.
Ödeme kuruluşu veya banka hesabının başvuru durumu, test/canlı bilgileri ve mağaza için gerekli erişimler net olmalıdır. Kargo tarafında anlaşma, entegrasyon hakkı ve barkodun hangi sistemden alınacağı belirlenmelidir. Gizli anahtarları açık doküman veya tarayıcı kodunda paylaşmayın.
9 Ekim 2026 tarihinde incelenen IdeaSoft siparişler yardım sayfası, kargo barkod süreçlerini kullanılan entegrasyona göre ayırıyor; bazı doğrudan bağlantılar ve üçüncü taraf uygulamalar için farklı satın alma yolları açıklıyor. Bu nedenle bütün kargoların her pakette ücretsiz olduğu varsayımı doğru değildir.
Yayına hazırlık dosyası nasıl tutulur?
Sağlayıcı adı, sözleşme kapsamı, kullanılacak mağaza veya müşteri numarasının nerede saklandığı ve test işleminin tarihi kaydedilebilir; gizli anahtarları ortak tabloya koymayın. Birden fazla mağaza varsa doğru hesabın bağlandığını ayrıca denetleyin. Test hesabının çalışması, canlı mağazanın aynı yetkiye sahip olduğunu göstermez. Değişiklik öncesinde mevcut ayarların güvenli yedeğini ve eski bağlantıya dönme sorumlusunu belirleyin.
Ödeme durumunu tarayıcının gördüğü sayfadan çıkarmayın
Ödeme sağlayıcısının güncel dokümanıyla bağlantı alanlarını doğrulayın. Eski ekran görüntüsündeki menü yolunu kalıcı talimat gibi kullanmayın. Test ortamı ve canlı ortamın birbirine karışmadığını, dönüş adreslerinin doğru alan adına gittiğini kontrol edin.
Başarılı işlemde tek sipariş ve doğru ödeme kaydı oluşmalıdır. Reddedilmiş ödeme mağazada başarılı görünmemelidir. Kullanıcının geri dönmesi veya aynı bildirimin tekrar gelmesi mükerrer sipariş oluşturmamalıdır. Kart bilgisini test notuna veya günlük kaydına gereksiz yere yazmayın.
İptal ve iade ayrı kabul senaryolarıdır
Siparişi panelden iptal etmenin ödeme tarafındaki etkisini mevcut bağlantıya göre öğrenin. Tam ve kısmi iade ihtiyacı varsa ayrı deneyin. Arayüzde durumun değişmesi, para hareketinin gerçekleştiğine dair tek kanıt değildir; sağlayıcı kaydıyla mutabakat yapın.
Müşteri ödeme sonunda tarayıcıyı kapatabilir; sağlayıcının sunucu bildirimi daha sonra ulaşabilir. Bu nedenle başarı sayfasının açılması tek başına finansal mutabakat değildir. Sipariş kaydı, sağlayıcı işlem kaydı ve tahsilat tutarı karşılaştırılmalıdır. Ödeme sayfasına geri dönmek de otomatik olarak işlemin başarısız olduğunu kanıtlamaz.
Gecikme ve tekrar bildirimini örnekleyin
Temsili testte aynı ödeme bildirimi iki kez gelir. Beklenen sonuç tek tahsilata karşı tek siparişin güncellenmesidir; yeni bir sipariş veya ikinci paket oluşması değildir. Başka bir testte tarayıcı hata gösterirken sağlayıcı başarılı işlem kaydeder. Operatör, müşteriye yeniden ödeme önermeden önce işlem kimliğiyle kontrol yapmalıdır. Bu senaryolar belirli bir IdeaSoft hesabında kusur bulunduğu iddiası değil, kabul kapsamıdır.
İptal, para iadesi ve sipariş durumunun değiştirilmesini aynı işlem sanmayın. IdeaSoft’un sipariş yardım belgesinde 9 Ekim 2026 tarihinde incelenen açıklama, panelde iade durumuna almanın kendiliğinden ödeme iadesi yapmadığını belirtir. Kullandığınız sağlayıcıdaki gerçek iade sonucunu kontrol edin; müşteriye para döndü bildirimi göndermeden önce işlem kanıtını kaydedin.
Kargo bedeli, paket ölçüsü ve müşteri vaadini eşleştirin
Desi, bölge, ödeme yöntemi ve ücretsiz kargo koşulları kullanılıyorsa sınır örneklerini test edin. İndirim öncesi ve sonrası sepet toplamının hangi kurala girdiğini belgeleyin. Ücretsiz kargo müşteriye ücretsiz olsa da işletme maliyetini ortadan kaldırmaz.
Birden çok ürün ve farklı teslimat adresleriyle kontrol yapın. Geçersiz veya hizmet dışı adres için anlaşılır hata gösterilmelidir. Kullanıcıya görünen teslimat bilgisi, işletmenin kargo anlaşmasına ve operasyon kapasitesine uygun olmalıdır.
Ücretsiz kargo sınırı varsa indirimin öncesindeki mi sonrasındaki mi tutara uygulandığını açıkça test edin. Sepete ikinci ürün eklenmesi paket sayısını veya hacmini değiştirebilir. Sepette gösterilen ücretin gerçek taşıyıcı faturasına eşit olması zorunlu değildir; işletmenin sübvansiyon kararı olabilir. Ancak bu fark bilinmeden her siparişin kârlı olduğu söylenemez.
Adres testinde ilçe seçimi, eksik telefon, hizmet dışı bölge ve uzun adres satırı gibi örnekler kullanın. Taşıyıcı hata verirse müşteriye yanlış takip numarası göstermeyin. Kargo sözleşmesindeki hizmet kapsamını, kurulum yapan ekibin teknik bağlantı kapsamından ayırın; panelde taşıyıcı adının görünmesi sözleşmenin etkinliğini tek başına doğrulamaz.
Barkod oluşturmayı gerçek taşıyıcı teslimiyle karıştırmayın
Test siparişini seçip barkod oluşturun; alıcı, adres, ürün ve gönderici bilgisini kontrol edin. Aynı işin yeniden denenmesinde yanlışlıkla ikinci gönderi açılmadığını inceleyin. Takip numarasının müşteri bildirimine doğru siparişle taşındığını doğrulayın.
Entegrasyon geçici hata verdiğinde manuel işleyiş ve sorumlu kişi belli olsun. Operasyon ekibinin hangi kayıtları tekrar deneyebileceğini açıklayın; körlemesine toplu tekrar, mükerrer gönderiye yol açabilir.
Barkod kaydı oluşturulmuş paket hâlâ depoda olabilir. Sipariş hazırlandı, etiket üretildi ve taşıyıcı teslim aldı durumlarının operasyon karşılıkları farklıdır. Müşteriye gönderilen metin bu farkı korumalıdır. Geçersiz veya henüz hareket görmeyen takip kaydında destek ekibi aynı açıklamayı kullanmalıdır.
Kesinti sırasında yeniden deneme nasıl yönetilir?
Temsili örnekte barkod isteği zaman aşımına uğrar fakat taşıyıcı kaydı oluşturmuştur. Kör biçimde yeni barkod üretmek yerine sipariş ve mevcut etiket kaydı araştırılır. Manuel etiket oluşturulursa numara siparişe işlenir ve otomatik kuyruğun aynı siparişi tekrar almaması sağlanır. Entegrasyonun hangi mekanizmayı sunduğu mevcut hesapta doğrulanmalıdır; burada belirli bir API alanının varlığı varsayılmıyor.
Teslimi ekran görüntüsüyle değil işlem dosyasıyla kabul edin
IdeaSoft kurulum çalışmasına ortam, kapsam, test kaydı ve erişim devrini ekleyin. Gerçek tahsilat ve gönderim kabulü yalnız yetkili canlı işlemlerle tamamlanabilir. Devam eden takip için operasyon kontrol rehberi yardımcıdır; bu yazı bağlantının hesabınızda kurulmuş olduğunu iddia etmez.
Kabul dosyasında test sipariş numarası, ödeme işlem referansı, tutar/para birimi, paket ve barkod referansı, bildirim sonucu ve sorumlu bulunmalıdır. Gerçek kart veya müşteri kişisel verisini açık rapora eklemeyin. Başarısız denemelerin sonucu da kayıtlı olmalıdır; yalnız başarılı ekranın saklanması hata yönetimini kanıtlamaz.
- Başarılı, reddedilen ve geciken ödeme ayrı denendi mi?
- Tekrarlanan bildirim ikinci sipariş oluşturmuyor mu?
- Kısmi veya tam iadenin finansal sonucu ayrıca kontrol edildi mi?
- Etiket üretimi ile taşıyıcıya teslim bildirimi ayrılıyor mu?
- Kesintide manuel işlem ve sonraki mutabakatın sorumlusu belli mi?
Kurulum sonrası ilk gerçek siparişler için kısa bir izleme dönemi planlayın. Bu dönem canlı ödemeyi test kaydı gibi göstermek için değil, sözleşme ve gerçek taşıyıcı akışının sahada beklenen biçimde çalıştığını yetkili ekipçe doğrulamak içindir.
İşlem istisnaları için karar ağacı oluşturun
Kısmi iade ile paket iptalini ayrı izleyin
Temsili siparişte iki üründen yalnız biri iade edilir. Finansal iade tutarı, geri gelen ürünün stok hareketi ve müşteriye gönderilen açıklama ayrı kayıtlardır. Tam siparişi iptal etmek, diğer ürünün teslim edildiği gerçeğini silebilir. Hangi işlemlerin panelden, hangilerinin sağlayıcıdan yürütülebildiği mevcut hesabın desteğiyle doğrulanmalıdır.
Başka bir örnekte ödeme tamamlanmıştır fakat stok sayımı ürünün bulunmadığını gösterir. Depo yeni barkod üretmeye devam etmeden sipariş istisnaya alınmalı; müşteri iletişimi ve gerçek para iadesi yetkili kişi tarafından yönetilmelidir. Teknik ekip, finans ekibi ve depo aynı sipariş numarasını kullanmazsa işlem iki kez yapılabilir. İstisna kaydında mevcut durum, yapılmış gerçek işlem, beklenen sonraki adım ve sorumlu bulunmalıdır. Ekrandaki durum adını değiştirmek sorunun çözüldüğüne dair yeterli kanıt değildir.
