यदि आप पैन (कार्ड नंबर) स्टोर करते हैं तो यह बिल्कुल एन्क्रिप्टेड होना चाहिए।
यदि आप कार्डधारक का नाम, समाप्ति तिथि, निर्गम संख्या (और उन्हें पैन से लिंक किया जा सकता है) संग्रहीत करते हैं, तो उन्हें चाहिए एन्क्रिप्ट किया जा सकता है, लेकिन (मेरी समझ) यह है कि यह बिल्कुल जरूरी नहीं है। पीसीआई-डीएसएस केवल यह बताता है कि कम से कम पैन को एन्क्रिप्ट किया जाना चाहिए।
CV2/AVS/CSC कोड को प्राधिकरण के बाद संग्रहीत नहीं किया जा सकता है, और आदर्श रूप से आप यह साबित करना चाहेंगे कि यह बिल्कुल भी संग्रहीत नहीं है (जैसे - प्राधिकरण करते समय केवल स्मृति में रखा जाता है)
प्रमाणपत्र/कुंजी के संबंध में - आप सभी कार्ड संबंधी डेटा के एन्क्रिप्शन के लिए केवल एक कुंजी का उपयोग कर सकते हैं। कई उद्देश्यों के लिए कुंजियों का उपयोग नहीं करना सबसे अच्छा अभ्यास है, इसलिए यदि आपके पास अन्य (गैर कार्ड से संबंधित) डेटा एन्क्रिप्ट किया गया है, तो उसके लिए एक अलग कुंजी का उपयोग करें।
सबसे कठिन हिस्सा वह है जिसका आपने वास्तव में विस्तार से उल्लेख नहीं किया है - और वह प्रमुख प्रबंधन है। पीसीआई आवश्यकताओं को पूरा करने के लिए कुंजी को डेटाबेस में एक अलग भौतिक बॉक्स पर संग्रहीत किया जाना चाहिए, और आपको कम से कम सालाना कुंजी बदलने की क्षमता की आवश्यकता है। SQL 2008 एक्सटेंसिबल की मैनेजमेंट (EKM) के साथ इसका समर्थन करता है।
इन सभी बिंदुओं पर एक स्वतंत्र क्यूएसए (योग्य सुरक्षा निर्धारक) के साथ सबसे अच्छी तरह से चर्चा की जाती है, जिसे पीसीआई अनुपालन को पूरा करने के लिए आपको किसी बिंदु पर शामिल करने की आवश्यकता होगी। आपका क्यूएसए इस तरह के सवालों पर आपका मार्गदर्शन करने में सक्षम होगा, और अंततः उसकी सलाह है कि अनुपालन पूरा करने के लिए आपको उसका पालन करना चाहिए।
यह उल्लेखनीय है कि अधिकांश लोगों को जल्द ही एहसास हो जाता है कि पीसीआई अनुपालन कितना बोझ हो सकता है, और तीसरे पक्ष के भुगतान गेटवे का उपयोग करके उस बोझ को कम करने की कोशिश करते हैं। अधिकांश भुगतान गेटवे आपको प्राधिकरण/निपटान करने और कार्ड विवरण उनके (पहले से ही पीसीआई अनुपालन) सर्वर पर संग्रहीत करने की अनुमति देंगे। तब आपको केवल एक TokenId स्टोर करने की आवश्यकता होती है जो उन भुगतान विवरणों का संदर्भ देता है यदि आपको उस कार्ड पर और शुल्क/धनवापसी करने की आवश्यकता है।
किसी भी तरह से शुभकामनाएँ!
