के लिए WHMCS में क्रिप्टो भुगतान स्वीकार करेंआप एक गेटवे मॉड्यूल स्थापित करते हैं, एक API कुंजी पेस्ट करते हैं, इसे अपने सर्वर पर एक वेबहुक URL की ओर इंगित करते हैं, और जब एक साइन किया हुआ वेबहुक आता है तो चालान को भुगतान के रूप में चिह्नित करते हैं। वह भाग यांत्रिक है। पढ़ने के लिए महत्वपूर्ण भाग वह सब कुछ है जो इसके चारों ओर होस्टिंग-विशिष्ट है: आपके खरीदार असामान्य रूप से क्रिप्टो-नैटिव हैं, आपका बिल हर चक्र में दोहराता है, और चार्जबैक एक वास्तविक व्यावसायिक जोखिम है। क्रिप्टो इन तीनों को बदलता है - दो आपके पक्ष में, और एक जो आपको एक मैनुअल प्रक्रिया की कीमत चुकाता है जिसे आपको इसे चालू करने से पहले तय करना चाहिए।
होस्टिंग एक सामान्य दुकान नहीं है
अधिकांश "क्रिप्टो स्वीकार करें" सलाह किसी ऐसे व्यक्ति के लिए लिखी गई है जो टी-शर्ट बेचता है, जहां क्रिप्टो एक अच्छा-से-है शायद 1% खरीदारों को छूता है। होस्टिंग अलग है। VPS, एक समर्पित बॉक्स या एक डोमेन खरीदने वाले लोग डेवलपर्स, सिस्टम एडमिन, ऑफशोर-मानसिकता वाले व्यवसाय और उन देशों में खरीदार हैं जहां विदेशी होस्टिंग कंपनी को कार्ड भुगतान जारीकर्ता द्वारा बिना किसी स्पष्ट कारण के अस्वीकृत कर दिया जाता है। उनके लिए एक महत्वपूर्ण हिस्से के लिए, क्रिप्टो एक सुविधा नहीं है - यह बिक्री और कोई बिक्री के बीच का अंतर है।
आप इसे समर्थन कतार में देख सकते हैं। कोई भी कपड़ों की दुकान को यह पूछने के लिए ईमेल नहीं करता कि क्या वे USDT लेते हैं; होस्टिंग कंपनियों को वह ईमेल लगातार मिलता है, और हर प्रेषक पहले से ही खरीदने का निर्णय ले चुका है।
ईमानदार भाग: कोई संग्रहीत कार्ड नहीं है
यहाँ आपको मार्केटिंग के बजाय सटीकता की आवश्यकता है। होस्टिंग आवर्ती बिलिंग है: WHMCS हर महीने या वर्ष में एक चालान उठाने और इसे ग्राहक के बिना सोचे-समझे संग्रहित करने के लिए मौजूद है। एक कार्ड गेटवे ऐसा करता है, एक टोकन को स्टोर करके और देय तिथि पर धन खींचकर।
एक गैर-निगरानी क्रिप्टो गेटवे ऐसा नहीं कर सकता। स्टोर करने के लिए कोई टोकन नहीं है और न ही किसी के वॉलेट से खींचने के लिए कोई स्थायी प्राधिकरण है - धन केवल तब स्थानांतरित होता है जब वॉलेट धारक लेनदेन पर हस्ताक्षर करता है। इसलिए "आवर्ती क्रिप्टो बिलिंग" को ईमानदारी से इस प्रकार वर्णित किया जाता हैएक चालान और एक भुगतान अनुरोध जिसे ग्राहक प्रत्येक चक्र में भुगतान करता है, न कि एक मौन स्वचालित चार्ज। पूरा मॉडल, जिसमें स्मार्ट-कॉन्ट्रैक्ट दृष्टिकोण और क्यों वे अधिकांश बिलिंग में फिट नहीं होते, में हैक्रिप्टो सब्सक्रिप्शन और आवर्ती भुगतान समझाया गया.
फिर भी नवीनीकरण को दर्द रहित बनाना
"स्वचालित चार्ज" और "ग्राहक प्रत्येक चक्र में भुगतान करता है" के बीच का अंतर एक UX समस्या है, और इसे हल किया जा सकता है। क्या काम करता है:
- देय तिथि से पहले चालान भेजें। WHMCS पहले से ही अग्रिम में चालान उत्पन्न करता है। क्रिप्टो भुगतान करने वालों को कार्ड ग्राहक की तुलना में अधिक समय दें - कोई जो एक्सचेंज से धन स्थानांतरित कर रहा है, उसे मिनटों में नहीं, बल्कि दिनों में आवश्यकता होती है।
- एक उदार चालान विंडो का उपयोग करें।एक क्रिप्टो इनवॉइस एक दर पर उद्धृत किया जाता है जो एक छोटे समय के लिए मान्य होता है, इसलिए भुगतान अनुरोध तब उत्पन्न करें जब ग्राहक भुगतान करने के लिए तैयार हो, हफ्तों पहले नहीं।
- लोगों को पहले से भुगतान करने दें।क्रिप्टो-नेटिव ग्राहक खुशी-खुशी एक साल का पूर्व भुगतान करेंगे ताकि उन्हें इसके बारे में सोचना न पड़े, और हर पूर्व भुगतान किया गया वर्ष एक नवीनीकरण है जिसे आप कभी नहीं खोजते।
- याद दिलाने वाले आपके ऑटो-चार्ज हैं।अवधि समाप्त नोटिस, एक स्पष्ट भुगतान लिंक, एक दृश्य निलंबन तिथि - वही मांसपेशी जिसका आप बैंक ट्रांसफर ग्राहकों के लिए उपयोग करते हैं।
- पहले चूक के दिन पर निलंबित न करें।एक पुष्टि में देरी या एक लंबित विनिमय निकासी एक डेडबीट नहीं है। एक अनुग्रह अवधि बनाएं।
चार्जबैक: होस्टिंग की सबसे महंगी समस्या
होस्टिंग एक चार्जबैक मैग्नेट है और उद्योग में हर कोई जानता है कि क्यों। एक चोरी किया गया कार्ड एक सर्वर खरीदता है, सर्वर का उपयोग उस चीज़ के लिए किया जाता है जिसके लिए इसे खरीदा गया था - स्पैम, स्कैनिंग, माइनिंग, और भी बुरा - और फिर असली कार्डधारक चार्ज को उलट देता है। आप पैसे, संसाधनों को जो इसे जलाते हैं और शुल्क खो देते हैं, और आपका चार्जबैक अनुपात उस सीमा की ओर बढ़ता है जहां आपका व्यापारी खाता एक बातचीत करता है जिसे आप नहीं चाहते। धोखाधड़ी उत्पाद के लिए आकस्मिक नहीं है; उत्पादहैधोखाधड़ी उपकरण।
क्रिप्टो भुगतान अंतिम होते हैं। एक बार जब लेनदेन में आपके द्वारा आवश्यक पुष्टि हो जाती है, तो कोई जारीकर्ता नहीं होता, कोई विवाद विंडो नहीं होती और न ही कोई उलटाव होता है। कोई भी तीन सप्ताह तक इसका उपयोग करने के बाद एक सर्वर को वापस नहीं लेता। एक होस्टिंग व्यवसाय के लिए, यह अक्सर कॉलम में सबसे मजबूत तर्क होता है, और अर्थशास्त्र को कवर किया गया है बिना व्यापारी खाते या चार्जबैक के भुगतान स्वीकार करना.
धोखाधड़ी गायब नहीं होती, स्पष्ट होने के लिए। दुरुपयोगी ग्राहक अभी भी साइन अप करते हैं - वे बस अपने पैसे से भुगतान करते हैं और इसे वापस नहीं ले सकते। आपकी दुरुपयोग प्रबंधन वहीं रहती है जहाँ थी।
साफ-साफ कहा गया व्यापार-समझौता
अंतिमता दोनों तरीकों से कटती है। क्योंकि कोई भी आपके लिए भुगतान को उलट नहीं सकता, आपएकमात्र व्यक्ति हैं जो पैसे वापस भेज सकते हैं - एक आउटबाउंड भुगतान के रूप में, हाथ से। कोई "रिफंड" बटन नहीं है जो एक निपटान लेनदेन को उलटता है। इसका मतलब है कि लॉन्च से पहले दो निर्णय:
- प्रो-रेटेड रद्दीकरण।पहले नीति तय करें और इसे अपने सेवा की शर्तों में लिखें। कई होस्ट ऑन-चेन रिफंड के बजाय खाता क्रेडिट जारी करते हैं, जो साफ-सुथरा होता है और ग्राहक को बनाए रखता है। यदि आप ऑन-चेन रिफंड करते हैं, तो नेटवर्क शुल्क शीर्ष से कटता है और कीमत बढ़ जाएगी - उस फिएट मूल्य को रिफंड करें जिस पर आप सहमत हुए थे या प्राप्त राशि को, लेकिन लिखित में बताएं कि कौन सा।
- जो बाहर जाने वाले भुगतान पर हस्ताक्षर करता है।एक गैर-निगरानी सेटअप में, प्राप्त करने वाले पते केवल सार्वजनिक कुंजी सामग्री से निकाले जाते हैं और निजी कुंजी कभी भी सर्वर को नहीं छूती हैं, इसलिए रिफंड और भुगतान ऑफ़लाइन एक मानव द्वारा हस्ताक्षरित होते हैं। यह एक विशेषता है - एक समझौता किया गया बिलिंग बॉक्स आपकी आय को नहीं चुरा सकता - लेकिन रिफंड एक जानबूझकर किया गया कार्य है, न कि एक एपीआई कॉल। आपका आंतरिक संतुलनयहां आप देखते हैं कि आपने क्या इकट्ठा किया है और इसे बाहर ले जाते हैं; मूल्य निर्धारणस्वीकृति के लिए 0% है, केवल तब शुल्क होते हैं जब पैसा बाहर जाता है: भुगतान, ट्रांसफर और निकासी पर फ्री योजना पर 1.5%, साथ ही एक भुगतान या निकासी पर सिक्के का नेटवर्क शुल्क (न्यूनतम निकासी $50)।
प्रावधान: वेबहुक पर भरोसा करें, रीडायरेक्ट पर कभी नहीं
यह वह विवरण है जो एक कार्यशील सेटअप को एक शोषण योग्य सेटअप से अलग करता है। जब एक ग्राहक भुगतान करना समाप्त करता है, तो उनका ब्राउज़र आपके WHMCS इंस्टॉल पर वापस रीडायरेक्ट किया जाता है।वह रीडायरेक्ट भुगतान का प्रमाण नहीं है।यह केवल एक URL है, और कोई भी आपके रिटर्न URL पर हिट कर सकता है।
हस्ताक्षरित वेबहुक पर प्रावधान और कुछ नहीं। Payora हर कॉलबैक को एचएमएसी-एसएचए256 के साथ पेलोड पर हस्ताक्षर करता है, जिसमें एक टाइमस्टैम्प विंडो और एक आइडेम्पोटेंसी कुंजी होती है। आपका एंडपॉइंट हस्ताक्षर की पुष्टि करता है, टाइमस्टैम्प की ताजगी की जांच करता है, यह जांचता है कि उसने पहले से उस कुंजी को प्रोसेस नहीं किया है, और तभी इनवॉइस को भुगतान के रूप में चिह्नित करता है और स्वचालन को सक्रिय करता है।दस्तावेज़हस्ताक्षर योजना और एक-फाइल PHP SDK को कवर करता है जो इसे संभालता है।
आइडेम्पोटेंसी यहाँ एक दुकान की तुलना में अधिक महत्वपूर्ण है: एक होस्टिंग ऑर्डर पर दो बार प्रोसेस किया गया वेबहुक केवल एक इनवॉइस को डबल-क्रेडिट नहीं करता, यह एक दूसरा प्रावधान रन भी ट्रिगर कर सकता है। आइडेम्पोटेंसी कुंजी पर ध्यान दें, न कि "क्या मैंने इस ऑर्डर आईडी को देखा है" पर।
तत्काल प्रावधान के लिए कौन से नेटवर्क सक्षम करें
यदि आपका उत्पाद तुरंत प्रावधान करता है, तो पुष्टि का समयहैचेकआउट अनुभव को प्रभावित करता है। एक ग्राहक जो 2 बजे "ऑर्डर VPS" पर क्लिक करता है, उसे मिनटों में एक रूट पासवर्ड की उम्मीद होती है, और बिटकॉइन का ब्लॉक समय एक खराब फिट है - $6 VPS के लिए पुष्टि की प्रतीक्षा करना एक समर्थन टिकट बनाने की प्रक्रिया है। डिफ़ॉल्ट रूप से तेज, सस्ते नेटवर्क को प्राथमिकता दें और बिटकॉइन को एक विकल्प के रूप में रखें न कि मुख्य शीर्षक के रूप में:
| नेटवर्क | फिट्स | नोट |
|---|---|---|
| TON (Gram) | तत्काल प्रावधान | अंतिमता के लिए सेकंड, छोटे शुल्क |
| ट्रॉन | USDT-भारी दर्शक | दुनिया के अधिकांश हिस्सों के लिए डिफ़ॉल्ट USDT रेल |
| सोलाना | तत्काल प्रावधान | तेज़ और सस्ता |
| बिटकॉइन | बड़े, गैर-तत्काल आदेश | वार्षिक योजनाएँ, समर्पित सर्वर, जमा |
स्थिरकॉइन यहाँ विशेष उल्लेख के योग्य हैं: USDT और USDC आपकी $6/महीने की योजना को $6 पर मूल्यांकित करते हैं, बिना यह बहस किए कि कौन सा दर लागू होता है। प्रत्येक नेटवर्क को वास्तव में कितनी पुष्टि की आवश्यकता होती है, और क्यों उत्तर आदेश के मूल्य पर निर्भर करता है, को कवर किया गया है कितनी पुष्टि एक क्रिप्टो भुगतान को सुरक्षित बनाती है.
WHMCS में क्रिप्टो भुगतान स्वीकार करने के लिए Payora मॉड्यूल सेट करें
WHMCS गेटवे मॉड्यूल उन मुफ्त ड्रॉप-इन इंटीग्रेशनों में से एक है जो हम प्रकाशित करते हैं मॉड्यूल, 21 अन्य के साथ। यह WHMCS में कोड लिखे बिना क्रिप्टो भुगतान स्वीकार करने का सबसे तेज़ तरीका है। उच्च स्तर पर:
- अपने WHMCS इंस्टॉलेशन में गेटवे मॉड्यूल स्थापित करें और इसे अपने भुगतान गेटवे के बीच सक्रिय करें।
- एक मुफ्त खाता बनाएं पंजीकरण करें और API कुंजी को मॉड्यूल की सेटिंग्स में पेस्ट करें।
- वेबहुक URL को मॉड्यूल के कॉलबैक एंडपॉइंट पर सेट करें ताकि साइन किए गए नोटिफिकेशन वहां पहुंच सकें।
- उन सिक्कों और नेटवर्कों को सक्षम करें जिन्हें आप पेश करना चाहते हैं, और अपने प्राप्त करने की कुंजी सामग्री को कॉन्फ़िगर करें।
- एक सस्ती नेटवर्क पर एक छोटा असली ऑर्डर रखें और पुष्टि करें कि चालान वेबहुक पर भुगतान किया गया है।
वहां से प्रवाह मानक है जैसा कि पर वर्णित है भुगतान स्वीकार करें: चालान में आपका ऑर्डर आईडी और राशि होती है, ग्राहक होस्टेड चेकआउट पर एक सिक्का चुनता है, Payora उस सिक्के की अंतिमता के लिए चेन की निगरानी करता है, और आपका सर्वर साइन किए गए कॉलबैक को प्राप्त करता है। यदि आप मॉड्यूल को छोड़ना चाहते हैं - कई होस्ट एक भारी कस्टमाइज्ड WHMCS चलाते हैं - तो साधारण-JSON REST API वही काम करता है।
एक तेज नेटवर्क और एक स्थिर सिक्के के साथ शुरू करें, देखें कि ग्राहक वास्तव में क्या चुनते हैं, और वहां से जोड़ें।एक खाता बनाएं, एक API कुंजी प्राप्त करें, और इसे घोषित करने से पहले अपने स्वयं के चेकआउट के माध्यम से एक असली $5 का ऑर्डर दें।



Comments