Blog

Tips, guides, and privacy advice

← Back to Blog
Geliştirici İpuçları

Pazartesi sabahı gelen talep: Kayıttan ödemeye kadar olan yolu gerçek kullanıcının yaşadığı gibi test etmek

24 Temmuz 2026·11 min read

Konu satırı dört kelimeden ibaret bir destek talebi düşünün: ödedim, hiçbir şey olmadı, yardım. Pazartesi sabahı 8.52'de düşüyor; ödeme akışınız hakkında yeni şeyler öğrenmeye başlamak için mümkün olan en kötü an. Ücretli bir üründe bir süredir çalışıyorsanız, bunun bir versiyonu size tanıdık gelecektir.

Müşteri sıra dışı bir şey yapmadı. Pazar akşamı kaydoldu, doğrulama e-postasını açmadan dikkati dağıldı, ertesi sabah geri döndü, doğrudan fiyatlandırma sayfasına gitti ve ödedi. Tahsilat geçti. Sonrasında hiçbir şey: makbuz yok, plan yükseltmesi yok, hoş geldin mesajı yok. Ürün açısından bu, tesadüfen ödeme de yapmış olan yarım kalmış bir kayıttan ibaret.

Bütün testler yeşil. Kayıt test edilmiş. E-posta gönderimi test edilmiş. Ödeme akışı, gerçekten önemseyen insanlar tarafından enine boyuna test edilmiş. Hata, kimsenin sahiplenmediği tek yerde yaşıyor: makbuzu üreten iş, yalnızca doğrulama bağlantısına tıklandığında dolan bir alanı okuyor ve bu müşteri tıklamadan önce ödeme yapmış. Onun için son derece sıradan olan bir olay sırası ve test paketindeki hiçbir testin hiç yürütmediği bir sıra, çünkü her test zaten doğrulanmış bir kullanıcıdan başlıyor.

Dikiş yerleri böyledir işte. Kayıt ekibi kaydın sahibidir. Faturalama ekibi faturalamanın sahibidir. Aradaki boşluk, oradan geçmeye denk gelen kişinindir — ve bunu kimse bilerek yapmazsa, oradan ilk geçen kişi pazartesi sabahı ödeme yapmış bir müşteri olur.

Bunları neden hiç bulamazsınız: siz yeni olamazsınız

İşte rahatsız edici kısım. Böyle bir hatadan haberdar olduktan sonra bile, onu yeniden üretmek zahmetlidir — çünkü kolayca yeni bir kullanıcı olamazsınız. E-posta adresiniz zaten kullanıcı tablosunda. Aynı zamanda ödeme sağlayıcısında bir müşteri kaydı, pazarlama aracında bir kişi, analitikte bir satır ve unuttuğunuz iki özellik bayrağı grubunun üyesi. Tarayıcınız bir oturum, kayıtlı bir kart ve geçen çeyrekte kapattığınız bir onboarding ipucu taşıyor.

Kaydı kendi adresinizle test ettiğinizde, hiçbir gerçek müşterinin yürümeyeceği bir yolda yürürsünüz. Tam olarak onların takıldığı bölümü atlarsınız; boş durumu, ilk kullanıma özel yükseltme teklifini ya da mart ayında sessizce gönderilmeyi bırakan hoş geldin e-postasını hiç görmezsiniz.

Gerçekten yeni olmak aynı anda iki şey ister: sistemin daha önce hiç görmediği bir kimlik ve sistemle hiç karşılaşmamış bir tarayıcı. İkisinin de hazırlığı bir dakika sürer. Birini atlarsanız, o koşu size hiçbir şey anlatmaz.

Sahneyi hazırlamak

