ब्लैक बॉक्स में पैसे नहीं कैसे गंवाएं: बिलिंग टेस्टिंग के तरीके

भुगतान सेवाओं की वैधता, परीक्षण परीक्षण में प्रमुख इंजीनियरिंग मुद्दों में से एक है। हमारा आवेदन दुनिया के 250 देशों में 70 भुगतान प्रदाताओं के साथ एकीकृत है, और कम से कम एक बग में अप्रत्याशित परिणाम हो सकते हैं।

इस लेख में, मैं उन परीक्षण विधियों के बारे में बात करूँगा, जिनका उपयोग हम Badoo में करते हैं, और इन विधियों की प्रयोज्यता की सीमाएँ - परीक्षण के चरण जिस पर वे सबसे प्रभावी हैं।

यह लेख परीक्षकों, डेवलपर्स और उत्पाद प्रबंधकों के लिए उपयोगी होगा, जिनकी परियोजनाएं पहले से ही भुगतान प्रदाताओं के साथ एकीकृत हैं, या एकीकरण प्रक्रिया अभी शुरू हो रही है। यदि आपके काम में आपको इस तरह के एकीकरण के लिए परीक्षण विधियों को चुनने की समस्या का सामना करना पड़ रहा है, तो बिल्ली का स्वागत करें!




मेरा नाम व्लादिमीर सोलोडोव है, मैं बिंग में क्यूए इंजीनियर हूं: मैं परीक्षण एकीकरण और भुगतान प्रसंस्करण के सत्यापन में व्यस्त हूं। मेरे सहयोगी विक्टर कोरोनविच ने पाठ तैयार करने में मेरी मदद की: उनके साथ मिलकर हमने हाइजेनबग सम्मेलन ( वीडियो ) में एक रिपोर्ट बनाई। लेख में, हमने विवरण प्रदाताओं को भुगतान प्रदाताओं के साथ सभी एकीकरणों में विस्तारित किया, जो कि बट्टे में उपयोग किए जाते हैं, वर्गीकृत होते हैं और बाहरी निर्भरता को और अधिक विस्तार से हटाने के अभ्यास का वर्णन किया है।

एक उदाहरण के रूप में व्यवसाय के मामले के अध्ययन का उपयोग करते हुए, मैं आपको बताता हूं कि आपको भुगतान की गई सेवाओं के परीक्षण पर अधिक ध्यान क्यों देना चाहिए और यदि वे फिर भी उत्पन्न नहीं होती हैं तो समस्याओं को कैसे बढ़ाएं। और फिर हम परीक्षण एकीकरण और उन्हें हल करने के तरीकों की तकनीकी समस्याओं का वर्णन करने के लिए आगे बढ़ेंगे।

लेख का दूसरा भाग, जिसमें हम iOS अनुप्रयोगों में परीक्षण भुगतान सेवाओं के स्वचालन के बारे में अधिक बात करते हैं, यहां है ।

चलो चलते हैं!

बिलिंग परीक्षण विनिर्देश

आमतौर पर, एक व्यवसाय का लक्ष्य राजस्व उत्पन्न करना है। डेटिंग में, डेटिंग के लिए एक सामाजिक नेटवर्क, आय ऋण और प्रीमियम सदस्यता द्वारा अर्जित की जाती है। ऋण Badoo की आंतरिक मुद्रा है। उनकी मदद से, उदाहरण के लिए, आप पहले स्थान पर खोज परिणामों में अपना प्रोफ़ाइल बढ़ा सकते हैं, दूसरे उपयोगकर्ता को उपहार दे सकते हैं, और बहुत कुछ। प्रीमियम सदस्यता एक निश्चित अवधि के लिए वैध है और एक साथ कई विकल्प प्रदान करती है: "अदृश्य" मोड चालू करें, उन लोगों को देखें, जिन्होंने आप में रुचि दिखाई है, अपने खाते की प्रामाणिकता की पुष्टि करें और बहुत कुछ।

