मुख्य सामग्री पर जाएं
Didit का सैंडबॉक्स Stripe के टेस्ट कार्ड या Sumsub के दस्तावेज़ टेम्पलेट जैसा है। यह आपको किसी भी सत्यापन परिणाम को निर्धारित रूप से दोहराने देता है, बिना वास्तविक प्रदाताओं, वास्तविक व्यक्तिगत डेटा (PII) या आपके बैलेंस को छुए।
इस डेटा का विश्वसनीय स्रोत service-didit-verification सेवा में serialize_catalog() है, जो लाइव GET /v1/sandbox/scenarios/ पर उपलब्ध है। उसी रिपॉज़िटरी में docs/sandbox/SANDBOX_REFERENCE.md की एक ड्रिफ़्ट-टेस्टेड कॉपी pipenv run python scripts/generate_sandbox_reference.py से बनती है। यह पेज उसी रेफ़रेंस को दर्शाता है। अगर यहाँ कोई जानकारी पुरानी लगे, तो हमेशा लाइव कैटलॉग endpoint पर भरोसा करें। कैटलॉग endpoint प्रमाणीकृत है: अपनी API कुंजी (x-api-key) उसी तरह भेजें जैसे किसी भी अन्य कॉल में भेजते हैं, या अगर आप चल रहे सत्र के भीतर से इसे पढ़ रहे हैं तो सत्र टोकन भेजें।

एनवायरनमेंट मॉडल

सैंडबॉक्स एक प्रति-एप्लिकेशन मोड है (ApplicationDetail.mode == SANDBOX), जो Stripe के टेस्ट मोड जैसा ही है। जब कोई सत्र सैंडबॉक्स एप्लिकेशन के तहत चलता है:
  • हर बाहरी प्रदाता (OCR, AML, चेहरा मिलान, लाइवनेस, NFC, फ़ोन, ईमेल, IP, POA, डेटाबेस सत्यापन, दस्तावेज़ AI) मॉक किया जाता है। किसी तीसरे पक्ष को कभी कॉल नहीं किया जाता।
  • लाइवनेस बिल्कुल वैसे ही चलता है जैसे लाइव में चलता है। एक्टिव-लाइवनेस वर्कफ़्लो सैंडबॉक्स में वास्तविक एक्टिव कैप्चर चलाता है, होस्टेड फ़्लो में और नेटिव SDK के वेब हैंडऑफ़ के ज़रिये, दोनों में समान रूप से, ताकि आप वही अनुभव परख सकें जो आपके उपयोगकर्ताओं को मिलेगा। केवल लाइवनेस परिणाम सिमुलेट होता है, जो सिनेरियो या मैजिक वैल्यू से तय होता है, और रिपोर्ट में वही विधि दर्ज होती है जो आपका वर्कफ़्लो कॉन्फ़िगर करता है।
  • कस्टम डोमेन केवल लाइव के लिए हैं। सैंडबॉक्स एप्लिकेशन कस्टम डोमेन नहीं जोड़ सकता; सैंडबॉक्स सत्र हमेशा डिफ़ॉल्ट होस्टेड सत्यापन डोमेन पर चलते हैं।
  • सत्र कभी बिल नहीं किए जाते और बैलेंस जाँच छोड़ दी जाती है।
  • प्रति 24 घंटे में प्रति एप्लिकेशन 500 सत्र बनाने की सीमा लागू होती है।
  • webhook में "environment": "sandbox" आता है (लाइव सत्रों में "environment": "live" आता है)।
  • होस्टेड फ़्लो सत्र का एनवायरनमेंट दिखाता है, ताकि UI उपयोगकर्ताओं को चेतावनी दे सके कि वास्तविक PII अपलोड न करें।
  • परिणाम कभी पिक्सेल पर निर्भर नहीं करते: निकाला गया डेटा और स्टेटस सिनेरियो या मैजिक वैल्यू से आते हैं। कैप्चर किया गया मीडिया (दस्तावेज़, सेल्फ़ी, वीडियो, POA फ़ाइलें) वास्तव में संग्रहीत होता है, ठीक वैसे ही जैसे लाइव सत्र में होता है।

सैंडबॉक्स में लेन-देन निगरानी