Bir geçici e-posta gelen kutusu kimlik tarafını halleder — yığınınızın hiçbir yerinde bulunmayan, bir saniyede hazır olan ve yirmi dakika sonra makbuz geldiğinde hâlâ okunabilen bir adres. Gerisi tamamen durum disiplini meselesi:

  • Yalnızca gizli pencere değil, temiz bir tarayıcı profili. Gizli mod çerezleri halleder, ama ayrı bir profil aynı zamanda hiç eklenti ve otomatik doldurulmuş kart olmaması demektir; ikisi de ödeme akışının davranışını sessizce değiştirir.
  • Bu ürünün daha önce hiç görmediği bir adres, böylece mevcut bir kayıtla çakışmak yerine yeni bir kayıt oluşturursunuz.
  • Ödeme tarafında da yeni bir kimlik. Bir test müşterisini yeniden kullanmak, onun kayıtlı kartlarını ve fatura geçmişini de yeniden kullanmak demektir; oysa ilk kez satın alan birinde tam olarak bu durum yoktur.
  • Farklı bir isim ve farklı bir şirket. Test verisi gibi görünen veriler, gerçek bir insana ait gibi görünen verilerden farklı doğrulamaları tetikler.
  • Ödeme sağlayıcısına test modunda bağlı bir staging ortamı. Asla canlı ortam, asla gerçek kart.
Başlamadan önce gelen kutusu adresini yer imlerine ekleyin. Adresin kendine ait bir bağlantısı var; böylece sekmeyi kapatıp yirmi dakikayı ödeme akışında geçirebilir ve aynı posta kutusuna dönebilirsiniz. Makbuz kayıt e-postasından çok sonra geldiğinde bunun önemi büyük.

Adım 1: Kaydolun ve e-postayı gerçekten okuyun

Adresi yapıştırın ve gönderin. Mesaj birkaç saniye içinde düşmeli — otuz saniye sürüyorsa bunu not edin, çünkü yarım dakika boyunca "gelen kutunuzu kontrol edin" ekranına bakan bir kullanıcı, sizden şüphe etmeye başlamış bir kullanıcıdır. Sonra sadece düğmeyi aramak yerine e-postayı düzgünce okuyun:

  • Ulaşma süresi. Ölçün. Yük altında bozulan metrik budur ve lansman gününe kadar kimse fark etmez.
  • Kimden geldiği. İnsanın okuyabileceği bir marka mı, yoksa bir no-reply sunucu adı mı? Yanıt bir insana ulaşıyor mu, yoksa kayboluyor mu?
  • Bağlantıya iki kez tıklayın. Biri doğrulamak için. İkincisi, jetonun tek kullanımlık olduğunu ve ikinci denemenin 500 hatası fırlatmak yerine kibarca reddedildiğini doğrulamak için.
  • Son kullanma. Birini ömrünü aşacak kadar kullanmadan bekletin ve yeni bir tane almanın yolunu anlatan bir mesajla reddedildiğini kontrol edin.
  • Büyük-küçük harf. Farklı bir yazımla tekrar kaydolun. Alan adı RFC 5321 uyarınca büyük-küçük harfe duyarsızdır ve neredeyse her ürün yerel kısmı da böyle ele alır; dolayısıyla burada ikinci bir hesap oluşmamalı.
  • Doğrulanmamış durum — açılıştaki senaryonun tam kendisi. Hiçbir şeye tıklamadan önce, uygulamanın size şimdiden neler yapma izni verdiğine bakın. Ekip arkadaşı davet edebiliyor musunuz? Ödeme yapabiliyor musunuz? Bazen bu bilinçlidir. Bazen de olmayı bekleyen bir pazartesi sabahı talebidir.

Asıl derdiniz doğrulamaysa, kendi başına bir oturumu hak eder — jetonlar ve uç durumlar konusunu geliştiriciler e-posta doğrulama akışlarını nasıl test eder yazısında daha derin ele aldık.

Adım 2: Para hareket etmeden önceki sessiz bölüm

Doğrulama ile ödeme arasında küçük bir otomatik mesaj kümesi durur: hoş geldiniz, onboarding hatırlatması, "hesabınızı kurmayı tamamlayın". Çoğu üründe en az test edilen e-postalar bunlardır, çünkü onları test sırasında birinin tıkladığı bir düğme değil, arka plan işleri gönderir.

Gelen kutusunu açık bırakın ve izleyin. Mükerrer bir hoş geldin e-postası, kayıttan doksan saniye sonra ateşlenen bir hatırlatma ya da hiç yazmadığınız bir isme yapılan hitap — hepsi gerçek kusurdur ve bir insan posta kutusunu okumadığı sürece hepsi görünmezdir.

Adım 3: Ödeme adımı — her zaman sandbox içinde

