> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# सैंडबॉक्स टेस्ट डेटा: परिदृश्य, मैजिक वैल्यू और दस्तावेज़

> Didit सैंडबॉक्स में परिदृश्य, मैजिक वैल्यू, arm endpoint, नमूना दस्तावेज़ और OTP कोड से टेस्ट करें, बिना PII और बिलिंग के।

Didit का **सैंडबॉक्स** Stripe के टेस्ट कार्ड या Sumsub के दस्तावेज़ टेम्पलेट जैसा है। यह आपको किसी भी सत्यापन परिणाम को निर्धारित रूप से दोहराने देता है, बिना वास्तविक प्रदाताओं, वास्तविक व्यक्तिगत डेटा (PII) या आपके बैलेंस को छुए।

> [!NOTE]
>
> इस डेटा का विश्वसनीय स्रोत `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 के वेब हैंडऑफ़ के ज़रिये, दोनों में समान रूप से, ताकि आप वही अनुभव परख सकें जो आपके उपयोगकर्ताओं को मिलेगा। केवल लाइवनेस *परिणाम* सिमुलेट होता है, जो सिनेरियो या मैजिक वैल्यू से तय होता है, और रिपोर्ट में वही विधि दर्ज होती है जो आपका वर्कफ़्लो कॉन्फ़िगर करता है।
* **कस्टम डोमेन केवल लाइव के लिए हैं।** सैंडबॉक्स एप्लिकेशन [कस्टम डोमेन](https://docs.didit.me/hi/console/custom-domain.md) नहीं जोड़ सकता; सैंडबॉक्स सत्र हमेशा डिफ़ॉल्ट होस्टेड सत्यापन डोमेन पर चलते हैं।
* सत्र **कभी बिल नहीं** किए जाते और बैलेंस जाँच छोड़ दी जाती है।
* प्रति 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* कार्ड में कहता है, "कोई नियम मूल्यांकित नहीं" जैसा सादा संदेश देने के बजाय।

> [!NOTE]
>
> **Travel Rule ही वह अपवाद है जहाँ "कुछ नहीं चलता" लागू नहीं होता।** Travel Rule सक्षम वाले एप्लिकेशन पर सैंडबॉक्स का `travelRule` लेन-देन फिर भी एक्सचेंज इंजन चलाता है: ट्रांसफ़र रिकॉर्ड बनता है और अपनी स्थितियों से होकर आगे बढ़ता है।
> सैंडबॉक्स कभी Didit के बाहर किसी से संपर्क नहीं करता।
> इसका एकमात्र प्रतिपक्ष [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) है, जो प्लेटफ़ॉर्म में अंतर्निहित है: किसी भी रेल (`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` लेन-देन पर लागू होता है।
> थ्रेशोल्ड से ऊपर स्व-होस्टेड वॉलेट जाँच सामान्य रूप से लागू होती है: [घोषित स्व-होस्टेड वॉलेट](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#घोषित-स्व-होस्टेड-वॉलेट) पर किया गया ट्रांसफ़र `UNCONFIRMED_OWNERSHIP` में जाता है और कुछ भी डिस्पैच नहीं होता। आप इसे सैंडबॉक्स में [वॉलेट-स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md) के ज़रिये पूरा कर सकते हैं, या जब गंतव्य वॉलेट पहले से आपकी वॉलेट पता सूची में हो तो [स्वामित्व की पुष्टि करें](https://docs.didit.me/hi/management-api/travel-rule/confirm-ownership.md) के ज़रिये।
> थ्रेशोल्ड से ऊपर का कोई भी अन्य ट्रांसफ़र `TEST_VASP` रेल पर Didit Test VASP के पास जाता है, जो उसे Didit के भीतर उस परिदृश्य के साथ उत्तर देता है जिसे आप लाभार्थी वॉलेट या नाम से चुनते हैं: वह पूरा हो जाता है, अस्वीकार कर दिया जाता है, या उसमें बेमेल होता है, `COUNTERPARTY_VASP_NOT_REACHABLE` बन जाता है, समाप्त हो जाता है (फिर आपका `timeout_outcome` लेन-देन पर लागू होता है) या वॉलेट स्वामित्व की प्रतीक्षा करता है।
> हर परिदृश्य के लिए [सैंडबॉक्स में Travel Rule की जाँच](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) देखें।
>
> **इनबाउंड** - `POST /v3/travel-rule/inbound/`। पंजीकरण कभी किसी रेल पर डिस्पैच नहीं होता, इसलिए इसके बारे में कुछ भी सिम्युलेट नहीं किया जाता: सैंडबॉक्स जमा को आपकी वॉलेट पता सूची से मिलाता है और सिंक्रोनस रूप से निपटाता है, ठीक वैसे ही जैसे लाइव करता है। परिणाम `AWAITING_COUNTERPARTY` नहीं, बल्कि एक वास्तविक परिणाम होता है: `ON_HOLD` (पता सूची में कोई मेल नहीं), `UNCONFIRMED_OWNERSHIP` (मिलान किया गया प्रविष्टि स्वामित्व-सत्यापित नहीं है), `COUNTERPARTY_MISMATCHED_DATA` (लाभार्थी का नाम वॉलेट धारक से नहीं मिलता), या `COMPLETED` और फिर `FINISHED` (सत्यापित प्रविष्टि से मेल हुआ)।
> Didit Test VASP से ट्रांसफ़र पाने के लिए इसके बजाय [Test VASP इनबाउंड ट्रांसफ़र ट्रिगर करें](https://docs.didit.me/hi/management-api/travel-rule/trigger-test-vasp-inbound.md) का उपयोग करें, और अपने पता-बुक वाले किसी एक वॉलेट का उपयोग करके।

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

कैटलॉग का `travel_rule.scenarios` ये आउटबाउंड परिदृश्य सूचीबद्ध करता है। सैंडबॉक्स एप्लिकेशन पर Travel Rule सक्षम करने के बाद, आउटबाउंड `travelRule` लेन-देन पर नीचे दिया गया लाभार्थी नाम सेट करें। ऊपर बताई गई थ्रेशोल्ड और घोषित स्व-होस्टेड वॉलेट जाँच पहले चलती हैं।

| परिदृश्य | लाभार्थी नाम | परिणाम |
| - | - | - |
| `accept` | `Didit Test VASP` | `COMPLETED` |
| `decline` | `Didit Test VASP Decline` | `COUNTERPARTY_VASP_GENERAL_DECLINE` |
| `name_mismatch` | `Didit Test VASP Name Mismatch` | `COUNTERPARTY_MISMATCHED_DATA` |
| `not_reachable` | `Didit Test VASP Not Reachable` | डिलीवरी पुनः प्रयासों के बाद `COUNTERPARTY_VASP_NOT_REACHABLE` |
| `timeout` | `Didit Test VASP Timeout` | `EXPIRED`, जब समाप्ति जाँच एक-मिनट की समय-सीमा के बाद चलती है |
| `self_hosted` | `Didit Test VASP Self Hosted` | `UNCONFIRMED_OWNERSHIP` |

आप लाभार्थी नाम के बजाय लाभार्थी वॉलेट पते से भी परिदृश्य चुन सकते हैं (दोनों सेट होने पर वॉलेट को प्राथमिकता मिलती है), और जो ट्रांसफ़र कोई भी नाम नहीं देता, वह `accept` के रूप में पूरा होता है। [सैंडबॉक्स में Travel Rule की जाँच](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) हर परिदृश्य का वॉलेट और उसका सटीक परिणाम सूचीबद्ध करती है।

[इनबाउंड Test VASP ट्रिगर](https://docs.didit.me/hi/management-api/travel-rule/trigger-test-vasp-inbound.md) अपने `scenario` फ़ील्ड में केवल `accept` और `name_mismatch` स्वीकार करता है।

> [!NOTE]
>
> **नियम को लाइव होने से पहले कैसे परखें।** [Backtest](https://docs.didit.me/hi/transaction-monitoring/rules-api.md#बनाएँ-बैकटेस्ट-करें-सक्रिय-करें) का उपयोग करें: यह नियम को आपके वास्तविक लेन-देन इतिहास पर फिर से चलाता है और `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-फ़्लो-शुरू-होने-से-पहले-सत्र-में-परिदृश्य-सक्रिय-या-पुनः-सक्रिय-करें) देखें), और फिर उस परिदृश्य के मैजिक वैल्यू पहले से लागू करके फ़्लो आगे बढ़ता है।
* **नमूना दस्तावेज़ स्ट्रिप।** दस्तावेज़ अपलोड/कैप्चर कॉम्पोनेंट के ठीक नीचे सैंडबॉक्स नमूना दस्तावेज़ों की एक पंक्ति (अधिकतम 3) दिखती है। वास्तविक अपलोड के बजाय उसका उपयोग करने के लिए किसी एक पर टैप करें।

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