सैंडबॉक्स सत्र-आधारित है: यह उन प्रदाताओं की नकल करता है जिन्हें कोई सत्यापन सत्र कॉल करेगा। लेन-देन निगरानी के लिए कोई प्रदाता नहीं है जिसकी नकल की जाए, इसलिए सैंडबॉक्स एप्लिकेशन दूसरा रास्ता अपनाता है: लेन-देन सहेजा जाता है, लेकिन उस पर कुछ भी नहीं चलता जो निर्णय लेता हो, स्क्रीन करता हो, सूचना भेजता हो या शुल्क लेता हो। सैंडबॉक्स एप्लिकेशन पर बनाया गया लेन-देन सामान्य रूप से सहेजा और लौटाया जाता है, और उसके साथ इनमें से कुछ भी नहीं होता:
  • कोई नियम मूल्यांकन नहीं। rule_runs खाली रहता है, चाहे आपके नियम किसी भी मोड में हों। सैंडबॉक्स एप्लिकेशन पर कोई ACTIVE नियम कभी लागू नहीं होता, इसलिए लेन-देन APPROVED रहता है, उसका स्कोर 0 रहता है, और कोई अलर्ट या केस नहीं खुलता।
  • कोई AML / वॉलेट स्क्रीनिंग नहीं। provider_results खाली रहता है, भले ही निगरानी-सक्षम एप्लिकेशन पर क्रिप्टो लेन-देन हो।
  • कोई webhook नहीं। सैंडबॉक्स लेन-देन के लिए न transaction.created और न transaction.status.updated डिलीवर होते हैं।
  • कोई बिलिंग नहीं। 0.0000 मूल्य पर एक उपयोग इवेंट दर्ज होता है और आपका बैलेंस अप्रभावित रहता है।
