एक बड़ी परियोजना में बिलिंग

एक परियोजना को "मुद्रीकृत" करने के विभिन्न तरीके हैं। लेकिन उनके पास एक चीज सामान्य है - जिस तरह से उपयोगकर्ता के वॉलेट से संगठन के खाते में पैसे ट्रांसफर होते हैं। आज हम बात करेंगे कि कैसे पेमेंट एक्सेप्टेंस का आयोजन बेथ में किया जाता है और पेमेंट गेटवे मार्केट में क्या पाया जा सकता है। हम तुरंत चेतावनी देते हैं कि लेख में आपको कंपनी के फंडों के कारोबार के लिए विशिष्ट आंकड़े नहीं मिलेंगे, लेकिन बाकी सब कुछ कम दिलचस्प नहीं होगा।

बिलिंग क्या है?

हमारे लिए, बिलिंग वह सब है जो उपयोगकर्ताओं से धन प्राप्त करने से संबंधित है: मूल्य कॉन्फ़िगरेशन, भुगतान स्वीकृति पृष्ठ, सीधे स्वीकार करना और भुगतान करना, भुगतान की गई सेवाएं प्रदान करना, विभिन्न पदोन्नति और, ज़ाहिर है, उपरोक्त सभी की निगरानी करना।

प्रारंभ में, सभी स्टार्टअप की तरह, हमारे पास सेवाओं का भुगतान नहीं था। विमुद्रीकरण की दिशा में पहला गंभीर कदम 2008 में वापस शुरू हुआ, इस तथ्य के बावजूद कि साइट को आधिकारिक तौर पर 2006 में लॉन्च किया गया था। प्रयोगों के लिए, फ्रांस को चुना गया था, और भुगतान केवल एसएमएस के माध्यम से स्वीकार किया गया था। भुगतान स्वीकृति स्वयं फाइलों पर आयोजित की गई थी। प्रत्येक अनुरोध को एक अलग फ़ाइल में लिखा गया था, जिसे बाद में एक फ़ोल्डर से दूसरे में स्क्रिप्ट के माध्यम से स्थानांतरित किया गया था, जिसका मतलब प्रसंस्करण स्थितियों में बदलाव था। डेटाबेस का उपयोग केवल सफलतापूर्वक संसाधित लेनदेन रिकॉर्ड करने के लिए किया गया था। इस तरह की एक योजना ने एक साल से थोड़ा अधिक समय तक सफलतापूर्वक काम किया, जिसके बाद इसे बनाए रखना मुश्किल हो गया, और हमने फाइलों को छोड़ने और डेटाबेस का उपयोग करके सब कुछ फिर से लिखने का फैसला किया।

नए संस्करण का विकास काफी तेज था, क्योंकि कई ऐसे देश नहीं थे जहां भुगतान की गई सेवाएं उपलब्ध थीं। लेकिन यह केवल एसएमएस के माध्यम से भुगतान प्राप्त करने के लिए डिज़ाइन किया गया था, इस वजह से हमारे पास अभी भी कई मज़ेदार कलाकृतियाँ हैं, उदाहरण के लिए, MSISDN (फोन नंबर) और शॉर्ट कोड (जिस नंबर पर भुगतान किया गया एसएमएस भेजा जाता है) संसाधित तालिका में फ़ील्ड्स भुगतान।

अब हम लगभग पूरी दुनिया में भुगतान स्वीकार करते हैं। हर सेकंड, उपयोगकर्ता साइट पर या सभी लोकप्रिय मोबाइल प्लेटफार्मों के लिए एप्लिकेशन में कुछ के लिए भुगतान करने का प्रयास करते हैं। और यदि आप इसे मानचित्र पर रखते हैं, तो आपको "रात में अंतरिक्ष से पृथ्वी का दृश्य" चित्र मिलता है:



हमारे पास विभिन्न भागीदारों से लगभग 50 भुगतान विधियां उपलब्ध हैं। मोबाइल एप्लिकेशन में बैंक कार्ड, एसएमएस और डायरेक्ट बिलिंग और खरीदारी सबसे लोकप्रिय हैं।



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

बैंक भुगतान

सभी भुगतान प्रणाली आपको अपने उपयोगकर्ताओं से भुगतान स्वीकार करने की अनुमति देती हैं। ऐसे प्रत्यक्ष एकीकरण करना सुविधाजनक है जब तक कि उनमें से बहुत कुछ न हो और आप अच्छी तरह से ज्ञात सिस्टम को डीबग की गई प्रक्रियाओं से जोड़ दें। लेकिन जब आपको स्थानीय बाजारों में प्रवेश करने की आवश्यकता होती है, तो समस्याएं दिखाई देने लगती हैं। विभिन्न एपीआई के "चिड़ियाघर" को बनाए रखना कठिन होता जा रहा है, नियामकों की आवश्यकताएं अलग-अलग हैं, लोकप्रिय स्थानीय भुगतान प्रणाली यहां तक ​​कि कम गति पर विदेशी ग्राहकों के साथ काम करने से इनकार कर सकती है, या अनुबंध पर हस्ताक्षर करने और कानूनी समस्याओं को हल करने में लंबा समय लग सकता है। ऐसी कठिनाइयों के बावजूद, स्थानीय भुगतान प्रणाली आपको उनके रूपांतरण के साथ सुखद रूप से आश्चर्यचकित कर सकती है। उदाहरण के लिए, नीदरलैंड, जिसे हम बहुत आशाजनक नहीं मानते थे, इस देश में लोकप्रिय iDeal भुगतान पद्धति को जोड़ने के बाद, 30-40% अधिक धन लाने के लिए शुरू किया।