इन भुगतान सेवाओं को काम करने के लिए, हम 70 से अधिक भुगतान प्रदाताओं के साथ एकीकरण का उपयोग करते हैं। प्रदाता की पसंद मंच, देश, डिवाइस, मोबाइल ऑपरेटर और अन्य कारकों पर निर्भर करती है। इसलिए, भुगतान सेवाओं के परीक्षण का मुद्दा बहुत जरूरी है।

शुरू करने के लिए, विचार करें कि परीक्षण भुगतान सेवाओं का विशेष ध्यान क्यों दिया जाना चाहिए। इसके दो कारण हैं।

1. बिलिंग कीड़े व्यवसाय के लिए महत्वपूर्ण हैं।

पहली समस्या प्रतिष्ठित है। सेवा के लिए भुगतान करने वाला उपयोगकर्ता एप्लिकेशन में बग के लिए अधिक संवेदनशील (और कम सहिष्णु) हो जाता है। सार्वजनिक स्थान पर कोई भी प्रतिक्रिया, चाहे वह किसी ब्लॉग एप्लिकेशन की समीक्षा हो या ऐप स्टोर या Google Play पर टिप्पणी, एक उपयोगकर्ता जो किसी भुगतान सेवा में बग का सामना करता है, अधिक भावनात्मक होगा - यह एक ऐसा कारक है जो प्रतिष्ठा की हानि की ओर जाता है।

दूसरी समस्या यह है कि, जैसे ही आप किसी सेवा के लिए उपयोगकर्ता से धन प्राप्त करना शुरू करते हैं, आप एक कानून का उद्देश्य बन जाते हैं, जो सेवा के उपभोक्ता की रक्षा करता है। और प्रतिष्ठित नुकसान आसानी से वित्तीय में बदल सकते हैं।

कंपनियां तीन तरह से पैसा खोती हैं।

पहला तरीका रिफंड है । मान लीजिए कि एक उपयोगकर्ता पाता है कि आपने उसे ऐसी सेवा बेची है जो उसकी अपेक्षाओं पर खरा नहीं उतरती है। इस मामले में, वह आपकी सहायता टीम से संपर्क करेगा। इसके कर्मचारी एक जांच करते हैं और पता लगाते हैं कि उपयोगकर्ता की अपेक्षाएं वास्तव में एप्लिकेशन में बग के कारण नहीं हुईं। आप धनवापसी आरंभ करें। इस मामले में, एक वापसी है: परिणामस्वरूप, कंपनी को खोए हुए मुनाफे का सामना करना पड़ता है, और यह पैसा खोने का सबसे हानिरहित तरीका है।

दूसरा तरीका चार्जबैक है । मान लीजिए कि वही स्थिति हुई, केवल उपयोगकर्ता ने आपकी सहायता सेवा से संपर्क नहीं किया, लेकिन बैंक जिसने उसे कार्ड, या भुगतान प्रदाता जारी किया था। बैंक / प्रदाता रिफंड की शुरुआत करता है। इस मामले में, हम एक चार्जबैक के साथ काम कर रहे हैं। यहां व्यापार के लिए खतरा केवल खोए हुए मुनाफे में नहीं है। एक निश्चित संख्या में चार्जबैक के बाद, कंपनी को जुर्माना मिलता है, और इसकी जोखिम रेटिंग घट जाती है। बदले में, भुगतान प्रदाताओं की सेवाओं की लागत में वृद्धि की ओर जाता है।

तीसरा तरीका - मुकदमे (दावे) । सबसे उपेक्षित मामलों में, मुकदमे (सामूहिक सहित) हो सकते हैं, जिससे सबसे गंभीर परिणाम सामने आते हैं। इसलिए, 2015 में, टॉगेम के नियामक द्वारा एक मुकदमा के बाद, ब्रिटिश गैस को उन उपयोगकर्ताओं को बहु मिलियन डॉलर के मुआवजे का भुगतान करने के लिए मजबूर किया गया था जिन्होंने चार्जिंग सिस्टम में त्रुटि के कारण उच्च शुल्क लिया था। इसके बारे में यहाँ और पढ़ें।

2. एकीकरण के परीक्षण के लिए, ज्ञान और विशेषज्ञता की आवश्यकता होती है।

