Global Bir Ödeme Geçidi Projesi Oluştururken Nelere Dikkat Etmek Gerekir?

Dijitalleşmenin artması ile birlikte insanların kullandıkları ödeme yöntemleri de hızlı şekilde değişmeye başladı. Önce kağıt paranın yerini kredi kartları, sonrasında da mobil uygulamalar ve dijital cüzdanlar almaya başladı. Bundan dolayı da ödeme sektörü de sürekli kendini yenilemek ve bu hızlı değişime ayak uydurmak zorunda kaldı.

Bu yazıda sizlere, servislerimize ait, yaklaşık 200 ülkedeki milyonlarca kullanıcımızdan tahsilat yaparken öğrendiğimiz deneyimlerimizden önemli olduklarını düşündüklerimi anlatmaya çalışacağım.

Kısaca servislerimizden bahsetmem gerekirse abonelik seçenekleri sunan, kullanıcılardan belirlediğimiz periyotlarda ücretlendirme yapan, her ülkeye özel ve o ülkenin para biriminde tahsilatlar yaptığımız mobil uygulamalar ya da web projeleridir.

Bu yazının konu başlıkları ağırlıklı olarak geliştirme ve marketing konularını kapsayacaktır.

Konu başlıklarımız kısaca:

• Ürün Geliştirme Süreçleri
• Fraud Yönetimi — Anomaly Detection
• Farklı Ödeme Servisleri İle Çalışma — Ödemenin Lokalleştirilmesi

Ürün Geliştirme Süreçleri

Bir ödeme servisine başlarken, bu servisin diğer projelere nazaran mümkün olduğu kadar patlamayacak şekilde dizayn edilmesi en önemli konuların başında gelir. Özellikle Saas bir servis olarak başka müşterilere de hizmet verecekseniz, 1 dk’lık bir kesinti bile müşteri + güven kaybına neden olabilir. O yüzden henüz tek satır kod yazmadan vermeniz gereken kritik kararlar vardır. Bunlardan kısaca bahsetmem gerekirse:

Programlama Dili

Hangi proje olursa olsun projenin yazılacağı programlama diline karar vermek çok önemlidir. Özellikle bir ödeme projesinde çok farklı PSP’ler ile entegrasyon olacağını varsayarsak çalışacağınız PSP’ler kullanacağınız dile SDK desteği sunuyor mu, kullandığınız dil geliştirme konusunda sizi hızlandırıyor mu, proje güvenliğinde problemler oluşturur mu, hızlı aksiyon almanız gereken durumlarda sizi yavaşlatıyor mu gibi çok farklı sorular karşınıza çıkacaktır. O yüzden öncelikle bu soruların cevabını çıkarıp sonra yazılım diline karar vermek önemlidir.

Ayrıca ödeme servislerinin çok hızlı büyüyebileceği de göz önüne alınarak ilerleyen süreçlerde performans, support desteği de önemli olan bir dil seçilmelidir.

Büyüme — Ölçeklendirilebilme

Biz ödeme sistemini canlıya çıktıktan sonra onu kısa süre de olsa kapatıp kaynakları arttırma — ayarlama gibi şansınız çok fazla olmayacaktır. Çünkü ödeme sistemleri askeri tabirle radar sistemleri gibi sürekli çalışmak ve gelen ödeme isteğini karşılamak zorundadır. Cevap veremediğiniz süreçte kaçırdığınız müşteri hem size hem de sizinle çalışan müşterilerinize ciddi problemler doğurabilir. O yüzden ödeme sistemleri projesini henüz canlıya ilk çıkıldığı andan itibaren zero-downtime ile genişletilebilecek planlamak çok önemlidir. Burada AWS, Google Cloud, Azure gibi cloud sistemleri kullanabilir ya da kendiniz bunların sunduğu servisleri kaşılayacak mimariler oluşturabilirsiniz.

Not: Biz daha çok AWS olmak üzere bazı Google Cloud ürünlerini de kullanıyoruz. Zero-downtime destek verebilmek için projelerimizi kubernetes üzerinde çalıştırıyoruz. Burada hem Aws EKS, hem de Google Cloud — GKE kullanıyoruz.

Loglama — Hata Yakalama

Bir ödeme servisinde loglama ve doğru log kullanımı en az projenin geliştirilmesi süreçleri kadar önemlidir. Çünkü bu servisler çok fazla third-party sistem ile entegre çalışırken aynı zamanda yaptığı entegrasyon süreçlerinde tahsilatlar yapılmaktadır.

Bir PSP’de sorun yaşanması durumunda, ödeme alındıktan sonra veritabanına yazılamaması durumu gibi tüm kritik durumlar loglanmalı ve bu loglar log analiz araçları ile analiz edilerek alarmlar üretilmelidir.

Biz projelerimizde ileride ihtiyacımız olacağını düşündüğüm tüm olayları loglayıp bunları Graylog’a aktarıyoruz. Belirlediğimiz kurallara göre alarmlar üreterek anlık bir hata, durum oluştuğunda bundan anında haberimiz oluyor.