अगर मांग है, तो एक प्रस्ताव होगा। बाजार पर कई एग्रीगेटर कंपनियां हैं, या, एक अन्य तरीके से, भुगतान गेटवे, जिसका उद्देश्य एकल एपीआई के तहत स्थानीय लोगों सहित सभी लोकप्रिय भुगतान प्रणालियों को एकजुट करना है। इस तरह के एक एकीकरण के बाद, हमें दुनिया भर में दर्जनों भुगतान प्रणालियों के माध्यम से भुगतान स्वीकार करने का अवसर मिलता है। आपको अपनी वेबसाइट पर भुगतान पृष्ठ भी नहीं बनाना है, लेकिन एग्रीगेटर और दर्जी द्वारा उपलब्ध कराए गए एक का उपयोग केवल अपने लिए डिजाइन करना है। विशेष रूप से उन्नत कंपनियां अपनी सीएसएस और जेएस फाइलें अपलोड करना, चित्र, अनुवाद ग्रंथों को बदलना और यहां तक ​​कि अपने उपडोमेन पर परिणामी पृष्ठ को दर्ज करना संभव बनाती हैं, उदाहरण के लिए, payment.example.com। यह "अनुकूलन" के लिए बहुत समृद्ध अवसर देता है, और उपयोगकर्ता को यह महसूस होता है कि वह आपकी साइट को नहीं छोड़ रहा है। हम घर पर इस अवसर का उपयोग नहीं करते हैं, क्योंकि हम एक ही समय में कई एग्रीगेटर के साथ काम करते हैं, लेकिन कुछ के लिए यह एक बहुत ही सुविधाजनक समाधान हो सकता है।

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

एसएमएस भुगतान

मोबाइल फोन के संतुलन से एसएमएस और सीधे कटौती के माध्यम से भुगतान अलग। वे कई देशों में बहुत तंग नियंत्रण में हैं, खासकर यूरोप में। स्थानीय नियामक या राज्य को स्वयं इस बात पर विशेष आवश्यकता हो सकती है कि भुगतान पृष्ठ कैसे दिखना चाहिए या एसएमएस संदेशों का पाठ क्या होना चाहिए। ऐसी आवश्यकताओं में परिवर्तन की निगरानी की जानी चाहिए और समय पर साइट पर किए गए बदलाव। इसलिए, उदाहरण के लिए, बेल्जियम में एक नियम है कि एक काले रंग की पृष्ठभूमि पर सफेद फ़ॉन्ट में एक छोटी संख्या लिखी जानी चाहिए, और इसकी लागत इसके बगल में इंगित की जानी चाहिए।



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

• एक छोटी संख्या में एक एसएमएस भेजें, एक विशिष्ट पाठ के साथ या इसके बिना आने वाले एसएमएस का जवाब दें;
• एसएमएस को एक छोटी संख्या पर भेजें, साइट पर प्राप्त पिन-कोड दर्ज करें;
• वेबसाइट पर फोन नंबर दर्ज करें, पिन कोड प्राप्त करें, इसे वेबसाइट पर दर्ज करें।

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

तकनीकी विवरण

PHP PHP + MySQL के एक समूह पर चलता है, इसलिए हम भुगतानों को संसाधित करने के लिए उसी तकनीक का उपयोग करते हैं। कोड एक आम पूल से पृथक एक अलग सर्वर समूह पर चलता है। अंदर, हमने इसे कई तार्किक उपसमूहों में विभाजित किया है: आने वाले अनुरोधों को संसाधित करने के लिए सर्वर, पृष्ठभूमि के संचालन के लिए सर्वर और डेटा संग्रह, डेटाबेस सर्वर, बैंक कार्ड भुगतानों के प्रसंस्करण के लिए सर्वर। बाद वाले को एक अलग समूह में आवंटित किया जाता है, क्योंकि उन्हें वीज़ा, मास्टरकार्ड, अमेरिकन एक्सप्रेस, जेसीबी की भागीदारी के साथ विकसित पीसीआई डीएसएस सुरक्षा मानक का पालन करना चाहिए और बैंक कार्ड धारक डेटा को काम करने या संग्रहीत करने वाले संगठनों की खोज करनी चाहिए।

