सैंडबॉक्स हरा है, पर पेमेंट अभी लॉन्च के लिए तैयार नहीं

इंटीग्रेशन टेस्टिंग की रिपोर्ट में «टेस्ट पेमेंट सफल रहा» लिखना आसान है। यह साबित करना कहीं ज़्यादा मुश्किल है कि जवाब खो जाने के बाद सामान एक ही बार दिया जाएगा, रिफ़ंड दोगुना नहीं होगा और रात का रिकंसिलिएशन वही रकम ढूँढेगा। पेमेंट इंटीग्रेशन की तैयारी इन्हीं असहज सीनेरियो में दिखती है। आइए जाँच को उस नुकसान के इर्द-गिर्द बनाएँ जिसे सिस्टम को रोकना है।

टेस्ट चलाने से पहले अपेक्षित नतीजा लिखिए

हर सीनेरियो के लिए एक पंक्ति बनाइए: पेमेंट मेथड, कस्टमर की कार्रवाई, सिम्युलेट किया गया इवेंट, प्लेटफ़ॉर्म की अपेक्षित स्थिति और जाँचने का तरीका। मालिक और नतीजे का लिंक भी जोड़िए। «पेमेंट काम करता है» बहुत अस्पष्ट है। बेहतर है: «एक ही ट्रांज़ैक्शन का कन्फ़र्मेशन दोबारा आने पर क्रेडिट की एक ही एंट्री बनती है; सपोर्ट को दोनों प्रयास और एक अंतिम रकम दिखती है»।

एक काल्पनिक प्लेटफ़ॉर्म पर विक्रेता पेमेंट लेते हैं और खरीदार रिफ़ंड माँग सकते हैं। टीम सिर्फ़ वही मेथड और ट्रांज़ैक्शन टेस्ट करती है जो सच में उसके प्रोडक्ट में चालू हैं और प्रोवाइडर द्वारा अनुमत हैं। कार्ड ऑथराइज़ेशन, बैंक ट्रांसफ़र के कन्फ़र्मेशन और प्राप्तकर्ता को पेआउट के अपेक्षित चरण अलग होने चाहिए। एक पेमेंट प्रोसेस का «सफल» स्टेटस उसका मतलब तय किए बिना दूसरे में मत ले जाइए।

मैट्रिक्स को पैसे के नुकसान और अनिश्चितता के इर्द-गिर्द बनाइए

• सामान्य समापन। रकम, करेंसी, ऑर्डर से संबंध, लेजर की एंट्री और कस्टमर को साफ़ कन्फ़र्मेशन जाँचिए।
• अपेक्षित डिक्लाइन। प्रोवाइडर का तय टेस्ट सीनेरियो इस्तेमाल कीजिए; पक्का कीजिए कि सामान या अंदरूनी बैलेंस जारी नहीं होता।
• कस्टमर की अतिरिक्त कार्रवाई। मेथड के लिए उपलब्ध वेरिफ़िकेशन पूरा कीजिए, उसे रद्द कीजिए और बीच में रोकिए; हर नतीजा अलग से जाँचिए।
• खोया हुआ जवाब। भेजने के बाद नेटवर्क टूटने का सिमुलेशन कीजिए और पक्का कीजिए कि सिस्टम अनिश्चितता और ट्रांज़ैक्शन की पहचान बनाए रखता है।
• दोहराव और देर से आया इवेंट। एक जैसा नोटिफ़िकेशन दोबारा भेजिए, उसे देर से भेजिए और दूसरे इवेंट के साथ क्रम बदलिए।
• रिफ़ंड या कैंसलेशन। अनुमत पूरे और आंशिक कदम, रकम की गलतियाँ और ऑपरेटर का दोबारा क्लिक जाँचिए।
• रिकवरी। अंदरूनी हैंडलर रोकिए, टेस्ट इवेंट जमा होने दीजिए और कतार की नियंत्रित प्रोसेसिंग जाँचिए।
• रिकंसिलिएशन। कुछ ट्रांज़ैक्शन को ऑर्डर से लेकर प्रोवाइडर के रिकॉर्ड और अंदरूनी फ़ाइनेंशियल रिपोर्ट तक ट्रैक कीजिए।

आधिकारिक टेस्ट वैल्यू इस्तेमाल कीजिए। Stripe बताता है कि पैसे की आवाजाही के बिना पेमेंट, डिक्लाइन, ऑथेंटिकेशन और दूसरे इवेंट का सिमुलेशन कैसे करें। वही डॉक्यूमेंटेशन सैंडबॉक्स पर लोड टेस्टिंग और असली पेमेंट डिटेल्स के साथ live मोड में टेस्टिंग के खिलाफ़ चेतावनी देता है। जाँच का तरीका चुनी गई सर्विस के नियमों के अनुरूप होना चाहिए।

