Müşterilerin aboneliklerini duraklatıp yeniden başlatmasına izin veren bir mobil uygulama nasıl tasarlanır ve yapılır öğrenin: faturalama kuralları, UX örüntüleri ve yayın adımları.
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.
Duraklama sırasında nelerin değişeceğine karar verin:
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.
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:
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.
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.
Uygulamanız için “hizmet teslimi”nin ne anlama geldiğini listeleyin; çünkü bu kenar durumları belirler:
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.
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.
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.
Bir müşterinin ne sıklıkta duraklatma yapabileceğini tanımlayı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.
Aboneliğinizin sağladığı her hakkı listeleyin ve duraklatmada “devam eder” ya da “durur” olarak seçin:
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.
Ç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.
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.
En azından şu varlıkları ve sorumluluklarını tanımlayın:
Herkesin anlayabileceği küçük bir durum kümesi kullanın:
Bir aboneliği durumlar arasında nelerin taşıyabileceğini tanımlayın:
PausePeriod oluşturur ve active → paused olur.PausePeriodu kapatır ve paused → active olur.paused → active).active → past_due), ödeme kurtarılırsa (past_due → active), iptal sonrası dönemin sonu (canceled → expired).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.
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.
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:
Bu kart, kullanıcı unutmuş olsa bile kafa karışıklığını ve destek taleplerini azaltır.
Kullanıcı Pausea dokunduğunda seçenekleri kısa ve tanıdık tutun:
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”).
Kullanıcı onaylamadan önce etkileri düz ve anlaşılır bir şekilde gösteren bir onay ekranı sunun:
Belirsiz ifadelerden kaçının. Mümkün olduğunca tarihler ve tutarlar kullanın.
Duraklatma sırasında iki ana eylemi görünür tutun:
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.
İ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.
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.
İ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.
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.
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.
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, “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ı.
Genellikle iki uygulanabilir desen vardır:
paused_at, resume_at kaydedilir ve sonraki fatura zamanı dinamik hesaplanır. Bu daha basittir ve defterinizi temiz tutar, ama hassas tarih hesaplaması gerektirir.Birini seçin ve web, mobil ve destek araçlarında tutarlı kullanın.
Duraklatmanın zamanı dondurup dondurmadığı veya faturalama döngülerini atlayıp atlamadığına karar verin:
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).
Bir duraklatma isteği genellikle başarısız bir tahsilatın hemen ardından gelir. Net bir kural belirleyin:
Bu kuralları yardım merkezinde ve uygulama içi metinlerde belgeleyin ki kullanıcılar şaşırması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.
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.
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:
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ünler için duraklatma gelecekteki gönderimleri hemen bloke etmelidir. Bu genellikle demektir:
İçerik abonelikleri için kullanıcıların anlayacağı bir politika gerekir. Seçenekler:
Hangi seçeneği seçerseniz seçin, tüm platformlar ve cihazlar arasında tutarlı uygulayın.
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.
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.
Kullanıcının duraklatma tarihleri ve faturalama kurallarına bağlı küçük bir zaman çizelgesiyle başlayın:
Birden fazla duraklatmaya izin veriyorsanız, kalan duraklatma haklarını veya uygunluk kurallarını da ekleyin.
Mesaj kanallarını farklı ele alın:
Uygulama mağazası gereksinimlerine uygun olarak izin ve bildirim kullanımını yansıtan ayarlar olduğundan emin olun.
Ö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.
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.
Birbirine katılabilecek küçük, tutarlı bir event seti izleyin. Asgari:
Ayrıca resume_failed (hata kategorisi ile) izlemeyi düşünün ki destek taleplerine yansımayan sorunları görebilesiniz.
Yüksek duraklatma oranı otomatik olarak iyi değildir. Hacmi şu sonuç metrikleriyle eşleştirin:
Varsa, duraklatma erişimi olan ve olmayan kohortlar için net gelir tutma (NRR) takibi yapı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.
Aşağıyı hızlıca gösteren panolar hazırlayın:
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.
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.
En azından abonelik durum makinesini ve sahip olduğunuz tarih matematiğini birim-testlerle doğrulayın.
Ödeme sağlayıcıları webhook/event'leri birden fazla kez veya sıranın dışında gönderebilir.
Mobil koşullar ince kenar durumlar yaratır ve bunlar faturalama hatası gibi görünebilir.
Aşağıyı kapsayan uçtan uca senaryolar dahil edin:
Test checklist’inizi ürün spesifikasyonuna yakın tutun ki faturalama kurallarındaki değişiklikler otomatik olarak yeni test vakaları tetiklesin.
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.
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:
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.
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.
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.
“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.
Ö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:
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:
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.
Eski uygulama sürümlerinin “paused” aboneliklerle güvenli şekilde karşılaşmasını planlayın. En azından:
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.
Her iki terimi de iş dilinde tanımlayın:
Bu kuralları plan bazında yazın ki kullanıcılar “durduruldu ama hala ücretlendirildi” gibi durumlarla karşılaşmasın.
Çoğu ürün şu modellerden birini seçer:
Bir model seçin ve onay ekranında ortaya çıkan bir sonraki ücretlendirme tarihini gösterin.
Basit ve öngörülebilir başlayın:
Özel tarihleri istisnalar (çoğunlukla yıllık planlar veya destek yardımı) için ayırın.
Her abonelik türünü ayrı ele alın:
Bu farkları yardım içeriğinde ve uygulama içi onay metinlerinde açıkça belirtin.
Küçük ve anlaşılır bir durum seti kullanın ve geçişleri netleştirin:
active, paused, past_due, canceled, expiredHer duraklatmayı ayrı bir kayıt olarak saklayın (ör. ile start/end/actual resume) ve kim neyi ne zaman değiştirdiğini gösteren değişmez bir audit log tutun.
İlk sürümde minimal ve deterministik endpoint'ler tutun:
GET /subscriptions/{id}: durum, bir sonraki fatura tarihi, uygunlukPOST /subscriptions/{id}/pausePOST /subscriptions/{id}/resumePUT /subscriptions/{id}/pause-scheduleHer zaman normalleştirilmiş bir yanıt döndürün: “mevcut durum + sonraki adım nedir”, böylece uygulama tahmin yapmak zorunda kalmaz.
Pause/resume yazmalarında idempotency uygulayın:
Idempotency-Key başlığı isteyin.Ayrıca UI düğmelerini istek sırasında devre dışı bırakın ve hatalı ağ koşullarında tekrar denemeleri güvenli hale getirin.
Erişim davranışını önceden belirleyin ve sunucu tarafında uygulayın:
Uygulama başlatıldığında ve her pause/resume işleminden sonra yetkilendirmeleri yenilesin; kısa önbellekleme ile birlikte erişim kısıtlandığında net mesaj gösterin.
Borç ve başarısız ödemeler için net kurallar koyun:
invoice_payment_failed ve subscription_paused gibi event'ler yayımlayın ki destek ve mesajlaşma tutarlı olsun.Kullanıcı dostu hata kodları gösterin (ör. ) ve sonraki adımları belirtin.
Kullanıcı duraklatma ve yeniden başlatma işlemleri için küçük, tutarlı bir mesaj takvimi gönderin:
Bağlantılar yerine yardım metinlerine veya hesap ayarlarına yönlendiren ifadeler tercih edin; eğer limitleriniz varsa kalan duraklatma hakkını gösterin.
PausePeriodSUBSCRIPTION_NOT_ELIGIBLE