Abonelikleri Durdurup Yeniden Başlatan Bir Mobil Uygulama Oluşturun

Pause/Resume Kullanım Senaryosunu Netleştirin

Herhangi bir şey inşa etmeden önce, ürününüzde “pause” ve “resume”ın ne anlama geldiğini tanımlayın. Bu kelimeler bariz görünebilir, ama müşteriler ve faturalama sistemleri bunları farklı yorumlar. Güvenilir bir özelliği en hızlı şekilde yayına almak için tanımlarda anlaşın ve bu tanımları UX, backend ve faturalamada tutarlı şekilde uygulayın.

“Pause”ı iş terimleriyle tanımlayın

Duraklama sırasında nelerin değişeceğine karar verin:

• Erişim/Yetkiler: Kullanıcı erişimi hemen mi kaybeder, mevcut fatura dönemi sonuna kadar mı devam eder, yoksa kısmi erişim mi sürer (ör. salt okunur)?
• Faturalama: Ücretleri tamamen durduruyor musunuz, bir sonraki yenileme tarihini erteliyor musunuz, yoksa kredi mi veriyorsunuz?
• Zaman: Minimum/maksimum duraklatma süresi var mı (ör. 1–12 hafta)? Kullanıcılar yılda birden fazla kez duraklatma yapabilir mi?

Sonra “resume”ı aynı şekilde açıkça tanımlayın. Örneğin: yeniden başlatma “hemen yeniden etkinleştir ve şimdi ücretlendir” anlamına gelebilir veya “şimdi yeniden etkinleştir ama faturalama bir sonraki planlı yenilemeye bırak” anlamına gelebilir. Her plan için bir model seçin, kullanıcı bazında değil.

Destekleyeceğiniz abonelik türlerini listeleyin

Duraklatma/yeniden başlatma kuralları genellikle abonelik türüne göre değişir. v1 kapsamına hangi türlerin girdiğini yazın:

• Aylık planlar: Genellikle en basit—çoğunlukla yenileme tarihini duraklatılan süre kadar ileri çekmek tercih edilir.
• Yıllık planlar: Duraklatmanın dönemi uzatıp uzatmayacağına, orantılı kredi sunup sunmayacağınıza veya izin verilip verilmeyeceğine karar verin.
• Ücretsiz denemeler: Kalan deneme günlerini dondurmayı mı yoksa denemenin sona ermesini mi tercih edeceğinizi düşünün.

Eğer uygulama içi satın alımları destekliyorsanız, Apple/Google kurallarıyla nelerin yapılabileceğini ve nelerin hizmet içi “hesap seviyesi” duraklatma olarak ele alınması gerektiğini doğrulayın.

Kim duraklatabilir netleştirin

Uygunluğu tanımlayın: tüm kullanıcılar mı, sadece belirli planlar mı, sadece ödeme durumu iyi olan kullanıcılar mı veya sadece belirli bir süre abone olduktan sonra mı? Ayrıca duraklatmanın sadece self-servis mi yoksa destek onayı mı gerektirdiğine karar verin.

Gerçek dünya bağımlılıklarını belirleyin

Uygulamanız için “hizmet teslimi”nin ne anlama geldiğini listeleyin; çünkü bu kenar durumları belirler:

• Kargo: Siparişleri durdurma, transitteki gönderimler, ön ödemeli stok ve adres değişiklikleri.
• İçerik erişimi: Çevrimdışı indirmeler, kaydedilmiş öğeler, yalnız üyelere özel içerik.
• Randevular: Var olan rezervasyonlar, iptal kuralları ve duraklatma sırasında yeniden planlama.

Bu netlik, “durduruldu ama yine de ücretlendirildi” veya “yeniden başlatıldı ama hiçbir şey çalışmıyor” gibi kafa karıştırıcı deneyimleri önler.

Duraklatma Politikanızı ve Faturalama Kurallarını Belirleyin

Kullanım senaryosu netleşince, bunu yazılı bir duraklatma politikasına çevirin. Açık bir politika destek taleplerini, iadeleri ve tutarsız faturalamayı önler.

İzin verilen duraklatma sürelerini seçin

Basit, kolay açıklanabilir seçeneklerle başlayın. Birçok uygulama sabit seçenekler sunar (ör. 2 hafta, 1 ay, 2 ay) çünkü bunlar faturalama ve raporlama için öngörülebilir. Özel tarihler daha esnek görünebilir, ama aynı zamanda zaman dilimleri, ay sonu yenilemeleri ve çakışan promosyonlar gibi kenar durumlarını artırır.

