लाइव जाने से पहले क्रिप्टो भुगतान गेटवे का परीक्षण कैसे करें

आप Payora पर एक क्रिप्टो भुगतान गेटवे का परीक्षण सैंडबॉक्स में नहीं कर सकते, क्योंकि Payora के पास ऐसा कोई नहीं है: न कोई टेस्टनेट मोड, न कोई टेस्ट-मोड API कुंजी, न कोई नकली चालान। इसके बजाय, आप वास्तविक होस्टेड चेकआउट की जांच करते हैं /demo, एक वेबहुक को फिर से चलाते हैं जिसे आपने अपने हैंडलर के खिलाफ स्वयं हस्ताक्षरित किया, फिर एक सस्ते नेटवर्क पर अपने स्वयं के चालान पर लगभग एक डॉलर का एक वास्तविक भुगतान भेजते हैं। अंतिम कदम की लागत बहुत कम होती है और यह साबित करता है कि एक सैंडबॉक्स कभी भी ऐसा नहीं कर सकता।

क्यों कोई सैंडबॉक्स नहीं है, और क्यों यह वह समस्या नहीं है जो आप सोचते हैं

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

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

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

1. कोड की एक पंक्ति लिखने से पहले वास्तविक चेकआउट को देखें

खोलें /demo. यह वास्तविक होस्टेड चेकआउट पर एक लाइव इनवॉइस बनाता है, वही पृष्ठ जो आपके खरीदार देखेंगे। कोई खाता नहीं, कोई कोड नहीं। वास्तव में क्या होता है, इसे देखें: सिक्का चयनकर्ता कैसे व्यवहार करता है, दर लॉक विंडो कैसी दिखती है, खरीदार क्या देखता है जब लेनदेन अभी भी असत्यापित है, जब टाइमर समाप्त होता है तो क्या होता है।

यहाँ पांच मिनट बाद में एक तर्क को बचाता है, क्योंकि अधिकांश एकीकरण बग एक गलत मानसिक मॉडल के रूप में जीवन शुरू करते हैं। पढ़ें /docs इसके साथ और प्रत्येक स्क्रीन को इसके पीछे के इनवॉइस फ़ील्ड से मिलाएं। फिर अपने खाते को बनाएं /register और अपना API कुंजी प्राप्त करें और api_secret.

2. बिना कुछ खर्च किए अपने वेबहुक हैंडलर का परीक्षण करें

यह बड़ा है। आपका हैंडलर वह कोड है जो "पैसा आया" को "ग्राहक को उनकी चीज मिली" में बदलता है, और यह वह हिस्सा है जिसे आप मुफ्त में पूरी तरह से परीक्षण कर सकते हैं, क्योंकि आपके पास वेबहुक पर हस्ताक्षर करने का रहस्य है। जो कुछ भी Payora हस्ताक्षर कर सकता है, आप भी हस्ताक्षर कर सकते हैं।

योजना साधारण HMAC है। हस्ताक्षर है hex(hmac_sha256(timestamp . '.' . rawBody, api_secret)), भेजा गया है X-Payora-Signature, उसी टाइमस्टैम्प के साथ X-Payora-Timestamp. टाइमस्टैम्प अब से ±120 सेकंड के भीतर होना चाहिए, और प्रत्येक डिलीवरी में एक Idempotency-Key हेडर होता है जो उसी घटना के पुनः प्रयासों में स्थिर रहता है। कच्चाबॉडी बाइट्स, न कि एक पुनः-कोडित एरे — पुनः-कोडिंग एक सही हस्ताक्षर विफल होने का क्लासिक कारण है।

<?php
// Sign a webhook exactly the way Payora signs one, and POST it at your own endpoint.
$secret = 'YOUR_API_SECRET';                          // the secret your handler verifies with
$url    = 'https://yoursite.com/payora-webhook.php';  // your endpoint, on your dev host

$body = json_encode([
    'event'      => 'invoice.paid',
    'invoice_id' => 'inv_local_1',
    'order_id'   => '1001',
    'status'     => 'paid',
    'amount'     => '1.00',
    'currency'   => 'USD',
    'asset'      => 'USDT',
    'network'    => 'tron',
], JSON_UNESCAPED_SLASHES);

$ts  = (string) time();
$sig = hash_hmac('sha256', $ts . '.' . $body, $secret);   // lowercase hex

$ch = curl_init($url);
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_POSTFIELDS     => $body,          // send the RAW body you signed
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER     => [
        'Content-Type: application/json',
        'X-Payora-Timestamp: ' . $ts,
        'X-Payora-Signature: ' . $sig,
        'Idempotency-Key: whk_local_1',
    ],
]);
$out  = curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
echo "$code\n$out\n";

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

3. परीक्षण जो वास्तव में बग पकड़ते हैं