भुगतान प्रदाताओं के साथ एकीकरण की प्रक्रिया शुरू करने वाली टीमें अक्सर इस समस्या का सामना करती हैं। सभी संभावित बिलिंग मामलों को नहीं जानते हुए, भुगतान प्रदाताओं की सूचनाओं के लिए सिस्टम की प्रतिक्रिया का एहसास होने पर वे महत्वपूर्ण बारीकियों को याद करते हैं।

इससे अप्रत्याशित परिणाम हो सकते हैं - खोए हुए मुनाफे से असंतुष्ट उपयोगकर्ता।

आइए उस योजना को देखें जो भुगतान सेवाओं के प्रकारों को सूचीबद्ध करती है, और समस्या को अधिक सावधानी से विचार करती है।


चित्र 1. संभावित बिलिंग मामले

तीन मुख्य मामले हैं: एक गलती, एक सफल भुगतान और उपयोगकर्ता को एक वापसी। लेकिन प्रत्येक मामले में विवरण होता है, प्रत्येक मामले को आपके सिस्टम को अलग तरह से संभालना पड़ता है।

त्रुटियां आलोचनात्मक और अलौकिक हो सकती हैं। अधिसूचना त्रुटि को गैर-महत्वपूर्ण के लिए जिम्मेदार ठहराया जा सकता है - जब भुगतान प्रदाता उपयोगकर्ता के खाते में धन की कमी के बारे में सूचित करता है, और महत्वपूर्ण - उपयोगकर्ता के भुगतान विधि को अवरुद्ध करता है। और अगर पहले मामले में आप बाद में भुगतान करने की कोशिश कर सकते हैं, तो दूसरे में - यह पता लगाना अच्छा होगा कि विधि अवरुद्ध क्यों है। शायद उपयोगकर्ता धोखाधड़ी में देखा गया था और आपको उसके लेनदेन के बारे में अधिक सावधान रहना चाहिए।

धन वापसी । आप पहले से ही जानते हैं कि दो तरह के रिटर्न हैं: रिफंड और चार्जबैक। आपके सिस्टम को उन्हें अलग तरह से जवाब देना चाहिए। उदाहरण के लिए, चार्जबैक के बाद, यह उपयोगकर्ता के लिए आपके एप्लिकेशन के कुछ कार्यों को अवरुद्ध करने के बारे में सोचने के लिए समझ में आता है, क्योंकि चार्जबैक सबसे लोकप्रिय धोखाधड़ी तरीकों में से एक है।

एक सफल भुगतान एक बार का भुगतान हो सकता है, या यह एक सदस्यता हो सकती है।

एकमुश्त भुगतान उपभोज्य और गैर-उपभोज्य हो सकता है। खर्च किए गए भुगतान का एक उदाहरण, हमने लेख की बहुत शुरुआत में जांच की - ये लडकियां हैं। खेल से गैर-व्यय योग्य भुगतान का एक उदाहरण दिया जा सकता है। मान लीजिए आपके पास एक चरित्र है जो आप खेलते हैं। आप उसके लिए ऐसे सुपरपावर खरीदना चाहते हैं जो कुछ समय के लिए आसपास रहे हों। इस मामले में, खरीद गैर-व्यय योग्य भुगतान के वर्ग से संबंधित है।

सदस्यता (सदस्यता)। यहां सबसे ज्यादा मामले सामने आते हैं। सदस्यता की प्रारंभिक खरीद के अलावा, आपके पास हो सकता है:

• एक सदस्यता का नवीकरण (नवीनीकरण);
  
• करीबी सदस्यता (सदस्यता रद्द करें);
  
• परीक्षण सदस्यता (परीक्षण);
  
• अनुग्रह अवधि सदस्यता: जब हम सदस्यता को नवीनीकृत नहीं कर सकते हैं और अनुग्रह अवधि नामक अवधि के लिए फिर से भुगतान करने का प्रयास कर सकते हैं। उपयोगकर्ता के लिए, अनुग्रह अवधि इस तरह दिखती है। मान लीजिए आपने एक मासिक अखबार की सदस्यता खरीदी है। कंपनी जो आपको समाचार पत्र भेजती है वह पहले महीने के अंत के बाद सदस्यता के अगले महीने के लिए भुगतान लिखने की कोशिश कर रही है, लेकिन ऐसा नहीं कर सकती (कार्ड लॉक के कारण, खाते में धन की कमी, आदि)। यदि ग्रेस अवधि की वैधता अवधि दस दिन है, तो इस समय के दौरान कंपनी भुगतान को लिखने की कोशिश करती है, जबकि सदस्यता वैध रहती है। यदि कंपनी पैसे नहीं लिख पाती है, तो सदस्यता रद्द कर दी जाती है। यदि यह है, तो सदस्यता को अंतिम भुगतान की तारीख से नवीनीकृत किया जाता है;
  