एक सीनेरियो को कंपोनेंट्स की सीमाएँ पार करनी चाहिए

टेस्ट T-27 की कल्पना कीजिए: खरीदार 36 यूरो का ऑर्डर देता है, कन्फ़र्मेशन के तुरंत बाद पेज बंद कर देता है, और नोटिफ़िकेशन बाद में आता है। जाँचने वाला सिर्फ़ API का जवाब नहीं देखता। वह ऑर्डर दोबारा खोलता है, पेमेंट का रिकॉर्ड, इवेंट की कतार, सामान जारी करने की कार्रवाई और सपोर्ट को दिखने वाला इतिहास जाँचता है। नतीजे में एक समझाने लायक अंतिम स्थिति होनी चाहिए, भले ही ब्राउज़र सुंदर सक्सेस पेज का इंतज़ार न कर पाया हो।

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

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

प्रोडक्ट के वादे को दूसरी स्क्रीन से जाँचिए

अगर टेस्ट पेमेंट बनाता है और उसी API का जवाब जाँचता है, तो वह इंटीग्रेशन की गलत धारणा को ही दोहरा सकता है। एक स्वतंत्र अवलोकन जोड़िए: फ़ाइनेंशियल एंट्री, फ़ुलफ़िलमेंट जॉब्स की सूची, सपोर्ट में ऑर्डर का इतिहास। काल्पनिक टेस्ट में 36 यूरो और एक डिस्पैच अपेक्षित है। साथ ही जाँचिए कि दूसरा डिस्पैच, बिना वजह का बैलेंस और एक और «सफल» ऑर्डर नहीं है। यहाँ अतिरिक्त असर का न होना उतना ही अहम टेस्ट नतीजा है जितना ज़रूरी असर का होना।

सबूतों को तीन स्तरों में बाँटिए: प्रोवाइडर के साथ कॉन्ट्रैक्ट, अपने ऐप्लिकेशन का व्यवहार और ऑपरेशन टीम का काम। टेस्ट API सिर्फ़ उसमें उपलब्ध सीनेरियो की पुष्टि करता है। शिफ्ट के साथ अभ्यास दिखाता है कि कर्मचारी डेवलपर की पहुँच के बिना अज्ञात पेमेंट ढूँढ पाएगा या नहीं। रिकंसिलिएशन की जाँच दिखाती है कि पैसे की एंट्रियाँ मेल खाती हैं या नहीं। एक स्तर दूसरे की जगह नहीं लेता।

हर कदम के बाद विफलता

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

मैट्रिक्स को दुनिया की हर चीज़ की सूची मत बनाइए। हर गंभीर गलती के लिए पहचानने का तरीका, ठोस टेस्ट और लॉन्च का फैसला होना चाहिए। अगर किसी ज्ञात खामी को अगली रिलीज़ तक छोड़ा जा रहा है, तो सीमित इस्तेमाल का सीनेरियो, मालिक और रुकने की शर्त लिखिए। इन सीमाओं के बिना «रिस्क स्वीकार» का दस्तखत उस ड्यूटी इंजीनियर को कुछ नहीं बताता जो रात में समस्या से टकराएगा।

प्रोडक्शन एनवायरनमेंट में जाने को अलग से जाँचिए

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

लॉन्च से पहले प्रोडक्शन API के पते, प्राप्तकर्ता का अकाउंट, इवेंट सब्सक्रिप्शन, अनुमतियाँ, मेथड की उपलब्धता, एस्केलेशन संपर्क और नए ट्रांज़ैक्शन रोकने का सुरक्षित तरीका मिलाइए। टेस्ट रिपोर्ट में सीक्रेट शामिल मत कीजिए। एक ऐसा व्यक्ति तय कीजिए जो ऐप्लिकेशन की गलती और प्रोवाइडर की अधूरी सेटिंग में फ़र्क कर सके।

पहले अनुमत असली ट्रांज़ैक्शन की निगरानी को सहमत नियमों के तहत सीमित लॉन्च की तरह आयोजित कीजिए। उसकी जगह नकली खरीदारी, किसी और के इन्फ़्रास्ट्रक्चर पर लोड या जाँचों को बायपास करना मत अपनाइए। रुकने की शर्तें पहले से तय कीजिए, खास तौर पर दोहरे क्रेडिट, अज्ञात नतीजों और लेजर की गड़बड़ियों के लिए।

लॉन्च की तैयारी की पुष्टि सबूतों का एक पूरा सेट करता है: पास हुए गंभीर सीनेरियो, सुलझाए गए अपवाद, जाँचा गया प्रोडक्शन कॉन्फ़िगरेशन और निगरानी का ज़िम्मेदार व्यक्ति। एक सफल पेमेंट उपयोगी टेस्ट बना रहता है, लेकिन इस सेट की जगह नहीं लेता।