हर लेन-देन प्रतिक्रिया में एक environment फ़ील्ड ("live" या "sandbox") होता है, ताकि खाली rule_runs कभी अस्पष्ट न रहे: "sandbox" का अर्थ है कि नियमों का मूल्यांकन नहीं हुआ, न कि यह कि उनमें से कोई मेल नहीं खाया। Business Console भी यही बात लेन-देन के Risk & decision कार्ड में कहता है, “कोई नियम मूल्यांकित नहीं” जैसा सादा संदेश देने के बजाय।
Travel Rule ही वह अपवाद है जहाँ “कुछ नहीं चलता” लागू नहीं होता। Travel Rule सक्षम वाले एप्लिकेशन पर सैंडबॉक्स का travelRule लेन-देन फिर भी एक्सचेंज इंजन चलाता है: ट्रांसफ़र रिकॉर्ड बनता है और अपनी स्थितियों से होकर आगे बढ़ता है। सैंडबॉक्स कभी Didit के बाहर किसी से संपर्क नहीं करता। इसका एकमात्र प्रतिपक्ष Didit Test VASP है, जो प्लेटफ़ॉर्म में अंतर्निहित है: किसी भी रेल (TRP, आपके जोड़े गए नेटवर्क की सदस्यता, ईमेल, या INTERNAL) के ज़रिये कोई अनुपालन संदेश किसी वास्तविक प्रतिपक्ष VASP तक नहीं पहुँचता, प्रतिपक्ष VASP की एट्रिब्यूशन स्क्रीनिंग नहीं की जाती, और रद्दीकरण से प्रतिपक्ष को कुछ नहीं भेजा जाता। travel_rule.status.updated webhooks डिलीवर होते हैं और उन पर "environment": "sandbox" अंकित होता है।आउटबाउंड - वह travelRule लेन-देन जिसे आप सबमिट करते हैं। पहले threshold_amount जाँच चलती है, और सैंडबॉक्स में यह तभी लागू होती है जब आप transaction_details.amount_in_default_currency भेजते हैं, क्योंकि सैंडबॉक्स मुद्राएँ परिवर्तित नहीं करता। इसके बिना हर सैंडबॉक्स ट्रांसफ़र थ्रेशोल्ड से ऊपर गिना जाएगा। जिस ट्रांसफ़र का उत्तर नहीं आता, वह confirmation_timeout_hours के बाद समाप्त हो जाता है, और फिर आपका timeout_outcome लेन-देन पर लागू होता है। थ्रेशोल्ड से ऊपर स्व-होस्टेड वॉलेट जाँच सामान्य रूप से लागू होती है: घोषित स्व-होस्टेड वॉलेट पर किया गया ट्रांसफ़र UNCONFIRMED_OWNERSHIP में जाता है और कुछ भी डिस्पैच नहीं होता। आप इसे सैंडबॉक्स में वॉलेट-स्वामित्व विजेट के ज़रिये पूरा कर सकते हैं, या जब गंतव्य वॉलेट पहले से आपकी वॉलेट पता सूची में हो तो स्वामित्व की पुष्टि करें के ज़रिये। थ्रेशोल्ड से ऊपर का कोई भी अन्य ट्रांसफ़र TEST_VASP रेल पर Didit Test VASP के पास जाता है, जो उसे Didit के भीतर उस परिदृश्य के साथ उत्तर देता है जिसे आप लाभार्थी वॉलेट या नाम से चुनते हैं: वह पूरा हो जाता है, अस्वीकार कर दिया जाता है, या उसमें बेमेल होता है, COUNTERPARTY_VASP_NOT_REACHABLE बन जाता है, समाप्त हो जाता है (फिर आपका timeout_outcome लेन-देन पर लागू होता है) या वॉलेट स्वामित्व की प्रतीक्षा करता है। हर परिदृश्य के लिए सैंडबॉक्स में Travel Rule की जाँच देखें।इनबाउंड - POST /v3/travel-rule/inbound/। पंजीकरण कभी किसी रेल पर डिस्पैच नहीं होता, इसलिए इसके बारे में कुछ भी सिम्युलेट नहीं किया जाता: सैंडबॉक्स जमा को आपकी वॉलेट पता सूची से मिलाता है और सिंक्रोनस रूप से निपटाता है, ठीक वैसे ही जैसे लाइव करता है। परिणाम AWAITING_COUNTERPARTY नहीं, बल्कि एक वास्तविक परिणाम होता है: ON_HOLD (पता सूची में कोई मेल नहीं), UNCONFIRMED_OWNERSHIP (मिलान किया गया प्रविष्टि स्वामित्व-सत्यापित नहीं है), COUNTERPARTY_MISMATCHED_DATA (लाभार्थी का नाम वॉलेट धारक से नहीं मिलता), या COMPLETED और फिर FINISHED (सत्यापित प्रविष्टि से मेल हुआ)। Didit Test VASP से ट्रांसफ़र पाने के लिए इसके बजाय Test VASP इनबाउंड ट्रांसफ़र ट्रिगर करें का उपयोग करें, और अपने पता-बुक वाले किसी एक वॉलेट का उपयोग करके।

Travel Rule Test VASP परिदृश्य

कैटलॉग का travel_rule.scenarios ये आउटबाउंड परिदृश्य सूचीबद्ध करता है। सैंडबॉक्स एप्लिकेशन पर Travel Rule सक्षम करने के बाद, आउटबाउंड travelRule लेन-देन पर नीचे दिया गया लाभार्थी नाम सेट करें। ऊपर बताई गई थ्रेशोल्ड और घोषित स्व-होस्टेड वॉलेट जाँच पहले चलती हैं। आप लाभार्थी नाम के बजाय लाभार्थी वॉलेट पते से भी परिदृश्य चुन सकते हैं (दोनों सेट होने पर वॉलेट को प्राथमिकता मिलती है), और जो ट्रांसफ़र कोई भी नाम नहीं देता, वह accept के रूप में पूरा होता है। सैंडबॉक्स में Travel Rule की जाँच हर परिदृश्य का वॉलेट और उसका सटीक परिणाम सूचीबद्ध करती है। इनबाउंड Test VASP ट्रिगर अपने scenario फ़ील्ड में केवल accept और name_mismatch स्वीकार करता है।
नियम को लाइव होने से पहले कैसे परखें। Backtest का उपयोग करें: यह नियम को आपके वास्तविक लेन-देन इतिहास पर फिर से चलाता है और evaluated / matched / affected_entities रिपोर्ट करता है, बिना किसी लेन-देन की स्थिति बदले। इसके साथ लाइव एप्लिकेशन पर TEST मोड का उपयोग करें: TEST नियम हर नए लाइव लेन-देन का मूल्यांकन करता है और दर्ज करता है कि वह किससे मेल खाता, बिना स्कोर या स्थिति बदले। जब चयनात्मकता सही लगे, तब ACTIVE पर स्विच करें।