• आंशिक भुगतान (आंशिक बिलिंग)। उदाहरण के लिए, पेपाल आपको आंशिक भुगतान करने की अनुमति देता है यदि उपयोगकर्ता के खाते में पर्याप्त धन (आंशिक भुगतान) नहीं है, या भुगतान को भागों (आंशिक चालान) में तोड़ने के लिए है।
  

आपको दो विशेषताओं को भी ध्यान में रखना होगा जो भुगतान प्रदाता पर पूरी तरह से निर्भर हैं: सदस्यता को आपके आवेदन द्वारा नियंत्रित किया जा सकता है या बाहरी रूप से प्रबंधित किया जा सकता है।

• आंतरिक रूप से प्रबंधित सदस्यता, उदाहरण के लिए, क्रेडिट कार्ड या पेपाल का उपयोग करने वाली एक सदस्यता है, जब पहले भुगतान के बाद आपको एक टोकन दिया जाता है जिसके साथ आप प्रदाता को फिर से आवेदन करते हैं, उपयोगकर्ता के भुगतान विवरण के बिना।
  
• बाह्य रूप से प्रबंधित सदस्यता तब होती है जब भुगतान एग्रीगेटर आपकी सदस्यता का पूर्ण नियंत्रण लेता है और बस आपको उनकी वर्तमान स्थितियों के बारे में सूचनाएं भेजता है।
  

चित्रा में, सबसे स्पष्ट क्षेत्र, जिस पर प्रतिक्रिया आमतौर पर पहली जगह में महसूस की जाती है, बैंगनी में हाइलाइट की जाती है। विशेषज्ञता के संचय के रूप में अन्य सभी को बहुत बाद में ध्यान में रखा जाना शुरू होता है। यह मोटे तौर पर बिलिंग के क्षेत्र में पुनरावृत्ति विकास के तरीकों के गलत अनुप्रयोग द्वारा सुविधा प्रदान करता है।


चित्रा 2. बिलिंग मामले जो मुख्य रूप से सिस्टम में लागू होते हैं

इस तरह के चरणबद्ध कार्यान्वयन से अप्रत्याशित परिणाम हो सकते हैं। उदाहरण के लिए, मैंने उन परियोजनाओं में से एक है जिसमें मैंने पहले काम किया था, वापसी की संभावना को ध्यान में नहीं रखा गया था। नतीजतन, सभी रिटर्न रिफंड के माध्यम से नहीं, बल्कि चार्जबैक के माध्यम से किए गए, जिसने कंपनी की जोखिम रेटिंग को नकारात्मक रूप से प्रभावित किया और आय के आंकड़े एकत्र करने में विफलताओं का कारण बना। विभिन्न प्रकार के बिलिंग मामलों की अनदेखी से लाभ कम हो सकता है या उपयोगकर्ताओं को ठगा महसूस करने वाले उपयोगकर्ताओं के प्रति कंपनी की भेद्यता बढ़ सकती है।

इसलिए, एक तरफ, भुगतान प्रसंस्करण में कीड़े को रिलीज से पहले पाया जाना चाहिए, क्योंकि वे सबसे नकारात्मक परिणाम पैदा कर सकते हैं। यदि यह संभव नहीं था, तो जितनी जल्दी हो सके यह समझना महत्वपूर्ण है कि बग एप्लिकेशन के रिलीज़ संस्करण में मिला है, इसे ठीक करें और सबसे महत्वपूर्ण बात यह है कि इस बग का सामना करने वाले उपयोगकर्ताओं को "आश्वस्त" करने के लिए कितने लोग भूल जाते हैं।

