2010-07-09 13 views
5

मैं एक ईकॉमर्स साइट बना रहा हूं जो भुगतान गेटवे डीपीएस का उपयोग करता है। भुगतान गेटवे सिर्फ उपयोगकर्ता के विवरण लेता है और भुगतान करता है कि भुगतान सफल था या नहीं।भुगतान सर्वोत्तम प्रथाओं को स्वीकार करना

मैं सोच रहा हूं कि किसी के पास वास्तव में मजबूत भुगतान पृष्ठ बनाने के लिए कोई अच्छा संसाधन है जो लेनदेन की बड़ी मात्रा को सुरक्षित रूप से संभाल सकता है। क्या उच्च मात्रा भुगतान पृष्ठों के लिए अच्छी तरह से परीक्षण तकनीक और रणनीतियों हैं?

+0

"लेनदेन की बड़ी मात्रा" से आपका क्या मतलब है? क्या आप हमें एक अनुमानित अनुमान दे सकते हैं? – webbiedave

+0

अपने उपयोगकर्ताओं को पेपैल, Google Checkout, ... – Stephen

+0

के साथ केवल 200 दिन प्रति दिन एक पक्ष के साथ एकीकरण और एकीकृत करें, लेकिन यह जल्द ही लगभग 1000 तक बढ़ने की उम्मीद है। तो अभी भी काफी छोटा है, लेकिन इतना बड़ा है कि हमें कुछ सावधानी बरतने और मजबूत कोड लिखने की आवश्यकता है जो सर्वर टाइमआउट और समवर्ती मुद्दों जैसे अप्रत्याशित मुद्दों को संभाल सकता है। – nick

उत्तर

1

मैं भुगतान प्रसंस्करण और ई-कॉमर्स अनुप्रयोगों के विकास पर एक विशेषज्ञ नहीं हूँ, लेकिन मेरे (commonsense) के दिशा निर्देशों में से कुछ हैं:

  1. बल HTTPS उपयोगकर्ताओं से सीसी जानकारी प्रस्तुत करने (काफी सभी भुगतान प्रसंस्करण के लिए गेटवे अपने गेटवे के साथ संवाद करते समय एसएसएल के उपयोग को मजबूर करते हैं);
  2. प्रसंस्करण के बाद डेटाबेस में क्रेडिट कार्ड की जानकारी स्टोर न करें; *
  3. सामान्य सुरक्षा दिशानिर्देशों का पालन करें (उदाहरण के लिए सादा-पाठ पासवर्ड या ई-मेल पासवर्ड न सहेजें);

* नोट:

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

मुझे भुगतान प्रक्रिया के साथ स्केलेबिलिटी समस्याओं के बारे में बहुत कुछ पता नहीं है क्योंकि मुझे उस क्षेत्र में कोई अनुभव नहीं है। मेरे सभी एप्लिकेशन केवल दिन में लगभग 5-25 ऑर्डर करते हैं।

+0

अरे आपके त्वरित उत्तर के लिए धन्यवाद। हम डीपीएस नामक एक भुगतान गेटवे का उपयोग करते हैं जो कई आवश्यक वस्तुओं का ख्याल रखता है, शेष मूलभूत बातें जिन्हें हमने स्वयं से ख्याल रखा है। वर्तमान में हम एक दिन में 200 लेनदेन कर रहे हैं और वास्तव में तेजी से बढ़ रहे हैं। मेरी चिंताओं को समेकन मुद्दों, पोस्टग्रेस लेनदेन और सर्वर टाइमआउट के बारे में अधिक जानकारी थी। यदि कोई वास्तव में एक मजबूत भुगतान पृष्ठ के बारे में जानता है जो ओपन सोर्स या कोई संसाधन है, तो लेनदेन की बड़ी मात्रा में सुरक्षित तरीके से निपटने के लिए कैसे बहुत सराहना की जाएगी! – nick

+0

आह, ऐसा लगता है कि आपकी चिंता आपके आवेदन की अपनी भुगतान प्रक्रिया (चालान उत्पन्न/संग्रहित) के साथ है, भुगतान गेटवे के साथ बातचीत नहीं; क्या वो सही है? –

+0

हाँ यह ठीक है – nick

0

