निर्णय का आधार
पहले उपयोग के अधिकार और उनके बदलने का समय तय करें। भुगतान, बिल और सदस्यता जुड़े पर अलग राज्य हैं, जैसा Stripe की गाइड दिखाती है। ऐप को स्पष्ट पहुँच नीति चाहिए।
एक व्यावहारिक उदाहरण
काल्पनिक मासिक टीम प्लान में बीच अवधि अपग्रेड हो, भुगतान अतिरिक्त कदम माँगे और प्रशासक पेज रीफ्रेश करे। तय करें पुराना प्लान रहेगा या नहीं। अपुष्ट अपग्रेड पूरा बताने के बजाय लंबित बदलाव दिखाएँ।
भुगतान के साथ पहुँच स्थिति
सदस्यता, मिले अधिकार और संदेश साथ लिखें। हमेशा साथ नहीं बदलते: आगे की रद्दीकरण पर पहुँच रहे, पहला असफल भुगतान अधूरा हो। हर बदलाव अधिकृत घटना या सर्वर जाँच से जोड़ें। माँगने वाला और सहेजा काम तय करें, फिर घटनाएँ जोड़ें।
बीच में रुका अपग्रेड
परीक्षण में अपग्रेड शुरू, ब्राउजर बंद, सूचना दोहराएँ और प्रक्रिया देर करें। दो सदस्यता न बने और सफलता पेज से अधिकार न मिले। वापस शुरू करने योग्य स्थिति और आंतरिक संदर्भ दें, भुगतान रहस्य नहीं। पुराने नोटिस की वर्तमान राज्य से तुलना करें। अंतर का मिलान जिम्मेदार तय करें।
रद्द करना समझाएँ
आगे बिल बंद, सुविधा रुकना, निर्यात और डेटा मिटना अलग हैं। साथियों तथा कार्यों पर असर बताएं। वापस न लिए जा सकने वाले कदम उचित पुष्टि और असली नीति से अलग दिखाएँ। दूसरा व्यक्ति ट्रायल अंत, अपग्रेड, विफलता, रद्द और पुनः चालू जाँचे। सवाल सफल भुगतान से छिपे फैसले खोजते हैं।
विकल्पों का आकलन
वादे और प्रदाता के अनुसार बदलाव तुरंत, नवीनीकरण पर या पुष्टि के बाद हो सकते हैं। ट्रायल, असफल वसूली, रद्द और पुनः चालू अलग लिखें। बाहर का भुगतान पेज आपके अधिकार नियम नहीं बदलता।
योजना कहाँ टूटती है
checkout से लौटने भर पर पहुँच न दें। सर्वर पर सही स्थिति जाँचें और दोहराई सूचना सुरक्षित संभालें। बिल और टीम सदस्यता अलग रखें।
काम शुरू कराने से पहले
रद्द करने पर सहेजा काम क्या होगा? प्लान कौन बदलेगा? लंबित भुगतान सहायता कैसे समझाएगी? SaaS डिजाइन में तय करें।