Uygulamanızda Para Almak: Ödeme Kabul Etmeye Dair Sade Bir Rehber

Yapay zekâyla oluşturduğunuz bir uygulamada ödeme kabul etmek, kart formunu yöneten ve parayı taşıyan Stripe gibi bir sağlayıcıya bağlanmak demektir — uygulamanız yalnızca siparişi kaydeder ve ödeme onaylandığında buna göre tepki verir.

Uygulamanızın bir projeden bir işe dönüştüğü belirli bir an vardır: birinin sizin uygulamanız üzerinden size ilk kez ödeme yaptığı an. Aynı zamanda bir hatanın artık utanç verici olmaktan çıkıp “param alındı ama karşılığında hiçbir şey gelmedi” haline geldiği andır. Ödeme kabul etmek, çoğu uygulama geliştiricisinin ekleyeceği en yüksek riskli özelliktir; iyi haber şu ki zor ve korkutucu kısımları aslında sizin inşa etmeniz gerekmiyor. Sadece bunları doğru şekilde bağlamanız ve sıkıcı senaryoları atlamamanız yeterli.

Bu, yapay zekâyla oluşturduğunuz bir uygulamada ödeme kabul etmeye dair sade bir rehber: perde arkasında gerçekte neler oluyor, ters gidebilecek üç şey ve başlamanız gereken tek kurulum.

”Ödeme kabul etmek” tam olarak ne anlama gelir?

Ödeme kabul etmek, kendi ödeme sisteminizi inşa etmek yerine uygulamanızı bir ödeme sağlayıcısına bağlamak demektir — çoğu kişinin tercih ettiği Stripe’tır ve gayet iyi bir varsayılandır. İşte iş bölümü; çünkü anlaşılması gereken en rahatlatıcı kısım tam olarak bu:

Kart formunu sağlayıcı gösterir. Kart numarasını sağlayıcı alır, doğrular ve parayı taşır. Sonra sağlayıcı uygulamanıza tek bir şey söyler: “bu kişi size 40 dolar ödedi.” Uygulamanız kart numarasını asla görmez, saklamaz, ona hiç dokunmaz. Bu bir sınırlama değil — asıl mesele bu. Kart verisi yasal ve güvenlik açısından bir mayın tarlasıdır; bunu tamamen sağlayıcının içinde tutmak, o mayın tarlasının sizin değil onların işi olması anlamına gelir. Eğer geliştiriciniz size “kartı veritabanınızda saklayalım” diye bir öneride bulunursa, cevap her zaman hayırdır.

Yani uygulamanızın bir ödemedeki gerçek görevi küçüktür: müşteriyi sağlayıcının ödeme ekranına yönlendirmek, ardından sağlayıcı paranın geçtiğini söylediğinde doğru şekilde tepki vermek.

Önce tek seferlik ödemeleri mi, abonelikleri mi kabul etmelisiniz?

Tek seferlik ödemelerle başlayın. Temel bağlantı yapısı bir abonelikle aynıdır, ancak tekrarlayan ödemelerin uç senaryolarının hiçbiri yoktur; ilk ürünlerin çoğu zaten yalnızca “bir kez öde, ürünü al” mantığına ihtiyaç duyar. Abonelikleri, gerçekten her ay ödemeye değer bir şeyiniz olduğunda, bilinçli bir şekilde daha sonra ekleyin.

İki ödeme türü hemen hemen her şeyi kapsar:

  • Tek seferlik ödeme — bir bilet, bir şablon, tek bir koçluk seansı, indirilebilir bir rehber satın almak. Para bir kez hareket eder, işiniz biter.
  • Abonelik — aylık bir üyelik, tekrarlayan bir plan. Para her ay otomatik olarak hareket eder; bu da “kartlarının süresi dolduğunda ne olacak,” “iptal ettiklerinde ne olacak” ve “bu ayki ödeme gerçekten geçti mi” sorularını da kabul ettiğiniz anlamına gelir.

Yapay zekâyla oluşturulan bir uygulamada en sık yapılan ödeme hataları nelerdir?

Yapay zekâyla oluşturulan bir uygulamadaki ödeme sorunlarının neredeyse tamamı üç hataya dayanır: uygulamanın bir ödemenin gerçekleştiğini unutması, makbuz olmadığı için müşterilerin iki kez ödeme yapması ve yalnızca başarılı ödeme senaryosunun gerçek parayla test edilmesi. Her biri için geliştiricinize doğrudan yapıştırabileceğiniz sade bir talimat var.

1. Ödeme çalışır ama uygulama unutur. Müşteri öder, para sağlayıcı hesabınıza düşer — ama uygulamanızda kimin ne için ödeme yaptığına dair hiçbir kayıt yoktur. Bir atölye organizatörü bu şekilde 30 bilet sattı ve sonunda Stripe’ta para, ama içinde tek bir isim bile olmayan bir elektronik tablo buldu kendini. Kapıda kimi içeri alacağına dair hiçbir fikri yoktu.