दूसरी ओर, स्थिति इस तथ्य से जटिल है कि भुगतान प्रदाताओं के साथ एकीकरण हमेशा ब्लैक बॉक्स के साथ बातचीत होता है, जो परीक्षण प्रक्रिया में बहुत सारे चर जोड़ता है।

बिलिंग परीक्षण के दौरान तकनीकी समस्याएँ

आइए उन्हें ऐप स्टोर के साथ सगाई एकीकरण के उदाहरण पर विचार करें।

ऐप स्टोर पर सदस्यता बाहरी रूप से प्रबंधित वर्ग के हैं, अर्थात, वे प्रदाता की ओर से पूरी तरह से प्रबंधित हैं, और हमारा सिस्टम केवल वर्तमान स्थिति का अनुरोध कर सकता है या इसके परिवर्तन की सूचना प्राप्त कर सकता है।

हमने विशेष रूप से इस एकीकरण को चुना, क्योंकि यह सबसे जटिल है और इसमें सभी प्रकार के मामले हैं जो सेवा को अन्य भुगतान प्रदाताओं के साथ एकीकृत करने की प्रक्रिया में पाए जा सकते हैं।

शुरू करने के लिए, हम एक बार की खर्चीली खरीद की ओर मुड़ते हैं।


चित्र 3. एकमुश्त व्ययशील भुगतान करने की प्रक्रिया

चरण 1 पर, उपयोगकर्ता सेवा खरीदने का अनुरोध करता है। एप्लिकेशन तय करता है कि भुगतान किया जाना चाहिए, और चरण 2 में, नियंत्रण भुगतान प्रदाता (ऐप स्टोर) को स्थानांतरित कर दिया जाता है। चरण 3: भुगतान करने के लिए उपयोगकर्ता को एक फॉर्म के साथ प्रस्तुत किया जाता है। चरण 4: उपयोगकर्ता भुगतान के लिए डेटा प्रदान करता है। चरण 5: प्रदाता लेनदेन को पूरा करता है और आवेदन के परिणाम की रिपोर्ट करता है, खरीद (तिथि, सेवा, स्थिति, आदि) के बारे में पूरी जानकारी युक्त एक रसीद लौटाता है। चरण 6: चेक, उपयोगकर्ता डेटा के साथ पूरक, प्रसंस्करण के लिए सर्वर को भेजा जाता है। सर्वर चेक डेटा को संसाधित करता है और सातवें चरण में आवेदन के लिए एक धक्का अधिसूचना उत्पन्न करता है। आठवें चरण में, अधिसूचना उपयोगकर्ता को दिखाई जाती है।

समस्या यह है कि भुगतान प्रदाता की ओर से चरण 3, 4 और 5 का प्रदर्शन किया जाता है, व्यावहारिक रूप से हमारे द्वारा नियंत्रित नहीं किया जाता है और इसमें विभिन्न विविधताएं हो सकती हैं। इस प्रकार, प्रक्रिया में वास्तव में एक रैखिक संरचना नहीं होती है, जैसा कि चित्र 2 में दिखाया गया है, लेकिन एक शाखा (चित्र 4 देखें), और प्रत्येक शाखा को आवेदन द्वारा अलग तरीके से नियंत्रित किया जाना चाहिए।


चित्रा 4. एक बार भुगतान स्थिति आरेख शाखा

सब्सक्रिप्शन खरीदना एक बार के भुगतान के रूप में शुरू होता है, लेकिन आगे की प्रक्रिया को नियंत्रित करना काफी मुश्किल होता है।


चित्रा 5. बाहरी रूप से प्रबंधित सदस्यता की स्थिति

आपको याद दिला दूं कि Apple सदस्यता, जिसे हम एक उदाहरण के रूप में मानते हैं, बाहरी रूप से प्रबंधित है। इसका मतलब यह है कि खरीद के बाद उपयोगकर्ता इसे अतुल्यकालिक रूप से प्रबंधित कर सकता है: करीब, समाप्ति की तारीख बदल सकता है, धनवापसी का अनुरोध कर सकता है। हम इसे चरण 9 में देखते हैं। चूंकि कार्रवाई हमारे सिस्टम के बाहर होती है, इसलिए मैंने इसे एक बिंदीदार रेखा के साथ चिह्नित किया।

