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