Mobil Uygulamada Kartla Ödeme Nasıl Alınır? Ürün ve Hizmet İçin Rehber

Bu yazıda Talha Aslan ve ekibi olarak bu akışı uçtan uca anlatıyoruz. Özellikle yemek siparişi, giyim, kargo, temizlik ya da kurye gibi gerçek dünyada tüketilen işler satıyorsanız rehber tam size göre. Kısaca yol haritası şöyle:

1. Sattığınız şeyin fiziksel ürün veya hizmet mi, yoksa dijital içerik mi olduğunu netleştirin.
2. Bir ödeme kuruluşu ya da banka sanal POS'u seçin ve üye işyeri sözleşmesini tamamlayın.
3. Ödeme kuruluşunun mobil SDK'sını uygulamaya, gizli anahtarları ise yalnız sunucuya ekleyin.
4. 3D Secure, kart saklama ve iade akışlarını test ortamında tek tek deneyin.
5. Apple Pay ve Google Pay gibi cüzdanları ikinci adımda ekleyin.
6. Mağaza incelemesine ödeme akışını açıklayan notlarla gönderin.

Fiziksel ürün ve hizmette neden mağaza içi satın alma kullanmazsınız?

Apple ve Google, uygulamanın dışında tüketilen ürün ve hizmetler için kendi faturalandırma sistemlerini kullanmanızı istemez. Hatta Apple tarafında durum bir tercih değil, kuraldır. App Store İnceleme Yönergeleri 3.1.3(e) maddesi, uygulama dışında tüketilen fiziksel ürün veya hizmet satışında mağaza içi satın alma dışında bir yöntem kullanmanızı ister. Örnek olarak da Apple Pay ve klasik kart girişini sayar.

Google tarafı da benzer. Google Play Ödemeler politikası, fiziksel ürün satışında ve ulaşım, temizlik, yemek teslimatı ya da etkinlik bileti gibi fiziksel hizmetlerde Play faturalandırma sisteminin kullanılmaması gerektiğini açıkça yazar. Yani market siparişi alan bir uygulama Play faturalandırmasıyla ödeme alırsa kuralı çiğner.

Bu ayrım, işletmeniz için önemli bir avantaj da sağlar. Fiziksel ürün ve hizmet satışında mağaza komisyonu devreye girmez; ödeme kuruluşu ile kendi anlaştığınız koşullar geçerli olur. Ancak bu serbestlik, kart güvenliği sorumluluğunu da size ve seçtiğiniz ödeme kuruluşuna yükler. Yazının geri kalanı tam olarak bu sorumluluğu nasıl yöneteceğinizi anlatıyor.

Hangi durumda mağaza içi satın alma zorunlu olur?

Kural basit bir soruya dayanır: Kullanıcı satın aldığı şeyi uygulamanın içinde mi tüketiyor? Abonelikle açılan premium özellikler, oyun içi para birimi, kilitli içerik ya da reklamsız sürüm dijital içeriktir. Apple yönergelerinin 3.1.1 maddesi bu tür kilit açmalar için mağaza içi satın almayı şart koşar. Google Play politikası da dijital özellik ve içerikte kendi faturalandırma sistemini ister; bazı ülkelerdeki alternatif faturalandırma programları ise ayrı başvuru gerektirir.

Bu konunun komisyon ve web ödeme tarafını uygulama içi satın alma mı, web ödeme mi yazımızda ayrıntılı anlattık; burada tekrar etmiyoruz. Dijital abonelik kurgulamayı düşünüyorsanız uygulamada abonelik modeli rehberimiz daha uygun bir başlangıç olur.

Ara bölgede kalan bir durum daha var. Apple, iki kişi arasında gerçek zamanlı verilen birebir hizmetlerde, örneğin özel ders ya da kişisel antrenmanda, mağaza içi satın alma dışında yöntem kullanmanıza izin verir. Öte yandan bir eğitmenin aynı anda birçok kişiye verdiği canlı ders için mağaza içi satın alma gerekir. Bu nedenle hizmetinizi tanımlarken "kaç kişiye ve nerede sunuyorum" sorusunu mutlaka yanıtlayın.