इनमें से प्रत्येक को अपने हैंडलर के खिलाफ चलाएं और चेक करें डेटाबेस, न कि केवल HTTP स्थिति। अपेक्षित परिणाम फुटनोट नहीं हैं; वे परीक्षण हैं।

• मान्य हस्ताक्षर → 200, ऑर्डर भुगतान के रूप में चिह्नित, एक बार बिल्कुल।
• एक ही वेबहुक दो बार वितरित किया गया (समान Idempotency-Key) → अभी भी एक ही भुगतान आदेश है। कोई डबल क्रेडिट नहीं, कोई दूसरा लाइसेंस कुंजी नहीं, कोई दूसरा शिपिंग लेबल नहीं। यह भुगतान एकीकरण में सबसे सामान्य वास्तविक बग है, और पुनः प्रयास सामान्य हैं, असाधारण नहीं।
• पुरानी हस्ताक्षर के साथ छेड़छाड़ की गई सामग्री — परिवर्तन amount से 1.00 तक 1000.00, हस्ताक्षर बनाए रखें → अस्वीकृत, आदेश भुगतान नहीं किया गया।
• गलत या अनुपस्थित हस्ताक्षर → अस्वीकृत। एक खाली X-Payora-Signature को गलत एक की तरह ही असफल होना चाहिए।
• पुराना टाइमस्टैम्प — इसे दस मिनट पहले पर सेट करें → विंडो पर अस्वीकृत, भले ही HMAC स्वयं मान्य हो।
• अज्ञात या विदेशी चालान आईडी → साफ-सुथरी अस्वीकृति। कोई गंभीर त्रुटि नहीं, कोई 500 नहीं, कोई आधा लिखा हुआ पंक्ति नहीं।
• आपका एंडपॉइंट 500 लौटाता है → इसके बाद जो पुनः प्रयास होता है, उसे दो बार लागू नहीं करना चाहिए। यदि आप सुनिश्चित होना चाहते हैं तो हैंडलर के मध्य में डेटाबेस कनेक्शन को समाप्त करें।
• स्थायी समय तुलना — उपयोग करें hash_equals(), कभी नहीं ==. और कभी भी लॉग न करें api_secret, डिबग स्तर पर नहीं, संक्षिप्त नहीं, एक बार भी नहीं।

यदि सभी आठ पास हो जाते हैं, तो आपका हैंडलर अधिकांश लाइव इंटीग्रेशनों की तुलना में बेहतर स्थिति में है। अब ध्यान दें कि इनमें से किसी ने भी यह साबित नहीं किया: कि पैसा वास्तव में आप तक पहुँच सकता है।

4. अपने लिए एक छोटा वास्तविक भुगतान

अब एक डॉलर खर्च करें। API के माध्यम से एक चालान बनाएं या /accept-payments, चेकआउट खोलें, और इसे भुगतान करें अपने ही वॉलेट से, अपने ही चालान के लिए, लगभग $1 के साथ।

एक सस्ता, तेज नेटवर्क चुनें ताकि यह सेंट की लागत आए न कि डॉलर की: TON (Gram), Tron और Solana सभी सेकंडों में एक सेंट के एक अंश के लिए पुष्टि करते हैं। यदि आप विशेष रूप से बिटकॉइन भेज रहे हैं तो इसे बिटकॉइन मेननेट पर न चलाएं — आपको हर प्रयास के लिए दस मिनट इंतजार करना होगा और इसके लिए भुगतान करना होगा।

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

5. साबित करें कि आप पैसे निकाल सकते हैं

हर कोई इसे छोड़ देता है। यह वह कदम है जो चोट पहुँचाता है।

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

एक गेटवे जिसमें आप प्राप्त कर सकते हैं लेकिन निकाल नहीं सकते, वह गेटवे नहीं है। यह एक जाल है जिसमें एक अच्छा चेकआउट पृष्ठ है। $1 फंसे होने पर यह पता लगाना एक कहानी है जो आप बाद में बताते हैं। $40,000 फंसे होने पर यह पता लगाना एक बहुत अलग दोपहर है।

6. सत्यापित करें कि व्युत्पन्न पते वास्तव में आपके हैं

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

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

यह लाइव जाने से पहले करें। पहले शिकायत के बाद नहीं।

सच्चाई से stated trade-off

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

एक डॉलर, एक दोपहर और एक चेकलिस्ट एक ऐसे सिम्युलेटर को मात देते हैं जो आपके साथ सहमत होता है।

क्या इसे चलाने के लिए तैयार हैं? /register पर एक मुफ्त खाता बनाएं, अपना पहला चालान बनाएं /accept-payments से, और सूची के अनुसार काम करें। पूरी सीढ़ी में लगभग एक घंटा और लगभग एक डॉलर लगता है।