Şimdi herkesin etrafından dolaştığı kısım geliyor, çünkü ödemelere dokunmak tehlikeli hissettirir. Yalnızca yanlış ortamda tehlikelidirler. Ciddi her sağlayıcı tam da bunun için bir sandbox sunar: Stripe eksiksiz bir test kartı seti yayımlar ve PayPal sandbox hesapları sağlar; ikisi de tek kuruş kıpırdatmadan gerçeği gibi davranır.

Bunları kullanın. Test ortamına asla gerçek bir kart numarası girmeyin — ne kendinizinkini, hele ki bir meslektaşınızın ya da müşterinizin kartını hiç. Gerçek kart verisi, üzerinde çalıştığınız makineyi PCI DSS kapsamına sokar ve bir staging makinesi bunun ait olduğu en son yerdir. Test numaraları tam da bu, bir muhakeme meselesi olmasın diye vardır.

Asıl değer, mutlu yolda durmayı reddetmektedir. Yalnızca her şey yolunda gittiğinde çalışan bir ödeme akışı gerçekten test edilmiş sayılmaz:

  • Temiz bir başarı. Ödeme onaylandı, plan gerçekten etkinleşti, kullanıcı boş bir panel yerine anlamlı bir yere düştü.
  • Sıradan bir ret. Kullanıcı net bir açıklama alıp form verilerini koruyor mu, yoksa bir hata yığını ve boş bir sepetle mi karşılaşıyor?
  • Yetersiz bakiye. Genel bir retten farklıdır ve kendine ait bir metni hak eder.
  • Bir 3-D Secure doğrulaması. Güçlü müşteri kimlik doğrulaması birçok pazarda zorunludur. Bir kez tamamlayın, sonra yeniden çalıştırıp yarısında terk edin. Terk edilen bir doğrulama, arkasında yarım kalmış bir abonelik bırakmamalı.
  • Süresi dolmuş kart ve yanlış CVC. Tek bir işe yaramaz mesaja çökmeyi çok seven iki hata yolu.
  • Çift gönderim. Öde düğmesine hızlıca iki kez tıklayın. Tek tahsilat olmalı, iki değil. Kaçarsa bu listedeki en pahalı hata budur.
  • Geri düğmesi. Ödeyin, geri gidin, yeniden gönderin. Aynı soru, farklı kapı.
  • Para birimi ve vergi. Bölgelere farklı ücretlendirme yapıyorsanız ikisini de deneyin. Vergi tek bir yerde hesaplanır, üç yerde gösterilir ve bu üçü zamanla birbirinden ayrılır.

Stripe kullanıyorsanız, aşağıdaki numaralar bu listenin tamamını kapsar ve koşu ortasında dokümantasyonu karıştırmaktan sizi kurtarır. Herhangi birini gelecekteki bir son kullanma tarihi ve üç haneli herhangi bir CVC ile birlikte kullanın:

  • 4242 4242 4242 4242 — temiz başarı. Referans noktanız.
  • 4000 0000 0000 0002 — genel bir ret.
  • 4000 0000 0000 9995 — yetersiz bakiye; kullanıcıya genel bir retten farklı okunmalı.
  • 4000 0000 0000 0069 — süresi dolmuş kart.
  • 4000 0000 0000 0127 — hatalı CVC.
  • 4000 0025 0000 3155 — 3-D Secure kimlik doğrulamasını zorunlu kılar. İki kez çalıştırın: biri tamamlanmış, biri yarıda terk edilmiş olarak.

Diğer sağlayıcılar da eşdeğer setler yayımlar, yani aynı altı senaryo olduğu gibi taşınır; yalnızca numaralar değişir. Sağlayıcılar bu listeleri güncellediği için ara sıra güncel test dokümantasyonundan kontrol etmekte fayda var.

Önce hata senaryolarını çalıştırın. Bir test kullanıcısı bir kez mutlu mesut abone olduktan sonra onu ödeme öncesi temiz duruma döndürmek zahmetlidir; oysa yeni bir gelen kutusu ve temiz bir profil sizi saniyeler içinde başlangıç çizgisine götürür.

Adım 4: Makbuz da ürünün parçasıdır