Hangi satış türünde hangi ödeme yolu doğru?

Aşağıdaki tablo, sahada en sık karşılaştığımız satış türlerini resmi kurallarla eşleştiriyor. Tablo bir karar yardımcısıdır; sınırda kalan bir modeliniz varsa güncel kuralı mutlaka resmi yönergelerden kontrol edin.

Tabloda dikkat çeken nokta şu: Aynı uygulama iki modeli birlikte taşıyabilir. Örneğin bir kafe uygulaması kahve siparişini kartla, uygulama içindeki reklamsız deneyimi ise mağaza içi satın almayla satabilir. Böyle bir karma yapıda iki akışı kod ve arayüz düzeyinde net ayırmanız gerekir.

Sanal POS ile ödeme kuruluşu arasındaki fark nedir?

Sanal POS, bir bankanın size internet üzerinden kart çekimi için açtığı üye işyeri hesabıdır. Ödeme kuruluşu ise birden çok bankayla çalışan, size tek bir arayüz ve genellikle hazır mobil SDK sunan lisanslı aracı kurumdur. İkisi de mobil uygulamada kartla ödeme almanızı sağlar; fark, entegrasyon kolaylığı ve operasyon yükündedir.

• Banka sanal POS'u: Doğrudan bankayla sözleşme yaparsınız. Mobil SDK sunmayan bankalarda ödeme sayfası ya da web görünümü üzerinden ilerlersiniz.
• Ödeme kuruluşu: Kart saklama, taksit gösterimi, iade ve pazar yeri gibi özellikleri hazır sunar. Mobil SDK desteği çoğunlukla daha olgundur.
• Ortak nokta: İkisinde de kart verisi sizin sunucunuza değil, sağlayıcının güvenli altyapısına gider.

Hangi sağlayıcının işletmenize uyduğunu belirleyen kriterleri sanal POS ve online ödeme altyapısı seçimi yazımızda karşılaştırdık. Mobil uygulama açısından ek olarak şunu sorun: Sağlayıcının iOS ve Android için güncel ve iyi belgesi olan bir SDK'sı var mı? Kullandığınız çatıya, örneğin React Native veya Flutter'a, resmi ya da bakımı süren bir paket sunuyor mu?

Ödeme kuruluşu SDK'sı uygulamanın içinde nasıl çalışır?

SDK (yazılım geliştirme kiti), ödeme kuruluşunun uygulamanıza eklediğiniz hazır kod paketidir. Kart formunu, 3D Secure ekranını ve kartın sağlayıcıya şifreli gönderimini bu paket yönetir. Böylece kart numarası sizin kodunuzdan ve sunucunuzdan geçmez. Tipik akış şu sırayla ilerler:

1. Kullanıcı sepeti onaylar; uygulama, sipariş bilgisini kendi sunucunuza gönderir.
2. Sunucunuz tutarı veritabanındaki fiyatlardan yeniden hesaplar ve ödeme kuruluşunda bir ödeme oturumu başlatır.
3. Sağlayıcı, uygulamanın kullanacağı tek kullanımlık bir oturum anahtarı döner.
4. Uygulama bu anahtarla SDK'nın kart formunu açar; kullanıcı kartını girer.
5. Gerekirse 3D Secure doğrulaması çalışır ve SDK sonucu sağlayıcıya gönderir.
6. Sağlayıcı, ödeme sonucunu sunucunuza ayrıca bildirir; siparişi ancak bu bildirimle onaylarsınız.

Bu yapıda iki taraf da bir API (uygulama programlama arayüzü) üzerinden konuşur. Kavramı yeni duyuyorsanız API nedir yazımız arka planı sade bir dille anlatıyor. En kritik kural ise şudur: Ödeme kuruluşunun gizli anahtarı asla uygulama paketine girmez. Uygulama dosyası kullanıcının telefonuna iner ve çözümlenebilir; bu yüzden gizli anahtar yalnız sunucuda durur.

