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

> Published: 2026-07-28
> Updated: 2026-07-28
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/hi/blog/pci

यदि कार्ड डेटा आपके द्वारा लिखे गए कोड को कभी भी छूता है, तो आपको PCI DSS की पूरी ज़िम्मेदारी उठानी होगी। यहाँ SAQ A से SAQ D तक का विस्तार क्रम, कार्ड-मौजूद (card-present) भुगतानों को प्रमाणित हार्डवेयर की आवश्यकता क्यों है, और ऐसा निर्माण कैसे करें कि इनमें से कुछ भी आप पर न आए, इस बारे में बताया गया है।

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

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

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

PCI DSS (पेमेंट कार्ड इंडस्ट्री डेटा सिक्योरिटी स्टैंडर्ड) एक संविदात्मक दायित्व है, कोई कानून नहीं। कार्ड नेटवर्क इसे बैंकों और भुगतान प्रोसेसरों पर लागू करते हैं, और वे इसे व्यापारियों और उन व्यापारियों द्वारा चलाए जाने वाले सॉफ्टवेयर पर लागू करते हैं। वर्तमान संस्करण 4.0.1 है, और इसकी नई आवश्यकताओं की अंतिम लहर 31 मार्च, 2025 को अनिवार्य हो गई है[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)। यह मानक नेटवर्क सुरक्षा और एन्क्रिप्शन से लेकर एक्सेस कंट्रोल और लॉगिंग तक 12 आवश्यकता श्रेणियों में फैला हुआ है, जो सैकड़ों व्यक्तिगत नियंत्रणों में विस्तृत होते हैं[²](https://secureframe.com/blog/pci-saq)।

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

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

दायरा ही पूरा खेल है। PCI DSS उन सभी सिस्टमों पर लागू होता है जो कार्डधारक डेटा को स्टोर, प्रोसेस या ट्रांसमिट करते हैं, साथ ही उन सिस्टमों से जुड़े सभी चीज़ों पर भी लागू होता है। सत्यापन एक सीढ़ी की तरह काम करता है, और प्रत्येक पायदान पिछले वाले की तुलना में काफी भारी है[²](https://secureframe.com/blog/pci-saq):

- **SAQ A** (सेल्फ-असेसमेंट क्वेश्चनर A): भुगतान पूरी तरह से एक अनुपालन प्रदाता को आउटसोर्स किए जाते हैं और कार्ड डेटा आपके सिस्टम को कभी नहीं छूता है। सबसे छोटी प्रश्नावली।
- **SAQ A-EP**: आपकी साइट कभी भी कार्ड डेटा को स्पर्श नहीं करती है, लेकिन यह नियंत्रित करती है कि ग्राहक भुगतान फॉर्म तक कैसे पहुँचते हैं। पूर्ण मानक का एक बड़ा हिस्सा अब आपके वेब सर्वर पर लागू होता है।
- **SAQ D**: कार्ड डेटा आपके द्वारा बनाई गई किसी भी चीज़ से होकर गुज़रता है, भले ही थोड़े समय के लिए या बिना स्टोर किए। प्रभावी रूप से पूरा मानक, जिसे हर साल प्रलेखित और सत्यापित किया जाता है।

![अनुपालन दस्तावेज़ीकरण का ढेर जिसके ऊपर क्रेडिट कार्ड रखा है, जो PCI DSS सेल्फ-असेसमेंट प्रश्नावली का प्रतिनिधित्व करता है](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0c4ed4b3d666d99c-pci-saq-paperwork-stack.png)

सबसे निचला पायदान भी "कुछ नहीं" नहीं है। जनवरी 2025 में PCI सुरक्षा मानक परिषद ने SAQ A से भुगतान-पेज स्क्रिप्ट आवश्यकताओं को हटा दिया, लेकिन एक पात्रता शर्त जोड़ी: आपको यह पुष्टि करनी होगी कि आपकी साइट ऐसी स्क्रिप्ट हमलों के प्रति संवेदनशील नहीं है जो आपके ई-कॉमर्स सिस्टम को प्रभावित कर सकते हैं[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)। यहाँ तक कि पूरी तरह से आउटसोर्स किया गया स्तर भी आपसे उस पेज की रक्षा करने की अपेक्षा करता है जो किसी अन्य के भुगतान फॉर्म को होस्ट करता है।

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

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

नहीं। व्यक्तिगत रूप से किए जाने वाले भुगतान वे स्थान हैं जहां सीढ़ी एक दीवार बन जाती है। कार्ड-मौजूद लेनदेन के लिए प्रमाणित हार्डवेयर की आवश्यकता होती है: भौतिक रीडर जो काउंसिल के [PTS लैब प्रोग्राम](https://www.pcisecuritystandards.org/standards/pts-point-of-interaction-poi/) को पास कर चुके हों, स्वीकृत फर्मवेयर चला रहे हों, और भुगतान प्रोसेसर के माध्यम से प्रदान किए गए हों। केवल सॉफ्टवेयर की मदद से किसी फोन को रीडर में बदलना एक अलग मानक [Mobile Payments on COTS (MPoC)](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/) के अंतर्गत आता है, और यह समाधान प्रदाता को प्रमाणित करता है, आपके बिल्ड को नहीं।

![दुकान के काउंटर पर बिना ब्रांड वाला प्रमाणित भुगतान टर्मिनल, हार्डवेयर परत जो कार्ड-मौजूद भुगतानों के लिए PCI द्वारा आवश्यक है](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0d02d9e5e5229253-certified-payment-terminal-counter.jpg)

यह एक ऐसी सीमा है जिसे AI कोड जेनरेशन पार नहीं कर सकता। एक मॉडल एक दोपहर में एक आकर्षक चेकआउट स्क्रीन तैयार कर सकता है; [Can You Build a POS with Lovable or Replit?](/blog/build-a-pos-with-lovable-or-replit) और [Vibe Coding a Point of Sale](/blog/vibe-coding-a-point-of-sale) बताते हैं कि वे बिल्ड कहाँ रुक जाते हैं। कोई भी जनरेट किया गया कोड एक प्रमाणित रीडर, एक एक्वायरिंग समझौता, या अनुपालन का सत्यापन नहीं दे सकता, चाहे [मॉडल बिना किसी निगरानी के कितनी भी देर कोड क्यों न करे](/blog/claude-opus-5-pos-more-than-code)। अनुपालन एक आवर्ती कारण भी है जिसकी वजह से [वाइब-कोडेड भुगतान ऐप्स को ऐप स्टोर से अस्वीकृत कर दिया जाता है](/blog/why-vibe-coded-payment-apps-get-rejected)।

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

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

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

![शीशे के केस में सील किया गया क्रेडिट कार्ड, जो कार्ड डेटा को PCI के दायरे से बाहर रखने का प्रतीक है](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2630089c92683ed9-card-data-out-of-scope-glass-case.jpg)

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

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

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

यही वह आर्किटेक्चर है जिससे Final भी इसे संभालता है। Final पर बनाया गया चेकआउट, चाहे Build में प्रॉम्प्ट किया गया हो या आपके अपने AI द्वारा MCP के माध्यम से बनाया गया हो, Final Pay के माध्यम से अपने भुगतान चलाता है: एक भुगतान प्रोसेसर और प्रमाणित टर्मिनल हार्डवेयर कार्ड डेटा को संभालते हैं, इसलिए फ्लो स्वयं कभी भी कार्ड नंबर का मालिक नहीं होता है। [Where Final Pay is available](https://finalpos.com/help/where-final-pay-is-available) व्यावहारिक पक्ष को कवर करता है, और [Connecting Tap to Pay to an AI POS Flow](/blog/connecting-tap-to-pay-to-an-ai-pos-flow) दिखाता है कि अनुपालन परत पहले से मौजूद होने पर कार्ड स्वीकृति कैसी दिखती है।

## FAQ

**Q: क्या PCI अनुपालन एक कानूनी आवश्यकता है?**
A: नहीं। PCI DSS बैंकों और भुगतान प्रोसेसरों के माध्यम से कार्ड नेटवर्क द्वारा लगाया गया एक संविदात्मक दायित्व है। इसके परिणाम व्यावसायिक हैं: आपके एक्वायरिंग बैंक के माध्यम से दिए जाने वाले जुर्माने, उच्च प्रसंस्करण दरें, या कार्ड स्वीकार करने की क्षमता खो देना।

**Q: क्या भुगतानों को पूरी तरह से आउटसोर्स करने से PCI दायित्व समाप्त हो जाते हैं?**
A: नहीं। पूरी तरह से आउटसोर्स करने वाले व्यापारी सबसे छोटी प्रश्नावली, SAQ A से सत्यापन कर सकते हैं, लेकिन जनवरी 2025 के संशोधन के बाद से उन्हें यह भी पुष्टि करनी होगी कि उनकी साइट ऐसी स्क्रिप्ट हमलों के प्रति संवेदनशील नहीं है जो ई-कॉमर्स सिस्टम को प्रभावित कर सकती हैं।

**Q: SAQ A और SAQ D के बीच क्या अंतर है?**
A: SAQ A तब लागू होता है जब कोई अनुपालन करने वाला तीसरा पक्ष सभी कार्ड डेटा को संभालता है और यह मानक के एक छोटे हिस्से को कवर करता है। SAQ D तब लागू होता है जब कार्ड डेटा आपके अपने सिस्टम को छूता है और यह प्रभावी रूप से पूरे मानक को कवर करता है, जिसे सालाना सत्यापित किया जाता है।

**Q: क्या AI द्वारा जनरेट किया गया ऐप PCI अनुपालन कर सकता है?**
A: कोड सुरक्षित पैटर्न का पालन कर सकता है, लेकिन अनुपालन व्यवसाय और उसके इन्फ्रास्ट्रक्चर से जुड़ता है: प्रमाणित कार्ड रीडर, एक प्रोसेसर समझौता और एक वार्षिक सत्यापन। कोई भी जनरेट किया गया कोड ये चीज़ें प्रदान नहीं करता है।

**Q: PCI DSS का कौन सा संस्करण वर्तमान में प्रभावी है?**
A: इस लेख के प्रकाशन के समय तक PCI DSS 4.0.1। इसकी अंतिम भविष्य-दिनांकित आवश्यकताएं 31 मार्च, 2025 को अनिवार्य हो गईं। वर्तमान स्थिति के लिए PCI सुरक्षा मानक परिषद की साइट देखें।