ऋषि (पूर्व में प्रोटक्स) का उपयोग करें, यह पेपैल का समर्थन करता है और आपको कार्ड भुगतान लेने की अनुमति देता है। यह ऋषि सूट (एक accoutants सपने) में भी एकीकृत करता है यह डेटा प्रविष्टि उपभोग करने में बहुत समय स्वचालित कर सकते हैं।

www.sagepay.com

के रूप में दूसरों को कह रहे हैं - कभी कभी छोटे साइटों यह कार्ड अपने आप को संग्रहीत करने का जोखिम ले लायक नहीं है के लिए। मैं उन वेबसाइटों पर भुगतान करना पसंद करता हूं जहां मुझे एक प्रसिद्ध भुगतान सेवा (जैसे पेपैल, ऋषि या Google चेकआउट) पर रीडायरेक्ट किया जाता है क्योंकि मुझे पता है कि इस सॉफ्टवेयर को सुरक्षित करने पर बहुत पैसा खर्च किया जाता है। यदि आप ऐसी वेबसाइट हैं जो मैं पहली बार उपयोग कर रहा हूं, तो मुझे छोड़ दिया जा रहा है।

3

आप अपना कोड इस तरह से डिजाइन करना चाहते हैं जैसे आपके डेटा को वैध स्थिति में रखा गया हो।

आपके सामने आने वाली बड़ी देयता यह है कि आप किसी भी कारण से डेटा को भेजते हैं, और फिर, आपके अंत में कुछ विफल रहता है। आपने अपने ग्राहक से शुल्क लिया है, लेकिन किसी भी कारण से, आप इस तथ्य को नहीं जानते! आखिरकार, कुछ परेशान ग्राहक फोन पर आप पर चिल्ला रहे हैं। यह एक बुरा समय है।

सामान्य विचार कुछ सुरक्षा उपायों को रखना है ताकि आप इन प्रकार की समस्याओं की पहचान कर सकें। समस्या बहुत दुर्लभ होनी चाहिए, अगर यह कभी भी होता है, तो गड़बड़ी को ठीक करना शायद मैन्युअल प्रक्रिया होगी।

यहाँ मैं क्या कर सकता है:

  1. डिजाइन एक डेटाबेस तालिका है कि भुगतान पटरियों (इसे "भुगतान" कहते हैं), और इसे अपने "आदेश" तालिका से संबंधित हैं (ताकि payment.order_id संदर्भ order.id)।
  2. जब आपके गेटवे से बातचीत करने का समय हो, तो एक नया भुगतान रिकॉर्ड स्थापित करें, जिसमें कोई भी गैर-संवेदनशील डेटा है जिसे आप भुगतान गेटवे में पास करने वाले हैं। अपनी भुगतान तालिका में "स्थिति" कॉलम रखें, और इसे "लंबित"
  3. पर सेट करें अपने गेटवे के साथ ऑथ/कैप्चर लेनदेन का प्रयास करें। प्रतिक्रिया प्राप्त करने पर, "अनुमोदित", "अस्वीकृत", या "त्रुटि" में भुगतान रिकॉर्ड स्थिति अपडेट करें और किसी भी प्रासंगिक मेटाडेटा (अस्वीकृति कारण, लेनदेन आईडी इत्यादि) को सहेजें। अगर गेटवे का समय समाप्त हो जाता है, तो शायद यह सिर्फ एक प्रकार की "त्रुटि" है, हालांकि आप एक या दो बार फिर से प्रयास कर सकते हैं।

हर समय एक क्रॉन नौकरी चलाएं और फिर "लंबित" भुगतान रिकॉर्ड की तलाश करें, और 30 सेकंड से अधिक कहें। यदि आपको कोई भी पता चलता है, तो आतंक और डेवलपर/ऑपरेशंस व्यक्ति को बताएं।

निश्चित रूप से अन्य चीजें हैं जो गलत हो सकती हैं, लेकिन यह एक बड़ी बात है जो दिमाग में आती है, और मैंने जो रणनीति वर्णित की है वह एक है जिसे मैंने कई मौकों पर जोखिम को कम करने के लिए उपयोग किया है।

+0

यह आपके भुगतान रिकॉर्ड को वास्तव में संसाधित करने के साथ आपके भुगतान रिकॉर्ड को सिंक में रखने के लिए एक बहुत अच्छा तरीका लगता है। मुझे निकट भविष्य में ऐसा कुछ चाहिए और शायद इस पैटर्न को फिर से देख सके। –

संबंधित मुद्दे