Kart formu uygulamanın içinde mi, ödeme sayfasında mı olmalı?

Mobil uygulamada kartla ödeme için üç temel yöntem var. Hangisini seçtiğiniz hem kullanıcı deneyimini hem de güvenlik sorumluluğunuzu doğrudan etkiler. Aşağıdaki karşılaştırma kararınızı kolaylaştırır.

Biz projelerin büyük çoğunluğunda ilk satırı öneriyoruz. Sağlayıcı SDK sunmuyorsa ikinci yol da güvenli bir seçenektir; ancak web görünümünden uygulamaya dönüşü dikkatle kurmanız gerekir. Kart numarasını kendi formunuzla toplayıp kendi sunucunuza göndermek, sizi kart verisi işleyen kurum konumuna sokar. Bu da PCI uyumu tarafında çok daha büyük bir yük demektir.

3D Secure mobil uygulamada nasıl işler?

3D Secure, kart sahibinin kimliğini kartı çıkaran banka adına doğrulayan ek güvenlik adımıdır. Kullanıcı çoğunlukla bankanın gönderdiği tek kullanımlık kodu girer ya da bankacılık uygulamasından onay verir. Mobil uygulamada bu adımı ya SDK'nın kendi ekranı ya da bankanın doğrulama sayfasını açan bir web görünümü yönetir.

Uygulama tarafında en sık yaşanan sorunlar teknik değil, akış kaynaklıdır:

• Kullanıcı kodu almak için SMS uygulamasına geçer, geri döndüğünde ödeme ekranı sıfırlanmıştır.
• Kullanıcı banka uygulamasında onay verir ama uygulamanız sonucu dinlemediği için sipariş "beklemede" kalır.
• Doğrulama ekranı küçük telefonlarda taşar ve onay düğmesi görünmez.
• Bağlantı zaman aşımına düşer; kullanıcı ikinci kez dener ve iki ayrı ödeme girişimi oluşur.

Bu yüzden 3D Secure ekranından dönüşü sağlam kurmalısınız. Ayrıca sipariş durumunu yalnız uygulamanın gördüğü sonuca değil, sunucuya gelen bildirime bağlamalısınız. Kullanıcı tarafında doğrulama hiç tamamlanmıyorsa nedenleri 3D Secure doğrulaması başarısız yazımızda adım adım ele aldık.

Kart saklama ve tokenizasyon ne anlama gelir?

Tokenizasyon, kart numarasının yerine o karta işaret eden ve tek başına bir işe yaramayan bir referans değer (token) kullanmaktır. Kullanıcı "kartımı kaydet" dediğinde kart bilgisini ödeme kuruluşu saklar ve size yalnız bu token'ı döner. Siz de bir sonraki siparişte kart numarası yerine token'ı gönderirsiniz.

Bu yaklaşımın işletmeye faydası büyüktür. Veritabanınız ele geçirilse bile saldırgan kart numarasına ulaşamaz; çünkü token yalnız sizin üye işyeri hesabınızla ve sağlayıcının sisteminde anlam taşır. Öte yandan kullanıcı her siparişte kartını yeniden yazmak zorunda kalmaz; bu da özellikle sık sipariş veren müşterilerde ödeme adımını ciddi biçimde kısaltır.

Ekranda kullanıcıya gösterdiğiniz bilgi de sınırlı olmalıdır. Genellikle kart markası, son dört hane ve kullanıcının verdiği kart adı yeterlidir. Kartın güvenlik kodunu ise ne uygulamada ne sunucuda saklarsınız. Kayıtlı kartla yapılan ödemede bankanın kuralına göre yeniden 3D Secure ya da güvenlik kodu istenebileceğini akışınızda hesaba katın.

Kayıtlı kartla tek dokunuşla ödeme kurarken nelere dikkat etmelisiniz?

Tek dokunuşla ödeme, dönüşümü artıran güçlü bir özelliktir; ama kötü kurgulanırsa güveni hızla zedeler. Sahada en çok işe yarayan kurallar şunlar:

• Kartı kaydetme seçeneğini varsayılan olarak işaretli getirmeyin; kullanıcı kendisi seçsin.
• Kayıtlı kartları listeleyen ve tek dokunuşla silen bir ekran ekleyin.
• Hesap silindiğinde sağlayıcıdaki kayıtlı kart referanslarını da silin.
• Uygulama açılışında biyometrik kilit gibi ek bir onay katmanını değerlendirin.
• Ödeme onayından önce tutarı, teslimat ücretini ve teslim süresini tek ekranda gösterin.

Kart saklamak kişisel veri işlemek anlamına da gelir. Aydınlatma metni, açık rıza gerektiren durumlar ve izin ekranları için mobil uygulamada KVKK uyumu yazımıza göz atabilirsiniz. Not: Bu bölüm hukuki danışmanlık değildir; metinlerinizi bir hukukçuyla birlikte son haline getirin.

Mobil uygulamada kartla ödemeye Apple Pay ve Google Pay nasıl eklenir?

Apple Pay ve Google Pay, kullanıcının cüzdanında kayıtlı kartla, kart numarası yazmadan ödeme yapmasını sağlar. Önemli bir ayrıntı şu: Cüzdanlar kendi başına bir sanal POS değildir. Ödeme yine sizin ödeme kuruluşunuz üzerinden geçer; cüzdan yalnız kart bilgisini şifreli ve tokenize biçimde taşır.

Apple, Apple Pay geliştirici sayfasında bu yöntemle müşterinizin gerçek kart numarasını almadığınızı açıkça belirtir. Google Pay tarafında ise entegrasyon tipini seçersiniz. Google Pay API başvuru belgelerine göre ödeme geçidi (gateway) tipinde token doğrudan ödeme kuruluşunuza gider. Kartın şifresini kendi sunucunuzda çözdüğünüz doğrudan tip ise PCI DSS uyumunu ve bunun yetkili bir denetçi tarafından doğrulanmasını şart koşar.

Pratikte ilk iş, ödeme kuruluşunuzun iki cüzdanı da desteklediğini teyit etmektir. Ardından Apple geliştirici hesabında işyeri kimliği ve sertifika adımlarını, Google tarafında da sağlayıcının yönlendirdiği yapılandırmayı tamamlarsınız. Kullanıcı açısından ise sonuç çok net: Daha az form, daha az yazım hatası ve genellikle daha hızlı bir ödeme ekranı.

Apple Pay kullanırken mağaza kuralları neyi şart koşar?

Apple yönergelerinin 4.9 maddesi Apple Pay kullanan uygulamalar için net beklentiler koyar. Satıştan önce tüm temel satın alma bilgisini kullanıcıya göstermeniz ve Apple Pay marka öğelerini resmi tasarım kurallarına uygun kullanmanız gerekir. Düğmeyi kendi renginize boyamak ya da logoyu değiştirmek bu yüzden red sebebi olabilir.

Tekrarlayan ödeme alıyorsanız, örneğin haftalık temizlik hizmeti ya da aylık kahve çekirdeği gönderimi gibi, kurallar daha da belirginleşir. Apple bu durumda en az şunları açıkça göstermenizi ister:

• Yenileme süresinin uzunluğu ve iptal edilene kadar devam ettiği.
• Her dönemde kullanıcıya ne sunulacağı.
• Kullanıcının gerçekte ödeyeceği tutar.
• Aboneliğin nasıl iptal edileceği.

Bu bilgiler aynı zamanda iyi bir kullanıcı deneyiminin de parçasıdır. Dolayısıyla Apple Pay kullanmasanız bile tekrarlayan kart çekimlerinde aynı şeffaflığı kart formunuzda da uygulamanızı öneriyoruz.

PCI uyumu sizin için ne anlama gelir?

PCI DSS, kart verisini saklayan, işleyen ya da ileten kuruluşların uyması gereken teknik ve operasyonel güvenlik gereksinimlerini tanımlayan standarttır. Standardı kart markalarının kurduğu PCI Security Standards Council yayımlar. Kapsam, kart verisi ortamının güvenliğini etkileyebilecek sistemleri de içine alır.