भुगतान प्रसंस्करण के लिए, हम मास्टर-मास्टर प्रतिकृति में काम करते हुए, पेरकोना से MySQL के साथ दो डेटाबेस सर्वर का उपयोग करते हैं। मुख्य भार उनमें से केवल एक पर जाता है, दूसरे का उपयोग किसी दुर्घटना की स्थिति में "हॉट" प्रतिस्थापन या मुख्य एक को बदलने के लिए किया जाता है (इसकी सेवा के दौरान, निगरानी प्रणाली या सांख्यिकी संग्रह से अनुरोध के लिए)।

संपूर्ण बिलिंग प्रणाली को कई बड़े भागों में विभाजित किया जा सकता है:

• कोर। इसमें बुनियादी संस्थाएं शामिल हैं, जैसे कि ऑर्डर , भुगतान , सेवा और उनके लेखांकन और प्रावधान के लिए नियम, विभिन्न बुनियादी ढांचा चीजें।
• एग्रीगेटर प्लगइन्स। वह सब कुछ जो हमारे और भुगतान प्रणाली के बीच संचार के लिए जिम्मेदार है।
• सेवाओं के लिए चुनने और भुगतान करने के लिए पेज।

सिस्टम में एक नई भुगतान विधि को जोड़ने से इसका प्लगइन बनाने में ठीक-ठाक योगदान होता है। वह हमारे और भुगतान गेटवे के बीच सभी इंटरैक्शन के लिए जिम्मेदार है, जो दो प्रकार के होते हैं: जब हम सर्जक (पुल अनुरोध) और जब सर्जक एग्रीगेटर (पुश अनुरोध) होता है। पुल अनुरोधों के लिए, HTTP आमतौर पर प्रोटोकॉल के रूप में, या तो शुद्ध या JSON / XML या SOAP के लिए परिवहन के रूप में उपयोग किया जाता है। हाल ही में लोकप्रिय REST API कॉन्सेप्ट अक्सर नहीं देखा गया है, केवल बाजार की नई कंपनियों के बीच, उदाहरण के लिए, ब्रिटिश GoCardless, या पुरानी कंपनियों ने अपने API को फिर से डिज़ाइन करने का निर्णय लिया, उदाहरण के लिए, PayPal। पुश अनुरोधों के लिए, SOAP व्यावहारिक रूप से उपयोग नहीं किया जाता है (उन लोगों में से जो पुश सूचनाओं के इस प्रारूप की पेशकश करते हैं, केवल किवी को आसानी से याद किया जाता है)। शुद्ध HTTP मुख्य रूप से उपयोग किया जाता है या इसे सभी समान JSON और XML के परिवहन के रूप में भी उपयोग किया जाता है।

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



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

समर्थन और संचालन

उत्पादन सर्वरों पर नया एकीकरण होने के बाद, इसके संचालन और समर्थन का चरण शुरू होता है। तकनीकी समर्थन हमारे समय का लगभग 60-70% लेता है।



इसमें सबसे पहले, उपयोगकर्ता की शिकायतों का विश्लेषण शामिल है। सभी सरल स्थितियों को पहली पंक्ति की सहायता टीम द्वारा हल किया जाता है, लेकिन यह हमारे लिए विभिन्न भाषाओं की शिकायतों का अंग्रेजी में अनुवाद भी करती है। इसलिए, हमें केवल सबसे जटिल मामले मिलते हैं जो वास्तव में डेवलपर्स के ध्यान की आवश्यकता होती है।

तकनीकी सहायता का दूसरा घटक बग को ठीक कर रहा है या मौजूदा एकीकरण में परिवर्तन कर रहा है। विभिन्न कारणों से त्रुटियां होती हैं। उदाहरण के लिए, इसमें दस्तावेज या रिक्त स्थान के असंगत पढ़ने के कारण। एक बार, इसके बजाय, हमें एग्रीगेटर डेवलपर के साथ चैट लॉग का भी उपयोग करना पड़ा, क्योंकि उनकी नई प्रणाली के लिए प्रलेखन अभी तक तैयार नहीं था। ऐसे मामले थे जब एग्रीगेटर ने बिना सूचना के इंटरैक्शन प्रोटोकॉल या इसके मापदंडों को बदल दिया। दूसरी बार, अधिग्रहणकर्ता बैंक ने हमारे प्रवेश द्वार को काट दिया, और हमें तत्काल किसी अन्य स्थान पर यातायात को पुनर्निर्देशित करना पड़ा। जैसा कि बाद में पता चला, यह 80 के दशक से एक प्राचीन सर्वर था, जो कि बैंक के अनुसार, बिल्कुल भी कुछ भी संसाधित नहीं करना चाहिए। सामान्य तौर पर, आपको ऊब नहीं होना चाहिए, विशेष रूप से यह देखते हुए कि डाउनटाइम के प्रत्येक मिनट का लाभ कम होता है।

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

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

अनातोली पानोव
लीड डेवलपर