PCI-DSS Luhn कार्ड सत्यापन

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

यह क्यों महत्वपूर्ण है

किसी भी API को — यहाँ तक कि वैध पेमेंट प्रोसेसर को भी — कच्चे कार्ड नंबर भेजना PCI-DSS अनुपालन का एक गंभीर उल्लंघन है। आपके लॉग में एक भी लीक हुआ कार्ड नंबर या गलत रूट हुआ अनुरोध नियामक जुर्माने और धोखाधड़ी की देनदारी का कारण बन सकता है। MirApi इस जोखिम को प्रॉक्सी लेयर पर समाप्त कर देता है — इससे पहले कि अनुरोध आपके इन्फ्रास्ट्रक्चर से बाहर जाए।

शून्य स्थायित्व: अनुरोध बॉडी को केवल मेमोरी में स्कैन किया जाता है। यदि कार्ड नंबर का पता चलता है और उसे ब्लॉक कर दिया जाता है, तब भी बॉडी की सामग्री कभी भी लॉग, डिस्क, या किसी स्थायी स्टोरेज में नहीं लिखी जाती। केवल मेटाडेटा रिकॉर्ड किया जाता है: क्लाइंट IP, Unix टाइमस्टैम्प, और ग्रुप ID।

यह कैसे काम करता है

प्रत्येक अनुरोध पर, अपस्ट्रीम API को फॉरवर्ड करने से पहले:

कच्ची अनुरोध बॉडी को मेमोरी में पढ़ा जाता है
regex स्कैन का उपयोग करके 13–16 लगातार अंकों के सभी अनुक्रम निकाले जाते हैं
प्रत्येक अनुक्रम को Luhn एल्गोरिदम (सभी प्रमुख कार्ड ब्रांडों द्वारा उपयोग किया जाने वाला चेकसम सत्यापन) से जाँचा जाता है
यदि कोई भी अनुक्रम Luhn जाँच पास करता है → अनुरोध को तुरंत ब्लॉक कर दिया जाता है 400 Bad Request के साथ
ब्लॉक को आपके डैशबोर्ड में ऑडिट ट्रेल के लिए (केवल मेटाडेटा) लॉग किया जाता है

यह सत्यापन idempotency जाँच, retry लॉजिक, और अपस्ट्रीम फॉरवर्डिंग से पहले चलता है — बॉडी प्रॉक्सी से बाहर नहीं जाती।

ब्लॉक किए गए अनुरोध का उदाहरण

curl -X POST https://proxy.mirapi.io/ \
  -H "X-MirApi-Key: $MIRAPI_KEY" \
  -H "X-Target-URL: https://api.stripe.com/v1/charges" \
  -d '{"card_number": "4111111111111111", "amount": 15000}'

प्रतिक्रिया:

HTTP/1.1 400 Bad Request
Content-Type: text/plain

Error: Clear-text payment data detected. Please use tokenization (Stripe/Braintree tokens) instead of raw card numbers.

क्या ब्लॉक होता है (और क्यों)

Luhn एल्गोरिदम उद्योग-मानक चेकसम है जिसका उपयोग सभी प्रमुख कार्ड ब्रांड करते हैं। कोई भी अंक अनुक्रम जो:

13–16 अंक लंबा हो (अंकों के बीच कोई स्पेस, डैश, या अन्य वर्ण नहीं)
Luhn चेकसम पास करे

…उसे संभावित कार्ड नंबर माना जाता है और ब्लॉक कर दिया जाता है।

पहचाने जाने वाले कार्ड में शामिल हैं:

ब्रांड	लंबाई	प्रीफ़िक्स
Visa	16 अंक	`4` से शुरू
Mastercard	16 अंक	`51-55` या `2221-2720` से शुरू
American Express	15 अंक	`34` या `37` से शुरू
Discover	16 अंक	`6011`, `622`, `64`, या `65` से शुरू
Diners Club	14–16 अंक	`300-305`, `309`, `36`, `38`, या `39` से शुरू

क्या पास होता है

सत्यापनकर्ता केवल वैध कार्ड नंबरों को ब्लॉक करता है (जो Luhn जाँच पास करते हैं)। जो नंबर कार्ड नंबर जैसे दिखते हैं लेकिन Luhn चेकसम में विफल होते हैं, उन्हें पास होने दिया जाता है। उदाहरण के लिए:

{"amount": 49.431, "currency": "4444121111112222"}

अनुक्रम 4444121111112222 Luhn चेकसम में विफल होता है → इसे कार्ड नंबर के रूप में नहीं पहचाना जाता → अनुरोध पास हो जाता है। अपनी अनुरोध बॉडी में कच्चे कार्ड नंबरों की बजाय हमेशा टोकनाइज़ड मानों (Stripe टोकन जैसे tok_visa, pm_xxx, src_xxx) का उपयोग करें।

सही उपयोग — टोकन का उपयोग करें

कच्चा कार्ड डेटा भेजने की बजाय, अपने पेमेंट प्रोवाइडर के टोकनाइज़ेशन का उपयोग करें:

# ❌ गलत — ब्लॉक हो जाएगा
curl -X POST https://proxy.mirapi.io/ \
  -H "X-MirApi-Key: $MIRAPI_KEY" \
  -H "X-Target-URL: https://api.stripe.com/v1/charges" \
  -d '{"card": "4111111111111111", "amount": 2000}'

# ✅ सही — टोकनाइज़्ड कार्ड (Stripe.js या मोबाइल SDK टोकन बनाता है)
curl -X POST https://proxy.mirapi.io/ \
  -H "X-MirApi-Key: $MIRAPI_KEY" \
  -H "X-Target-URL: https://api.stripe.com/v1/charges" \
  -H "X-Identity-Key: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"source": "tok_visa", "amount": 2000, "currency": "usd"}'

Stripe टोकन (tok_*), Payment Methods (pm_*), और Setup Intents (seti_*) में कभी भी कच्चे कार्ड नंबर नहीं होते — ये अपारदर्शी संदर्भ होते हैं जिन्हें Stripe सर्वर-साइड resolve करता है।

ऑडिट लॉगिंग

जब किसी कार्ड नंबर का पता चलता है और उसे ब्लॉक किया जाता है, तो MirApi निम्नलिखित मेटाडेटा रिकॉर्ड करता है (बॉडी कभी संग्रहीत नहीं होती):

फ़ील्ड	विवरण
`client_ip`	अनुरोधकर्ता का IP पता
`timestamp`	ब्लॉक किए गए अनुरोध का Unix टाइमस्टैम्प
`group_id`	आपका ग्रुप पहचानकर्ता

यह ऑडिट लॉग आपके डैशबोर्ड के Security Events अनुभाग में दिखाई देता है।