## Scenarios

हर परिदृश्य मैजिक वैल्यू का एक नामित समूह है। उसका स्लग सत्र बनाते समय `sandbox_scenario` के रूप में पास करें (या सिमुलेट endpoint को भेजें), ताकि वही परिणाम दोहराया जा सके।

| स्लग | शीर्षक | डिफ़ॉल्ट स्थिति | विवरण |
| - | - | - | - |
| `approve` | हैप्पी पाथ — सभी सुविधाएँ स्वीकृत | स्वीकृत | डिफ़ॉल्ट सैंडबॉक्स व्यवहार: हर मॉक की गई सुविधा अपना साफ़ APPROVED परिणाम लौटाती है। सत्र की स्थिति APPROVED पर समाप्त होती है। |
| `decline_aml_hit` | AML — राजनीतिक रूप से उजागर व्यक्ति | अस्वीकृत | AML मॉक एक हिट लौटाता है और सत्र AML सुविधा पर अस्वीकृत हो जाता है। यह हिट उसी [Hit schema](https://docs.didit.me/hi/core-technology/aml-screening/report-aml-screening.md#प्रति-हिट-फ़ील्ड) का उपयोग करता है जो लाइव AML प्रदाता करते हैं: `url`, `match_score`, `risk_score`, `review_status`, `properties`, `pep_matches[]` और `score_breakdown` सभी भरे होते हैं, और POSSIBLE\_MATCH\_FOUND चेतावनी लॉग लिखा जाता है। |
| `decline_document_expired` | पहचान सत्यापन — दस्तावेज़ की समय-सीमा समाप्त | अस्वीकृत | पहचान सत्यापन मॉक एक पासपोर्ट लौटाता है जिसकी समाप्ति तिथि अतीत में है। सत्र पहचान सत्यापन पर DOCUMENT\_EXPIRED चेतावनी लॉग के साथ अस्वीकृत हो जाता है। |
| `decline_minimum_age` | पहचान सत्यापन — न्यूनतम आयु नीति के तहत निर्धारित आयु से कम | अस्वीकृत | पहचान सत्यापन मॉक ऐसी जन्म तिथि लौटाता है जिससे उपयोगकर्ता लगभग 10 वर्ष का होता है। प्रोडक्शन आयु जाँच MINIMUM\_AGE\_NOT\_MET जारी करती है और वर्कफ़्लो अस्वीकार कर देता है। |
| `decline_mrz_validation` | पहचान सत्यापन — MRZ चेकसम विफलता | अस्वीकृत | पहचान सत्यापन मॉक ऐसा पासपोर्ट लौटाता है जिसका MRZ चेकसम दूषित है। प्रोडक्शन MRZ वैलिडेटर MRZ\_VALIDATION\_FAILED जारी करता है और सत्र अस्वीकृत हो जाता है। |
| `decline_could_not_recognize_document` | पहचान सत्यापन — अपठनीय दस्तावेज़ | अस्वीकृत | पहचान सत्यापन मॉक एक खाली रिस्पॉन्स लौटाता है। प्रोडक्शन सिस्टम COULD\_NOT\_RECOGNIZE\_DOCUMENT उठाता है और उसे SDK तक पहुँचाता है। |
| `decline_face_match_low_similarity` | चेहरा मिलान — समानता अस्वीकृति थ्रेशोल्ड से कम | अस्वीकृत | चेहरा मिलान मॉक कम स्कोर लौटाता है। प्रोडक्शन सिस्टम LOW\_FACE\_MATCH\_SIMILARITY जारी करता है और वर्कफ़्लो नोड की कार्रवाई मैपिंग अस्वीकार कर देती है। |
| `decline_database_no_match` | डेटाबेस सत्यापन — सभी सेवाओं में कोई मिलान नहीं | अस्वीकृत | चयनित हर डेटाबेस सेवा NO\_MATCH लौटाती है। प्रोडक्शन सिस्टम DATABASE\_VALIDATION\_NO\_MATCH जारी करता है और वर्कफ़्लो अस्वीकार कर देता है। |
| `decline_phone_high_risk` | फ़ोन — आरक्षित उच्च-जोखिम परीक्षण नंबर | अस्वीकृत | फ़ोन सत्यापन मॉक सत्यापन को ब्लॉक करता है (आरक्षित परीक्षण रेंज)। फ़ोन सत्यापन BLOCKED पर समाप्त होता है और HIGH\_RISK\_PHONE\_NUMBER जारी होता है। |
| `decline_email_breach` | ईमेल — ब्रीच-डेटाबेस हिट | अस्वीकृत | ईमेल ब्रीच मॉक उस पते पर एक ब्रीच हिट लौटाता है। ईमेल सत्यापन BREACHED\_EMAIL\_DETECTED जारी करता है। |
| `decline_ip_blocklist` | IP विश्लेषण — IP पता ब्लॉकलिस्ट में | अस्वीकृत | IP विश्लेषण मॉक IP\_ADDRESS\_IN\_BLOCKLIST के साथ स्थान को अस्वीकार करता है। सत्र IP विश्लेषण पर अस्वीकृत हो जाता है। |
| `decline_poa_address_mismatch` | POA — दिए गए पते से मेल नहीं खाता | अस्वीकृत | POA मॉक ADDRESS\_MISMATCH\_WITH\_PROVIDED के साथ पते के प्रमाण को अस्वीकार करता है। सत्र POA पर अस्वीकृत हो जाता है। |
| `decline_liveness_attack` | लाइवनेस — चेहरे पर हमला पहचाना गया | अस्वीकृत | पैसिव लाइवनेस मॉक चेहरे पर हमले का संकेत पहचानता है और LIVENESS\_FACE\_ATTACK जारी करता है। सत्र लाइवनेस पर अस्वीकृत हो जाता है। |
| `decline_nfc_chip_not_verified` | NFC — ePassport चिप सत्यापित नहीं | अस्वीकृत | ePassport मॉक ऐसी चिप लौटाता है जिसके SOD/DG हस्ताक्षर की अखंडता विफल होती है। प्रोडक्शन सिस्टम NFC\_CHIP\_NOT\_VERIFIED जारी करता है और जब वर्कफ़्लो असत्यापित चिप पर अस्वीकार करता है, तब सत्र NFC पर अस्वीकृत हो जाता है। |
| `decline_nfc_trust_anchor_missing` | NFC — जारीकर्ता ट्रस्ट एंकर उपलब्ध नहीं | अस्वीकृत | ePassport मॉक ऐसी चिप लौटाता है जिस पर DSC से हस्ताक्षर है, और जिसका जारी करने वाला CSCA ट्रस्ट स्टोर में नहीं है। प्रोडक्शन सिस्टम NFC\_TRUST\_ANCHOR\_MISSING जारी करता है और जब वर्कफ़्लो असत्यापित चिप पर अस्वीकार करता है, तब सत्र अस्वीकृत हो जाता है। |
| `decline_document_ai_unreadable` | Document AI — अपठनीय दस्तावेज़ | अस्वीकृत | Document AI मॉक कोई पठनीय फ़ील्ड नहीं लौटाता। प्रोडक्शन सिस्टम DOCUMENT\_AI\_UNREADABLE\_DOCUMENT जारी करता है और पुनः प्रयास की सीमा समाप्त होने पर दस्तावेज़ की स्थिति अस्वीकृत हो जाती है। |
| `review_aml_possible_match` | AML — संभावित मिलान की समीक्षा चाहिए | समीक्षाधीन | AML मॉक कम विश्वास वाला हिट लौटाता है। सत्र समीक्षाधीन स्थिति में पहुँचता है और विश्लेषक के हल करने के लिए चेतावनी स्तर का POSSIBLE\_MATCH\_FOUND लॉग होता है। |
| `review_face_match_borderline` | चेहरा मिलान — सीमा-रेखा समानता | समीक्षाधीन | चेहरा मिलान मॉक ऐसा स्कोर लौटाता है जो समीक्षा और अस्वीकृति थ्रेशोल्ड के बीच है। सत्र चेहरा मिलान पर समीक्षाधीन स्थिति में पहुँचता है। |
| `review_document_borderline_age` | पहचान सत्यापन - कम आयु, समीक्षा के लिए भेजा गया | समीक्षाधीन | पहचान सत्यापन मॉक ऐसी जन्म तिथि लौटाता है जो वर्कफ़्लो की कॉन्फ़िगर की गई न्यूनतम आयु से कम है। वर्कफ़्लो का minimum\_age\_action REVIEW पर सेट है, DECLINE पर नहीं, इसलिए सत्र अस्वीकार होने के बजाय पहचान सत्यापन पर समीक्षाधीन स्थिति में पहुँचता है। |
| `review_poa_partial_match` | POA — आंशिक पता मिलान | समीक्षाधीन | POA मॉक ऐसा पता लौटाता है जो दिए गए पते से केवल आंशिक रूप से मेल खाता है। सत्र पते के प्रमाण पर समीक्षाधीन स्थिति में पहुँचता है। |
| `review_database_partial_match` | डेटाबेस सत्यापन — आंशिक मिलान | समीक्षाधीन | डेटाबेस सेवाएँ नाम और जन्म तिथि पर आंशिक मिलान लौटाती हैं। सत्र डेटाबेस सत्यापन पर समीक्षाधीन स्थिति में पहुँचता है। |
| `decline_kyb_registry_mismatch` | KYB - रजिस्ट्री डेटा मेल नहीं खाता | अस्वीकृत | रजिस्ट्री मॉक ऐसी कंपनी लौटाता है जिसका पंजीकरण डेटा अपेक्षित विवरणों से मेल नहीं खाता। व्यवसाय सत्र रजिस्ट्री जाँच पर अस्वीकृत हो जाता है। |
| `review_kyb_registry_partial` | KYB - रजिस्ट्री डेटा आंशिक रूप से मेल खाता है | समीक्षाधीन | रजिस्ट्री मॉक ऐसी कंपनी लौटाता है जिसका नाम केवल आंशिक रूप से मेल खाता है। व्यवसाय सत्र रजिस्ट्री जाँच पर समीक्षाधीन स्थिति में पहुँचता है। |

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

## मैजिक वैल्यू

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

| सुविधा | इनपुट फ़ील्ड | मैजिक वैल्यू | जोखिम | विवरण |
| - | - | - | - | - |
| AML | `user_email` | `sandbox+aml_hit@didit.test` | `POSSIBLE_MATCH_FOUND` | AML: राजनीतिक रूप से उजागर व्यक्ति; AML मॉक एक हिट लौटाता है, और सत्र AML पर अस्वीकृत हो जाता है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_EXPIRED` | `DOCUMENT_EXPIRED` | OCR: दस्तावेज़ की समय-सीमा समाप्त हो चुकी है; सत्र पहचान सत्यापन पर अस्वीकृत हो जाता है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MINIMUM_AGE_NOT_MET` | `MINIMUM_AGE_NOT_MET` | OCR: जन्म तिथि के अनुसार उपयोगकर्ता कॉन्फ़िगर की गई न्यूनतम आयु से कम है; सत्र अस्वीकृत हो जाता है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MAXIMUM_AGE_EXCEEDED` | `MAXIMUM_AGE_EXCEEDED` | OCR: निकाली गई जन्म तिथि कॉन्फ़िगर की गई अधिकतम आयु नीति से अधिक है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NUMBER_FORMAT_MISMATCH` | `DOCUMENT_NUMBER_FORMAT_MISMATCH` | OCR: निकाला गया दस्तावेज़ नंबर दस्तावेज़ रजिस्ट्री से मिले अपेक्षित फ़ॉर्मैट regex से मेल नहीं खाता। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_PERSONAL_NUMBER_FORMAT_MISMATCH` | `PERSONAL_NUMBER_FORMAT_MISMATCH` | OCR: निकाला गया व्यक्तिगत नंबर दस्तावेज़ रजिस्ट्री की फ़ॉर्मैट जाँच में विफल रहता है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION` | `DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION` | OCR: निकाला गया दस्तावेज़ प्रकार एप्लिकेशन की `documents_allowed` नीति से बाहर है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED` | `FULL_NAME_MISMATCH_WITH_PROVIDED` | OCR: दस्तावेज़ पर लिखा नाम उस नाम से मेल नहीं खाता जो ग्राहक ने `expected_details` में पहले से भरा था, और यह अंतर नाम-मिलान थ्रेशोल्ड से ऊपर है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_GENDER_MISMATCH_WITH_PROVIDED` | `GENDER_MISMATCH_WITH_PROVIDED` | OCR: निकाला गया लिंग `expected_details.gender` से मेल नहीं खाता। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED` | `DOB_MISMATCH_WITH_PROVIDED` | OCR: निकाली गई जन्म तिथि `expected_details.date_of_birth` से मेल नहीं खाती। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COUNTRY_MISMATCH_WITH_PROVIDED` | `COUNTRY_MISMATCH_WITH_PROVIDED` | OCR: जारी करने वाला राज्य `expected_details.country` (या `id_country`) से मेल नहीं खाता। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_NATIONALITY_MISMATCH_WITH_PROVIDED` | `NATIONALITY_MISMATCH_WITH_PROVIDED` | OCR: निकाली गई राष्ट्रीयता `expected_details.nationality` से मेल नहीं खाती। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED` | `IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED` | OCR: निकाला गया दस्तावेज़, व्यक्तिगत या कर संख्या `expected_details.identification_number` से मेल नहीं खाती। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_RECOGNIZE_DOCUMENT` | `COULD_NOT_RECOGNIZE_DOCUMENT` | OCR पाइपलाइन खाली या न पहचाने जाने योग्य परिणाम लौटाती है; प्रोडक्शन में COULD\_NOT\_RECOGNIZE\_DOCUMENT उत्पन्न होता है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_NOT_DETECTED` | `MRZ_NOT_DETECTED` | OCR: दस्तावेज़ से MRZ अपेक्षित है, लेकिन पाइपलाइन उसे ढूँढ नहीं पाई। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_VALIDATION_FAILED` | `MRZ_VALIDATION_FAILED` | OCR: MRZ मिला, लेकिन चेकसम या फ़ॉर्मैट सत्यापन में विफल रहा। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME` | `MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME` | OCR: MRZ के पहचान फ़ील्ड, VIZ से निकाले गए फ़ील्ड से मेल नहीं खाते। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_NOT_DETECTED` | `BARCODE_NOT_DETECTED` | OCR: दस्तावेज़ से बारकोड अपेक्षित है, लेकिन कोई नहीं मिला। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_VALIDATION_FAILED` | `BARCODE_VALIDATION_FAILED` | OCR: बारकोड डिकोड हुआ, लेकिन क्रॉस-फ़ील्ड सत्यापन में विफल रहा। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_NOT_DETECTED` | `QR_NOT_DETECTED` | OCR: दस्तावेज़ से QR कोड अपेक्षित है, लेकिन कोई नहीं मिला। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_VALIDATION_FAILED` | `QR_VALIDATION_FAILED` | OCR: QR कोड डिकोड हुआ, लेकिन क्रॉस-फ़ील्ड सत्यापन में विफल रहा। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATA_INCONSISTENT` | `DATA_INCONSISTENT` | OCR: VIZ फ़ील्ड पर की गई आंतरिक संगति जाँच आपस में मेल नहीं खाती। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_SIDES_MISMATCH` | `DOCUMENT_SIDES_MISMATCH` | OCR: सामने और पीछे के document\_name एक ही दस्तावेज़ के रूप में मेल नहीं खाते। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_NAME_NOT_DETECTED` | `NAME_NOT_DETECTED` | OCR: दस्तावेज़ से न पहला नाम निकल सका, न अंतिम नाम। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATE_OF_BIRTH_NOT_DETECTED` | `DATE_OF_BIRTH_NOT_DETECTED` | OCR: दस्तावेज़ वर्ग में जन्म तिथि अपेक्षित है, लेकिन निष्कर्षण में कोई नहीं मिली। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_EXPIRATION_DATE_NOT_DETECTED` | `EXPIRATION_DATE_NOT_DETECTED` | OCR: दस्तावेज़ वर्ग में समाप्ति तिथि अपेक्षित है, लेकिन निष्कर्षण में कोई नहीं मिली। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NUMBER_NOT_DETECTED` | `DOCUMENT_NUMBER_NOT_DETECTED` | OCR: न दस्तावेज़ नंबर निकल सका, न व्यक्तिगत नंबर। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_DETECT_DOCUMENT_TYPE` | `COULD_NOT_DETECT_DOCUMENT_TYPE` | OCR: क्लासिफ़ायर कैप्चर को किसी समर्थित दस्तावेज़ प्रकार से नहीं जोड़ सका। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_PORTRAIT_IMAGE_NOT_DETECTED` | `PORTRAIT_IMAGE_NOT_DETECTED` | OCR: पाइपलाइन दस्तावेज़ पर पोर्ट्रेट क्षेत्र अलग नहीं कर सकी। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_UNPARSED_ADDRESS` | `UNPARSED_ADDRESS` | OCR: दस्तावेज़ में पते का फ़ील्ड है, लेकिन जियोकोडिंग / पार्सिंग से कोई उपयोगी परिणाम नहीं मिला। |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_NO_MATCH` | `DATABASE_VALIDATION_NO_MATCH` | डेटाबेस सत्यापन: हर सरकारी/रजिस्ट्री सेवा NO\_MATCH लौटाती है; डेटाबेस सत्यापन पर सत्र अस्वीकृत होता है। |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_LOW_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | चेहरा मिलान: समानता स्कोर अस्वीकृति थ्रेशोल्ड से नीचे है; चेहरा मिलान पर सत्र अस्वीकृत होता है। |
| PHONE | `phone_number` | `+15005550009` | `HIGH_RISK_PHONE_NUMBER` | फ़ोन: आरक्षित, न पहुँचने योग्य / उच्च-जोखिम वाला परीक्षण नंबर; फ़ोन सत्यापन मॉक विफलता लौटाता है। |
| EMAIL | `user_email` | `sandbox+breach@didit.test` | `BREACHED_EMAIL_DETECTED` | ईमेल: ब्रीच डेटाबेस इस पते पर एक मिलान लौटाता है। |
| LOCATION | `expected_details.first_name` | `SANDBOX_IP_BLOCKLIST` | `IP_ADDRESS_IN_BLOCKLIST` | IP विश्लेषण: कॉलर का IP एप्लिकेशन की ब्लॉकलिस्ट में है; IP विश्लेषण पर सत्र अस्वीकृत होता है। |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_ADDRESS_MISMATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | POA: अपलोड किए गए दस्तावेज़ का पता उस पते से मेल नहीं खाता जो ग्राहक ने `expected_details` में पहले से भरा था; POA पर सत्र अस्वीकृत होता है। |
| LIVENESS | `expected_details.first_name` | `SANDBOX_LIVENESS_ATTACK` | `LIVENESS_FACE_ATTACK` | लाइवनेस: पैसिव लाइवनेस मॉक फ़ेस-अटैक संकेत का पता लगाता है; लाइवनेस पर सत्र अस्वीकृत होता है। |
| NFC | `expected_details.first_name` | `SANDBOX_NFC_CHIP_NOT_VERIFIED` | `NFC_CHIP_NOT_VERIFIED` | NFC: ePassport मॉक ऐसी चिप लौटाता है जिसका SOD/DG हस्ताक्षर अखंडता जाँच में विफल होता है; प्रोडक्शन NFC\_CHIP\_NOT\_VERIFIED जारी करता है और जब वर्कफ़्लो असत्यापित चिप पर अस्वीकार करता है, तब सत्र अस्वीकृत होता है। |
| NFC | `expected_details.first_name` | `SANDBOX_NFC_TRUST_ANCHOR_MISSING` | `NFC_TRUST_ANCHOR_MISSING` | NFC: DSC एक ऐसे CSCA से जुड़ती है जो ट्रस्ट स्टोर में मौजूद नहीं है; प्रोडक्शन NFC\_TRUST\_ANCHOR\_MISSING जारी करता है और कॉन्फ़िगर की गई असत्यापित-चिप कार्रवाई लागू करता है। |
| DOCUMENT\_AI | `expected_details.first_name` | `SANDBOX_DOCUMENT_AI_UNREADABLE` | `DOCUMENT_AI_UNREADABLE_DOCUMENT` | Document AI: एक्सट्रैक्शन में कोई पठनीय फ़ील्ड नहीं मिलता; प्रोडक्शन DOCUMENT\_AI\_UNREADABLE\_DOCUMENT जारी करता है और पुनः प्रयास सीमा समाप्त होने पर दस्तावेज़ अस्वीकृत के रूप में निपट जाता है। |
| AML | `user_email` | `sandbox+aml_review@didit.test` | `POSSIBLE_MATCH_FOUND` | AML: संभावित मिलान जिसे मैन्युअल रूप से हल करना होगा; सत्र समीक्षाधीन हो जाता है। |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_BORDERLINE_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | चेहरा मिलान: समीक्षा और अस्वीकृति थ्रेशोल्ड के बीच की समानता; सत्र समीक्षाधीन हो जाता है। |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BORDERLINE_AGE` | `MINIMUM_AGE_NOT_MET` | OCR: व्यक्ति की आयु न्यूनतम आयु से कम है, लेकिन वर्कफ़्लो न्यूनतम आयु की विफलताओं को अस्वीकार करने के बजाय समीक्षा करता है; सत्र समीक्षाधीन हो जाता है। |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_PARTIAL_MATCH` | `DATABASE_VALIDATION_PARTIAL_MATCH` | डेटाबेस सत्यापन: पहचान मेल खाती है, लेकिन नाम/जन्म तिथि केवल आंशिक रूप से मेल खाते हैं; सत्र समीक्षाधीन हो जाता है। |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_PARTIAL_MATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | POA: अपलोड किए गए दस्तावेज़ का पता दिए गए पते से आंशिक रूप से मेल खाता है; सत्र समीक्षाधीन हो जाता है। |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-MISMATCH` | `KYB_REGISTRY_DATA_MISMATCH_WITH_EXPECTED` | KYB: रजिस्ट्री कंपनी डेटा अपेक्षित विवरण से मेल नहीं खाता; सत्र अस्वीकृत होता है। |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-REVIEW` | `KYB_REGISTRY_DATA_PARTIAL_MATCH_WITH_EXPECTED` | KYB: रजिस्ट्री कंपनी डेटा आंशिक रूप से मेल खाता है; सत्र समीक्षाधीन हो जाता है। |

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

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

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

| परिदृश्य | अनुकरणित परिणाम |
| - | - |
| `lookup_partial_match` | रजिस्ट्री आंशिक मिलान लौटाती है; प्रयास सीमा में गिना जाता है। |
| `lookup_no_match` | रजिस्ट्री बिना मिलान के उत्तर देती है; प्रयास सीमा में गिना जाता है। |
| `lookup_provider_error` | रजिस्ट्री कोई उत्तर नहीं देती; उपयोगकर्ता से फिर से प्रयास करने को कहा जाता है, और तीन अनुत्तरित प्रयासों के बाद प्रदाता-त्रुटि फ़ॉलबैक लागू होता है। |
| `wallet_cancelled` | उपयोगकर्ता वॉलेट साइन-इन रद्द करता है। |
| `wallet_timeout` | वॉलेट साइन-इन की समय-सीमा समाप्त हो जाती है। |
| `wallet_provider_error` | वॉलेट साइन-इन पूरा नहीं कर पाता। |

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

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

सैंडबॉक्स बैंक सत्यापन चरण हर देश में [दोनों तरीके](https://docs.didit.me/hi/core-technology/bank-verification/verification-methods.md) प्रस्तुत करता है, चरण द्वारा निर्धारित क्रम में। यह एक अनुकरणित सेवा पर चलता है, जिसमें कोई वास्तविक बैंक नहीं है और कोई लागत नहीं है। डिफ़ॉल्ट क्रम में व्यक्ति बैंक साइन-इन से शुरू करता है और [खाता जाँच](https://docs.didit.me/hi/core-technology/bank-verification/account-check.md) चलाने के लिए **अपने खाते का विवरण दर्ज करें** चुनता है। इसे पहले शुरू करने के लिए `bank_method_order` को `["account_lookup", "open_banking"]` पर सेट करें।

दर्ज किए गए खाते के अंतिम चार अक्षर उत्तर तय करते हैं; हर अंतिम चार-अक्षर संयोजन और हर प्रारूप के लिए एक मान्य खाता देखने के लिए [सैंडबॉक्स में परीक्षण करें](https://docs.didit.me/hi/core-technology/bank-verification/account-check.md#सैंडबॉक्स-में-इसका-परीक्षण-करें) देखें। [खाता जाँच API](https://docs.didit.me/hi/standalone-apis/bank-account-check.md) उन्हीं अंतिम चार-अक्षर संयोजनों से सैंडबॉक्स कुंजी लौटाता है।

## Los documentos de muestra

> [!WARNING]
>
> 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:

| País | Tipo de documento |
| - | - |
| España | Documento Nacional de Identidad |
| Argentina | Pasaporte |
| Polonia | Permiso de conducir |

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:

| Campo | Valor |
| - | - |
| `date_of_birth` | `1990-06-15` |
| Fecha de emisión | `2025-06-15` |
| Fecha de caducidad | `2035-06-15` |

El resto de la identidad depende del documento que uses:

| `sandbox_sample` | Documento | `first_name` | `last_name` | `gender` | `nationality` | `id_country` | `identification_number` |
| - | - | - | - | - | - | - | - |
| *(predeterminado, ninguna muestra seleccionada)* | Pasaporte electrónico de Brasil | `GUSTAVO` | `MATSUMOTO` | `M` | `BRA` | `BRA` | `YC531181` |
| `spain-id-card-2021` | Documento Nacional de Identidad de España | `CARMEN` | `ESPAÑOLA ESPAÑOLA` | `F` | `ESP` | `ESP` | `CAA000000` |
| `argentina-passport-2009` | Pasaporte de Argentina | `MARIA VICTORIA` | `VILLAREAL` | `F` | `ARG` | `ARG` | `AAF794880` |
| `poland-driving-license-2019` | Permiso de conducir de Polonia | `JAN` | `KOWALSKI` | no aparece en este documento | `POL` | `POL` | `SP005/89/5` |

```json theme={null}
{
  "workflow_id": "<your-workflow-uuid>",
  "expected_details": {
    "date_of_birth": "1990-06-15",
    "gender": "M",
    "nationality": "BRA",
    "identification_number": "YC531181"
  }
}
```

`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.

> [!NOTE]
>
> 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](https://docs.didit.me/hi/console/workflows.md#ब्रांच-शर्तें-सत्र-डेटा-कैसे-पढ़ती-हैं) 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:

| Patrón de consentimiento | Ejemplo |
| - | - |
| `<local>+sandbox@<domain>` | `alice+sandbox@example.com` |
| `*@didit.test` | `alice@didit.test` |

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

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

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

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

```json theme={null}
{
  "workflow_id": "<your-workflow-uuid>",
  "sandbox_scenario": "decline_document_expired"
}
```

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

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

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

पहले से मौजूद सत्र पर सक्रिय परिदृश्य सेट या बदलें, बशर्ते वह `Not Started` से आगे न बढ़ा हो। यही वह endpoint है जिसे [फ़्लो से पहले का परिदृश्य चयनकर्ता](#होस्टेड-सत्यापन-फ़्लो-में-सैंडबॉक्स) कॉल करता है। आप इसे खुद भी कॉल कर सकते हैं, ताकि कस्टम चयनकर्ता या टेस्ट हार्नेस बना सकें:

```
POST /v3/session/{session_id}/sandbox/arm/
Session-Token: <session_token>
```

```json theme={null}
{
  "scenario": "decline_document_expired"
}
```

200 रिस्पॉन्स:

```json theme={null}
{
  "session_id": "<session_id>",
  "scenario": "decline_document_expired",
  "status": "Not Started"
}
```

* सत्र के अपने `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` में से कम से कम एक आवश्यक है:

| फ़ील्ड | प्रकार | क्या करता है |
| - | - | - |
| `new_status` | string | `Approved`, `Declined`, `In Review`, `Expired` या `Abandoned`। छोड़ने पर यह जोखिम मामले (`risk`, या परिदृश्य की मैजिक वैल्यू में मौजूद पहले जोखिम) की डिफ़ॉल्ट स्थिति होती है, और वह न हो तो परिदृश्य की डिफ़ॉल्ट स्थिति। |
| `scenario` | string, अधिकतम 100 अक्षर | परिदृश्य slug। `risk` के बिना, उसकी मैजिक वैल्यू में मौजूद पहला जोखिम लागू होता है। |
| `risk` | string, अधिकतम 128 अक्षर | एक जोखिम मामला। उसकी चेतावनी सत्र में जोड़ी जाती है। |
| `node_id` | string, अधिकतम 128 अक्षर | वर्कफ़्लो नोड जिससे चेतावनी जुड़ती है। डिफ़ॉल्ट सत्र का वर्तमान नोड है। |
| `comment` | string, अधिकतम 500 अक्षर | उस गतिविधि एंट्री में जोड़ा गया नोट, जिसमें स्थिति बदलाव दर्ज होता है। |
| `send_webhooks` | boolean, डिफ़ॉल्ट `true` | क्या स्थिति बदलाव webhook भेजेगा। |

`send_webhooks: true` ठीक वही webhook भेजता है जो असली स्थिति बदलाव भेजता है: `status.updated`, साथ ही वे `user.status.updated` और `user.data.updated` इवेंट (या बिज़नेस सत्र के लिए `business.status.updated` और `business.data.updated`) जो बदलाव से उत्पन्न होते हैं, उन गंतव्यों पर जो इनकी सदस्यता लिए हुए हैं।
`send_webhooks: false` के साथ स्थिति फिर भी बदलती है, लेकिन कोई webhook न लॉग होता है न भेजा जाता है।
छूटे webhook की रिकवरी उस निर्णय को कभी दोबारा नहीं भेजती, और कंसोल फिर भी लाइव अपडेट होता है।
सत्र का अगला स्थिति बदलाव सामान्य रूप से webhook भेजता है।

```json theme={null}
{
  "scenario": "decline_aml_hit",
  "send_webhooks": false
}
```

200 रिस्पॉन्स:

```json theme={null}
{
  "session_id": "<session_id>",
  "previous_status": "In Progress",
  "status": "Declined",
  "scenario": "decline_aml_hit",
  "risk": "POSSIBLE_MATCH_FOUND",
  "send_webhooks": false
}
```

* `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/`) पर जाता है:

```json theme={null}
{
  "full_name": "Ada Lovelace",
  "save_api_request": true,
  "sandbox_scenario": "decline_aml_hit"
}
```

* `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`) कुछ सतहों पर वापस दिखाया जाता है, और कुछ पर जानबूझकर नहीं:

| सतह | दिखाया जाता है? |
| - | - |
| वर्तमान स्टेप payload (KYC और KYB) | हाँ, `sandbox_scenario` के रूप में |
| `GET /v1/session/{id}/decision/` | हाँ, `sandbox_scenario` के रूप में |
| `GET /v3/session/{id}/decision/` (देखें [सत्र प्राप्त करें](https://docs.didit.me/hi/sessions-api/retrieve-session.md)) | हाँ, शीर्ष-स्तरीय `sandbox_scenario` (सक्रिय न होने पर null) |
| सत्र webhook (`status.updated`, `data.updated`) | हाँ, `sandbox_scenario` के रूप में, लाइव सत्रों या बिना सक्रिय परिदृश्य वाले सैंडबॉक्स सत्रों पर `null` |

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

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

सैंडबॉक्स उपयोग ट्रैक किया जाता है, लेकिन उसका शुल्क कभी नहीं लिया जाता:

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.