परीक्षण क्रेडिट कार्ड नंबर: ये क्या हैं और कहाँ उपयोग करें

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

परीक्षण क्रेडिट कार्ड नंबर असल में क्या है

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

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

व्यवहारिक अर्थ यह है कि इस संदर्भ में मान्य का मतलब केवल सही ढाँचे वाला है। यह गणित और लंबाई के बारे में एक कथन है, स्वामित्व या स्थिति के बारे में नहीं।

परीक्षण नंबरों की ज़रूरत आखिर क्यों पड़ी?

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

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

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

क्या परीक्षण नंबर पर कभी शुल्क लग सकता है?

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

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

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

परीक्षण नंबर कहाँ सुरक्षित हैं

असली अंतर यह है कि कोई सिस्टम नंबर को केवल पढ़ता है या उस पर शुल्क लगाने की कोशिश भी करता है। घटती सुरक्षा के क्रम में मोटे तौर पर:

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

यह सूची उसी क्षण सुरक्षित रहना बंद कर देती है जब विन्यास में असली गेटवे कुंजी आ जाती है। यदि आपका स्टेजिंग वातावरण उत्पादन क्रेडेंशियल साझा करता है — और कई करते हैं — तो बनाया गया नंबर परीक्षण डेटा नहीं रहता, वह शुल्क लगाने का प्रयास बन जाता है।

ऐसे नंबर चुनें जिन्हें दोहराया जा सके

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

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

दो आदतें इसे बहुत आसान बना देती हैं। हर फ़िक्स्चर समूह को तारीख के बजाय छोटा वर्णनात्मक नाम दें, और यह दर्ज करें कि कौन सा नंबर किस नेटवर्क का दावा करता है, ताकि विफलता रिपोर्ट बताए कि पहचान की कौन सी शाखा देखनी है।

डेवलपर के लिए: व्यवहार करने वाला फ़िक्स्चर डेटा

कुछ छोटी बातें तय करती हैं कि परीक्षण नंबरों का समूह उपयोगी है या केवल रिपॉज़िटरी में मौजूद है।

पहली, डेटा पठनीय रखें। किसी इंसानी जाँच के लिए रखे गए नंबर को उसी तरह समूहित लिखें जैसे वह कार्ड पर छपा होता है, भले ही कोड सत्यापन से पहले विभाजक हटा देता हो; वह समूहन स्वयं दस्तावेज़ है। प्रारूप और सत्यापन तर्क की चर्चा प्रारूप गाइड तथा Luhn एल्गोरिदम पर लेख में है, जो वही जाँच है जिसे अंतिम अंक को पूरा करना होता है।

दूसरी, सीमाओं को जानबूझकर शामिल करें। केवल सोलह अंकों वाले Visa नंबर रखने वाला समूह पंद्रह अंकों वाले American Express की शाखा को कभी नहीं छूएगा, और सत्रह अंकों की प्रविष्टि ठुकराने वाले कोड तक पहुँचेगा ही नहीं। जितने लंबाई नियम आप समर्थित मानते हैं, उतने नंबर शामिल करें।

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

अंत में, यह तय करें कि डेटा गलत होने पर आपका सूट क्या करेगा। चेकसम की विफलता की सूचना खराब इनपुट के रूप में मिलनी चाहिए, भुगतान ठुकराए जाने के रूप में नहीं; दोनों को मिला देने से असली दोष वातावरण की त्रुटियों के पीछे छिप जाते हैं।

कार्ड टूल में बैच बनाना

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

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

आगे क्या करें

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