Mobil uygulamada kartla ödeme kuran bir işletme için iyi haber şu: Doğru mimariyle kapsamınızı ciddi ölçüde daraltırsınız. Kart numarası yalnız sağlayıcının SDK'sından veya ödeme sayfasından geçiyorsa, sizin sistemleriniz kart verisine hiç dokunmaz. Yine de sorumluluğunuz sıfırlanmaz; uygulamanın ve sunucunun güvenliği, gizli anahtarların korunması ve sağlayıcının istediği uyum beyanları sizde kalır.

Bu nedenle sözleşme aşamasında ödeme kuruluşunuza şu soruları sorun: Bizim entegrasyon tipimizde hangi uyum belgesini doldurmamız gerekiyor? Yıllık bir doğrulama istiyor musunuz? Hangi durumda kapsamımız genişler? Uyum gereklilikleri değişebildiği için güncel yükümlülüğünüzü her zaman sağlayıcınızdan ve resmi standarttan teyit edin.

Mobil uygulamada kartla ödeme için sunucuda hangi kontroller gerekir?

Ödeme akışının en kırılgan yeri çoğu zaman uygulama değil, onu yöneten sunucudur. Telefon kullanıcının elindedir ve uygulamanın gönderdiği her değer değiştirilebilir. Bu yüzden şu kontrolleri sunucunuzda kurmanızı öneriyoruz:

1. Tutarı sunucu hesaplar: Uygulamadan gelen fiyatı asla doğru kabul etmeyin; ürün ve teslimat ücretini veritabanından yeniden toplayın.
2. Tek sipariş, tek ödeme: Her ödeme girişimine benzersiz bir sipariş numarası verin; böylece çift dokunuş çift çekime dönüşmez.
3. Sonuç bildirimiyle onay: Siparişi, sağlayıcının sunucunuza gönderdiği bildirimi doğruladıktan sonra "ödendi" yaparsınız.
4. Kayıt tutma: Kart verisi olmadan; tutar, zaman, sipariş numarası ve sağlayıcı yanıt kodunu kaydedin.
5. Anahtar yönetimi: Test ve canlı anahtarları ayrı tutun, düzenli aralıklarla yenileyin.

Örneğin bir kullanıcı ödeme sırasında bağlantısını kaybederse uygulama sonucu göremez. Ancak sunucunuz bildirimi almıştır ve uygulama yeniden açıldığında siparişi doğru durumda gösterir. Böylece müşteri hizmetlerine gelen "param çekildi, sipariş görünmüyor" şikâyetlerinin büyük kısmını baştan önlersiniz.

İade, iptal ve kısmi tutarı nasıl yönetirsiniz?

Fiziksel ürün ve hizmet satışında iade kaçınılmazdır. Sipariş eksik gelir, kurye geç kalır ya da müşteri randevuyu iptal eder. Bu yüzden ödeme akışını tasarlarken iadeyi baştan düşünmelisiniz. Aksi halde her iade, panelden elle yapılan ve hata riski taşıyan bir işe dönüşür.

Ödeme kuruluşlarının çoğu tam iade ve kısmi iadeyi API üzerinden destekler. Bazı sağlayıcılar ayrıca tutarı önce bloke edip sonra kesinleştirme (ön provizyon) imkânı sunar. Örnek senaryo: Bir market uygulaması sepet tutarını bloke eder, toplama sırasında eksik çıkan ürünleri düşer ve yalnız gerçek tutarı çeker. Bu özelliğin varlığını ve koşullarını sağlayıcınızın belgelerinden kontrol edin.

Kullanıcı tarafında ise iadenin ne zaman hesaba yansıyacağı sorusu öne çıkar. Bu süre bankaya göre değişir; o yüzden uygulamada kesin gün vermek yerine "bankanıza bağlı olarak birkaç iş günü sürebilir" gibi dürüst bir ifade kullanmanızı öneriyoruz. İade durumunu sipariş ekranında görünür kılmak, destek yükünü de belirgin biçimde azaltır.

