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