मुख्य सामग्री पर जाएं

Webhook

इस दस्तावेज़ में GetProcess आर्टिकल्स एक endpoint को कॉल करके किसी प्रोसेस की स्थिति प्राप्त करने का तरीका बताते हैं। इस तरह, बनाई गई प्रोसेस के बारे में जानकारी प्राप्त करने के लिए पोलिंग की जाती है। इसका मतलब है कि नवीनतम स्थिति प्राप्त करने के लिए एक ही प्रोसेस के लिए endpoint को कई बार कॉल किया जा सकता है।

Webhooks के उपयोग से, जब भी किसी प्रोसेस की स्थिति बदलती है, तब हर बार एक विशिष्ट endpoint को सूचित करना संभव है।

Webhook क्या है?​

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

Webhook को कैसे कॉन्फ़िगर करें​

Webhook को कॉन्फ़िगर करने के लिए, निम्नलिखित जानकारी आवश्यक है:

  • Notification URL: यह वह endpoint है जिसका उपयोग Unico द्वारा स्थिति अपडेट के बारे में सूचनाओं के लिए किया जाता है।
  • Authentication Type: यह वह तरीका है जिसका उपयोग endpoint के invocation को प्रमाणित करने के लिए किया जाता है। निम्नलिखित विकल्प उपलब्ध हैं:
    • OAuth2;
    • Basic Authorization;
    • API Key;
    • कोई प्रमाणीकरण नहीं।
  • OAuth2 के लिए, निम्नलिखित जानकारी प्रदान करनी होगी:
    • Webhook endpoint;
    • OAuth2 provider URL;
    • OAuth2 provider ClientId;
    • OAuth2 provider Secret.
  • Basic Authorization के लिए, user:pass फॉर्मेट में भेजना आवश्यक है।
  • API Key के लिए, दो फॉर्मेट संभव हैं:
    • header:value, जब एक विशिष्ट header नाम वांछित हो;
    • value, जब वांछित header Authorization हो।
  • Retry Settings: यह endpoint को कॉल करते समय विफलता की स्थिति में प्रयासों की संख्या को इंगित करता है:
    • अधिकतम प्रयासों की संख्या;
    • प्रयासों के बीच अंतराल (सेकंड में);
    • Rate Limit: एक साथ किए जाने वाले सबमिशन की अधिकतम संख्या (अधिकतम: 500);
    • Timeout: endpoint की प्रतिक्रिया के लिए अधिकतम प्रतीक्षा समय (सेकंड में)।
  • Status to be notified: आप सूचनाएं प्राप्त करने के लिए विशिष्ट statuses को सब्सक्राइब कर सकते हैं। इनमें शामिल हैं:
    • approved: लेनदेन स्वीकृत;
    • processing: लेनदेन प्रोसेसिंग में;
    • inconclusive: हम एक निर्णायक वैलिडेशन नहीं कर सके;
    • shared: लेनदेन साझा किया गया, सबमिशन की प्रतीक्षा में;
    • skipped: व्यक्ति ने फ्लो में बायोमेट्रिक कैप्चर को स्किप किया;
    • unknown-share: व्यक्ति ने चिह्नित किया कि वे खरीद को नहीं पहचानते;
    • absent-holder: कार्डधारक कैप्चर करने के लिए उपस्थित नहीं है;
    • expired: व्यक्ति ने निर्धारित समय के भीतर कैप्चर पूरा नहीं किया और लेनदेन एक्सपायर हो गया।
प्रमाणीकरण के बारे में

API को Basic Authentication या API Key जैसी प्रमाणीकरण विधि द्वारा सुरक्षित किया जा सकता है। अतिरिक्त सुरक्षा के लिए एक्सेस हेतु वैध IPs की सूची भी परिभाषित की जा सकती है।

कार्ड नॉट प्रेजेंट सत्यापन के साथ इंटीग्रेशन​

प्लेटफ़ॉर्म पर webhook कॉन्फ़िगर करते समय, आप उन प्रोसेस के बारे में जानकारी प्राप्त कर सकते हैं जो आपके द्वारा इन अपडेट को प्राप्त करने के लिए विकसित किए गए API के एक endpoint पर भेजी गई सूचनाओं के माध्यम से मिलती है।

प्लेटफ़ॉर्म द्वारा API को भेजी गई जानकारी में शामिल है:

  • ID: लेनदेन की ID;
  • Status: लेनदेन की स्थिति;
  • HasIdentityChanged: क्या लेनदेन में कोई पहचान परिवर्तन हुआ (वैकल्पिक)।
