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