Ödeme geçtiği anda gelen kutusu testin en ilginç ekranı hâline gelir. Makbuzlar en son inşa edilir, en önce unutulur; oysa müşteri için bütün bunların gerçekten olduğunu kanıtlayan belge tam da budur — muhasebeye ilettiği dosya, masraf formuna eklediği ek.

  • Tutar ödeme sayfasıyla birebir aynı. Bariz görünür ama indirimler, kıst hesaplar ve kur çevrimi işin içine girdiğinde istediğinizden daha sık tutmaz.
  • Vergi doğru şekilde ayrıştırılmış — test ettiğiniz bölge için.
  • Plan adı müşteriye görünen ad, plan_pro_v2_2024 değil.
  • Fatura numarası, tarih ve şirket bilgileri mevcut ve bir insanın okuyabileceği biçimde.
  • PDF ya da barındırılan fatura bağlantısı, giriş yapmamış biri için de açılıyor. İletilen postayı alan muhasebeci kişinin hesabı yok.
  • Her bağlantı herkese açık bir yeri gösteriyor. Staging ortamı, localhost adreslerini e-postalara büyük bir hevesle sızdırır.

Adım 5: Bir ay beklemeden yenilemeler ve başarısız ödemeler

Abonelik hataları gelecekte saklanır; bu yüzden bu kadar uzun yaşarlar. Yenileme tahsilatı, kartın süresinin dolacağı uyarısı, tahsilat hatırlatma zinciri, son iptal bildirimi — hepsi sürümden haftalar sonra gerçekleşir ve o sırada kimse bir gelen kutusunu izlemiyordur.

Beklemenize gerek yok. Stripe'ın test saatleri bir test müşterisini saniyeler içinde faturalama döngülerinde ileri sarar ve çoğu sağlayıcıda benzeri vardır. Bunu tek kullanımlık bir gelen kutusuna yöneltin; bir yıllık faturalama yazışması birkaç dakikada gelsin:

  • Yenileme makbuzu doğru gün, doğru tutarla gidiyor.
  • Yaklaşan tahsilat bildirimi, gönderiyorsanız, işe yarayacak kadar erken ulaşıyor.
  • Tahsilat hatırlatma zinciri başarısız olan bir kart karşısında makul biçimde tırmanıyor ve ödeme başarılı olduğu anda duruyor. Zaten ödemiş biri üçüncü sinirli hatırlatmayı almamalı.
  • Düşürme ve erişim kısıtlama bildirimleri hesabın gerçekten hâlâ yapabildikleriyle örtüşüyor.

Adım 6: İptal edin, sonra iade edin

Sonuna kadar yürüyün. İptal edin ve onay mesajının, erişimin ödenen dönemin sonuna kadar süreceği mi yoksa hemen mi kesileceği konusunda doğruyu söyleyip söylemediğini kontrol edin — faturalama alanında en çok öfkeli takip talebi üreten tek cümle budur. Ardından sağlayıcı tarafından iade yapın ve bir alacak dekontunun ya da iade onayının gerçekten müşteriye ulaştığını doğrulayın; paranın, müşterinin göremediği bir panelin içinde sessizce hareket etmesi yeterli değildir.

Her mesaja uygulanacak kontrol

Onu ne üretmiş olursa olsun, her e-posta aynı hızlı kontrolden geçer. Alışkanlık hâline geldiğinde saniyeler sürer:

  • Ulaştı, hem de sessizce elenmek yerine gelen kutusuna.
  • Hiçbir şey ham yer tutucu olarak görüntülenmiyor. Hitapta çözülmemiş bir jeton, bu yazıdaki en utandırıcı hatadır ve durmadan canlıya çıkar.
  • Düz metin sürümü var ve düzgün okunuyor. Pek çok istemci ve ekran okuyucu HTML yerine onu kullanır.
  • Bağlantılar mutlak ve herkese açık.
  • Pazarlama e-postalarında çalışan bir abonelikten çıkma var, RFC 8058'deki tek tıkla çıkış başlığı dahil; Google'ın gönderen yönergeleri uyarınca toplu gönderenler için artık fiilen zorunlu. İşlemsel makbuzlarda ise bulunmamalı.
  • Kimlik doğrulama geçiyor. Test postaları kötü teslim ediliyorsa, bunu şimdi öğrenin — işlemsel e-postalar neden spam'e düşer nedenleri anlatıyor.

Tek kullanımlık gelen kutusu bu döngüye neden uyar

