Ödeme Mimarisi ve Sanal POS Entegrasyonu

Ödeme mimarisi nedir, ne zaman ayrıca ele alınmalı?

Ödeme mimarisi; ödemenin nasıl başlatıldığını, kart sahibinin nasıl doğrulandığını, sonucun sisteme nasıl ve hangi güvenceyle yazıldığını, iadenin ve muhasebe kaydının nasıl izlendiğini belirleyen yazılım yapısıdır. Tek bir ödeme düğmesinin arkasında sipariş, stok, fatura, bildirim ve raporlama sistemleri birlikte çalışır.

Hazır bir e-ticaret platformunun standart ödeme eklentisi çoğu basit mağaza için yeterlidir. Ödeme akışını ayrıca tasarlamak şu durumlarda gerekir:

• Abonelik, üyelik ya da kullanıma göre faturalama gibi tekrarlayan tahsilat modeliniz varsa.
• Birden fazla satıcının ürününü sattığınız bir pazar yeri ya da hizmet platformu işletiyorsanız.
• Ödeme web sitesinde, mobil uygulamada ve çağrı merkezinde aynı müşteri hesabı üzerinden alınıyorsa.
• Birden fazla banka ya da ödeme kuruluşuyla çalışıp maliyet ve onay oranına göre yönlendirme yapmak istiyorsanız.
• Mutabakat elle yapılıyor, iadeler e-postayla takip ediliyor ve muhasebe kayıtları tahsilatla tutmuyorsa.

UNIT İstanbul ödeme altyapısında neyi yapar, neyi yapmaz?

Ödeme hizmeti sunmak, kart verisi işlemek ve müşteri parasını tutmak Türkiye'de ve çalıştığımız diğer pazarlarda lisans gerektiren, düzenlenmiş işlerdir. UNIT İstanbul ödeme kuruluşu, elektronik para kuruluşu ya da banka değildir. Biz, bu lisanslara sahip kuruluşların sunduğu altyapıya bağlanan yazılımı tasarlıyor ve geliştiriyoruz.

İlgili ödeme mevzuatının işinize nasıl uygulandığı konusunda hukuki görüş vermiyoruz; bu soruları hukuk danışmanınızla ve çalışacağınız lisanslı kuruluşla netleştirmenizi öneriyoruz. Yazılım tarafında ise bu kararları teknik gereksinime çeviriyoruz.

Sanal POS entegrasyonu mu, ödeme kuruluşu mu?

Sanal POS, bankanın üye işyerine internetten kart kabul etmesi için verdiği hizmettir. Ödeme kuruluşları ise birçok bankanın ve ödeme yönteminin önüne tek bir arayüz koyar; başvuru ve entegrasyon daha hızlıdır ama komisyon ve kontrol dengesi farklıdır. Hangisinin uygun olduğu işlem hacminize, taksit ihtiyacınıza ve ekibinizin operasyon kapasitesine bağlıdır.

Hangi seçenekle başlarsanız başlayın, sağlayıcıya özgü kodu kendi iş mantığınızdan ayıran bir ödeme katmanı kuruyoruz. Böylece ileride sağlayıcı eklemek ya da değiştirmek, sipariş ve muhasebe kodunu yeniden yazmayı gerektirmez.

Kart sahibi doğrulaması (Three-Domain Secure) akışı nasıl kurulmalı?

Kart sahibi doğrulaması, bankanın ödemeyi onaylamadan önce kart sahibine tek kullanımlık kod ya da banka uygulaması onayı sorduğu adımdır ve yaygın olarak Three-Domain Secure adıyla bilinir. Kullanıcı bu adımda kısa süreliğine bankanın ekranına geçer; akış sağlam kurulmazsa sipariş, para çekildiği hâlde onaysız kalabilir.

1. 1.Ödemeden önce sipariş, benzersiz bir kimlik ve beklemede durumuyla kaydedilir.
2. 2.Ödeme isteği sunucudan başlatılır; tutar ve para birimi tarayıcıdan gelen veriye güvenilerek değil, sipariş kaydından alınır.
3. 3.Kullanıcı doğrulama ekranına yönlendirilir ya da ekran sayfanın içinde açılır; mobilde uygulamadan kopmadan tamamlanacak biçimde tasarlanır.
4. 4.Bankadan dönüşte sonuç, kullanıcının tarayıcısına değil sağlayıcıdan sunucuya yapılan doğrulama sorgusuna ya da imzalı bildirime dayanarak işlenir.
5. 5.Sipariş onaylanır, stok düşülür ve bildirimler gönderilir; kullanıcı dönüş sayfasını kapatsa bile bu adım sunucuda tamamlanır.

