ऐप डेवलपर्स के लिए PCI अनुपालन: एक संक्षिप्त, कठिन संस्करण

PCI अनुपालन (कार्ड डेटा संभालने वाले किसी भी व्यक्ति के लिए पेमेंट कार्ड उद्योग के सुरक्षा नियम) "क्रेडिट कार्ड स्वीकार करता है" शब्दों की कीमत है। संक्षेप में: यदि कार्ड डेटा कभी भी आपके द्वारा लिखे गए कोड या आपके द्वारा चलाए जाने वाले सर्वर को छूता है, तो आपको सैकड़ों नियंत्रणों, एक वार्षिक सत्यापन (एक औपचारिक हस्ताक्षरित घोषणा कि आप मानकों को पूरा करते हैं), और आपके भुगतान प्रोसेसर के माध्यम से मिलने वाले परिणामों वाले सुरक्षा मानक की ज़िम्मेदारी लेनी होगी। ऐप डेवलपर्स के लिए PCI अनुपालन का कठिन पक्ष: अधिकांश लोगों को यह तब पता चलता है जब चेकआउट पहले ही बन चुका होता है।

विशिष्ट विवरणों से पहले एक नोट। नीचे दी गई संस्करण संख्याएं, तिथियां और प्रश्नावली के नियम प्रकाशन के समय तक सटीक हैं; मानक बदलते रहते हैं, इसलिए विवरणों को एक स्नैपशॉट के रूप में देखें।

वास्तव में PCI अनुपालन क्या है?

PCI DSS (पेमेंट कार्ड इंडस्ट्री डेटा सिक्योरिटी स्टैंडर्ड) एक संविदात्मक दायित्व है, कोई कानून नहीं। कार्ड नेटवर्क इसे बैंकों और भुगतान प्रोसेसरों पर लागू करते हैं, और वे इसे व्यापारियों और उन व्यापारियों द्वारा चलाए जाने वाले सॉफ्टवेयर पर लागू करते हैं। वर्तमान संस्करण 4.0.1 है, और इसकी नई आवश्यकताओं की अंतिम लहर 31 मार्च, 2025 को अनिवार्य हो गई है¹। यह मानक नेटवर्क सुरक्षा और एन्क्रिप्शन से लेकर एक्सेस कंट्रोल और लॉगिंग तक 12 आवश्यकता श्रेणियों में फैला हुआ है, जो सैकड़ों व्यक्तिगत नियंत्रणों में विस्तृत होते हैं²।

कोई नियामक आपके दरवाजे पर नहीं आता। इसके परिणाम व्यावसायिक रूप से आते हैं: आपके एक्वायरिंग बैंक (वह बैंक जो मर्चेंट के लिए कार्ड भुगतानों का निपटान करता है) के माध्यम से दिए जाने वाले जुर्माने, उच्च प्रसंस्करण दरें, और सबसे खराब स्थिति में कार्ड स्वीकार करने की क्षमता खो देना। डेटा उल्लंघन (breach) के बाद, फॉरेंसिक जांच और कार्ड फिर से जारी करने की लागत इसी रास्ते से आती है।

"बस भुगतान जोड़ें" आपके पूरे ऐप को इसके दायरे में क्यों ले आता है?

दायरा ही पूरा खेल है। PCI DSS उन सभी सिस्टमों पर लागू होता है जो कार्डधारक डेटा को स्टोर, प्रोसेस या ट्रांसमिट करते हैं, साथ ही उन सिस्टमों से जुड़े सभी चीज़ों पर भी लागू होता है। सत्यापन एक सीढ़ी की तरह काम करता है, और प्रत्येक पायदान पिछले वाले की तुलना में काफी भारी है²:

• SAQ A (सेल्फ-असेसमेंट क्वेश्चनर A): भुगतान पूरी तरह से एक अनुपालन प्रदाता को आउटसोर्स किए जाते हैं और कार्ड डेटा आपके सिस्टम को कभी नहीं छूता है। सबसे छोटी प्रश्नावली।

• SAQ A-EP: आपकी साइट कभी भी कार्ड डेटा को स्पर्श नहीं करती है, लेकिन यह नियंत्रित करती है कि ग्राहक भुगतान फॉर्म तक कैसे पहुँचते हैं। पूर्ण मानक का एक बड़ा हिस्सा अब आपके वेब सर्वर पर लागू होता है।

• SAQ D: कार्ड डेटा आपके द्वारा बनाई गई किसी भी चीज़ से होकर गुज़रता है, भले ही थोड़े समय के लिए या बिना स्टोर किए। प्रभावी रूप से पूरा मानक, जिसे हर साल प्रलेखित और सत्यापित किया जाता है।

सबसे निचला पायदान भी "कुछ नहीं" नहीं है। जनवरी 2025 में PCI सुरक्षा मानक परिषद ने SAQ A से भुगतान-पेज स्क्रिप्ट आवश्यकताओं को हटा दिया, लेकिन एक पात्रता शर्त जोड़ी: आपको यह पुष्टि करनी होगी कि आपकी साइट ऐसी स्क्रिप्ट हमलों के प्रति संवेदनशील नहीं है जो आपके ई-कॉमर्स सिस्टम को प्रभावित कर सकते हैं¹। यहाँ तक कि पूरी तरह से आउटसोर्स किया गया स्तर भी आपसे उस पेज की रक्षा करने की अपेक्षा करता है जो किसी अन्य के भुगतान फॉर्म को होस्ट करता है।

प्रति वर्ष साठ लाख से अधिक कार्ड लेनदेन के बाद, स्व-मूल्यांकन पूरी तरह से समाप्त हो जाता है और QSA (एक प्रमाणित बाहरी मूल्यांकनकर्ता) द्वारा ऑन-साइट ऑडिट शुरू होता है²।

