खाते के स्वामित्व वाले मैसेजिंग ब्रांड का उपयोग करें
अनुमत स्रोत आईपी पते से HTTPS के माध्यम से सक्षम API खाते का उपयोग करें। Basic और Bearer प्रमाणीकरण समर्थित हैं। ब्रांड आईडी उसी खाते की होनी चाहिए। प्रदाता के टोकन, ब्रांड की पहचान संबंधी डेटा और प्राप्त रिपोर्ट गोपनीय रखें।
प्रदाता के मौजूदा परिणाम का उपयोग करें
किसी समर्थित प्रदाता के मौजूदा सत्यापन परिणाम को अपने ब्रांड से जोड़ने के लिए PUT का उपयोग करें। इससे नई जाँच का ऑर्डर नहीं दिया जाता। प्रदाता की सही लेनदेन आईडी और आवश्यक पुष्टि टोकन सीधे उसी प्रदाता से प्राप्त करें, और सुनिश्चित करें कि रिपोर्ट उसी व्यावसायिक पहचान से संबंधित है।
AUTHPLUS इस आयात कार्यप्रवाह का समर्थन नहीं करता। प्रदाता-विशिष्ट मिलान नियम फिर भी लागू होते हैं; आयात अनुरोध से इन नियमों में छूट नहीं मिलती और न ही हर अभियान उपयोग के लिए पात्रता की गारंटी मिलती है।
आयात की तैयारी करें
| फ़ील्ड | मान |
|---|---|
| evpId | समर्थित प्रदाता की आईडी, 1–10 वर्ण। |
| vettingId | प्रदाता के वास्तविक सत्यापन लेनदेन का पहचानकर्ता, अधिकतम 255 वर्ण। इसकी जगह ब्रांड आईडी न दें और कोई पहचानकर्ता स्वयं न गढ़ें। |
| vettingToken | प्रदाता द्वारा आवश्यक होने पर पुष्टि टोकन, अधिकतम 65535 वर्ण। इसे गोपनीय रखें और जब प्रदाता को इसकी आवश्यकता न हो तो इसे शामिल न करें। |
प्रदाता के वास्तविक मानों से vetting-import.json बनाएँ। केवल प्रतिक्रिया में मिलने वाले स्कोर, स्थिति या समय-मुद्रा फ़ील्ड इस धारणा से न भेजें कि वे परिणाम बदल सकते हैं।
परिणाम एक बार आयात करें
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request PUT \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary @vetting-import.json \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"मौजूदा शुल्क समझें
यह प्रॉक्सी नए आयातित परिणाम को नए सशुल्क ऑर्डर के रूप में दर्ज नहीं करता। इससे पहले से ऑर्डर की गई जाँच रद्द नहीं होती: जब उसी vettingId के लिए परिणाम की प्रतीक्षा में या शुल्क वसूली के लिए लंबित ऑर्डर पहले से मौजूद हो, तो ACTIVE या FAILED परिणाम आयात करने से उसका दर्ज शुल्क वसूला जा सकता है। समन्वयन की इस शाखा में उस रिकॉर्ड पर दोबारा शुल्क नहीं लगाया जाता जिस पर पहले ही शुल्क लग चुका है।
वास्तविक परिणाम पर नज़र रखें
सफल HTTP प्रतिक्रिया में लंबित सत्यापन रिकॉर्ड हो सकता है। उसका vettingId सुरक्षित रखें और उपलब्ध होने पर vettingStatus, कारणों, स्कोर तथा प्रभावी होने और समाप्त होने की तारीखों की जाँच करें। PENDING और UNSCORE के लिए आगे भी स्थिति जाँचना आवश्यक है; ACTIVE, FAILED और EXPIRED अलग-अलग परिणाम दर्शाते हैं। केवल HTTP स्वीकृति से अनुकूल स्कोर या अभियान की पात्रता सिद्ध नहीं होती।
रिकॉर्ड पर नज़र रखने के लिए बाहरी सत्यापन की स्थिति का उपयोग करें। अंतिम स्थिति वाले परिणाम को पढ़ने या आयात करने से किसी पहले से मौजूद सशुल्क ऑर्डर का शुल्क वसूला जा सकता है; इसका अर्थ यह नहीं कि कोई मौजूदा बकाया शुल्क नहीं लगेगा।
उसी अभिप्रेत अनुरोध का पुनः प्रयास करें
हर अभिप्रेत कार्रवाई के लिए एक Idempotency-Key का उपयोग करें और विधि, पथ, क्वेरी तथा बॉडी के बाइट बिल्कुल वैसे ही बनाए रखें। कुंजियों में बिना रिक्त स्थान के 1–128 मुद्रण योग्य ASCII वर्ण समर्थित हैं। पहले से चल रहे अनुरोध की प्रतिलिपि पर Retry-After के साथ 409 मिल सकता है। पूरे हो चुके अनुरोधों की संग्रहीत प्रतिक्रिया, त्रुटियों सहित, फिर से लौटाई जाती है। अनुरोध दर की सीमाओं का पालन करें।
परिवहन विफलता के बाद कैश किया गया 502 मिल सकता है। requestId के साथ कैश किया गया 500 यह संकेत दे सकता है कि रजिस्ट्री ने कार्रवाई स्वीकार कर ली, लेकिन स्थानीय रूप से डेटा सहेजना या बिलिंग विफल हो गई। अनुरोध आईडी सुरक्षित रखें, वर्तमान रिकॉर्ड जाँचें और नई कुंजी का उपयोग करने से पहले सहायता टीम के साथ रिकॉर्ड तथा शुल्क का मिलान कर स्थिति स्पष्ट करें। यह न मानें कि त्रुटि का अर्थ है कि कोई ऑर्डर मौजूद नहीं है।