Kart saklama ve PCI DSS kapsamı nasıl küçültülür?

PCI DSS, kart verisini işleyen, ileten ya da saklayan her kuruluşun uyması gereken kart endüstrisi güvenlik standardıdır. Uyum yükünü azaltmanın en etkili yolu, kart numarasının sizin sunucularınıza hiç ulaşmamasıdır.

• Barındırılan ödeme alanları: Kart bilgisi, sağlayıcının sayfanıza gömdüğü güvenli alanlara ya da ödeme sayfasına girilir; sizin sisteminiz yalnızca bir anahtar (token) alır.
• Tokenizasyon: Kayıtlı kartla tekrar ödeme ve abonelik, kart numarası yerine sağlayıcının verdiği anahtarla yapılır.
• Güvenlik kodu saklanmaz: Kartın arkasındaki kod hiçbir koşulda veritabanına, loga ya da hata kaydına yazılmaz.
• Log maskeleme: İstek ve yanıt kayıtlarında kart, kimlik ve iletişim verileri otomatik olarak maskelenir.
• Erişim ayrımı: Ödeme servisinin anahtarları ayrı bir gizli değer deposunda tutulur, yetkiler kişi bazında verilir ve düzenli döndürülür.

Bu yaklaşım hangi PCI DSS öz değerlendirme formunun size uygulanacağını da etkiler; nihai değerlendirmeyi sağlayıcınızla ve gerekiyorsa yetkili bir denetçiyle birlikte yapmanızı öneriyoruz. Kişisel verilerin işlenmesi ve saklama süreleri KVKK aydınlatma metniyle uyumlu kurulur.

Abonelik, pazar yeri ve split ödemeler nasıl tasarlanır?

Abonelik ve tekrarlayan ödeme

Abonelikte asıl iş ilk tahsilattan sonra başlar. Yenileme takvimi, başarısız çekimde ne zaman ve kaç kez yeniden deneneceği, kartın süresi dolduğunda müşteriye nasıl haber verileceği, paket yükseltme ve düşürmede kalan sürenin nasıl hesaplanacağı yazılı kurallara bağlanmalıdır. Bu kurallar koddan bağımsız, yönetim panelinden değiştirilebilir biçimde tasarlandığında ürün ekibi geliştirici beklemeden fiyatlandırma deneyebilir.

Pazar yeri ve alt üye işyeri ödemeleri

Pazar yerinde müşteri tek ödeme yapar, tutar ise satıcılar, platform komisyonu ve kargo gibi kalemlere bölünür. Bu bölünmeyi ve satıcılara aktarımı lisanslı ödeme kuruluşunun alt üye işyeri altyapısı yürütür; yazılım tarafında satıcı kaydı, komisyon kuralları, hakediş takvimi, kısmi iade sonrası bölüşümün yeniden hesaplanması ve satıcı raporları kurulur. Satıcıya ödemeyi platformun kendi hesabından yapmak gibi lisans gerektirebilecek kurguları başlangıçta hukuk danışmanınızla netleştirmek gerekir.

İade, iptal ve mutabakat nasıl yönetilir?

İptal, gün sonu kapanmadan işlemin tamamen geri alınmasıdır; iade ise kapanmış bir işlemin tamamının ya da bir kısmının karta geri ödenmesidir. Ters ibraz ise kart sahibinin bankasına yaptığı itirazla başlar ve belge toplamayı gerektirir. Bu üç durum yazılımda ayrı durumlar olarak modellenmelidir.

Mutabakat, sizin sisteminizdeki ödeme kayıtlarının sağlayıcının raporlarıyla ve banka hesabına geçen tutarlarla karşılaştırılmasıdır. Sağlayıcı raporlarını otomatik çeken, eşleşmeyen kayıtları işaretleyen ve muhasebe ya da ERP sistemine kayıt aktaran bir mutabakat servisi, finans ekibinin elle yaptığı kontrolleri büyük ölçüde azaltır. Muhasebe ve ERP tarafındaki geniş kapsamlı entegrasyonları kurumsal yazılım çalışmalarımızla birlikte planlıyoruz.

