पायोरा — एक टर्नकी क्रिप्टो भुगतान गेटवे

01प्रोजेक्ट का अवलोकन

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

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

हमने उत्पाद को अंत से अंत तक डिज़ाइन और बनाया — अवसंरचना और आर्किटेक्चर से लेकर लैंडिंग पृष्ठ, व्यापारी डैशबोर्ड, और दस्तावेज़ीकरण तक। नीचे हम उस समस्या के बारे में चलते हैं जिसे Payora हल करता है, यह अंदर कैसे काम करता है, और इंजीनियरिंग निर्णय जो क्रिप्टो को स्वीकार करना पूर्वानुमानित और सुरक्षित बनाते हैं।

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

02संदर्भ और समस्या

क्रिप्टो भुगतान स्वीकार करना "तकनीकी" रूप से आसान है — कठिन हिस्सा इसे करना हैविश्वसनीयता और दोहराने योग्य. जब हमने कार्य को तोड़ा, तो एक पूरी श्रृंखला की समस्याएँ सामने आईं जो हर कोई जो अपने तरीके से क्रिप्टो स्वीकार करता है, का सामना करता है:

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

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

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

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

03प्रोजेक्ट के लक्ष्य

संक्षिप्त से ठोस उत्पाद और इंजीनियरिंग लक्ष्य विकसित हुए जिन्हें हमने हर चरण में ध्यान में रखा:

• सरल एकीकरण।एक साइट को जोड़ना एक चालान बनाने के लिए एक अनुरोध और एक वेबहुक हैंडलर है। हजारों पंक्तियों का SDK नहीं, बल्कि साधारण, पठनीय REST।
• डिफ़ॉल्ट रूप से गैर-निगरानी।निजी कुंजियाँ कभी भी मालिक की ओर से नहीं जातीं। गेटवे सर्वर केवल पढ़ने के लिए चलता है जहाँ धन की स्वीकृति का संबंध है।
• एक तैयार भुगतान स्क्रीन।इसलिए व्यापारी को भुगतान UI डिज़ाइन करने की आवश्यकता नहीं है - Payora चालान, पता, QR, और टाइमर के साथ एक होस्टेड चेकआउट प्रदान करता है।
• विश्वसनीय सूचनाएँ।हर वेबहुक पर हस्ताक्षर होता है; स्टोर हस्ताक्षर की पुष्टि करता है और एक नकली "भुगतान" से धोखा नहीं खा सकता।
• पूर्वानुमानिता।स्पष्ट चालान स्थिति, अधूरे भुगतान और समाप्ति के लिए पारदर्शी तर्क, आइडेम्पोटेंसी।
• स्वयं-होस्टिंग।अपने स्वयं के सर्वर पर तैनाती, API, भुगतान और प्रशासन के लिए अलग उपडोमेन के साथ।

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

04हमने क्या बनाया

Payora क्रिप्टो स्वीकृति को तीन स्पष्ट निर्माण ब्लॉकों में पैक करता है जो पूरे भुगतान जीवनचक्र को कवर करते हैं:

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

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

05सॉल्यूशन आर्किटेक्चर

Payora कई उपडोमेन में विभाजित है - इस तरह भूमिकाएँ और लोड भौतिक रूप से अलग होते हैं, और पहुँच को लॉक करना आसान होता है:

• payora.money — लैंडिंग पृष्ठ: स्थिति, डेवलपर दस्तावेज़, डैशबोर्ड में प्रवेश बिंदु।
• api.payora.money — प्रोग्रामेटिक इंटरफ़ेस: जहाँ स्टोर चालान बनाने और उनकी स्थिति की जांच करने के लिए कॉल करते हैं।
• pay.payora.money — होस्टेड चेकआउट: भुगतान पृष्ठ जो खरीदार देखता है।
• admin.payora.money — प्रशासन पैनल और व्यापारी डैशबोर्ड: परियोजनाएँ, कुंजी, चालान इतिहास, वेबहुक सेटिंग्स।

यह विभाजन केवल सौंदर्यात्मक नहीं है। यह हमें भुगतान स्क्रीन और API को अलग कैशिंग और सुरक्षा नीतियाँ देने, प्रशासनिक क्षेत्र को अलग करने, और आवश्यकता पड़ने पर भागों को स्वतंत्र रूप से स्केल या निकालने की अनुमति देता है। इसके पीछे एक सर्वर स्टैक है PHP 8.3, एक पैनल-प्रबंधित वातावरण में तैनात, Cloudflare (DNS, TLS, परिधि सुरक्षा) के पीछे।