क्या आप कार्ड-मौजूद (card-present) भुगतानों के लिए कोड के ज़रिए रास्ता निकाल सकते हैं?

नहीं। व्यक्तिगत रूप से किए जाने वाले भुगतान वे स्थान हैं जहां सीढ़ी एक दीवार बन जाती है। कार्ड-मौजूद लेनदेन के लिए प्रमाणित हार्डवेयर की आवश्यकता होती है: भौतिक रीडर जो काउंसिल के PTS लैब प्रोग्राम को पास कर चुके हों, स्वीकृत फर्मवेयर चला रहे हों, और भुगतान प्रोसेसर के माध्यम से प्रदान किए गए हों। केवल सॉफ्टवेयर की मदद से किसी फोन को रीडर में बदलना एक अलग मानक Mobile Payments on COTS (MPoC) के अंतर्गत आता है, और यह समाधान प्रदाता को प्रमाणित करता है, आपके बिल्ड को नहीं।

यह एक ऐसी सीमा है जिसे AI कोड जेनरेशन पार नहीं कर सकता। एक मॉडल एक दोपहर में एक आकर्षक चेकआउट स्क्रीन तैयार कर सकता है; Can You Build a POS with Lovable or Replit? और Vibe Coding a Point of Sale बताते हैं कि वे बिल्ड कहाँ रुक जाते हैं। कोई भी जनरेट किया गया कोड एक प्रमाणित रीडर, एक एक्वायरिंग समझौता, या अनुपालन का सत्यापन नहीं दे सकता, चाहे मॉडल बिना किसी निगरानी के कितनी भी देर कोड क्यों न करे। अनुपालन एक आवर्ती कारण भी है जिसकी वजह से वाइब-कोडेड भुगतान ऐप्स को ऐप स्टोर से अस्वीकृत कर दिया जाता है।

डेवलपर्स वास्तव में PCI के दायरे को कैसे कम करते हैं?

आप अनुपालन के लिए अतिरिक्त प्रयास नहीं करते; आप इस तरह आर्किटेक्ट करते हैं कि अनुपालन के लिए कम से कम चीज़ें बचें:

• PAN (प्राइमरी अकाउंट नंबर, यानी कार्ड नंबर) को कभी भी अपने कोड को न छूने दें। अपने प्रोसेसर के होस्ट किए गए भुगतान फ़ील्ड का उपयोग करें ताकि कार्ड डेटा ग्राहक के ब्राउज़र से सीधे प्रोसेसर तक जाए।

• कार्ड के बजाय टोकन स्टोर करें। टोकनाइज़ेशन (कार्ड नंबर को एक संदर्भ स्ट्रिंग से बदलना जो चोरी होने पर बेकार है) सहेजे गए कार्ड और रिफंड को आपके डेटाबेस को दायरे में लाने से रोकता है।

• व्यक्तिगत रूप से होने वाली बिक्री के लिए, अपने प्रोसेसर से प्रमाणित रीडर का उपयोग करें ताकि कार्ड डेटा आपके ऐप से गुज़रे बिना सीधे रीडर से प्रोसेसर तक पहुँचे।

• भुगतान पेज को सरल रखें। उस पर मौजूद प्रत्येक थर्ड-पार्टी स्क्रिप्ट एक ऐसी चीज़ बन जाती है जिसका हिसाब आपको देना पड़ता है।

सही तरीके से किए जाने पर, आपका ऐप कभी भी कार्ड डेटा रखे बिना एक बिक्री का समन्वय (orchestrate) करता है, और प्रश्नावली छोटी रहती है। गलत तरीके से किए जाने पर, एक सुविधा फ़ीचर ("बस पूरी रिक्वेस्ट बॉडी को लॉग करें") चुपचाप आपको SAQ D में बदल देता है।

तो ऐप डेवलपर्स के लिए PCI अनुपालन कितना कठिन है?

यह इस बात के अनुपात में कठिन है कि आपका कोड कितने कार्ड डेटा को छूता है, यही वजह है कि सबसे समझदारी भरा कदम यह है कि इसे बिल्कुल न छुआ जाए। मानक को इससे कोई फ़र्क नहीं पड़ता कि आपके ऐप को किसी डेवलपर टीम ने लिखा है या किसी AI ने इसे एक दोपहर में बनाया है; दायरा तो दायरा है। कार्ड स्वीकार करने वाली किसी भी चीज़ को शिप करने से पहले, एक सवाल पूछें: क्या कोई कार्ड नंबर कभी मेरे द्वारा लिखे गए कोड से होकर गुज़र सकता है? यदि हां, तो ऑडिट के लिए बजट बनाएं। यदि नहीं, तो इसे ऐसा ही रहने दें।

यही वह आर्किटेक्चर है जिससे Final भी इसे संभालता है। Final पर बनाया गया चेकआउट, चाहे Build में प्रॉम्प्ट किया गया हो या आपके अपने AI द्वारा MCP के माध्यम से बनाया गया हो, Final Pay के माध्यम से अपने भुगतान चलाता है: एक भुगतान प्रोसेसर और प्रमाणित टर्मिनल हार्डवेयर कार्ड डेटा को संभालते हैं, इसलिए फ्लो स्वयं कभी भी कार्ड नंबर का मालिक नहीं होता है। Where Final Pay is available व्यावहारिक पक्ष को कवर करता है, और Connecting Tap to Pay to an AI POS Flow दिखाता है कि अनुपालन परत पहले से मौजूद होने पर कार्ड स्वीकृति कैसी दिखती है।