सुरक्षा

यह अनुवाद सुविधा के लिए प्रदान किया गया है। अंग्रेजी संस्करण कानूनी रूप से बाध्यकारी है।

1. कुंजी की सुरक्षा

यह महत्वपूर्ण है, इसलिए इसे दो बार पढ़ें। डिफ़ॉल्ट रूप से, प्राप्त पते ऑपरेटर द्वारा रखे गए कुंजी सामग्री से निकाले जाते हैं, न कि आपके द्वारा: भुगतान ऑपरेटर के पते पर आते हैं और आपके बैलेंस में क्रेडिट होते हैं, और आप वहीं से निकासी करते हैं। हस्ताक्षर स्वचालित नहीं हैं - वेब एप्लिकेशन के पास अपने आप एक ट्रांसफर प्रसारित करने का कोई रास्ता नहीं है; निकासी और भुगतान ऑपरेटर द्वारा बाहर की समीक्षा, हस्ताक्षरित और प्रसारित किए जाते हैं। एक व्यापारी जो नहीं चाहता कि ऑपरेटर उनके फंड को बिल्कुल भी रखे, वह अपने स्वयं के xPub से व्युत्पत्ति के लिए पूछ सकता है; तब भुगतान केवल उन पते पर निपटते हैं जिन्हें केवल वह व्यापारी नियंत्रित करता है, और ऑपरेटर के पास कभी भी उनके कुंजी नहीं होते।

2. API और वेबहुक अखंडता

2.1 हस्ताक्षर

API अनुरोध और वेबहुक HMAC-SHA256 के साथ हस्ताक्षरित होते हैं, पुनःप्रस्तुति को सीमित करने के लिए एक टाइमस्टैम्प विंडो के साथ, और आइडेम्पोटेंसी कुंजी ताकि एक पुनः प्रयास किया गया कॉल दो बार न हो। हस्ताक्षर को स्थिर समय में तुलना की जाती है।

2.2 आउटबाउंड वेबहुक

आउटबाउंड वेबहुक्स SSRF-गार्डेड हैं: केवल https, व्यापारी द्वारा कॉन्फ़िगर किए गए URL पर भेजे जाते हैं, एक मान्य आईपी पते पर पिन किए जाते हैं, निजी, CGNAT और NAT64 रेंज को अस्वीकृत किया जाता है।

3. विश्राम में प्रमाणपत्र

पासवर्ड को bcrypt के साथ हैश किया जाता है। api_secret को AES-256-GCM के साथ आराम में एन्क्रिप्ट किया गया है। निजी कुंजी, बीज वाक्यांश और कार्ड नंबर कभी भी संग्रहीत नहीं किए जाते हैं।

4. खाता सुरक्षा

वसूली कोड के साथ वैकल्पिक TOTP दो-कारक प्रमाणीकरण। सत्र सर्वर-साइड पर ट्रैक किए जाते हैं और रद्द किए जा सकते हैं। CSRF टोकन स्थिति-परिवर्तन करने वाले अनुरोधों की सुरक्षा करते हैं। दर सीमा प्रति IP और प्रति कुंजी लागू होती है।

5. परिवहन और ब्राउज़र को मजबूत करना

HSTS, एक सामग्री सुरक्षा नीति, X-Frame-Options को DENY पर सेट किया गया है, X-Content-Type-Options nosniff, और एक Referrer-Policy।

6. धन की अखंडता

सेटलमेंट एक अपेंड-ओनली लेजर में UNIQUE आइडेम्पोटेंसी एंकर के साथ दर्ज किए जाते हैं, इसलिए एक ही जमा को दो बार क्रेडिट नहीं किया जा सकता। सलाहकार लॉक बैलेंस परिवर्तनों को अनुक्रमित करते हैं, इसलिए समवर्ती संचालन बैलेंस को गलत स्थिति में नहीं ले जा सकते।

7. हम क्या नहीं दावा करते

Payora के पास कोई PCI-DSS, SOC 2 या ISO 27001 प्रमाणन नहीं है, और न ही कोई नियामक का लाइसेंस है। जो कोई आपको इसके विपरीत बताता है, वह गलत है। सॉफ़्टवेयर ऑपरेटर को मजबूत डिफ़ॉल्ट देता है; एक चल रही उदाहरण की सुरक्षा भी ऑपरेटर के सर्वर, होस्टिंग और प्रथाओं पर निर्भर करती है।

8. इसका आपका पक्ष

अपने API रहस्य और पासवर्ड को निजी रखें। दो-कारक प्रमाणीकरण चालू करें। वेबहुक हस्ताक्षरों की पुष्टि करें बजाय इसके कि लोड पर भरोसा करें। भुगतान पते को ध्यान से जांचें, जिसमें कोई गंतव्य टैग या मेमो शामिल है, क्योंकि भेजा गया लेनदेन वापस नहीं लिया जा सकता।

9. एक कमजोरियों की रिपोर्ट करना

सुरक्षा मुद्दों की रिपोर्ट ऑपरेटर को करें support@payora.money. कृपया पुन: उत्पन्न करने के लिए पर्याप्त विवरण दें, और कृपया दूसरों के खातों या डेटा के खिलाफ परीक्षण न करें।

अंतिम अपडेट: 16 जुलाई 2026। यदि हम इस पृष्ठ में महत्वपूर्ण परिवर्तन करते हैं, तो अपडेटेड संस्करण यहां पोस्ट किया जाएगा।