लाइव और सैंडबॉक्स के बीच कैसे स्विच करें

लाइव और सैंडबॉक्स अलग-अलग एप्लिकेशन हैं, इसलिए टेस्ट ट्रैफ़िक और प्रोडक्शन डेटा कभी आपस में नहीं मिलते। हर एप्लिकेशन का mode या तो live होता है या sandbox:
  • मॉक्ड, बिल न किए गए और सिम्युलेट करने योग्य सत्र पाने के लिए सैंडबॉक्स मोड वाले एप्लिकेशन की API कुंजी का उपयोग करें।
  • वास्तविक सत्यापन के लिए लाइव मोड वाले एप्लिकेशन की API कुंजी का उपयोग करें।
sandbox_scenario फ़ील्ड (सत्र बनाते समय और स्टैंडअलोन AML API पर) और सिम्युलेट एंडपॉइंट केवल सैंडबॉक्स एप्लिकेशन पर स्वीकार किए जाते हैं; लाइव एप्लिकेशन पर इन्हें अस्वीकार कर दिया जाता है।

होस्टेड सत्यापन फ़्लो में सैंडबॉक्स

सैंडबॉक्स एप्लिकेशन के अंतर्गत बनाए गए सत्र होस्टेड सत्यापन फ़्लो में अतिरिक्त UI दिखाते हैं (POST /v3/session/ द्वारा लौटाया गया url):
  • कार्ड के भीतर सैंडबॉक्स बैनर। हर स्क्रीन पर कार्ड के भीतर एक बैनर दिखता है - “केवल परीक्षण डेटा - कोई वास्तविक कॉल नहीं”। इससे साफ़ रहता है कि सत्र कभी किसी वास्तविक प्रदाता को कॉल नहीं करता और आपके बैलेंस को नहीं छूता। कैप्चर किया गया मीडिया भी किसी भी सत्र की तरह संग्रहीत होता है, इसलिए वास्तविक पहचान दस्तावेज़ या निजी जानकारी के बजाय नमूना दस्तावेज़ और परीक्षण डेटा का उपयोग करें।
  • फ़्लो से पहले का परिदृश्य पिकर। कैप्चर शुरू होने से पहले कार्ड के भीतर एक पिकर उपयोगकर्ता को टेस्ट परिणाम चुनने में मार्गदर्शन करता है: पहले एक परिणाम चुनें, फिर उस परिणाम के लिए एक ट्रिगर। पुष्टि करने पर POST /v3/session/{session_id}/sandbox/arm/ कॉल होता है (नीचे सत्र शुरू होने से पहले उसे आर्म या री-आर्म करें देखें), और फिर उस परिदृश्य के मैजिक वैल्यू पहले से लागू करके फ़्लो आगे बढ़ता है।
  • नमूना दस्तावेज़ स्ट्रिप। दस्तावेज़ अपलोड/कैप्चर कॉम्पोनेंट के ठीक नीचे सैंडबॉक्स नमूना दस्तावेज़ों की एक पंक्ति (अधिकतम 3) दिखती है। वास्तविक अपलोड के बजाय उसका उपयोग करने के लिए किसी एक पर टैप करें।
सैंडबॉक्स सत्र वास्तविक कैप्चर किया गया मीडिया संग्रहीत करते हैं - दस्तावेज़, सेल्फ़ी, लाइवनेस वीडियो और पते के प्रमाण की फ़ाइलें वैसे ही अपलोड और संग्रहीत होती हैं जैसे लाइव सत्र में होती हैं। निकाला गया डेटा (पहचान सत्यापन फ़ील्ड, चेहरा मिलान स्कोर, लाइवनेस परिणाम और इसी तरह की जानकारी) और सत्र का परिणाम स्वयं (स्वीकृत / समीक्षाधीन / अस्वीकृत) परिदृश्य या मैजिक वैल्यू द्वारा सिम्युलेट किए जाते हैं - ये कभी कैप्चर किए गए मीडिया से नहीं निकाले जाते। Business Console सैंडबॉक्स सत्र के निकाले गए डेटा वाले अनुभागों को अनुकरणित डेटा चिप से चिह्नित करता है, ताकि समीक्षक एक नज़र में देख सकें कि सत्र का कौन-सा हिस्सा वास्तविक कैप्चर है और कौन-सा हिस्सा परिदृश्य द्वारा संचालित है।