Bunu uygulanabilir kılan şey, gelen kutusunun tek kullanımlık olmasına rağmen işe yaramayacak kadar kısa ömürlü olmaması. Mesajlar gerçek zamanlı ulaşır; her birini sistem gönderdiği anda düşerken görürsünüz ve neden-sonuç ilişkisi net kalır. Adres bir saat yaşar; bu da bir kayıt, bir ödeme, bir 3-D Secure sapması ve ileri sarılmış bir faturalama döngüsünü rahatlıkla kapsar. On dakikalık bir gelen kutusu ise genellikle tam makbuz gelmek üzereyken sona erer.

Üstelik sonrasında toparlanacak bir şey kalmaz. Gerçek adresinizde biriken test hesapları yok, altı kişinin koşularının birbirine karıştığı ortak bir QA posta kutusu yok, ekrandaki mesajın bugünkü koşuya mı yoksa geçen perşembeye mi ait olduğunu düşünmek yok. Sonraki deneme gerçekten sıfırdan başlar; bütün mesele de bu. Bir saatin sonunda bunların hepsine ne olduğunu merak ediyorsanız, bunu bir saat sonra ne oluyor yazısında anlattık.

Bu yöntem gerçekte neyi yakalar

Böyle bir koşu, belirli bir kusur ailesini güvenilir biçimde ortaya çıkarır: sistemlerin içinde değil, aralarında yaşayanları.

  • Aşağı akıştaki bir iş, ilgisiz bir adımın doldurduğu bir alana ihtiyaç duyduğu için hiç gönderilmeyen makbuzlar. (Merhaba pazartesi.)
  • Sabırsız bir ikinci tıklamadan doğan çift tahsilatlar.
  • Doğrulamadan önce ödeyen kişiler için iki kez giden ya da hiç gitmeyen hoş geldin e-postaları.
  • Ödeme başarılı olurken planın sessizce etkinleşmemesi ve ödeme yapan müşterinin ücretsiz katmanda kalması.
  • Yarıda terk edilen 3-D Secure doğrulamalarının geride bıraktığı sahipsiz yarım abonelikler.
  • Müşterilere ulaşmasına tek bir yapılandırma bayrağı kalmış e-postalarda duran staging adresleri.
  • Çoktan ödeme yapmış birini hâlâ kovalayan tahsilat hatırlatma zincirleri.

Açıkça söylenmesi gereken bir uyarı

Bu, sorumlusu olduğunuz bir yazılımı, kontrol ettiğiniz bir ortamda, bir ödeme sandbox'ına karşı test etmek için bir tekniktir. Ücretsiz deneme toplamanın, ödeme duvarını aşmanın ya da başkasının hizmetinde hesap üretmenin bir yolu değildir. O kötüye kullanımdır, tek kullanımlık e-posta sağlayıcılarının engellenmesinin sebebidir ve bu aracın amacı değildir.

Sınır ters yönde de geçerli: tek kullanımlık bir gelen kutusu bilinçli olarak geçicidir, bu yüzden saklamanız gereken bir hesabı asla ona bağlamayın. O posta kutusu olmadan hesabı kurtaramayacaksanız, gerçek bir adres kullanın. Bu çizginin hangi tarafında durduğunuzdan emin değilseniz, takma ad ile geçici adres karşılaştırması doğru okuma olur.

Kahramanlık değil, alışkanlık hâline getirin

Bu tür şeyleri yakalayan ekipler, en ayrıntılı test planlarına sahip olanlar değildir. Anlamlı hiçbir şey yayına çıkmadan önce bütün yolu bir yabancı gibi yürüyenlerdir: yeni gelen kutusu, temiz profil, kaydol, doğrula, test kartıyla öde, her mesajı oku, iptal et, iade al. Yarım saat, tamamen elle ve otomatik test paketinin yapısı gereği bulamayacağı şeyleri bulmaya devam ediyor; çünkü o paket, kodla aynı varsayımlar üzerine kurulu.

Takvime koyun — iki haftada bir ya da kaydı veya faturalamayı etkileyen her sürümden önce. İlk koşu neredeyse her zaman kimsenin fark etmediği bir şeyi ortaya çıkarır ve pazartesi sabahı gelen o talep, başınıza gelen bir şey olmaktan çıkar. Yeni bir tek kullanımlık e-posta alın ve yolu baştan sona yürüyün.