Ödeme ekranında dönüşümü en çok ne düşürür?

Teknik altyapı kusursuz olsa bile ödeme ekranı kullanıcıyı kaybettirebilir. Mobilde ekran küçüktür, dikkat dağınıktır ve her fazladan alan bir vazgeçme fırsatıdır. Sahada en sık gördüğümüz hatalar şunlar:

• Üyelik zorunluluğu: Kullanıcı ödeme yapmak için önce uzun bir kayıt formu doldurmak zorunda kalır.
• Sürpriz maliyet: Teslimat ücreti ya da hizmet bedeli son adımda ortaya çıkar.
• Yanlış klavye: Kart numarası alanında sayısal klavye açılmaz.
• Belirsiz hata mesajı: "İşlem başarısız" yazar ama kullanıcı ne yapacağını bilmez.
• Güven eksikliği: Kart formunun yanında işletme adı, iade koşulu ya da iletişim bilgisi görünmez.

Bu hataların çoğu web sitelerinde de aynıdır; ayrıntılı çözüm önerilerini sepet terk oranı nasıl düşürülür yazımızda bulabilirsiniz. Mobil uygulamaya özgü fark ise cüzdan ödemeleridir. Apple Pay ve Google Pay düğmesini sepetin hemen altında sunmak, kart formunu birçok kullanıcı için tamamen ortadan kaldırır.

Ödeme almaya başlamadan önce hangi hesap ve belgeler gerekir?

Kod yazmaya başlamadan önce idari tarafı yoluna koymanız takvimi ciddi biçimde kısaltır. Ödeme kuruluşları ve bankalar üye işyeri başvurusunda işletmenizi, sattığınız ürünü ve satış koşullarınızı inceler. İstenen belgelerin listesi sağlayıcıya göre değişir; bu yüzden güncel listeyi doğrudan sağlayıcınızdan alın. Sahada genellikle şu hazırlıklar işe yarar:

• Şirket bilgileri ve faaliyet alanınızı gösteren resmi belgeler.
• Uygulamada ve web sitenizde erişilebilir satış koşulları, iade politikası ve iletişim bilgileri.
• Satacağınız ürün veya hizmetin açık bir tanımı ve örnek ekran görüntüleri.
• Apple ve Google geliştirici hesaplarının işletme adına açılmış olması.

Son madde sık atlanır. Mağazada satıcı olarak görünen ad ile ödeme kuruluşundaki işletme adının tutarlı olması, hem kullanıcı güvenini hem de inceleme sürecini olumlu etkiler. Ayrıca kart ekstresinde görünen işletme adını kullanıcının tanıyacağı biçimde ayarlamak, "bu çekimi tanımıyorum" itirazlarını azaltır. Kısacası belge tarafını erken toplarsanız geliştirme bittiğinde canlıya geçiş için beklemezsiniz.

Mobil uygulamada kartla ödeme için canlı öncesi hangi testler şart?

Ödeme kuruluşlarının neredeyse tamamı bir test ortamı (sandbox) ve test kartları sunar. Bu ortamda gerçek para hareket etmez; tüm senaryoları güvenle deneyebilirsiniz. Biz yayın öncesinde şu kontrol listesini kullanıyoruz:

1. Başarılı ödeme, yetersiz bakiye ve reddedilen kart senaryolarını ayrı ayrı deneyin.
2. 3D Secure ekranında doğru kod, yanlış kod ve zaman aşımını test edin.
3. Ödeme sırasında uygulamayı arka plana atın, interneti kesin ve geri dönün.
4. Kart kaydetme, kayıtlı kartla ödeme ve kart silme akışlarını deneyin.
5. Tam iade ve kısmi iadenin sipariş ekranına doğru yansıdığını kontrol edin.
6. Apple Pay ve Google Pay'i gerçek cihazda, test kartıyla deneyin.
7. Canlıya geçerken anahtarların doğru ortama ait olduğunu iki kişi kontrol etsin.

