Next.js वेबसाइट पर क्रिप्टो भुगतान कैसे स्वीकार करें

भुगतान की प्रक्रिया और ज़रूरतों को समझें

अगर आप जानना चाहते हैं कि Next.js वेबसाइट पर क्रिप्टो भुगतान कैसे स्वीकार करें, तो कोड से नहीं, भुगतान की प्रक्रिया से शुरुआत करें। आम तौर पर क्रिप्टो चेकआउट के 4 हिस्से होते हैं: ऑर्डर बनाना, भुगतान का अनुरोध दिखाना, ब्लॉकचेन पर नज़र रखना और पुष्टि होने के बाद ही ऑर्डर को भुगतान किया हुआ चिह्नित करना।

सुनने में आसान लगता है। लेकिन अक्सर होता नहीं है।

Next.js साइट पर “क्रिप्टो स्वीकार करने” का मतलब यह नहीं कि आपका ऐप खुद कॉइन अपने पास रखता है। ज़्यादातर मामलों में, आपकी साइट ग्राहक के लिए भुगतान अनुरोध बनाती है, ग्राहक अपने वॉलेट से रकम भेजता है, और कोई भुगतान सेवा या आपका बैकएंड ट्रांसफ़र की पुष्टि करता है। अच्छे चेकआउट में समय-सीमा भी होनी चाहिए, क्योंकि जो विनिमय दर सुबह 10 बजे ठीक थी, वह 20 मिनट बाद शायद न हो।

आपको यह भी तय करना होगा कि किन नेटवर्क और डिजिटल एसेट को सपोर्ट करेंगे। Ethereum, Polygon और BNB Chain पर USDT स्वीकार करने वाले स्टोर का काम उस साइट से अलग है जो सिर्फ़ एक चेन पर BTC स्वीकार करती है। नेटवर्क का चुनाव फ़ीस, पुष्टि में लगने वाले समय और ग्राहक के लिए ज़रूरी वॉलेट को प्रभावित करता है। अगर आप गलत नेटवर्क स्वीकार करते हैं, तो भुगतान ऐसी जगह पहुँच सकता है जहाँ से उसे किसी ऑर्डर से जोड़ना मुमकिन न हो।

यहाँ एक काम का परीक्षण है: क्या कोई नया ग्राहक 2 मिनट से कम समय में चेकआउट पूरा कर सकता है? अगर नहीं, तो प्रक्रिया में सुधार की ज़रूरत है। एक वॉलेट, एक रकम, एक साफ़ पता और एक स्पष्ट स्टेटस पेज। लोगों को इसी स्तर की स्पष्टता चाहिए।

क्रिप्टो भुगतान प्रदाता या वॉलेट इंटिग्रेशन चुनें

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

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

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

एक बात और: अगर कोई प्रदाता “सभी प्रमुख एसेट” सपोर्ट करने का दावा करे, तो उससे सटीक सूची माँगें। “सभी” का मतलब साफ़ नहीं है। “3 नेटवर्क पर BTC, ETH और USDC” एक ऐसा विकल्प है जिस पर आप सचमुच फ़ैसला ले सकते हैं।

भुगतान के लिए अपना Next.js प्रोजेक्ट सेट अप करें

ऐप का ढाँचा साफ़-सुथरा रखें। Next.js ऐप राउटर प्रोजेक्ट में पेमेंट लॉजिक को सर्वर रूट या सर्वर ऐक्शन में रखें और सीक्रेट की को क्लाइंट से दूर रखें। एक साधारण ढाँचे में 1 प्रोडक्ट पेज, 1 चेकआउट फ़ॉर्म, इनवॉइस बनाने के लिए 1 API रूट और भुगतान इवेंट के लिए 1 वेबहुक रूट हो सकता है।

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

अगर आपका प्रदाता SDK देता है, तो उसे सिर्फ़ सर्वर लेयर में इंस्टॉल करें। अगर वह सीधे HTTP एंडपॉइंट देता है, तो वह भी ठीक है। मुख्य बात एक ही है: ब्राउज़र आपके Next.js बैकएंड से भुगतान अनुरोध बनाने को कहे और बैकएंड प्रदाता से बात करे। ऑर्डर का भुगतान हो चुका है या नहीं, यह फ़ैसला ब्राउज़र को कभी नहीं करना चाहिए।

अगर आपकी टीम कार्ड पेमेंट से आ रही है, तो इसका ढाँचा Stripe की प्रक्रिया से बहुत अलग नहीं है—बस पुष्टि के चरण अलग हैं। यह तुलना मददगार लगे, तो API रूट की योजना बनाने से पहले how to migrate from stripe पढ़ें। प्रोटोटाइप के लिए 1 API रूट काफ़ी है; रीट्राई, रिफ़ंड और ऑर्डर स्टेटस का इतिहास जोड़ने पर 3 या 4 रूट बेहतर हो सकते हैं।

Next.js में चेकआउट UI बनाएँ

चेकआउट UI प्रोडक्ट कार्ड, कार्ट पेज या भुगतान शुरू करने वाला एक साधारण बटन हो सकता है। Next.js के क्लाइंट कंपोनेंट में बटन आम तौर पर ऑर्डर की जानकारी आपके सर्वर रूट को भेजता है, जवाब का इंतज़ार करता है और फिर ग्राहक को दूसरे पेज पर भेजता है या वॉलेट से जुड़ी जानकारी दिखाता है।