Çözüm: bir ödeme onaylandığı anda bir sipariş kaydı oluşturun — kim ödedi, ne satın aldı, ne kadar, ne zaman ve net bir “ödendi: evet” bilgisi. Geliştiricinize şunu sorun: “Bir ödeme başarılı olduğunda, müşteriyi, ürünü, tutarı ve ödeme durumunu içeren bir sipariş kaydı oluştur. Müşterinin teşekkür sayfasına geri dönmesine değil, sağlayıcının ödeme onayına güven.” Bu son kısım önemli — insanlar sekmeyi kapatır, bağlantıyı kaybeder ya da çift tıklar. Paranın gerçekten hareket ettiğine dair güvenilir sinyal, sağlayıcının uygulamanıza doğrudan gönderdiği mesajdır (bir webhook), müşterinin tarayıcısının bir başarı ekranına geri dönmesi değil.

2. Makbuz yok, bu yüzden iki kez ödüyorlar. Biri öde’ye basar, bir yükleniyor animasyonu görür, ne e-posta ne onay ne de başka bir şey gelir — bu yüzden başarısız olduğunu düşünüp tekrar öder. Şimdi birini iade etmeniz gerekir ve size güvenleri azalır. Geliştiricinize şunu sorun: “Bir ödeme tamamlandığı anda bir onay e-postası gönder ve ödemenin yapıldığını, sırada ne olduğunu açıkça belirten bir ekran göster.” Bir ödemeden sonraki sessizlik, uygulamanızdaki en pahalı sessizliktir.

3. Gerçek parayla test etmek. Sessizce bozuk şekilde yayına çıkan hata budur. Geliştiriciler ödeme akışını kendi ürünlerini kendi kartlarıyla satın alarak test eder, bir kez çalıştığını görür ve işi bitmiş sayarlar — bir kart reddedildiğinde ya da bir ödeme iade edildiğinde ne olduğunu hiç kontrol etmezler. Bir uygulama, kimse o senaryoyu test etmediği için kart reddedildiğinde bile siparişi “ödendi” olarak işaretledi; müşteri ürünü bedava aldı ve kurucu bunu ay sonunda fark etti.

Bunu test etmek için asla gerçek paraya ihtiyacınız yoktur. Her sağlayıcının, sahte kart numaralarıyla çalışan bir test modu vardır — uygulamanızın ne yaptığını görebilmeniz için özellikle reddedilmek üzere tasarlanmış kart numaraları da dahil. Geliştiricinize şunu sorun: “Tüm ödeme akışını önce test modunda oluştur ve test et. Yalnızca başarılı senaryoyu değil, reddedilen kart senaryosunu ve iade senaryosunu da ele al.” Test modu, tüm ödeme dünyasındaki en az kullanılan tek özelliktir.

Söylenmeyen kısım: artık işletme sizsiniz

İnsanların unuttuğu iki şey var. Birincisi, parayı gerçekten alabilmek için sağlayıcının gerçek bilgilerinize ihtiyacı vardır — ödemenin yatırılacağı bir işletme ya da banka hesabı. Bu, uygulamanın icat ettiği bir şey değil, bir kez doldurduğunuz bir formdur. İkincisi, kazandığınız paranın vergisi sizin sorumluluğunuzdadır, uygulamanın değil. İkisi de zor değildir; ama kimse yüksek sesle söylemezse ikisi de sizi kolayca şaşırtabilir.

Ödeme eklerken önce neyi inşa etmelisiniz?

Önce tam olarak tek bir şey inşa edin: tek bir ürün, tek bir fiyat, test modunda tek seferlik bir ödeme. O akış temiz bir şekilde çalışana kadar — para “hareket edene,” bir sipariş kaydedilene, bir onay görünene kadar — sepete, kuponlara, katmanlara, aboneliklere direnin. Çalışan o tek akış, hiçbir zaman reddedilen bir karta karşı sınanmamış, özellik dolu bir ödeme ekranından daha değerlidir.

Ardından yabancı testini iki kez uygulayın. Önce, reddedilmesi beklenen bir kart numarasıyla test modunda ödeme yapın — uygulamanız gerçeği mi söylüyor (“bu işlem gerçekleşmedi”), yoksa yalan söyleyip siparişi ödendi olarak mı işaretliyor? Sonra başarılı bir test satın alması yapın — müşteri siz olsaydınız güvenebileceğiniz bir sipariş kaydı ve onay aldınız mı?

Ödeme kabul etmek, ekleyeceğiniz en korkutucu özellik gibi hissettirir; oysa aslında üç başarısızlık senaryosu olan ve bunların hepsini ücretsiz olarak prova edebileceğiniz bir test modu bulunan bir bağlantı işidir. Ödemeye değer o tek şeyi seçin, tek bir test modu ödeme akışı bağlayın ve gerçek bir kart daha uygulamaya hiç dokunmadan önce sahte bir satışı — reddedilen kart dahil — baştan sona geçirin. İlk yapmanız gereken iş tam olarak bu.