Pratik bir orta yol: çoğu kullanıcı için sabit duraklatma süreleri, yıllık planlar veya destek yardımı gereken istisnalar için özel tarihler.

Sıklık limitleri ve kenar durumları ele alma

Bir müşterinin ne sıklıkta duraklatma yapabileceğini tanımlayın:

• Yılda maksimum duraklatma sayısı (ör. son 12 ay içinde 2 duraklatma)
• Duraklatmalar arasında minimum süre (ör. tekrar duraklatmadan önce en az 30 gün aktif olma)
• Minimum duraklatma süresi (ör. “duraklatma atlamayı” önlemek için en az 7 gün)

Ayrıca kullanıcı yenileme gününde, deneme sırasında veya bir fatura beklerken duraklatma yaparsa ne olacağını karar verin. Kuralı açıkça yazın: örn., ödeme dün başarısız olduysa duraklatmaya izin verir misiniz? Eğer hayırsa, engelleyin ve nedenini açıklayın.

Duraklatma sırasında hangi avantajlar devam eder karar verin

Aboneliğinizin sağladığı her hakkı listeleyin ve duraklatmada “devam eder” ya da “durur” olarak seçin:

• Uygulama erişimi (tam, salt okunur veya kilitli)
• Kullanım kredileri/izinleri (dondur, birikmeye devam et, veya sıfırla)
• Premium destek veya koçluk seansları

Ayrıca kullanıcının önceden indirilmiş içeriği tüketip tüketemeyeceğine, geçmiş verilere erişip erişemeyeceğine veya hesaplarını dışa aktarabileceğine burada karar verin.

Yenileme ve faturaların nasıl kaydırılacağını belgeleyin

Çoğu ürün bir sonraki fatura tarihini duraklatma süresi kadar ileri taşır (müşteriler için en basit zihinsel model). Örnek: yenileme 10 Mayıs’ta idi, kullanıcı 20 Nisan’da 30 gün duraklattı → sonraki yenileme 9/10 Haziran olur, kullandığınız “gece yarısında bitir” kuralına bağlı olarak.

Prorasyon konusunda açık olun: kullanılmayan zaman için geri ödeme yapacak mısınız, bakiye kredisi oluşturacak mısınız yoksa abonelik süresini mi uzatacaksınız? Bu kuralları açık dilde yazın ve uygulama içi onay ekranında yansıtın.

Abonelik Veri Modelini ve Durumları Tasarlayın

Pause/resume doğru çalışması, temiz ve paylaşılmış bir “gerçeklik kaynağı” veri modeliyle başlar. Uygulama, backend ve faturalama sisteminiz bir kullanıcının duraklatılmış olup olmadığında anlaşamazsa çift ücretlendirme, kayıp erişim ve zor destek vakaları görürsünüz.

Modellemeniz gereken temel varlıklar

En azından şu varlıkları ve sorumluluklarını tanımlayın:

• Plan: Müşterinin satın aldığı şey (fiyat, faturalama aralığı, deneme kuralları, duraklatmaya izin verilip verilmediği).
• Abonelik (Subscription): Bir plan üzerindeki müşteri kaydı (mevcut durum, yenileme tarihi, sağlayıcı ID'leri like App Store/Google Play ve müşteri tanımlayıcısı).
• PausePeriod: Her duraklatmanın kaydı (başlangıç zamanı, planlanan bitiş zamanı, gerçek resume zamanı, neden ve başlatan kişi).
• Fatura (Invoice) (veya Transaction/Charge): Ne faturalandı (tutar, para birimi, fatura dönemi, ödeme durumu, başarısızlık nedeni).
• Yetki/Entitlement: Müşterinin erişebildiği özellikler/içerik/limitler ve geçerlilik penceresi. Bu, abonelik durumu ve iş kurallarından türetilebilir olmalı.

Abonelik durumları (basit tutun)

Herkesin anlayabileceği küçük bir durum kümesi kullanın:

• active: Erişim verildi; faturalama güncel.
• paused: Erişim politika gereği azaltılmış veya durdurulmuş; faturalama davranışı kurallarınıza bağlı.
• past_due: Ödeme başarısız oldu; erişim sınırlı olabilir.
• canceled: Müşteri veya sistem yenilemeyi sonlandırdı.
• expired: Dönem sona erdi (genellikle iptal veya ödemesizlik sonrasında); erişim yok.

Durum geçişleri ve tetikleyiciler

Bir aboneliği durumlar arasında nelerin taşıyabileceğini tanımlayın:

• Kullanıcı işlemi: “Pause” bir PausePeriod oluşturur ve active → paused olur.
• Kullanıcı işlemi: “Resume” PausePeriodu kapatır ve paused → active olur.
• Sistem işi: Planlanan bitiş zamanında otomatik yeniden başlatma (paused → active).
• Faturalama webhook/işi: Başarısız ödeme (active → past_due), ödeme kurtarılırsa (past_due → active), iptal sonrası dönemin sonu (canceled → expired).

Denetlenebilir geçmiş (vazgeçilmez)

Abonelik değişiklikleri için değişmez bir audit log saklayın: kim yaptı (kullanıcı, yönetici, sistem), ne zaman, ne değişti ve neden (neden kodları). Bu destek, iade ve uyumluluk için elzemdir.

Mobil UX’i Planlayın: Pause ve Resume

Pause/resume deneyimi, bir teslimat tarihini güncellemek kadar basit ve öngörülebilir hissetmelidir. Kullanıcıların faturalama sistemlerini anlaması gerekmez—sadece nelerin değiştiğini ve ne zaman olduğunu bilmelidirler.

Açık bir abonelik durum kartı ile başlayın

Abonelik ekranınızın üstünde bir durum kartı koyun ki kullanıcı “işler şu anda nerede”yi hızlıca doğrulayabilsin. İçerik:

• Mevcut durum (Active, Paused, Scheduled to pause)
• Bir sonraki fatura tarihi (veya duraklatıldığında “Faturalama ... tarihinde yeniden başlar”)
• Erişim durumu (duraklatma sırasında neler kullanılabilir)

Bu kart, kullanıcı unutmuş olsa bile kafa karışıklığını ve destek taleplerini azaltır.

Basit duraklatma seçenekleri sunun

Kullanıcı Pausea dokunduğunda seçenekleri kısa ve tanıdık tutun:

• 1 hafta
• 1 ay
• Tarih seç (takvim)

Ayrıca hesaplanan duraklatma bitiş tarihini hemen gösterin (örn. “... tarihine kadar duraklatıldı”). İş kurallarınız izin veriyorsa küçük bir notla limitleri gösterin (örn. “En fazla 3 ay duraklatabilirsiniz”).

Onaydan önce etkiyi gösterin

Kullanıcı onaylamadan önce etkileri düz ve anlaşılır bir şekilde gösteren bir onay ekranı sunun:

• Erişim değişiklikleri: duraklatma sırasında neleri kullanıp kullanamayacakları
• Faturalama kaydırması: yeni bir sonraki ücret tarihini ve prorasyon uygulanıp uygulanmadığını
• Hizmet değişiklikleri: atlanacak gönderimler/rezervasyonlar/destek hakları

Belirsiz ifadelerden kaçının. Mümkün olduğunca tarihler ve tutarlar kullanın.

Resume ve ayarlamaları zahmetsiz yapın

Duraklatma sırasında iki ana eylemi görünür tutun:

• Şimdi devam et (erişimi ve faturalamayı hemen geri yükle)
• Duraklatma bitiş tarihini değiştir (iptal etmeden dönüş tarihini düzenle)

Her değişiklik sonrası durum kartında bir başarı durumu ve kısa bir “Sırada ne olacak” özeti gösterin ki güven inşa edilsin.

Pause/Resume için Backend API'sini Oluşturun

İyi bir pause/resume özelliği uygulamada “anlık” görünür, ancak bunu güvenli, öngörülebilir ve desteklenebilir kılan backend API'sidir.

Kimlik doğrulama ve yetkilendirme

Her abonelik işlemi için kimliği doğrulanmış kullanıcı isteyin. Sonra abonelik düzeyinde yetkilendirin: çağıran kişi aboneliğin sahibi olmalı (veya admin/destek rolü). Aile planları veya kurumsal hesapları destekliyorsanız, “hesap sahibi” ile “üye”nin farklı izinleri olup olmayacağını karar verin.

Ayrıca platform kısıtlarını doğrulayın. Örneğin, bir abonelik Apple/Google tarafından yönetiliyorsa, API'niz muhtemelen yalnızca kullanıcının niyetini depolayabilir ve mağazadan durumu okuyabilir; doğrudan faturalamayı değiştiremeyebilir.

Basit tutmak için temel endpoint'ler

İlk sürümünüzü küçük ve açık tutun:

• GET /subscriptions/{id}: mevcut durum, bir sonraki fatura tarihi, duraklatma uygunluğu ve planlanmış duraklatma/yeniden başlatma.
• POST /subscriptions/{id}/pause: şimdi duraklat veya planlanmış duraklatma (ile start_date, isteğe bağlı end_date).
• POST /subscriptions/{id}/resume: hemen yeniden başlat veya bir yeniden başlatma planla.
• PUT /subscriptions/{id}/pause-schedule: mevcut planı güncelle (tarihler, neden).

Her seferinde normalleştirilmiş bir yanıt gönderin (abonelik durumu + “sonraki adım ne”), böylece uygulama UI'yi tahmin etmeden çizebilir.

Idempotency: çift değişiklikleri önleyin

Mobil ağlar ve kullanıcılar çift tıklama yapar. pause/resume isteklerinde Idempotency-Key başlığı isteyin. Aynı anahtar tekrar gönderilirse, orijinal sonucu geri verin ve ikinci bir değişiklik uygulamayın.

Kullanıcı-dostu hatalar (sonraki adımlarla)

Açık hata kodları ve mesajları kullanın, örn. SUBSCRIPTION_NOT_ELIGIBLE, ALREADY_PAUSED, PAUSE_WINDOW_TOO_LONG. next_allowed_action, earliest_pause_date gibi alanlar veya destek için yardım metnine yönlendirme (ör. Yardım merkezi) ekleyin ki UI kullanıcıyı rehberlik edebilsin.

Koder.ai ile uygulamayı hızlandırma (opsiyonel)

Küçük bir ekiple bu özelliği inşa ediyorsanız, Koder.ai gibi bir vibe-coding platformu, pause/resume akışını hızlıca prototiplemenize yardımcı olabilir: React tabanlı web admin/destek ekranları, abonelik durum makinesi için Go + PostgreSQL backend ve gerekirse Flutter mobil yüzeyleri. Planning modu, politika kararlarını bir spesifikasyona kilitlemek için faydalıdır ve snapshot/rollback, fatura kritik mantığı üzerinde yineleme yaparken riski azaltır.

Faturalama Mantığını ve Ödeme İşlemeyi Uygulayın

Faturalama, “duraklatma”nın bir UI düğmesinden müşteriye verilen gerçek bir söz haline geldiği yerdir. Hedef: öngörülebilir ücretlendirme, net yenileme zamanlaması ve başarısız ödeme sonrası yanlış erişim olmaması.

Muhasebe yaklaşımınızı seçin

Genellikle iki uygulanabilir desen vardır:

• Durum değişikliklerini saklayın ve bir sonraki fatura yeni durumu yansıtsın. paused_at, resume_at kaydedilir ve sonraki fatura zamanı dinamik hesaplanır. Bu daha basittir ve defterinizi temiz tutar, ama hassas tarih hesaplaması gerektirir.
• Açık prorasyon düzeltmeleri oluşturun. Duraklatma başladığında (veya bittiğinde) kullanılmayan zaman için kredi/ücret üretilir. Bu faturaları daha şeffaf yapar ama karmaşıklığı ve kenar durumlarını artırır.

Birini seçin ve web, mobil ve destek araçlarında tutarlı kullanın.

Yenileme tarihi hareketi ve fatura zamanlaması

Duraklatmanın zamanı dondurup dondurmadığı veya faturalama döngülerini atlayıp atlamadığına karar verin:

• Zamanı dondur: yenileme tarihi duraklatılan süre kadar ileri taşınır. Müşteriler “ödedikleri süreyi korur” hisseder.
• Döngüleri atla: duraklatma sırasında yaklaşan yenileme iptal edilir ve yeniden başlatıldığında faturalama sabit bir takvime göre devam eder.

Ayrıca yeniden başlatmada ne zaman faturalama yapılacağına karar verin: hemen (metrelenen ekler için yaygın) vs. bir sonraki yenileme tarihinde (basit aylık planlar için yaygın).

Ödenmemiş faturalar ve başarısız ödemelerle başa çıkma

Bir duraklatma isteği genellikle başarısız bir tahsilatın hemen ardından gelir. Net bir kural belirleyin:

• Eğer ödenmemiş bir fatura varsa, duraklatmayı ödemeye kadar engelliyor musunuz yoksa duraklatmaya izin verip erişimi askıya mı alıyorsunuz?
• Borca izin veriyorsanız, tahsilat e-postalarının gönderilmeye devam ettiğinden ve destek ekibinin bakiye görebildiğinden emin olun.

Bu kuralları yardım merkezinde ve uygulama içi metinlerde belgeleyin ki kullanıcılar şaşırmasın.

Faturalamaya ilişkin olayları downstream sistemlere yayınlayın

Her faturalama ile ilgili değişiklik subscription_paused, invoice_payment_failed, subscription_resumed, renewal_date_changed gibi event'ler üretmelidir. Bunları e-posta, CRM, analitik ve destek sistemlerine yönlendirin ki mesajlaşma ve raporlama tutarlı olsun. Basit bir event log ayrıca uyuşmazlıkların çözümünü hızlandırır.

Yetkileri ve Hizmet Teslimini Eşitleyin

Pause/resume yalnızca kullanıcının görebildiği rozet değilse işe yarar—gerçekte müşterinin ne kullanabildiği abonelik durumuyla uyumlu olmalıdır. “Duraklatıldı” rozetinden fazlası gerekir: entitlement kontrolleriniz, fulfillment sistemleriniz ve önbellekleme davranışınız tüm cihazlarda anlaşmalıdır.

Abonelik durumlarını yetkilere eşleyin

active ve paused (ve kullandığınız diğer durumlar, örn. grace period) için açık bir yetki matrisi tanımlayın.

Örneğin:

• Active: ücretli özelliklere/içeriğe tam erişim, gönderimler planlanır, premium destek etkin
• Paused: faturalama durduruldu/ertelendi, premium erişim kısıtlı veya kısıtlanmış, gönderimler engellenir

Yetki değerlendirmesini mümkün olduğunca sunucu taraflı yapın. Uygulama başlatıldığında ve her pause/resume işleminden sonra mevcut yetki setini almalı ve kısa bir süreyle önbelleğe almalıdır.

Fiziksel ürün gönderiyorsanız: fulfillment'i durdurun ve yeniden planlayın

Fiziksel ürünler için duraklatma gelecekteki gönderimleri hemen bloke etmelidir. Bu genellikle demektir:

• Bir sonraki fulfillment işinin iptali veya tutulması
• Yeniden başlatmada bir sonraki gönderim tarihinin yeniden hesaplanması (politikaya göre “telafi” yapmayın)
• Kesme süreleri: bir kutu zaten paketlendiyse kullanıcıyı bilgilendirin ki gönderim yine de yapılabilir

İçerik sunuyorsanız: nelerin erişilebilir kalacağına karar verin

İçerik abonelikleri için kullanıcıların anlayacağı bir politika gerekir. Seçenekler:

• Duraklatma sırasında erişimi tamamen dondurun
• Önceden indirilen içeriğe izin ver, ancak yeni indirme/akışları engelle
• Duraklatma sırasında sınırlı bir “ücretsiz katman” deneyimi sun

Hangi seçeneği seçerseniz seçin, tüm platformlar ve cihazlar arasında tutarlı uygulayın.

Çoklu cihaz oturumları ve önbelleğe alınmış erişim

Kullanıcı bir cihazda duraklatma yapacak ve tüm cihazlarda bunun hızla yansımasını bekleyecek. Kısa ömürlü erişim token'ları kullanın, uygulama öne geldiğinde yetkileri yenileyin ve durum değiştiğinde oturumları geçersiz kılın. Çevrimdışı/önbelleğe alınmış erişim için net kurallar koyun (örn. son yetki yenilemesinden sonra X saat oynatma izni) ve erişim duraklatma nedeniyle kısıtlandığında uygulama içinde bir mesaj gösterin.

Bildirimler, E-postalar ve Uygulama İçi Mesajlaşma

Duraklatma ve yeniden başlatma yüksek niyetli anlardır: kullanıcılar isteklerinin gerçekleştiğini bilmek ister ve faturalama yeniden başladığında sürpriz istemezler. İyi mesajlaşma destek taleplerini azaltır ve “unutmuşum” iptallerini önler.

Ne göndermeli (ve ne zaman)

Kullanıcının duraklatma tarihleri ve faturalama kurallarına bağlı küçük bir zaman çizelgesiyle başlayın:

• Duraklatma onayı (anında): duraklatma başlangıç tarihi, duraklatma sırasında erişime ne olduğu ve planlanan yeniden başlama tarihi (veya “manuel olarak yeniden başlatılana kadar”).
• Yaklaşan yeniden başlama (planlı): hizmet veya faturalama yeniden başlamadan 3–7 gün önce hatırlatma, yönetim için uygulamaya dönüş çağrısı.
• Yeniden etkinleştirildi (anında): hizmetin tekrar etkin olduğunu doğrulayan ve bir sonraki fatura tarihini içeren onay.

Birden fazla duraklatmaya izin veriyorsanız, kalan duraklatma haklarını veya uygunluk kurallarını da ekleyin.

Onay tercihi, çıkış ve platform kuralları

Mesaj kanallarını farklı ele alın:

• E-posta: ayarlarda açık/kapalı kontrolleri sağlayın. Birçok uygulama, pazarlama e-postaları kapalı olsa bile işlemsel e-postalar (örn. “Aboneliğiniz duraklatıldı”) gönderebilir—bunları açıkça etiketleyin.
• Push bildirimleri: değeri olduğunda izin isteyin (örn. kullanıcı duraklatma planladıktan hemen sonra). “Yenileme hatırlatmaları” ve “Abonelik güncellemeleri” için ayarlar sunun.
• Uygulama içi inbox/banner: push kapalıyken bile kritik anlar için bunları kullanın.

Uygulama mağazası gereksinimlerine uygun olarak izin ve bildirim kullanımını yansıtan ayarlar olduğundan emin olun.

Sürprizleri önleyen uygulama içi mesajlaşma

Özellikle ödeme yöntemi başarısız olma olasılığı varsa, yenileme başlamadan önce hafif bir banner veya modal kullanın. Harekete geçirici ifadeler olsun: “Planı gözden geçir”, “Ödemeyi güncelle”, “Duraklatmayı uzat (uygun ise)”.

Daha fazla bağlam isteyenler için yardım merkezi içeriğine yönlendiren açıklayıcı metinler ekleyin.

Analitik ve Başarı Metrikleri

Pause/resume bir ürün özelliğidir; sadece faturalama geçişi değil—bu yüzden bunun müşterilerin kalmasını sağlayıp sağladığını ve güvenilir çalışıp çalışmadığını gösteren metriklere ihtiyacınız var.

Doğru event'leri instrument edin

Birbirine katılabilecek küçük, tutarlı bir event seti izleyin. Asgari:

• pause_started (içer: subscription_id, user_id, plan, pause_length, platform, entry_point)
• pause_ended (içer: ended_by = scheduled|user_resume|admin, effective_date)
• resumed_early (içer: days_paused, reason_if_provided)

Ayrıca resume_failed (hata kategorisi ile) izlemeyi düşünün ki destek taleplerine yansımayan sorunları görebilesiniz.

Etkiyi ölçün (sadece kullanım değil)

Yüksek duraklatma oranı otomatik olarak iyi değildir. Hacmi şu sonuç metrikleriyle eşleştirin:

• Churn azaltma: duraklatma yapan kullanıcıların iptal oranlarını benzer kullanıcılarla karşılaştırın (plan, abonelik süresi ve edinim kanalı kohortlarına göre).
• Yeniden etkinleşme oranı: duraklatma sonrası aktif faturalamaya dönüş oranı (%), ve 30/60/90 gün sonrası kalma oranı.
• Destek talebi baskılaması: abonelik yönetimiyle ilgili destek taleplerinde değişim.

Varsa, duraklatma erişimi olan ve olmayan kohortlar için net gelir tutma (NRR) takibi yapın.

Nedenleri hafifçe yakalayın

Kullanıcı duraklatırken isteğe bağlı, saygılı bir neden seçici sunun (ve sadece ‘Diğer’ için serbest metin alanı ekleyin eğer işleyebilecekseniz). Seçenekleri kısa tutun (5–7 seçenek) ve yargılayıcı etiketlerden kaçının. Bu, “geçici ihtiyaç” (seyahat, bütçe) ile “ürün açığı” (kullanım yok, özellik eksik) ayrımını yapmanıza yardımcı olur.

Eyleme dönüştürülebilir panolar oluşturun

Aşağıyı hızlıca gösteren panolar hazırlayın:

• Zaman içinde duraklatma hacmi (plan, platform, uygulama sürümüne göre)
• Funnel: duraklatma ekranı açıldı → onaylandı → pause_started
• Başarısız yeniden başlatma oranları (hata kategorileri, etkilenen sürümler)
• Ortalama duraklatma süresi ve dağılımı (kaç kişi erken döndü vs sonuna kadar bekledi)

Lansmanda haftalık, sonra aylık olarak bu metrikleri gözden geçirin ve öğrenimleri ürün yol haritanıza bağlayın ki duraklatma bir tutundurma aracına dönüşsün—göz ardı edilen bir boşluk değil.

Test Stratejisi ve Kenar Durumlar

Pause/resume faturalama, yetkilendirme ve UX'i etkiler—bu yüzden hatalar genellikle “erişim kayboldu” veya “çift ücretlendirildim” şeklinde görünür. İyi bir test planı durum değişikliklerine, tarih hesaplarına ve idempotency'e odaklanır.

Birim testleri: durumlar ve tarihler

En azından abonelik durum makinesini ve sahip olduğunuz tarih matematiğini birim-testlerle doğrulayın.

• Durum geçişleri: active → paused, paused → active, active → canceled, paused → canceled. Geçersiz geçişlerin reddedildiğini doğrulayın (örn. duraklatılmamışken resume reddedilir).
• Fatura tarihi hesaplamaları: duraklatma sırasında bir sonraki yenileme tarihinin doğru hareket ettiğinden emin olun; ayın daha kısa olduğu durumlarda tarih kaymamasını test edin (örn. 31 Ocak vakaları). Zaman dilimleri ve yaz saati uygulaması testleri ekleyin.
• Prorasyon kuralları varsa: kredi devri ve “yeniden başlatmada ücretlendirme” davranışının politika ile uyuştuğunu doğrulayın.

Entegrasyon testleri: sağlayıcı callback'leri, retry'ler ve sıralama

Ödeme sağlayıcıları webhook/event'leri birden fazla kez veya sıranın dışında gönderebilir.

• Çift callback işleme için idempotency ve event ID'lerini doğrulayın.
• Retry davranışı test edin: webhook geç geliyor, sunucunuz 500 döndü, sağlayıcı tekrar ediyor—duraklatma/yeniden başlatmayı iki kez uygulamadığınızdan emin olun.
• Yarış durumları için testler yazın: kullanıcı “Pause”a basarken aynı anda bir yenileme ödemesi işleniyor.

Uygulama testleri: gerçek dünya UX hata modları

Mobil koşullar ince kenar durumlar yaratır ve bunlar faturalama hatası gibi görünebilir.

• Çevrimdışı mod: kullanıcı bağlantı olmadan duraklatma isterse; sıraya alınmış işlemler, net mesajlar ve güvenli yeniden deneme sağlayın.
• Tekrarlı tıklamalar: Pause/Resume düğmelerine hızla basmak birden fazla istek yaratmamalı; düğmeyi devre dışı bırakın, yükleniyor durumu gösterin ve API çağrılarını idempotent yapın.

Zorunlu senaryolar

Aşağıyı kapsayan uçtan uca senaryolar dahil edin:

• Deneme kullanıcıları: deneme sırasında duraklatma, deneme sonrasında yeniden başlatma ve beklenmeyen ücretlendirme olmadığını doğrulama.
• Yıllık planlar: duraklatma kurallarını doğrulayın (çoğu ekip yıllık planlarda duraklatmayı yasaklar veya farklı ele alır) ve yenileme tarihleri tutarlı kalsın.
• Past-due hesaplar: duraklatma geçmiş borcu “silmemeli”; yeniden başlatma koleksiyon kurallarına uymalı.

Test checklist’inizi ürün spesifikasyonuna yakın tutun ki faturalama kurallarındaki değişiklikler otomatik olarak yeni test vakaları tetiklesin.

Güvenlik, Gizlilik ve Uyumluluk Düşünceleri

Pause/resume basit bir anahtar gibi görünse de faturalama, erişim ve müşteri haklarını değiştirir—bu yüzden kayıt ve ödemeler kadar dikkat gerektirir.

Pause/Resume API'sini koruyun

Bu endpoint'ler kötüye kullanılabilir (örn. botlar ücretten kaçmak için tekrar tekrar duraklatma isteyebilir). Bunları ödeme endpoint'leri gibi koruyun:

• Kullanıcı ve cihaz başına rate limit koyun, mantıklı cooldown’lar ekleyin (örn. saatte bir değişiklik).
• Replay koruması ekleyin ki yakalanmış bir istek daha sonra tekrar gönderilemesin. Kısa ömürlü idempotency anahtarları, sunucu tarafı nonceler ve zaman damgası doğrulaması kullanın.
• Güçlü kimlik doğrulama isteyin (son zamanlarda giriş, cihaza bağlı tokenlar) ve yüksek riskli hesaplar için step-up doğrulama düşünün.

Denetlenebilirlik ve uyuşmazlık yönetimi

Her abonelik durum değişikliği için bir audit trail kaydedin. Kim başlattı (kullanıcı/admin/sistem), ne zaman, hangi uygulama sürümünden ve öncesi/sonrası durumlar. Bu destek, iadeler ve itirazlar için gereklidir.

Audit logları değiştirilmeye karşı belirgin ve erişim kontrolüne tabi olmalı. Tam kart verilerini veya gereksiz kişisel bilgileri loglara koymaktan kaçının.

Gizliliği tasarımın merkezine koyun

Sadece aboneliği sunmak için gereken kişisel verileri toplayın. Hassas alanları dinlenmede şifreleyin (ve her zaman TLS kullanın). Personel için en az ayrıcalık erişimi ve veri saklama/anonimleştirme politikaları uygulayın.

Hesap silme destekliyorsanız, duraklatılmış aboneliklerin ve fatura tokenlarının doğru şekilde ele alındığından emin olun.

Uyumluluk ve platform kuralları

Yerel tüketici kurallarını (yenileme, iptal, açıklama gereksinimleri) gözden geçirin. Birçok bölgede net fiyatlandırma, yenileme koşulları ve kolay iptal gereklidir.

Ayrıca Apple/Google abonelik politikalarına uyun (özellikle faturalama, yetki erişimi ve iade işleme konularında). Bir ödeme işlemcisi kullanıyorsanız PCI gereksinimleri ile uyumu sağlayın—kart verileri tokenize edilse bile.

Yaygınlaştırma Planı ve Sürekli İşletme

“Duraklat ve yeniden başlat”ı yayınlamak tek seferlik bir iş değildir. Bunu fatura-kritik bir değişiklik olarak ele alın: kademeli olarak yayınlayın, gerçek davranışı izleyin ve operasyonu şaşırtmalar için hazır tutun.

Kademeli yayına alın

Özelliği bir feature flag ile başlatın; önce küçük bir dahili grup, sonra beta kohortu ve ardından kademeli bir dağıtım (örn. %5 → %25 → %100). Bu, gelir koruma ve destek yükünü azaltır eğer mağazalar, ödeme yöntemleri veya bölgeler arasında farklı davranışlar varsa.

Ramp-up sırasında izlenecekler:

• Denemeler vs başarılı duraklatma sayısı (ve en sık hata nedenleri)
• Yeniden başlatma girişimleri ve ödeme başarısızlıkları
• İade/chargeback oranı değişiklikleri
• 1.000 abone başına müşteri destek iletişim oranı

Operasyonel hazırlık: destek + SSS

Lansiyondan önce müşteri destek playbook'ları oluşturun. Ekran görüntüleri, beklenen zaman çizelgeleri (“duraklatma bir sonraki fatura döneminde başlar” vs “hemen”) ve sık sorulan sorular için standart cevaplar ekleyin:

• “Duraklatılmışken neden ücretlendim?”
• “Duraklatılmışken uygulamayı kullanmaya devam edebilir miyim?”
• “Nasıl yeniden başlatırım ve faturalama ne zaman yeniden başlar?”

Uygulama içinde ve yardım merkezinde net SSS yayınlayın. Plan karşılaştırmaları veya yükseltme yollarınız varsa, kullanıcıların duraklatma, downgrade veya faturalama periyot değiştirme arasında karar vermesi için /pricing yerine hesap ve fiyatlandırma sayfalarına yönlendirici bilgiler sunun.

Geriye dönük uyumluluk ve versiyonlama

Eski uygulama sürümlerinin “paused” aboneliklerle güvenli şekilde karşılaşmasını planlayın. En azından:

• Nötr bir “abonelik duraklatıldı” durumu gösterin (hata değil)
• Premium özellikleri tutarlı şekilde engelleyin
• Sadece gerçekten gerekiyorsa güncelleme istemi gösterin

Son olarak, aylık kontroller planlayın: kenar durum fatura sonuçları, politika sapmaları (örn. duraklatma kuralları olmayan yeni planlar) ve uygulama mağazası yönerge değişiklikleri için düzenli denetimler yapın.