चरण 10 में, ऐप स्टोर सदस्यता की स्थिति को बदल सकता है: विंडो में अनुग्रह अवधि दर्ज करें, नवीनीकृत करें, बंद करें।

ताकि हमें पता चल सके कि सदस्यता किस राज्य में है, चरण 11 है, जो ऐप स्टोर और Google वॉलेट जैसे एग्रीगेटर्स के लिए विशिष्ट है। इस चरण में, सिस्टम एक टोकन भेजता है, जिसका उपयोग रसीद के रूप में किया जाता है जो कि सदस्यता खरीदते समय या उसके पिछले नवीनीकरण के बाद बहुत शुरुआत में प्राप्त होता है।

चरण 12 प्रदाता की प्रतिक्रिया है। हमें सदस्यता की वर्तमान स्थिति के साथ एक चेक प्राप्त होता है। इस चरण में परिणाम एसिंक्रोनस चरणों 9 और 10 पर निर्भर करता है।

2018 के पतन में, सभी के लिए ऐप्पल ने सर्वर-टू-सर्वर सूचनाओं के एक तंत्र को लागू किया, जो आपको सदस्यता के साथ होने वाले परिवर्तनों के बारे में सूचित करने की अनुमति देता है। इस तरह की अधिसूचना की प्राप्ति चरण 13 में दिखाई गई है। अधिकांश अन्य प्रदाताओं के लिए, सर्वर-से-सर्वर अधिसूचना तंत्र केवल एक ही है, इसलिए यह तर्क दिया जा सकता है कि ऐप्पल का उदाहरण विभिन्न प्रकार के मामलों को कवर करता है। अन्य प्रदाताओं के मामले में, चरण 13 आपको योजना से चरण 11 और 12 को बाहर करने की अनुमति देता है।

चरण 14 पर, सर्वर सदस्यता की स्थिति को बदलने के लिए आवेदन के लिए एक प्रतिक्रिया उत्पन्न करता है।

इस प्रकार, हमें भुगतान किए गए सेवाओं की जांच करने के लिए राज्यों का एक पूरा ग्राफ प्राप्त करना चाहिए।


चित्र 6. भुगतान की स्थिति बदलने की पूरी प्रक्रिया (बाहरी प्रबंधित सदस्यता उदाहरण का उपयोग करके)

हमारे सिस्टम में जिन हिस्सों को हम नियंत्रित नहीं करते हैं वे नारंगी रंग के होते हैं, और वे हमारे लिए ब्लैक बॉक्स होते हैं।

बिलिंग परीक्षण विधियाँ

इसलिए, भुगतान सेवाओं का परीक्षण करते समय मुख्य तकनीकी समस्या "ब्लैक बॉक्स" की उपस्थिति है, जिन राज्यों में हमारा नियंत्रण बहुत कम है। यह उन तरीकों के एक सेट को परिभाषित करता है जो विभिन्न प्रकार के मामलों को कवर कर सकते हैं।

इनमें से कई तरीके नहीं हैं, और हमने उन्हें तीन श्रेणियों में विभाजित किया है: वास्तविक भुगतान, सैंडबॉक्स और "ब्लैक बॉक्स" से बाहरी निर्भरता का उन्मूलन।

वास्तविक भुगतान

परीक्षण पद्धति के रूप में वास्तविक भुगतान इस बात में अच्छे हैं कि वे एकीकरण की स्थिति का एक स्पष्ट विचार देते हैं। वास्तविक भुगतान करने में त्रुटि बग का बिना शर्त प्रमाण है।