Uygulama içi ödeme ve finansal akışlar nasıl entegre edilir?

Mobil uygulamada dijital içerik ve abonelik satıyorsanız uygulama mağazalarının kendi satın alma sistemlerini kullanma kuralları devreye girer; fiziksel ürün ve hizmet satışında ise kartla ödeme ya da dijital cüzdanlar kullanılabilir. Bu ayrımı ürün tasarımının başında yapmak, mağaza incelemesinde ret riskini azaltır. Uygulamanın geneline dair yaklaşımımızı mobil uygulama geliştirme sayfasında anlatıyoruz.

Hesap bilgisi görüntüleme, ödeme talimatı, yurt dışı para transferi ya da fatura ödeme gibi bankacılık işlevlerini uygulamanıza eklemek, lisanslı kuruluşların sunduğu açık bankacılık ve ödeme arayüzleriyle mümkündür. Bu entegrasyonlarda kullanıcı izni, oturum süresi, kur bilgisinin gösterimi ve işlemin hangi kuruluş tarafından yapıldığının açıkça belirtilmesi ekran tasarımının parçasıdır.

Ödeme hataları, zaman aşımları ve sahtecilik nasıl yönetilir?

Ödemede en tehlikeli durum, sonucu bilinmeyen işlemdir: istek gönderilmiş, yanıt zaman aşımına uğramıştır. Bu durumda ödemeyi körü körüne tekrarlamak çift çekime yol açabilir. Sağlam bir ödeme altyapısı şu ilkelerle kurulur:

• Her ödeme isteği tekrar güvenliği (idempotency) anahtarıyla gönderilir; aynı istek ikinci kez gelse de tek işlem oluşur.
• Ödeme durumları açık bir durum makinesiyle yönetilir; beklemede, onaylandı, reddedildi, iptal ve iade dışında ara durumlar tanımsız kalmaz.
• Sonucu belirsiz işlemler arka planda sağlayıcıya sorgulanır ve otomatik olarak doğru duruma çekilir.
• Sağlayıcı bildirimleri imzası doğrulanarak alınır, sırasız ya da tekrar gelen bildirimler güvenle işlenir.
• Sahtecilik önlemleri sağlayıcının risk motoruyla birlikte, sizin iş kurallarınızla (sık deneme sınırı, hesap yaşı, teslimat adresi tutarsızlığı) güçlendirilir.
• Onay oranı, red kodları, yanıt süreleri ve bildirim gecikmeleri izlenir; eşik aşıldığında ekip anında uyarılır.

Ödeme dönüşümü nasıl ölçülür ve iyileştirilir?

Ödeme ekranı bir huninin son adımıdır ve ayrıca ölçülmelidir. Ödeme sayfasına gelme, kart bilgisinin girilmesi, doğrulama ekranına geçiş, doğrulamadan dönüş ve onay ayrı olaylar olarak izlendiğinde kaybın nerede yaşandığı görünür. Bankanın red kodlarını kullanıcıya anlaşılır mesajlara çevirmek ve alternatif ödeme yöntemi önermek, kaybın bir kısmını geri kazandırabilir.

Pazarlama ajansı kökenimiz burada işe yarıyor: ödeme olaylarını reklam ve analitik ölçümüyle aynı dilde kuruyor, gelir verisinin kampanyalara doğru aktarılmasını baştan planlıyoruz. Huninin tamamındaki iyileştirmeleri CRO ve analitik ekibimizle birlikte yürütüyoruz; e-ticaret sitesinin geneli için web ve e-ticaret hizmetimize bakabilirsiniz.

Ödeme altyapısı projesinin maliyetini ne belirler?

Maliyeti en çok bağlanacak sağlayıcı sayısı, ödeme modeli (tek seferlik, abonelik, pazar yeri), kanal sayısı (web, mobil, çağrı merkezi), muhasebe ve ERP entegrasyonlarının derinliği ve mevcut sistemin durumu belirler. Sağlayıcının test ortamına erişim, üye işyeri onay süreci ve canlıya geçiş öncesi sağlayıcı testleri takvimi de etkiler. Keşif sonrasında kapsamı, teslimatları ve bakım koşullarını yazılı bir teklifte netleştiriyoruz. Diğer yazılım hizmetlerimizi ve referanslarımızı Unit Software sayfasında bulabilir, projenizi konuşmak için bize yazabilirsiniz.