फ़ॉर्म छोटा रखें। अक्सर प्रोडक्ट का नाम, रकम, ईमेल और शायद ऑर्डर से जुड़ा एक नोट काफ़ी होते हैं। अगर आप 9 फ़ील्ड माँगेंगे, तो ज़्यादा लोग बीच में प्रक्रिया छोड़ देंगे। 3 फ़ील्ड माँगने पर लोग जल्दी पूरा करेंगे। 30 सेकंड में पूरा होने वाला चेकआउट, 3 मिनट लेने वाले चेकआउट से बेहतर लगता है—भले ही दोनों में भुगतान एक ही हो।

पेमेंट बटन पर कार्रवाई साफ़ लिखी होनी चाहिए: “क्रिप्टो से भुगतान करें।” “आगे बढ़ें” या “जारी रखें” नहीं। ऐसे लेबल अगले चरण की असली बात छिपाते हैं। बटन क्लिक होने पर अपने बैकएंड को कॉल करें, भुगतान अनुरोध पाएँ, फिर उसी स्क्रीन पर वॉलेट का पता, QR कोड और रकम दिखाएँ।

एक उपयोगी तरीका यह है कि भुगतान की जानकारी लोड होते समय भी ऑर्डर का सारांश दिखता रहे। इससे ग्राहक को ठीक-ठीक पता रहता है कि वह कौन-सी चीज़ और कितनी रकम के लिए भुगतान कर रहा है। जब डॉलर में तय रकम किसी उतार-चढ़ाव वाले एसेट में चुकाई जाती है, तो इससे उलझन कम होती है।

भुगतान पते, इनवॉइस या पेमेंट लिंक बनाएँ

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

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

ग्राहक को जानकारी साफ़-साफ़ दिखाएँ: एसेट, चेन, रकम और भुगतान पाने का पता। QR कोड मददगार है, लेकिन उसे टेक्स्ट की जगह न रखें। कुछ वॉलेट QR कोड ठीक से स्कैन नहीं करते और कुछ लोग जानकारी कॉपी-पेस्ट करते हैं। एक साफ़ पता फिर भी सबसे भरोसेमंद विकल्प है।

अगर आपको सेवाओं या इनवॉइस के लिए पते के आधार पर बिलिंग करनी है, तो इसका तरीका क्रिप्टो पेमेंट गेटवे फ़ॉर फ्रीलांसर वाले लेख में बताए गए तरीकों जैसा ही है। एक बार के ऑर्डर के लिए पेमेंट लिंक अक्सर आसान होता है; भुगतान का इतिहास और रिमाइंडर चाहिए हों, तो अलग इनवॉइस रिकॉर्ड बेहतर रहता है।

ब्लॉकचेन भुगतान की पुष्टि करें और ऑर्डर स्टेटस अपडेट करें

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

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

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

अगर आपके सिस्टम में वेबहुक हैं, तो हर बार उनकी जाँच करें। how to verify payora signed webhooks वाला लेख PHP का इस्तेमाल न करने पर भी काम का है, क्योंकि बुनियादी सिद्धांत वही है: उन संदेशों को अस्वीकार करें जो यह साबित नहीं करते कि वे प्रदाता की ओर से आए हैं। यह एक जाँच नकली भुगतान इवेंट को तुरंत रोक सकती है।

अन्य स्थितियों, सुरक्षा और परीक्षण का ध्यान रखें

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

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

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

एक जैसे इवेंट पर भी ध्यान दें। कुछ प्रदाता वेबहुक दोबारा भेजते हैं और लापरवाही करने पर आपके सिस्टम में एक ही भुगतान कई बार दिख सकता है। ऑर्डर अपडेट करने वाला कोड इडेम्पोटेंट होना चाहिए—यानी एक ही इवेंट से एक ही ऑर्डर को दो बार भुगतान किया हुआ न माना जाए। यह छोटा-सा बचाव घंटों का काम बचा सकता है।

चेकआउट लॉन्च करें, निगरानी रखें और अनुभव बेहतर बनाएँ

Vercel या इससे मिलते-जुलते होस्ट पर Next.js ऐप आम तौर पर ठीक से चलता है, लेकिन भुगतान से जुड़े हिस्सों पर फिर भी ध्यान देना ज़रूरी है। सुनिश्चित करें कि आपका वेबहुक एंडपॉइंट इंटरनेट से खुल सके, प्रोडक्शन में एनवायरनमेंट वेरिएबल सेट हों और बिल्ड ऐसी वैल्यू पर निर्भर न हो जो सिर्फ़ आपके लोकल कंप्यूटर पर मौजूद हैं। आपके लैपटॉप पर काम करने वाला और प्रोडक्शन में विफल होने वाला पेमेंट रूट एक आम गलती है।

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

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

यहाँ से असली काम पहला भुगतान करवाना नहीं है। असली चुनौती दूसरा, तीसरा और वह भुगतान है जो वॉलेट, ब्लॉकचेन और आपके Next.js बैकएंड के बीच कहीं अटक जाता है। अगर आपका सिस्टम इन 3 स्थितियों को आसानी से संभाल सकता है, तो आपके पास ऐसा चेकआउट है जिस पर ग्राहक भरोसा कर सकते हैं।