अन्यथा, वास्तविक भुगतान खराब हैं। सबसे पहले, यह महंगा है: यह स्पष्ट है कि वास्तविक भुगतान करने के लिए, आपको वास्तविक पैसा खर्च करने की आवश्यकता है। आपको गलत लगता है अगर आपको लगता है कि अंत में पूरी राशि कंपनी को वापस कर दी जाएगी: सबसे पहले, प्रदाता प्रत्येक लेनदेन के लिए एक शुल्क लेते हैं, जिसका आकार, जैसा कि ऊपर वर्णित है, संगठन की जोखिम रेटिंग पर निर्भर करता है और 40% तक पहुंच सकता है (और इससे भी अधिक) ; दूसरी बात, मुद्रा प्रसार के कारण दूसरे देशों में भुगतान का परीक्षण करने पर आपको धन की हानि हो सकती है - मुद्रा की खरीद और बिक्री दर के बीच का अंतर (आप बैंक की विदेशी मुद्रा की बिक्री की दर से खरीद करेंगे, और वापसी खरीद की दर पर आएगी)।

इसके अलावा, इस पद्धति में एक लंबा समय लग सकता है, क्योंकि आपको सदस्यता के नवीनीकरण की अवधि, अनुग्रह अवधि के पूरा होने की प्रतीक्षा करनी होगी, और ये महीने हो सकते हैं।

सैंडबॉक्स

सैंडबॉक्स खूबसूरत हैं। यह, वास्तव में, वही कार्यक्षमता है जो एक भुगतान प्रदाता हमें वास्तविक भुगतान के मामले में देता है, लेकिन वास्तविक धन खर्च किए बिना। यह प्रदाता द्वारा पूरी तरह से समर्थित है, जिसका अर्थ है कि सैंडबॉक्स के साथ एकीकरण सस्ता है।

समय के साथ परीक्षण की लंबाई की समस्या को हल किया जाता है, एक नियम के रूप में, विभिन्न चाल का उपयोग करके। उदाहरण के लिए, ऐप स्टोर सैंडबॉक्स निम्नलिखित सदस्यता समाप्ति रूपांतरण का उपयोग करता है।

तालिका 1। Apple के सैंडबॉक्स में वास्तविक सदस्यता और सदस्यता की वैधता अवधि का अनुपात

डिफ़ॉल्ट Google वॉलेट सैंडबॉक्स सदस्यताएँ तालिका 2 में सूचीबद्ध हैं और इसे विक्रेता के कंसोल में कॉन्फ़िगर किया जा सकता है।

2. Google

Apple, Google , - . ., 3.

3. Google

-: App Store , Google Wallet Play Store.

, - . , 70 , Badoo, . Adyen PayPal. , ( Google Wallet), ( App Store Fortumo). , .


7.

, — , , . : , .

— (. . 8). , - +7111-111-11-11 . +7111-111-11-12 , « ».


8.

— ( ) (. . 9). . ( ), .


9.

— (. . 10), .


10.

, , . (, , ) . , , , , .

. 3, 4, 5 : , . - : , — , — . « ».


11. ( App Store)

, (, ). — , . . , , , . , . , .

. , ? :

• — ?
  
• end-to-end — : - ?
  
• — : , .
  

.


4.

. . . , . : , .

. , , Apple Google, . ( ). end-to-end : . , , .

, , — . . . : .

, , .

, . .

: . , , — .

, : — , , ; — : .


12.

, , , , .

, 12, Badoo.

. . QA- . , . , - , , . , .

: .

, , — . , Apple . . , . : - .

— , . -, . -, , -, , .

— : , Apple . 1 — , .

. , . , - .

, ( ).

निष्कर्ष

1. , .
   
2. ( ) . , .
   
3. « » , . - — . , : , — , — .
   
4. फेक, मोका और स्टब्स का उपयोग करते समय, यह याद रखना महत्वपूर्ण है कि ये वास्तविक भुगतान के मॉडल हैं, और, किसी भी मॉडल की तरह, उनके पास वास्तविकता और जोखिमों की एक डिग्री है। इन जोखिमों का मूल्यांकन किया जाना चाहिए और उन्हें वास्तविक भुगतानों या अतिरिक्त चेक द्वारा कवर किया जाना चाहिए।
   

IOS एप्लिकेशन में भुगतान सेवाओं के परीक्षण की एक स्थिर और सस्ती स्वचालन को प्राप्त करने में हम कैसे कामयाब रहे, इस बारे में हम अगले लेख में बात करते हैं ।

आपका ध्यान के लिए धन्यवाद! सभी बड़े लाभ और कम कीड़े!