Scenarios

हर परिदृश्य मैजिक वैल्यू का एक नामित समूह है। उसका स्लग सत्र बनाते समय sandbox_scenario के रूप में पास करें (या सिमुलेट endpoint को भेजें), ताकि वही परिणाम दोहराया जा सके। review_* सिनेरियो इसलिए मौजूद हैं ताकि आप बिना अस्वीकृति-स्तर के इनपुट के मैन्युअल समीक्षा का UX परखें (कंसोल की समीक्षा कतार, In Review webhook, समीक्षक की स्वीकृति या अस्वीकृति कार्रवाइयाँ)। ऊपर के दो kyb_* सिनेरियो expected_details.first_name की जगह expected_details.registration_number सेट करते हैं: ये केवल व्यवसाय सत्यापन (KYB) सत्रों पर लागू होते हैं।

मैजिक वैल्यू

मैजिक वैल्यू एक विशिष्ट इनपुट है, जो किसी एक मॉक की गई सुविधा से एक विशिष्ट जोखिम उत्पन्न कराता है। इसे ट्रिगर करने के लिए इनपुट फ़ील्ड को मैजिक वैल्यू पर सेट करें (सीधे, या किसी सिनेरियो के ज़रिए)।

गैर-दस्तावेज़ लुकअप और पहचान वॉलेट

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

बैंक सत्यापन: खाता जाँच

सैंडबॉक्स बैंक सत्यापन चरण हर देश में दोनों तरीके प्रस्तुत करता है, चरण द्वारा निर्धारित क्रम में। यह एक अनुकरणित सेवा पर चलता है, जिसमें कोई वास्तविक बैंक नहीं है और कोई लागत नहीं है। डिफ़ॉल्ट क्रम में व्यक्ति बैंक साइन-इन से शुरू करता है और खाता जाँच चलाने के लिए अपने खाते का विवरण दर्ज करें चुनता है। इसे पहले शुरू करने के लिए bank_method_order को ["account_lookup", "open_banking"] पर सेट करें। दर्ज किए गए खाते के अंतिम चार अक्षर उत्तर तय करते हैं; हर अंतिम चार-अक्षर संयोजन और हर प्रारूप के लिए एक मान्य खाता देखने के लिए सैंडबॉक्स में परीक्षण करें देखें। खाता जाँच API उन्हीं अंतिम चार-अक्षर संयोजनों से सैंडबॉक्स कुंजी लौटाता है।

Los documentos de muestra

Nunca subas documentos de identidad reales en el sandbox. Usa en su lugar los documentos de muestra integrados.
El flujo alojado ofrece tres documentos de muestra, uno por tipo de documento: Toca una muestra de la tira para usarla en lugar de una captura real. Los datos extraídos y el resultado de la sesión siempre provienen del escenario o del valor mágico seleccionado, de modo que cualquier muestra funciona con cualquier escenario.

Identidad de muestra: prueba de expected_details

Cada documento del sandbox se fabrica a partir de una identidad fija única. Los valores extraídos son los mismos en cada sesión y nunca se derivan de la fecha actual, de modo que puedes rellenar previamente expected_details con ellos y comprobar de principio a fin la comparación de campos y el manejo de advertencias. Envía los valores siguientes y las comparaciones pasan correctamente; envía cualquier otro valor y se activa a propósito la advertencia *_MISMATCH_WITH_PROVIDED correspondiente. Las fechas son compartidas por todos los documentos de muestra: El resto de la identidad depende del documento que uses:
first_name y last_name son la excepción: el sandbox replica en el documento fabricado los nombres que envías en expected_details, de modo que la comparación de nombres se supera con cualquier nombre. Usa el valor mágico SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED para probar una discrepancia de nombre, y SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED para una discrepancia de fecha de nacimiento.
Si tu flujo restringe documents_allowed a un país o tipo de documento que excluye el pasaporte electrónico de Brasil, el sandbox fabrica un documento a partir del primer país permitido, de modo que nationality, id_country y el nombre del documento siguen a ese país. Las fechas indicadas arriba no cambian.