नोट

ध्यान दें कि webhook कॉन्फ़िगरेशन के माध्यम से क्लाइंट जिन statuses के बारे में सूचित होना चाहता है, उन्हें चुनना संभव है। यह जानकारी भेजने के बाद, अपेक्षित प्रतिक्रिया सिंक्रोनस होनी चाहिए।

अनुरोध​

अनुरोध REST API के लिए एक POST मेथड होना चाहिए, जिससे जानकारी भेजना आसान और अधिक सुरक्षित हो जाता है। सभी फ़ील्ड्स अनिवार्य होने चाहिए। अनुरोध बॉडी को लेनदेन की ID और status स्वीकार करनी चाहिए, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

{
  "id": "8263a268-5388-492a-bca2-28e1ff4a69f0",
  "status": "approved",
  "hasIdentityChanged": false
}

प्रतिक्रिया​

प्रतिक्रिया सिंक्रोनस होनी चाहिए। सफल अनुरोधों के लिए status 200 से 299 की रेंज में होना चाहिए। कोई भी अन्य status विफलता माना जाएगा, और कार्ड नॉट प्रेजेंट सत्यापन 2xx प्रतिक्रिया प्राप्त होने या अधिकतम प्रयासों की संख्या तक पहुंचने तक अतिरिक्त सूचना प्रयास करेगा (जिनके बीच exponential backoff होगा)।

प्रतिक्रिया की स्थिति​

वर्तमान में, हमारे पास statuses का एक सेट है, लेकिन यह सेट भविष्य में बदल सकता है। इसलिए, यह अनुशंसित है कि क्लाइंट जिन statuses में रुचि रखता है, उन्हें एक्शन लेने के लिए कॉन्फ़िगरेबल बनाया जाए। उदाहरण के लिए, यदि इरादा यह है कि हर बार जब कैप्चर सफलतापूर्वक पूरा हो जाए तो एक्शन लिया जाए, तो यह वर्तमान में status "processing" के साथ होता है। हालांकि, चूंकि इसे भविष्य में संशोधित किया जा सकता है, इसलिए यह अनुशंसित है कि सफल कैप्चर को इंगित करने वाला status सिस्टम में कॉन्फ़िगरेबल हो, ताकि "captured" status में भविष्य के बदलाव को आसानी से लागू किया जा सके।

इसके अतिरिक्त, हम विशिष्ट statuses के लिए विशिष्ट एक्शन और status पहचान में न आने की स्थिति के लिए एक सामान्य एक्शन रखने की सलाह देते हैं (उदाहरण के लिए, यह मानते हुए कि "processing" और "approved" से अलग कुछ भी inconclusive है)। यह महत्वपूर्ण है क्योंकि भविष्य में नए statuses सामने आ सकते हैं, और इस वजह से webhook के टूटने की उम्मीद नहीं की जाती।

महत्वपूर्ण बातें​

उस API को विकसित करते समय निम्नलिखित पहलुओं पर ध्यान दें जिसका उपयोग कार्ड नॉट प्रेजेंट सत्यापन स्थिति परिवर्तनों को सूचित करने के लिए करेगा:

Rate limit — कई लेनदेन वाली स्थितियों में अपने संसाधनों को ओवरलोड होने से बचाने के लिए, endpoint को invoke किए जाने की संख्या पर एक ऊपरी सीमा निर्दिष्ट करना संभव है।

Error Rate — error rate ([200, 299] रेंज के बाहर की प्रतिक्रियाएं) हमेशा कम रखी जानी चाहिए। अन्यथा, webhook throughput स्वचालित रूप से कम हो जाएगा, और retry मैकेनिज्म के साथ मिलकर यह कमी नए webhooks के लिए बढ़े हुए एक्ज़ीक्यूशन समय का परिणाम हो सकती है।

Idempotence — वर्तमान webhook implementation at-least-once delivery की गारंटी देता है, इसलिए एक ही status एक से अधिक बार सूचित किया जा सकता है। इसलिए, endpoint implementation को idempotent तरीके से किया जाना चाहिए।

Fallback — webhook सेवा में किसी भी अनुपलब्धता की स्थिति में, यह अनुशंसित है कि एक fallback तरीका मौजूद हो ताकि आप निर्धारित प्रतिक्रिया समय के भीतर लेनदेन की statuses प्राप्त करना जारी रख सकें। endpoint क्वेरी का वर्णन इस दस्तावेज़ के API Reference सेक्शन में किया गया है।

अंतिम अपडेट को