Son madde basit gibi durur; ancak canlıda test anahtarıyla kalan uygulama ödeme alamaz ve bu hata genellikle ilk siparişlerde fark edilir. Ayrıca canlıya ilk geçişte küçük tutarlı bir gerçek sipariş verip ardından iade etmek, zinciri uçtan uca doğrulamanın en pratik yoludur.

Mağaza incelemesinde ödeme akışı yüzünden red almamak için ne yapmalısınız?

Mağaza inceleme ekipleri uygulamanızı gerçek bir kullanıcı gibi gezer. Ödeme ekranına ulaşamazlarsa ya da sattığınız şeyin fiziksel olduğunu anlayamazlarsa sorular ve gecikmeler başlar. Bu yüzden inceleme notlarını özenle hazırlamalısınız.

• İnceleme notunda sattığınız şeyin uygulama dışında tüketilen fiziksel ürün veya hizmet olduğunu açıkça yazın.
• Giriş gerektiren uygulamalarda çalışan bir demo hesap bilgisi verin.
• Dijital bir özellik satıyorsanız onu mağaza içi satın almayla sunduğunuzdan emin olun.
• Uygulama içinde dijital içerik için dış ödeme sayfasına yönlendiren bir bağlantı bırakmayın.

Karma modelli uygulamalarda en sık sorun, dijital bir avantajın, örneğin ücretli üyeliğe bağlı indirimlerin, kartla satılmasıdır. Böyle bir kurguda üyeliğin içeriğini ve tüketildiği yeri net tanımlamanız gerekir. Emin değilseniz kuralı yorumlamak yerine resmi yönergelerdeki ilgili maddeyi okuyup modeli ona göre tasarlayın.

E-ticaret siteniz varken ayrıca uygulamada ödeme almaya değer mi?

Zaten bir e-ticaret siteniz varsa ilk soru, uygulamanın kendisinin gerekli olup olmadığıdır. Bu kararı sipariş sıklığı, sadakat programı ve bildirim ihtiyacı gibi kriterlerle e-ticaret sitesine mobil uygulama gerekli mi yazımızda ele aldık.

Uygulama kararını verdiyseniz ödeme altyapısını iki kanal arasında ortak kurmak en verimli yoldur. Aynı ödeme kuruluşunu, aynı sipariş sistemini ve aynı iade kurallarını kullanırsınız. Böylece kullanıcının sitede kaydettiği kart da, sağlayıcının desteklemesi durumunda, uygulamada kullanılabilir hale gelir. Ayrıca raporları tek yerde toplarsınız ve muhasebe tarafında mutabakat kolaylaşır.

Örnek senaryo: Bir giyim markası sitede ve uygulamada aynı ödeme kuruluşunu kullanır. Kullanıcı sitede bir kez kart kaydeder; uygulamada giriş yaptığında aynı kartla tek dokunuşla öder. Bu senaryo için iki kanalın da aynı müşteri hesabına bağlı olması gerekir.

Uygulamanızda kartla ödemeyi kimle kurmalısınız?

Kartla ödeme, uygulamanın en hassas parçasıdır; hatası doğrudan para ve güven kaybı demektir. Bu yüzden ödeme akışını, mağaza kurallarını bilen ve sunucu tarafını da kuran bir ekiple geliştirmenizi öneriyoruz. Talha Aslan ve ekibi olarak mobil uygulama geliştirme projelerinde ödeme kuruluşu SDK'sı, 3D Secure, kart saklama ve cüzdan entegrasyonunu tek bir akış olarak kuruyoruz.

Uygulamanızı biz geliştirir, mağaza incelemesine biz hazırlar ve yayına biz çıkarırız. Siz yalnız ödeme kuruluşunuzla üye işyeri sözleşmenizi yaparsınız; teknik tarafı ekibimiz yürütür. Hangi ödeme yolunun işinize uyduğunu birlikte netleştirmek isterseniz mobil uygulama geliştirme hizmetimiz üzerinden projenizi anlatıp teklif alabilirsiniz.