Bir PSP çöktüğünde bazen PSP’den önce bizim haberimiz oluyor. Onlarla iletişme geçtiğimizde hata yok dedikten 2 dk sonra evet hata varmış dönüşü alıyoruz 😃

Güvenlik

Tüm yazılım projelerinde güvenlik önemlidir. Ancak bir ödeme projesinde çok çok önemlidir. O yüzden bir yazılım projesi geliştirilirken güvenlik ile ilgili tüm süreçler dikkatle planlanmalı ve uygulanmalıdır. Burada müşteri bilgilerinin saklanması, veritabanı güvenliği, kod, account güvenliği gibi servisinize özel durumlar olabilir.

Dışarıdan bir güvenlik taraması yaptırmak ve sizin de gözden kaçırabileceğiniz durumlar olabileceğini düşünerek projenize PCI-DSS sertifikası alabilir, sertifikasyon sürecinde projenizin güvenliğinden emin olabilirsiniz.

PCI DSS

Kredi Kartı Sektörü Veri Güvenliği Standardı (PCI DSS); American Express, Discover Financial Services, JCB International, MasterCard Worldwide ve Visa Inc. tarafından kurulan PCI Güvenlik Standartları Konseyi tarafından yönetilen tescilli bilgi güvenliği standardıdır.

PCI DSS, tüccarlar, işleyiciler, alıcı bankalar, verenler ve hizmet sağlayıcıları da dâhil olmak üzere kart sahibi verilerini (CHD) veya hassas kimlik doğrulama verilerini (SAD) depolayan, işleyen veya ileten kuruluşlar için geçerlidir. PCI DSS, kart markaları tarafından zorunlu kılınır ve Kredi Kartı Sektörü Güvenlik Standartları Konseyi tarafından yönetilir.

Rollback

Ödeme servislerinin olmazsa olmazı rollback mekanizmalarıdır. Bir durum gerçekleşmediğinde ya da hatalı gerçekleştiğinde daha önceden belirlenen senaryolara göre farklı bir kural çalıştırma, geriye dönük işlemleri iptal etmeye rollback denebilir.

Örnek senaryo olarak, bir kullanıcıdan ödeme çekmeye çalışırken PSP’den cevap alamadığınızı düşünelim. Böyle bir durumda PSP ödemeyi çekip size cevap dönemediyse sizin bunun takibini yapmanız gerekir. Bu yüzden böyle bir durumda bunun takibini yapacak rollback kuralını çalıştırmanız gerekir.

Yine ödemeyi çektiğinizi ancak o anda sizin servislerinizin patladığını ödemeyi veritabanına yazamadığını ve müşterinize ödeme sonucunu iletemediğinizi düşünelim. Bu durumda da belirlenecek senaryolara göre rollback kuralları çalıştırılmalıdır. Bu servisinizin özelliğine göre müşteriye anlık iade olabileceği gibi, bu işlemlerin farklı bir durumda loglanarak sistemler düzeldikten sonra ana kural içerisinde tekrardan işlenmesi olabilir.

Bizim sistemlerimizde akışı etkileyecek tüm durumlar için farklı senaryolar bulunmaktadır. Müşteri bazında istediğimiz rollback senaryolarını çalıştırabiliyoruz. Örneğin bazı müşterilerde hata durumunda otomatik iade, bazılarında ise işlemler farklı şekilde saklanıp sistem düzeldikten sonra aksiyonlar alınabilmektedir.

Fraud Yönetimi — Anomaly Detection

Fraud

Eskiden (hatta Somali’de falan devam ediyor) insanlar illegal yollardan para kazanmak için korsanlık yaparmış ve gemilere saldırıp malları yağmalarmış. Günümüzde dijital dünyada artık gemilerle olmasa bile farklı yöntemlerle sanal korsanlık yapılıyor.

Özellikle kredi kartlarının ele geçirilmesi dikkatli olunmadığı durumlarda çok kolay. Bu yüzden bir ödeme sistemi yazarken çalıntı kartlarla sizin sisteminizden işlem geçirmemeye çalışmak çok kritik. Çünkü çalıntı kart ile yapılan her işlem size chargeback olarak dönecek, aynı zamanda hukuki olarak da başınıza işler açılabilecektir.

Bunu önlemek için kendi in-house bir fraud sistemi yazarak kendi sisteminizden geçen işlemlerin analizini yapabilir ve riskli işlemleri engelleyebilirsiniz. İşlem sayısı arttıkça fraud sisteminiz daha sağlıklı sonuçlar üretmeye başlayacaktır.

Kendi fraud servisinize ek ödeme sistemleri için fraud desteği veren ürünler de bulunmaktadır. Bu ürünleri de kullanarak işlem risklerini minimuma indirebilirsiniz.

Kendi fraud servisinizi yazarken şu konulara dikkat edebilirsiniz.