तर्कसंगत रूप से, प्रणाली चार ब्लॉकों में विभाजित है: अनुरोध इनटेक (API और मान्यता), चालान लेखा (राज्य, स्थिति, राशि, और समयसीमा), ब्लॉकचेन निगरानी (चालान पते पर हस्तांतरण का पता लगाना), और सूचना (हस्ताक्षरित वेबहुक्स का निर्माण और भेजना)। प्रत्येक ब्लॉक अपने भुगतान जीवनचक्र का एक हिस्सा रखता है और स्पष्ट सीमाओं के पार दूसरों से बात करता है।

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

06भुगतान कैसे प्रवाहित होता है

इंटीग्रेटर के दृष्टिकोण से पूरा प्रवाह कुछ चरणों में फिट बैठता है, और उनमें से अधिकांश स्टोर की भागीदारी के बिना होते हैं:

• 1. चालान निर्माण। स्टोर API को कॉल करता है: राशि, मुद्रा, आदेश आईडी, वेबहुक पता। प्रतिक्रिया में - अद्वितीय विवरणों के साथ एक चालान और होस्टेड चेकआउट का लिंक।
• 2. भुगतान। खरीदार Payora के भुगतान स्क्रीन पर पहुंचता है: वे राशि, पता, QR कोड और टाइमर देखते हैं। वे किसी भी वॉलेट से भुगतान करते हैं।
• 3. ट्रांसफर पहचान।गेटवे चालान पते की निगरानी करता है और आने वाले ट्रांसफर को पंजीकृत करता है, राशि की तुलना अपेक्षित राशि से करता है और स्वीकार्य विचलन की अनुमति देता है।
• 4. पुष्टि।आवश्यक संख्या में पुष्टियों के बाद, चालान "भुगतान किया गया" स्थिति में चला जाता है।
• 5. हस्ताक्षरित वेबहुक।Payora स्टोर को स्थिति और एक हस्ताक्षर के साथ एक सर्वर-साइड अधिसूचना भेजता है; स्टोर हस्ताक्षर की पुष्टि करता है और अपनी कार्रवाई करता है - सामान जारी करता है, बैलेंस बढ़ाता है, पहुंच प्रदान करता है।

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

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

07मुख्य क्षमताएँ

आइए देखते हैं कि Payora को केवल "क्रिप्टो स्वीकृति" नहीं बल्कि एक उत्पादन-ग्रेड भुगतान गेटवे क्या बनाता है।

एक REST API

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

होस्टेड चेकआउट

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

साइन किए गए वेबहुक

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

राशि और समय सीमा लॉजिक

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

स्थिति और चालान जीवनचक्र

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

इडेम्पोटेंसी और विश्वसनीय डिलीवरी

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

08सुरक्षा और गैर-निगरानी डिज़ाइन

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

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

इसके अलावा, हमने लागू किया कम से कम विशेषाधिकार का सिद्धांत अवसंरचना स्तर पर: पूरे सेवा के लिए एक समर्पित प्रणाली खाता, उपडोमेन के बीच भूमिका विभाजन, और ऐसे हस्ताक्षर रहस्य जो केवल व्यापारी जानता है। प्रत्येक घटक के पास जितने कम अधिकार और डेटा होंगे, किसी एक गलती या लीक का विस्फोटक क्षेत्र उतना ही छोटा होगा — और पैसे संभालने वाले उत्पाद को संचालित करना उतना ही शांत होगा।

09TON और USDT: अद्वितीय पते

Payora स्वीकार करता है TON और USDT TON नेटवर्क पर — तेज, कम-शुल्क संपत्तियाँ जो ऑनलाइन भुगतान के लिए सुविधाजनक हैं। लेकिन एक मुद्रा का समर्थन करना केवल आधा काम है। दूसरा, अधिक सूक्ष्म आधा यह है कि कैसे एक विशिष्ट भुगतान को एक विशिष्ट चालान से मिलाना.

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

निश्चित निकासी पुनर्प्राप्ति के बारे में भी है। प्रत्येक चालान का पता मूल पैरामीटर से पुनः गणना किया जा सकता है, जिसका अर्थ है कि प्रणाली एक नाजुक "पता ↔ आदेश" भंडार पर निर्भर नहीं करती: लिंक निकासी तर्क से पुनर्स्थापित किया जाता है। USDT-on-TON और मूल TON को स्वीकार करने के लिए यह विशेष रूप से सुविधाजनक है — दोनों मुद्राएं एक ही नेटवर्क में रहती हैं, जो देखने को सरल बनाती है और "भारी" श्रृंखलाओं की तुलना में शुल्क को कम करती है।

10कम भुगतान, अधिक भुगतान, और समयसीमा

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

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

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

11व्यापारी डैशबोर्ड और प्रशासन