Lo que no incluye el documento fabricado

El documento fabricado es la plantilla genérica del país y tipo de documento permitidos, de modo que los campos que solo proporciona un documento real emitido por el Estado quedan vacíos. El que importa para el enrutamiento es la región / estado de EE. UU. (kyc.region): un permiso de conducir o una tarjeta de identidad de EE. UU. del sandbox no tiene estado, así que una condición de rama como Region equals IL nunca se cumple en el sandbox y, si ninguna otra rama del nodo se cumple, el flujo toma la rama de respaldo del nodo (la rama sin condiciones). Esto no es una revisión ni un fallo de la rama: la condición simplemente no tiene nada que leer. Un campo ausente también hace fallar not equals y not in; consulta cómo leen las condiciones de rama los datos de la sesión para ver la diferencia entre un campo ausente y una cadena vacía. Para probar un flujo que depende del estado en el sandbox, decide la ruta a partir de un valor que controles en la sesión en lugar de a partir del documento:
  • Envía el estado en metadata al crear la sesión (por ejemplo, "metadata": {"credential_state": "IL"}) y bifurca según metadata.credential_state. Los metadatos se evalúan en el sandbox exactamente igual que en producción.
  • Conserva la condición kyc.region, basada en el documento, para el tráfico real si también necesitas que el documento acredite el estado; en modo real, la región se lee del documento verdadero.
Todo lo demás del enrutamiento es idéntico al modo real: el grafo del flujo, las condiciones de rama, los valores de metadata y expected_details, los nodos de acción y los nodos de estado se ejecutan de verdad. El sandbox nunca fuerza por sí mismo una sesión a revisión: una sesión del sandbox termina En revisión solo cuando el flujo la dirige allí (un escenario review_*, un valor mágico asignado a una acción de revisión o un nodo de estado en el grafo).

Códigos OTP y consentimiento para recibir correos electrónicos

  • OTP de teléfono: la comprobación de teléfono del sandbox acepta cualquier código bien formado (de 4 a 8 dígitos; incluido 123456). Una entrada mal formada sigue devolviendo 400.
  • OTP de correo electrónico: la comprobación de correo del sandbox acepta cualquier código bien formado (incluido 123456). Una entrada mal formada sigue devolviendo 400.
De forma predeterminada, las sesiones del sandbox no envían correos electrónicos (alertas de revisión, cambios de estado, OTP, reenvío, nuevo enlace de sesión, etc.). Para entregar un correo de todos modos, usa uno de estos patrones de consentimiento en la dirección del destinatario:

सैंडबॉक्स परिणाम नियंत्रित करना: परिदृश्य, मैजिक वैल्यू, सक्रिय करना और simulate endpoint

सैंडबॉक्स परिणाम नियंत्रित करने के पाँच तरीके हैं।

1. सत्र बनाते समय sandbox_scenario

सत्र बनाते समय (POST /v3/session/) परिदृश्य का slug सेट करें। सत्र बनाने की प्रक्रिया परिदृश्य की साथ आने वाली मैजिक वैल्यू को सत्र के इनपुट फ़ील्ड में विस्तारित करती है, ताकि मॉक किए गए प्रदाता असली वर्कफ़्लो पाइपलाइन से होकर इच्छित परिणाम दें।

2. मैजिक वैल्यू हाथ से टाइप करना

इनपुट फ़ील्ड खुद सेट करें (उदाहरण के लिए expected_details.first_name = "SANDBOX_OCR_DOCUMENT_EXPIRED", या user_email = "sandbox+aml_hit@didit.test")। पूरी सूची के लिए ऊपर दी गई मैजिक वैल्यू तालिका देखें।

3. फ़्लो शुरू होने से पहले सत्र में परिदृश्य सक्रिय (या पुनः सक्रिय) करें