1. Kurallarınızı belirlerken genel kuralların dışında her müşterinize özel kurallar da ekleyebilmelisiniz. Böylece riskli müşterilerinize daha sert kurallar girerek işlem riskini düşürebilirsiniz.
2. Kuralların ülke bazında esnek olması önemli. Örneğin ip adresi engellediğinizi düşünelim. Bazı ülkelerde bir ip adresi aynı gün içinde milyonlarca kişiye atanabiliyor Bu gibi durumlarda ciddi satış kaybedebilirsiniz.
3. Endonezya, Rusya gibi çalıntı kartlarla çok fazla işlem denenen ülkeleri gruplayarak bunlara özel daha sert kurallar oluşturabilirsiniz.
4. Kurallarınızı tamamen engelleyici, belirli bir süre engelleyici, işlemi engellemeyen ama manuel kontrole düşüren şekilde gruplayarak az riskli işlemlerde ödemeyi çekip sonradan manuel kontrol edebilirsiniz. Ya da kullanıcının bir süre sonra ödeme yapmazına izin verebilirsiniz.

Anomaly Detection

Ödeme sistemleri kullanılmaya başladıktan sonra içerideki durumlara göre içerde patternler oluşmaya başlacaktır. Bu patternleri kullanarak olası riskli işlemleri önceden analiz edebilir ve engelleyebilirsiniz. Bunun için de gelen tüm request, response ve ödeme bilgilerinin düzenli şekilde saklanması gereklidir.

Örneğin bir ülke özelinde saatlik olarak gelebilecek request oranları bellidir. Ya da bir servisin günlük — saatlik ortalama satış adetleri bellidir. Bu oranların altında ya da üstünde bir işlem olduğunda anormal bir durum olabilir.

Ya da hiç request gelmeyen bir ülkeden bir anda çok fazla request gelmeye başlaması, bir ip adresinden olağan dışı istek gelmeye başlaması olağan dışı durumlardır.

İşte bu gibi öneden belirlenecek patternler, anomaly detection modelleri ile beslenerek sistemde ortaya çıkacak anormalliklerin anında önüne geçilebilir ya da bilgi sahibi olunabilir. O yüzden bir ödeme sisteminizde size özel ve sizin kurallarınıza göre çalışacak bir anomaly detection olması çok kritik bir konudur.

Farklı Ödeme Servisleri İle Çalışma — Ödemenin Lokalleştirilmesi

Esi çağlarda insanlar takas yöntemi ile alış veriş yapıyordu. Buğdayı veren yağını şekerini alıp işlemi tamamlıyordu. Sonrasında paranın icadı ile takas yöntemi para ile alışverişe döndü. Ancak dijital çağda artık kağıt paraların da bir anlamı kalmadı.

Kredi kartları ile beraber dijital dünyada ödemelerin çoğu bu kartlarla gerçekleştiriliyor. Online ödeme almak için ödeme hizmeti veren PSP’ler ile anlaşarak tahsilat yapabiliyorsunuz.

Sizin de bir PSP gibi çalışacağınızı düşünürsek ödeme almak için bir PSP ile anlaşmanız gerekiyor. Burada sorunlar ortaya çıkmaya başlıyor. Eğer tek bir PSP ile çalışıyor iseniz PSP tarafında bir problem olduğunda tüm sisteminiz etkilenecektir. Ondan dolayı her zaman en az 1 yedek PSP ile de sistemi çalışabilecek halde tutmak çok kritik.

Ayrıca hedef pazarda bir PSP ile anlaşıp onun üzerinden o pazarda ödeme almak yararınıza olacaktır. Çünkü global PSP’lerin fraud kuralları bazı ülkeler için çok sert olabilmekte. O yüzden o ülkeden bir PSP üzerinden tahsilat yaparak başarı oranlarını arttırabilirsiniz.

Ayrıca günümüzde artık kredi kartlarının kullanımının da kağıt paralar gibi neredeyse sıfırlandığı ülkeler mevcut. Eğer bu ülkelerden birisi sizin hedef pazarınız ise orada en çok kullanılan ödeme yöntemini de sisteminizin desteklemesi çok önemli.

Örneğin Endonezya’da kredi kartı kullanımı çok düşüktür. Orada insanlar daha çok sanal cüzdanlar üzerinden ödemelerini gerçekleştiriyor. Sizin pazarınız bu ülke ise ve siz bu cüzdanları desteklemiyorsanız satış anlamında büyük gelir kaybı yaşayabilirsininiz.

Bir de mümkün olduğunda hedef ülkelerin para biriminde tahsilatı desteklemeniz önemli. Bazı ülkeler bu konularda çok hassas. Örneğin Türkiye’de insanlara TRY fiyatı değil USD gösterip bunun üzerinden bir ürün satmaya çalıştığınızı düşünün. İnsanlar USD gördüğünde satın alma işleminden vazgeçecektir.

Bu konu ile ilgili Teknasyon Tech Day’23 etkinliğinde yaptığım sunumu da buraya ekliyorum:

Buraya kadar sabırla okuduğunuz için teşekkür ederim. Soru ve farklı durumlar için bana aşağıdaki linklerden ulaşabilirsiniz.

Linkedin: https://www.linkedin.com/in/beytullah/
Twitter: https://twitter.com/beytullah