उत्पाद को अपने दम पर खड़ा करने के लिए, केवल एक API पर्याप्त नहीं है - आपको एक इंटरफेस की आवश्यकता है जहां व्यापारी अपने प्रोजेक्ट्स का प्रबंधन करता है। प्रशासनिक क्षेत्र (admin.payora.money) में व्यवसाय प्रोजेक्ट्स बनाता है, कुंजी और वेबहुक्स पर हस्ताक्षर करने के लिए एक गुप्त प्राप्त करता है, हैंडलर का पता और मुद्राओं को कॉन्फ़िगर करता है, और स्थिति के साथ चालान इतिहास देखता है।

यह रोज़मर्रा के परिदृश्यों को कवर करता है बिना गेटवे डेवलपर को शामिल किए: एक नए साइट के लिए एक नया प्रोजेक्ट बनाना, एक कुंजी को फिर से जारी करना, यह जांचना कि क्या कोई विशेष भुगतान आया, एक विवादित चालान की जांच करना। मूल रूप से, डैशबोर्ड एक "कंसोल" है जो API द्वारा प्रोग्रामेटिक रूप से किए गए सभी कार्यों पर है।

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

12इंटीग्रेशन: परीक्षण में सिद्ध

Payora एक शून्य में नहीं है - इसे प्रोजेक्ट्स के पूरे पारिस्थितिकी तंत्र के लिए एक साझा भुगतान परत के रूप में बनाया गया था। पहले वास्तविक एकीकरणकर्ताओं में से एक फ्रीलांस मार्केटप्लेस है 24freelance: एक उपयोगकर्ता का बैलेंस टॉप-अप Payora के माध्यम से चलता है। स्टोर एक चालान बनाता है, उपयोगकर्ता होस्टेड चेकआउट पर भुगतान करता है, और पुष्टि के बाद Payora एक हस्ताक्षरित वेबहुक भेजता है जिस पर बैलेंस स्वचालित रूप से क्रेडिट किया जाता है।

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

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

13तकनीकी ढांचा और अवसंरचना

Payora के लिए हमने एक समर्पित, अलग वातावरण तैयार किया — अपने स्वयं के सिस्टम उपयोगकर्ता, उपडोमेन और नीतियों के साथ। यह सुरक्षा के दृष्टिकोण से अधिक साफ है और संचालन में आसान है।

• बैकेंड — PHP 8.3: एपीआई, चालान लेखा, वेबहुक बनाने और भेजने, स्थिति लॉजिक।
• ब्लॉकचेन लेयर — TON और USDT-on-TON के साथ काम करना: चालान पते की गणना करना और केवल पढ़ने के मोड में ट्रांसफर की निगरानी करना।
• अवसंरचना — api/pay/admin उपडोमेन के साथ एक अलग अलग खाता, क्लाउडफ्लेयर (DNS, TLS, सुरक्षा) के पीछे और मान्य लेट्स एनक्रिप्ट प्रमाणपत्रों के साथ।
• सुरक्षा — उपडोमेन के बीच भूमिका विभाजन, व्यापारी की ओर पर हस्ताक्षरित रहस्य, सर्वर पर कोई स्वीकृति निजी कुंजी नहीं।

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

14डिजाइन और UX

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

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

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

15हमने कैसे काम किया

हमने परियोजना को अनुक्रमिक चरणों में चलाया, हर कदम पर एक परिणाम प्रदर्शित किया:

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

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

16परिणाम

जो हमने प्राप्त किया है वह "क्रिप्टो-स्वीकृति स्क्रिप्ट" नहीं है, बल्कि एक आत्म-निहित भुगतान गेटवे है जिसे आप स्वयं तैनात कर सकते हैं और किसी भी संख्या के प्रोजेक्ट से कनेक्ट कर सकते हैं।

• क्रिप्टो भुगतान स्वीकृति एक शाम में जुड़ती है - एक चालान बनाने के लिए एक अनुरोध और एक वेबहुक हैंडलर।
• व्यवसाय के पास फंड पर पूर्ण नियंत्रण है: गैर-निगरानी और स्वयं-होस्टेड।
• हस्ताक्षरित वेबहुक और अद्वितीय पते पूरी श्रेणियों की त्रुटियों को हटा देते हैं: जाली सूचनाएँ और खोए हुए भुगतान।
• संरचना एक वास्तविक एकीकरण द्वारा सिद्ध है और नए परियोजनाओं के लिए स्केल करने के लिए तैयार है।

लेकिन मुख्य परिणाम व्यक्तिगत संख्याओं में नहीं है - यह मॉडल के बदलाव में है। पहले, हर नई साइट जो मालिक ने बनाई, का मतलब था एक नए भुगतान मॉड्यूल का निर्माण; अब यह बस एक साझा गेटवे में एक और व्यापारी परियोजना है। भुगतान लॉजिक एक बार का कार्य नहीं रहा और यह एक पुन: प्रयोज्य संपत्ति बन गई है जो जितनी अधिक परियोजनाएँ इससे जुड़ती हैं, उतना ही लाभ देती है।

17सीखने योग्य बातें

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

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

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