पहले से मौजूद सत्र पर सक्रिय परिदृश्य सेट या बदलें, बशर्ते वह Not Started से आगे न बढ़ा हो। यही वह endpoint है जिसे फ़्लो से पहले का परिदृश्य चयनकर्ता कॉल करता है। आप इसे खुद भी कॉल कर सकते हैं, ताकि कस्टम चयनकर्ता या टेस्ट हार्नेस बना सकें:
200 रिस्पॉन्स:
  • सत्र के अपने Session-Token से प्रमाणित करें (जो सत्र बनाने पर session_token के रूप में मिलता है), अपनी API कुंजी से नहीं: यह क्लाइंट-फ़ेसिंग endpoint है।
  • अज्ञात परिदृश्य slug के लिए 400 लौटाता है, और सत्र Not Started से आगे बढ़ जाने पर भी 400 लौटाता है ("Scenario can only be armed before the verification starts.")।
  • जब Session-Token किसी लाइव (गैर-सैंडबॉक्स) एप्लिकेशन का हो, या पाथ के session_id से मेल न खाए, तो 404 लौटाता है।
  • पुनः सक्रिय करने पर पिछला परिदृश्य बदल जाता है। यह केवल वे मैजिक वैल्यू हटाता है जो पिछले परिदृश्य ने लिखी थीं, और उपयोगकर्ता द्वारा हाथ से भरी चीज़ें (ईमेल, पहला नाम आदि) जैसी थीं वैसी छोड़ देता है। उदाहरण: decline_phone_high_risk सक्रिय करें, फिर approve सक्रिय करें। फ़ोन नंबर खाली हो जाता है, लेकिन ग्राहक द्वारा दर्ज ईमेल दोनों कॉल के बाद भी बना रहता है।

4. simulate endpoint

बाद में अंतिम स्थिति लागू करें:
  • कंसोल / API कुंजी (write:sessions विशेषाधिकार चाहिए; सीमित API कुंजी को सत्रों पर लिखने की अनुमति होनी चाहिए): POST /v3/session/{session_id}/simulate/
  • होस्टेड फ़्लो (Session-Token हेडर): POST /v3/session/{session_id}/sandbox/simulate/
ये दोनों KYC और KYB सैंडबॉक्स सत्रों पर काम करते हैं। लाइव (गैर-सैंडबॉक्स) सत्र पर 404 लौटता है, और वैसे ही वह Session-Token भी जो पाथ के session_id से मेल न खाए। बॉडी का हर फ़ील्ड वैकल्पिक है, लेकिन new_status, scenario या risk में से कम से कम एक आवश्यक है: send_webhooks: true ठीक वही webhook भेजता है जो असली स्थिति बदलाव भेजता है: status.updated, साथ ही वे user.status.updated और user.data.updated इवेंट (या बिज़नेस सत्र के लिए business.status.updated और business.data.updated) जो बदलाव से उत्पन्न होते हैं, उन गंतव्यों पर जो इनकी सदस्यता लिए हुए हैं। send_webhooks: false के साथ स्थिति फिर भी बदलती है, लेकिन कोई webhook न लॉग होता है न भेजा जाता है। छूटे webhook की रिकवरी उस निर्णय को कभी दोबारा नहीं भेजती, और कंसोल फिर भी लाइव अपडेट होता है। सत्र का अगला स्थिति बदलाव सामान्य रूप से webhook भेजता है।
200 रिस्पॉन्स:
  • status वह स्थिति है जो सिमुलेशन ने सेट की, और previous_status वह है जो सत्र की पहले थी।
  • scenario आपका slug वापस दोहराता है और risk लागू किया गया जोखिम मामला है; कोई न होने पर हर एक null होता है।
  • send_webhooks लागू किया गया मान दोहराता है।
  • अज्ञात परिदृश्य या जोखिम के लिए, जब कोई new_status निकाला न जा सके, किसी और new_status के लिए, और जब सत्र में पहले से माँगी गई स्थिति हो (["The new status is the same as the current status."]), तो 400 लौटाता है।

5. स्टैंडअलोन AML API पर sandbox_scenario

बैकएंड AML स्क्रीनिंग में कोई एंड यूज़र नहीं होता और सक्रिय करने के लिए कोई सत्र नहीं होता, इसलिए slug स्वयं स्क्रीनिंग अनुरोध (POST /v3/aml/) पर जाता है:
  • decline_aml_hit एक प्रोडक्शन जैसा हिट लौटाता है और स्क्रीनिंग को Declined के रूप में निपटाता है; review_aml_possible_match उसे In Review पर निपटाता है। जो परिदृश्य कोई AML परिणाम सक्रिय नहीं करता, वह स्क्रीनिंग को साफ़ छोड़ता है।
  • save_api_request: true (डिफ़ॉल्ट) के साथ स्क्रीनिंग ठीक वैसे ही सहेजी जाती है जैसे लाइव कुंजी पर, इसलिए लौटाए गए request_id को GET /v3/session/{request_id}/decision/ और GET /v3/session/{request_id}/generate-pdf/ के माध्यम से प्राप्त किया जा सकता है।
  • अज्ञात परिदृश्य slug के लिए 400 लौटाता है, और जब API कुंजी किसी लाइव एप्लिकेशन की हो, तो 400 लौटाता है।

sandbox_scenario कहाँ दिखता है

सक्रिय परिदृश्य का slug (यदि कोई सक्रिय नहीं है तो null) कुछ सतहों पर वापस दिखाया जाता है, और कुछ पर जानबूझकर नहीं: यदि आपके इंटीग्रेशन को सर्वर-साइड पर सक्रिय परिदृश्य के आधार पर शाखा बनानी है, तो उसे webhook एनवेलप से या किसी भी निर्णय endpoint (v1 या v3) से पढ़ें।

उपयोग और बिलिंग

सैंडबॉक्स उपयोग ट्रैक किया जाता है, लेकिन उसका शुल्क कभी नहीं लिया जाता:
  • हर मॉक की गई कॉल अब भी एक उपयोग इवेंट रिकॉर्ड करती है (is_sandbox: true, मूल्य 0.0000), ताकि डीबगिंग के लिए सैंडबॉक्स की मात्रा दिखती रहे। लेकिन यह आपके कुल उपयोग में कभी नहीं जोड़ी जाती, बैलेंस से कभी नहीं घटाई जाती, और कभी किसी इनवॉइस पर दिखाई नहीं देती।
  • Business Console के बैलेंस, टॉप अप करें और लाइव उपयोग से जुड़े विवरण डिफ़ॉल्ट रूप से सैंडबॉक्स उपयोग को छिपाते हैं। टॉप अप उपयोग endpoints environment पैरामीटर स्वीकार करते हैं (live, जो डिफ़ॉल्ट है, या sandbox), ताकि सैंडबॉक्स की मात्रा अलग से देखी जा सके। यह हमेशा शून्य लागत पर होता है और निःशुल्क स्तर का कोई उपयोग नहीं होता।
  • ईमेल और फ़ोन सत्यापन प्रति सत्र परिणाम के बजाय प्रति अनुरोध बिल होते हैं, और सैंडबॉक्स webhook स्तर पर इसे पूरी तरह दोहरा नहीं सकता। सैंडबॉक्स में ईमेल/फ़ोन जाँच अब भी हर अनुरोध के लिए मूल्य 0.0000 पर एक उपयोग इवेंट रिकॉर्ड करती है, अन्य सभी मॉक की गई सुविधाओं की तरह। यह एक स्वीकृत और ज्ञात भिन्नता है, जो लाइव बिलिंग व्यवहार से अलग है, कोई बग नहीं।
  • सैंडबॉक्स में डेटाबेस सत्यापन की प्रतिक्रिया का ढाँचा जानबूझकर लाइव प्रति-प्रदाता ढाँचे से अलग है, क्योंकि नकल करने के लिए कोई वास्तविक प्रदाता नहीं है। सैंडबॉक्स डेटाबेस सत्यापन payloads को परिणाम (स्थिति और चेतावनी कोड) के स्टैंड-इन के रूप में समझें, किसी लाइव प्रदाता की प्रतिक्रिया का बाइट-दर-बाइट पूर्वावलोकन के रूप में नहीं।
अंतिम संशोधन 7 नवंबर 2026