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

# Dades de prova del sandbox: escenaris, valors i documents

> Prova Didit al sandbox: escenaris, valors màgics, endpoint arm, documents de mostra i codis OTP per a resultats deterministes, sense PII ni facturació.

El **sandbox** de Didit equival a les targetes de prova de Stripe o a les plantilles de documents de Sumsub: et permet reproduir qualsevol resultat de verificació de manera determinista, sense tocar proveïdors reals, dades personals reals ni el teu saldo.

> [!NOTE]
>
> La font de veritat d'aquestes dades és `serialize_catalog()` al servei de verificació, que es serveix en directe a `GET /v1/sandbox/scenarios/`. Es genera una còpia verificada amb proves de deriva a `docs/sandbox/SANDBOX_REFERENCE.md` del repositori `service-didit-verification` amb `pipenv run python scripts/generate_sandbox_reference.py`. Aquesta pàgina reflecteix aquesta referència: si alguna cosa d'aquí sembla desactualitzada, confia sempre en l'endpoint de catàleg en directe. L'endpoint de catàleg requereix autenticació: envia la teva clau d'API (`x-api-key`) com en qualsevol altra crida, o un token de sessió si el consultes des d'una sessió en curs.

## Model d'entorn

El sandbox és un **mode per aplicació** (`ApplicationDetail.mode == SANDBOX`), la mateixa idea que el mode de prova de Stripe. Mentre una sessió s'executa sota una aplicació de sandbox:

* Tots els proveïdors externs (OCR, AML, coincidència facial, prova de vida, NFC, telèfon, correu electrònic, IP, comprovant de domicili, validació de bases de dades i IA documental) són **simulats**: mai no es crida cap tercer.
* **La prova de vida funciona exactament igual que en producció.** Un flux de treball de prova de vida activa executa la captura activa real al sandbox, tant en el flux allotjat com en el pas web dels SDK natius, de manera que pots provar l'experiència que tindran els teus usuaris. Només es simula el *resultat* de la prova de vida, mitjançant l'escenari o el valor màgic, i l'informe registra el *mètode* que configura el teu flux de treball.
* **Els dominis personalitzats són només de producció.** Una aplicació de sandbox no pot afegir un [domini personalitzat](https://docs.didit.me/ca/console/custom-domain.md); les sessions de sandbox sempre s'executen al domini de verificació allotjat per defecte.
* Les sessions **mai es cobren** i la comprovació de saldo s'omet.
* S'aplica una quota per aplicació de **500 creacions de sessió / 24 h**.
* Els webhooks porten `"environment": "sandbox"` (les sessions de producció porten `"environment": "live"`).
* El flux allotjat mostra l'entorn de la sessió perquè la interfície pugui advertir els usuaris que no pugin dades personals reals.
* **Els resultats mai no depenen dels píxels**: les dades extretes i els estats provenen de l'escenari o del valor màgic. El contingut capturat (documents, selfie, vídeo, fitxers de comprovant de domicili) s'emmagatzema de veritat, exactament com en una sessió de producció.

## Monitoratge de transaccions en sandbox

El sandbox és **de tipus sessió**: simula els proveïdors que cridaria una sessió de verificació. El Monitoratge de transaccions no té cap proveïdor a simular, així que una aplicació sandbox segueix l'altra via: la transacció s'emmagatzema, però **mai no s'executa res que hi prengui decisions, la sotmeti a cribratge, en faci notificacions o en faci el cobrament**.

Una transacció creada en una aplicació sandbox es persisteix i es retorna com de costum, i no li passa cap de les coses següents:

* **Cap avaluació de regles.** `rule_runs` és buit, siguin quins siguin els modes de les teves regles. Una regla `ACTIVE` en una aplicació sandbox mai no s'activa, de manera que la transacció es manté `APPROVED` amb puntuació `0` i no s'obre cap alerta ni cas.
* **Cap cribratge AML ni de carteres.** `provider_results` és buit fins i tot per a transaccions de criptoactius en una aplicació amb el monitoratge habilitat.
* **Cap webhook.** Ni `transaction.created` ni `transaction.status.updated` no s'envien per a una transacció sandbox.
* **Cap facturació.** Es registra un esdeveniment d'ús amb preu `0.0000` i el teu saldo no canvia.

Cada resposta de transacció inclou un camp `environment` (`"live"` o `"sandbox"`), de manera que un `rule_runs` buit mai no és ambigu: `"sandbox"` vol dir que les regles no s'han avaluat, no que cap d'elles no hagi coincidit. La Business Console diu el mateix a la targeta *Risk & decision* de la transacció, en lloc de mostrar un simple "No rules evaluated".

> [!NOTE]
>
> **La Travel Rule és l'única excepció a «no s'executa res».** En una aplicació amb la Travel Rule habilitada, una transacció `travelRule` de sandbox sí que executa el motor d'intercanvi: el registre de la transferència es crea i avança pels seus estats.
> El que el sandbox mai no fa és comunicar-se amb ningú fora de Didit.
> L'única contrapart és el [Didit Test VASP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md), integrat a la plataforma: cap missatge de compliment no arriba a un VASP contrapart real per cap canal (`TRP`, una pertinença a xarxa que hagis connectat, correu electrònic o `INTERNAL`), s'omet el cribratge d'atribució del VASP contrapart, i una cancel·lació no envia res a la contrapart.
> Els webhooks `travel_rule.status.updated` s'envien, marcats amb `"environment": "sandbox"`.
>
> **Sortint** - una transacció `travelRule` que tu envies.
> La comprovació de `threshold_amount` s'executa primer. En sandbox només s'aplica quan envies `transaction_details.amount_in_default_currency`, perquè el sandbox no converteix monedes; sense aquest camp, cada transferència sandbox superaria el llindar.
> Una transferència sense resposta caduca després de `confirmation_timeout_hours`, i llavors s'aplica el teu `timeout_outcome` a la transacció.
> Per sobre del llindar, la comprovació de cartera autoallotjada s'aplica com de costum: una transferència a una [cartera autoallotjada declarada](https://docs.didit.me/ca/transaction-monitoring/travel-rule.md#carteres-autoallotjades-declarades) passa a `UNCONFIRMED_OWNERSHIP` sense cap enviament, i la pots completar en sandbox amb el [widget de verificació de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md), o amb [confirmar la titularitat](https://docs.didit.me/ca/management-api/travel-rule/confirm-ownership.md) quan la cartera de destinació ja és a la teva llibreta d'adreces de carteres.
> Qualsevol altra transferència per sobre del llindar va al Didit Test VASP pel canal `TEST_VASP`, que la respon dins de Didit amb l'escenari que triïs segons la cartera o el nom del beneficiari: es completa, és rebutjada, no coincideix, passa a `COUNTERPARTY_VASP_NOT_REACHABLE`, caduca (llavors s'aplica el teu `timeout_outcome` a la transacció) o espera la titularitat de la cartera.
> Consulta [Prova la Travel Rule en sandbox](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) per veure tots els escenaris.
>
> **Entrant** - `POST /v3/travel-rule/inbound/`. La inscripció mai no es tramet per cap canal, de manera que res d'aquesta inscripció no se simula: el sandbox resol el dipòsit contra la teva llibreta d'adreces de carteres i el liquida de manera síncrona, exactament com en producció. El resultat és sempre un resultat real i mai `AWAITING_COUNTERPARTY`: `ON_HOLD` (sense coincidència a la llibreta d'adreces), `UNCONFIRMED_OWNERSHIP` (l'entrada coincident no té la titularitat verificada), `COUNTERPARTY_MISMATCHED_DATA` (el nom del beneficiari no coincideix amb el del titular de la cartera), o `COMPLETED` i després `FINISHED` (coincidència amb una entrada verificada).
> Per rebre una transferència del Didit Test VASP, fes servir [Activa una transferència entrant del Test VASP](https://docs.didit.me/ca/management-api/travel-rule/trigger-test-vasp-inbound.md) amb una de les carteres de la teva llibreta d'adreces.

### Escenaris del Test VASP de la Travel Rule

El `travel_rule.scenarios` del catàleg enumera aquests escenaris de sortida. Estableix el nom del beneficiari indicat a continuació en una transacció `travelRule` de sortida, després d'habilitar la Travel Rule a la teva aplicació sandbox. Les comprovacions de llindar i de cartera autoallotjada declarada descrites anteriorment s'executen primer.

| Escenari | Nom del beneficiari | Resultat |
| - | - | - |
| `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` després de reintents de lliurament |
| `timeout` | `Didit Test VASP Timeout` | `EXPIRED` quan la comprovació de caducitat s'executa després del termini d'un minut |
| `self_hosted` | `Didit Test VASP Self Hosted` | `UNCONFIRMED_OWNERSHIP` |

També pots triar un escenari amb l'adreça de la cartera del beneficiari en lloc del nom (la cartera té prioritat quan s'indiquen tots dos), i una transferència que no indica cap dels dos es completa com a `accept`. [Prova la Travel Rule en sandbox](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) enumera la cartera de cada escenari i el resultat exacte.

[L'activador de Test VASP entrant](https://docs.didit.me/ca/management-api/travel-rule/trigger-test-vasp-inbound.md) només accepta `accept` i `name_mismatch` al seu camp `scenario`.

> [!NOTE]
>
> **Com provar una regla abans de posar-la en producció.** Fes servir el
> [Backtest](https://docs.didit.me/ca/transaction-monitoring/rules-api.md#crear-fer-backtest-i-activar): reprodueix la regla sobre el teu historial real de transaccions i informa de `evaluated` / `matched` / `affected_entities` sense modificar l'estat de cap transacció. Combina'l amb el mode `TEST` a l'aplicació en producció: una regla `TEST` s'avalua en cada nova transacció real i registra amb què hauria coincidit, sense canviar la puntuació ni l'estat, i després passa a `ACTIVE` quan la selectivitat sigui l'adequada.

## Com canviar entre producció i sandbox

La producció i el sandbox són **aplicacions separades**, de manera que el trànsit de prova i les dades de producció mai es barregen. Cada aplicació té un `mode` de `live` o `sandbox`:

* Fes servir la clau d'API d'una aplicació en **mode sandbox** per obtenir sessions simulades, sense facturació i simulables.
* Fes servir la clau d'API d'una aplicació en **mode de producció** per a verificacions reals.

El camp `sandbox_scenario` (a la creació de sessió i a l'API AML independent) i els endpoints de simulació només s'accepten en aplicacions sandbox; en aplicacions de producció es rebutgen.

## Sandbox al flux de verificació allotjat

Les sessions creades en una aplicació sandbox mostren elements d'interfície addicionals al flux de verificació allotjat (la `url` que retorna `POST /v3/session/`):

* **Bàner de sandbox dins la targeta.** Cada pantalla mostra un bàner dins la targeta amb el text "Només dades de prova - sense crides reals", perquè quedi sempre clar que la sessió mai crida proveïdors reals i mai no toca el teu saldo. Els suports capturats s'emmagatzemen com en qualsevol sessió, de manera que has d'utilitzar els documents de mostra i les dades de prova en lloc de documents d'identitat reals o informació personal.
* **Selector d'escenaris previ al flux.** Abans que comenci la captura, un selector dins la targeta guia l'usuari per triar un resultat de prova: tria un resultat i després un activador per a aquest resultat. En confirmar, es crida `POST /v3/session/{session_id}/sandbox/arm/` (vegeu [Armar (o tornar a armar) la sessió abans que comenci el flux](#3-armar-o-tornar-a-armar-la-sessió-abans-que-comenci-el-flux) més avall), i després es continua el flux amb els valors màgics de l'escenari ja aplicats.
* **Franja de documents de mostra.** Una sola fila de documents de mostra del sandbox (fins a 3) es troba just sota del component de pujada o captura de documents. Toca'n un per utilitzar-lo en lloc d'una pujada real.

Les sessions sandbox emmagatzemen els suports **reals** capturats: documents, selfie, vídeo de prova de vida i fitxers de comprovant de domicili es pugen i es conserven exactament com ho farien en una sessió de producció. Les dades *extretes* (camps de verificació d'identitat, puntuacions de coincidència facial, resultats de prova de vida i similars) i el resultat de la sessió (Aprovada / En revisió / Rebutjada) són simulats per l'escenari o pel valor màgic, i mai no es deriven dels suports capturats. La Business Console marca les seccions de dades extretes d'una sessió sandbox amb un distintiu **Dades simulades**, perquè els revisors puguin veure d'un cop d'ull quines parts de la sessió corresponen a la captura real i quines es basen en l'escenari.

## Escenaris

Cada escenari és un conjunt de valors màgics amb nom. Passa'n el slug com a `sandbox_scenario` en crear la sessió (o a l'endpoint de simulació) per reproduir el resultat.

| Slug | Títol | Estat per defecte | Descripció |
| - | - | - | - |
| `approve` | Camí feliç: totes les funcionalitats aproven | Aprovada | Comportament per defecte del sandbox: cada funcionalitat simulada retorna el seu resultat APPROVED net. L'estat de la sessió acaba com a APPROVED. |
| `decline_aml_hit` | AML: persona políticament exposada | Rebutjada | El simulador d'AML retorna una coincidència i la sessió es rebutja en la funcionalitat AML. La coincidència utilitza el mateix [esquema de coincidència](https://docs.didit.me/ca/core-technology/aml-screening/report-aml-screening.md#camps-per-hit) que els proveïdors d'AML en producció: `url`, `match_score`, `risk_score`, `review_status`, `properties`, `pep_matches[]` i `score_breakdown` s'omplen tots, i s'escriu un Log d'advertència POSSIBLE\_MATCH\_FOUND. |
| `decline_document_expired` | Verificació d'identitat: document caducat | Rebutjada | El simulador de verificació d'identitat retorna un passaport la data de caducitat del qual ja ha passat. La sessió es rebutja en la verificació d'identitat amb un Log d'advertència DOCUMENT\_EXPIRED. |
| `decline_minimum_age` | Verificació d'identitat: per sota de l'edat mínima establerta per la política | Rebutjada | El simulador de verificació d'identitat retorna una data de naixement que fa que l'usuari tingui aproximadament 10 anys. La comprovació d'edat en producció emet MINIMUM\_AGE\_NOT\_MET i el flux de treball rebutja la sessió. |
| `decline_mrz_validation` | Verificació d'identitat: error de suma de control de la MRZ | Rebutjada | El simulador de verificació d'identitat retorna un passaport amb una suma de control de la MRZ corrupta. El validador de MRZ en producció emet MRZ\_VALIDATION\_FAILED i la sessió es rebutja. |
| `decline_could_not_recognize_document` | Verificació d'identitat: document il·legible | Rebutjada | El simulador de verificació d'identitat retorna una resposta buida. En producció es genera COULD\_NOT\_RECOGNIZE\_DOCUMENT i es mostra al SDK. |
| `decline_face_match_low_similarity` | Coincidència facial: similitud per sota del llindar de rebuig | Rebutjada | El simulador de coincidència facial retorna una puntuació baixa. En producció s'emet LOW\_FACE\_MATCH\_SIMILARITY i el mapatge d'accions del node del flux de treball rebutja la sessió. |
| `decline_database_no_match` | Validació en bases de dades: cap coincidència en tots els serveis | Rebutjada | Cada servei de bases de dades seleccionat retorna NO\_MATCH. En producció s'emet DATABASE\_VALIDATION\_NO\_MATCH i el flux de treball rebutja la sessió. |
| `decline_phone_high_risk` | Telèfon: número de prova d'alt risc reservat | Rebutjada | El simulador de verificació de telèfon bloqueja la verificació (rang de prova reservat). La verificació de telèfon acaba com a BLOCKED i s'emet HIGH\_RISK\_PHONE\_NUMBER. |
| `decline_email_breach` | Correu electrònic: coincidència en una base de dades de filtracions | Rebutjada | El simulador de filtracions de correu electrònic retorna una coincidència de filtració per a l'adreça. La verificació de correu electrònic emet BREACHED\_EMAIL\_DETECTED. |
| `decline_ip_blocklist` | Anàlisi d'IP: adreça a la llista de bloqueig | Rebutjada | El simulador d'anàlisi d'IP rebutja la ubicació amb IP\_ADDRESS\_IN\_BLOCKLIST. La sessió es rebutja en l'anàlisi d'IP. |
| `decline_poa_address_mismatch` | POA: l'adreça no coincideix amb la proporcionada | Rebutjada | El simulador de POA rebutja el comprovant de domicili amb ADDRESS\_MISMATCH\_WITH\_PROVIDED. La sessió es rebutja en la POA. |
| `decline_liveness_attack` | Prova de vida: atac facial detectat | Rebutjada | El simulador de prova de vida passiva detecta un senyal d'atac facial i emet LIVENESS\_FACE\_ATTACK. La sessió es rebutja en la prova de vida. |
| `decline_nfc_chip_not_verified` | NFC: xip de l'ePassport no verificat | Rebutjada | El simulador de l'ePassport retorna un xip la signatura SOD/DG del qual falla la integritat. En producció s'emet NFC\_CHIP\_NOT\_VERIFIED i la sessió es rebutja en NFC quan el flux de treball rebutja els xips no verificats. |
| `decline_nfc_trust_anchor_missing` | NFC: ancoratge de confiança de l'emissor no disponible | Rebutjada | El simulador de l'ePassport retorna un xip signat per un DSC la CSCA emissora de la qual és absent del magatzem de confiança. En producció s'emet NFC\_TRUST\_ANCHOR\_MISSING i la sessió es rebutja quan el flux de treball rebutja els xips no verificats. |
| `decline_document_ai_unreadable` | Document AI: document il·legible | Rebutjada | El simulador de Document AI no retorna cap camp llegible. En producció s'emet DOCUMENT\_AI\_UNREADABLE\_DOCUMENT i el document queda rebutjat quan s'esgota el pressupost de reintents. |
| `review_aml_possible_match` | AML: possible coincidència que cal revisar | En revisió | El simulador d'AML retorna una coincidència de menor confiança. La sessió queda en revisió amb un Log d'advertència POSSIBLE\_MATCH\_FOUND perquè un analista la resolgui. |
| `review_face_match_borderline` | Coincidència facial: similitud limítrofa | En revisió | El simulador de coincidència facial retorna una puntuació entre els llindars de revisió i de rebuig. La sessió passa a l'estat «En revisió» en la coincidència facial. |
| `review_document_borderline_age` | Verificació d'identitat: menor d'edat enviat a revisió | En revisió | El simulador de verificació d'identitat retorna una data de naixement per sota de l'edat mínima configurada al flux de treball. El minimum\_age\_action del flux de treball està definit com a REVIEW en lloc de DECLINE, de manera que la sessió queda en revisió en la verificació d'identitat en lloc de rebutjar-se. |
| `review_poa_partial_match` | POA: coincidència parcial de l'adreça | En revisió | El simulador de POA retorna una adreça que només coincideix parcialment amb la proporcionada. La sessió queda en revisió al comprovant de domicili. |
| `review_database_partial_match` | Validació en bases de dades: coincidència parcial | En revisió | Els serveis de bases de dades retornen coincidències parcials en el nom i la data de naixement. La sessió queda en revisió a la validació en bases de dades. |
| `decline_kyb_registry_mismatch` | KYB: les dades del registre no coincideixen | Rebutjada | El simulador del registre retorna una empresa les dades de registre de la qual no coincideixen amb les dades esperades. La sessió empresarial es rebutja en el control del registre. |
| `review_kyb_registry_partial` | KYB: les dades del registre coincideixen parcialment | En revisió | El simulador del registre retorna una empresa el nom de la qual només coincideix parcialment. La sessió empresarial queda en revisió al control del registre. |

Els escenaris `review_*` existeixen perquè puguis provar l'experiència de revisió manual (la cua de revisió de la consola, els webhooks de `In Review` i les accions d'aprovació i rebuig del revisor) sense necessitat d'una entrada que provoqui un rebuig clar. Els dos escenaris `kyb_*` de dalt estableixen `expected_details.registration_number` en lloc de `expected_details.first_name`: només s'apliquen a les sessions de verificació d'empreses (KYB).

## Valors màgics

Un valor màgic és una entrada concreta que fa que una funcionalitat simulada emeti un risc concret. Estableix el camp d'entrada amb el valor màgic (directament o mitjançant un escenari) per activar-lo.

| Funcionalitat | Camp d'entrada | Valor màgic | Risc | Descripció |
| - | - | - | - | - |
| AML | `user_email` | `sandbox+aml_hit@didit.test` | `POSSIBLE_MATCH_FOUND` | AML: persona políticament exposada; la simulació d'AML retorna una coincidència i la sessió es rebutja en AML. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_EXPIRED` | `DOCUMENT_EXPIRED` | OCR: document caducat; la sessió es rebutja en la verificació d'identitat. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MINIMUM_AGE_NOT_MET` | `MINIMUM_AGE_NOT_MET` | OCR: la data de naixement fa que l'usuari sigui menor de l'edat mínima configurada; la sessió es rebutja. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MAXIMUM_AGE_EXCEEDED` | `MAXIMUM_AGE_EXCEEDED` | OCR: la data de naixement extreta supera la política d'edat màxima configurada. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NUMBER_FORMAT_MISMATCH` | `DOCUMENT_NUMBER_FORMAT_MISMATCH` | OCR: el número de document extret no coincideix amb l'expressió regular de format esperada del document, segons el registre de documents. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_PERSONAL_NUMBER_FORMAT_MISMATCH` | `PERSONAL_NUMBER_FORMAT_MISMATCH` | OCR: el número personal extret no supera la comprovació de format del registre de documents. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION` | `DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION` | OCR: el tipus de document extret queda fora de la política `documents_allowed` de l'aplicació. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED` | `FULL_NAME_MISMATCH_WITH_PROVIDED` | OCR: el nom del document no coincideix amb el nom que el client ha introduït prèviament a `expected_details` per sobre del llindar de coincidència del nom. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_GENDER_MISMATCH_WITH_PROVIDED` | `GENDER_MISMATCH_WITH_PROVIDED` | OCR: el gènere extret no coincideix amb `expected_details.gender`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED` | `DOB_MISMATCH_WITH_PROVIDED` | OCR: la data de naixement extreta no coincideix amb `expected_details.date_of_birth`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COUNTRY_MISMATCH_WITH_PROVIDED` | `COUNTRY_MISMATCH_WITH_PROVIDED` | OCR: l'estat emissor no coincideix amb `expected_details.country` (o `id_country`). |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_NATIONALITY_MISMATCH_WITH_PROVIDED` | `NATIONALITY_MISMATCH_WITH_PROVIDED` | OCR: la nacionalitat extreta no coincideix amb `expected_details.nationality`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED` | `IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED` | OCR: el número de document, personal o fiscal extret no coincideix amb `expected_details.identification_number`. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_RECOGNIZE_DOCUMENT` | `COULD_NOT_RECOGNIZE_DOCUMENT` | El flux d'OCR retorna un resultat buit o no reconeixible; en producció es genera COULD\_NOT\_RECOGNIZE\_DOCUMENT. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_NOT_DETECTED` | `MRZ_NOT_DETECTED` | OCR: el document espera una MRZ però el flux no ha pogut localitzar-la. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_MRZ_VALIDATION_FAILED` | `MRZ_VALIDATION_FAILED` | OCR: s'ha trobat la MRZ però no ha superat la validació de suma de verificació o de format. |
| 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: els camps d'identitat de la MRZ no coincideixen amb els camps extrets de la zona visual (VIZ). |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_NOT_DETECTED` | `BARCODE_NOT_DETECTED` | OCR: el document espera un codi de barres però no n'ha trobat cap. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BARCODE_VALIDATION_FAILED` | `BARCODE_VALIDATION_FAILED` | OCR: el codi de barres s'ha descodificat però no ha superat la validació entre camps. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_NOT_DETECTED` | `QR_NOT_DETECTED` | OCR: el document espera un codi QR però no n'ha trobat cap. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_QR_VALIDATION_FAILED` | `QR_VALIDATION_FAILED` | OCR: el codi QR s'ha descodificat però no ha superat la validació entre camps. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATA_INCONSISTENT` | `DATA_INCONSISTENT` | OCR: les comprovacions de coherència interna detecten incoherències entre els camps VIZ. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_SIDES_MISMATCH` | `DOCUMENT_SIDES_MISMATCH` | OCR: els document\_name de l'anvers i del revers no corresponen al mateix document. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_NAME_NOT_DETECTED` | `NAME_NOT_DETECTED` | OCR: no s'ha pogut extreure ni el nom ni el cognom del document. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DATE_OF_BIRTH_NOT_DETECTED` | `DATE_OF_BIRTH_NOT_DETECTED` | OCR: la classe de document espera una data de naixement però l'extracció no n'ha retornat cap. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_EXPIRATION_DATE_NOT_DETECTED` | `EXPIRATION_DATE_NOT_DETECTED` | OCR: la classe de document espera una data de caducitat però l'extracció no n'ha retornat cap. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_DOCUMENT_NUMBER_NOT_DETECTED` | `DOCUMENT_NUMBER_NOT_DETECTED` | OCR: no s'ha pogut extreure ni el número de document ni el número personal. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_COULD_NOT_DETECT_DOCUMENT_TYPE` | `COULD_NOT_DETECT_DOCUMENT_TYPE` | OCR: el classificador no ha pogut associar la captura a un tipus de document compatible. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_PORTRAIT_IMAGE_NOT_DETECTED` | `PORTRAIT_IMAGE_NOT_DETECTED` | OCR: el flux de processament no ha pogut aïllar una regió de retrat al document. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_UNPARSED_ADDRESS` | `UNPARSED_ADDRESS` | OCR: el document té un camp d'adreça però la geocodificació o el parseig no ha retornat cap resultat utilitzable. |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_NO_MATCH` | `DATABASE_VALIDATION_NO_MATCH` | Validació en bases de dades: tots els serveis governamentals o de registres retornen NO\_MATCH; la sessió es rebutja per la validació en bases de dades. |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_LOW_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | Coincidència facial: la puntuació de similitud és inferior al llindar de rebuig; la sessió es rebutja per la coincidència facial. |
| PHONE | `phone_number` | `+15005550009` | `HIGH_RISK_PHONE_NUMBER` | Telèfon: número de prova reservat, no lliurable o d'alt risc; la simulació de verificació de telèfon retorna un error. |
| EMAIL | `user_email` | `sandbox+breach@didit.test` | `BREACHED_EMAIL_DETECTED` | Correu electrònic: la base de dades de filtracions retorna una coincidència per a aquesta adreça. |
| LOCATION | `expected_details.first_name` | `SANDBOX_IP_BLOCKLIST` | `IP_ADDRESS_IN_BLOCKLIST` | Anàlisi d'IP: la IP del client apareix a la llista de bloqueig de l'aplicació; la sessió es rebutja per l'anàlisi d'IP. |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_ADDRESS_MISMATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | Comprovant de domicili: l'adreça del document pujat no coincideix amb l'adreça que el client ha omplert prèviament a `expected_details`; la sessió es rebutja pel comprovant de domicili. |
| LIVENESS | `expected_details.first_name` | `SANDBOX_LIVENESS_ATTACK` | `LIVENESS_FACE_ATTACK` | Prova de vida: la simulació de prova de vida passiva detecta un senyal d'atac facial; la sessió es rebutja per la prova de vida. |
| NFC | `expected_details.first_name` | `SANDBOX_NFC_CHIP_NOT_VERIFIED` | `NFC_CHIP_NOT_VERIFIED` | NFC: la simulació del passaport electrònic retorna un xip amb una signatura SOD/DG que no supera la verificació d'integritat; en producció s'emet NFC\_CHIP\_NOT\_VERIFIED i la sessió es rebutja quan el flux de treball rebutja els xips no verificats. |
| NFC | `expected_details.first_name` | `SANDBOX_NFC_TRUST_ANCHOR_MISSING` | `NFC_TRUST_ANCHOR_MISSING` | NFC: el DSC encadena a una CSCA que no és al magatzem de confiança; en producció s'emet NFC\_TRUST\_ANCHOR\_MISSING i s'aplica l'acció configurada per als xips no verificats. |
| DOCUMENT\_AI | `expected_details.first_name` | `SANDBOX_DOCUMENT_AI_UNREADABLE` | `DOCUMENT_AI_UNREADABLE_DOCUMENT` | Document AI: l'extracció no retorna cap camp llegible; en producció s'emet DOCUMENT\_AI\_UNREADABLE\_DOCUMENT i el document queda rebutjat quan s'esgota el límit de reintents. |
| AML | `user_email` | `sandbox+aml_review@didit.test` | `POSSIBLE_MATCH_FOUND` | AML: possible coincidència que necessita una resolució manual; la sessió passa a En revisió. |
| FACEMATCH | `expected_details.first_name` | `SANDBOX_FACE_BORDERLINE_MATCH` | `LOW_FACE_MATCH_SIMILARITY` | Coincidència facial: similitud al límit entre els llindars de revisió i de rebuig; la sessió passa a En revisió. |
| ID\_VERIFICATION | `expected_details.first_name` | `SANDBOX_OCR_BORDERLINE_AGE` | `MINIMUM_AGE_NOT_MET` | OCR: la data de naixement és inferior a l'edat mínima, però el flux de treball revisa en lloc de rebutjar les fallades relatives a l'edat mínima; la sessió passa a En revisió. |
| DATABASE\_VALIDATION | `expected_details.first_name` | `SANDBOX_DB_PARTIAL_MATCH` | `DATABASE_VALIDATION_PARTIAL_MATCH` | Validació en bases de dades: la identificació coincideix, però el nom i la data de naixement només coincideixen parcialment; la sessió passa a En revisió. |
| PROOF\_OF\_ADDRESS | `expected_details.first_name` | `SANDBOX_POA_PARTIAL_MATCH` | `ADDRESS_MISMATCH_WITH_PROVIDED` | Comprovant de domicili: l'adreça del document pujat coincideix parcialment amb l'adreça proporcionada; la sessió passa a En revisió. |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-MISMATCH` | `KYB_REGISTRY_DATA_MISMATCH_WITH_EXPECTED` | KYB: les dades de l'empresa al registre no coincideixen amb les dades esperades; la sessió es rebutja. |
| KYB\_REGISTRY | `expected_details.registration_number` | `SANDBOX-KYB-REVIEW` | `KYB_REGISTRY_DATA_PARTIAL_MATCH_WITH_EXPECTED` | KYB: les dades de l'empresa al registre coincideixen parcialment; la sessió passa a En revisió. |

## Consulta sense document i carteres d'identitat

Les aplicacions de sandbox poden activar totes les carteres d'identitat del catàleg del país, incloses les que no estan disponibles a les aplicacions en producció.
L'escenari predeterminat `approve` simula una identitat verificada sense iniciar sessió a cap cartera externa.
El resultat es desa a la sessió i segueix el pas següent habitual del flux de treball.
El sandbox no valida una credencial de cartera real ni cobra pels intents simulats.

Les sol·licituds de consulta continuen validant els camps introduïts i apliquen el límit d'intents configurat, que per defecte és d'un intent.
Utilitza els escenaris següents per provar els reintents i les regles d'alternativa:

| Escenari | Resultat simulat |
| - | - |
| `lookup_partial_match` | Coincidència parcial al registre; compta per al límit d'intents. |
| `lookup_no_match` | El registre respon sense coincidència; compta per al límit d'intents. |
| `lookup_provider_error` | El registre no respon; es demana a l'usuari que ho torni a provar i, després de tres intents sense resposta, s'aplica l'alternativa d'error del proveïdor. |
| `wallet_cancelled` | L'usuari cancel·la l'inici de sessió a la cartera. |
| `wallet_timeout` | L'inici de sessió a la cartera caduca. |
| `wallet_provider_error` | La cartera no pot completar l'inici de sessió. |

Els errors de la cartera segueixen l'opció configurada al país: passar a la captura del document o rebutjar.
Els intents de consulta completats es registren per separat, de manera que dos intents permesos produeixen dos resultats abans de l'alternativa.
Tot l'ús del sandbox continua sent gratuït.

## Comprovació del compte de verificació bancària

Un pas de verificació bancària en sandbox ofereix [tots dos mètodes](https://docs.didit.me/ca/core-technology/bank-verification/verification-methods.md) a tots els països, en l'ordre que defineix el pas, amb un servei simulat sense cap banc real i sense cost.
Amb l'ordre predeterminat, la persona comença a la pantalla d'inici de sessió bancari i tria **Introdueix les dades del teu compte** per fer la [comprovació del compte](https://docs.didit.me/ca/core-technology/bank-verification/account-check.md); estableix `bank_method_order` a `["account_lookup", "open_banking"]` per començar per aquesta opció.
Els quatre últims caràcters del compte introduït determinen la resposta; consulta [Prova-ho al sandbox](https://docs.didit.me/ca/core-technology/bank-verification/account-check.md#prova-ho-en-sandbox) per veure totes les terminacions i un compte vàlid per format.
L'[API de comprovació de compte](https://docs.didit.me/ca/standalone-apis/bank-account-check.md) respon amb una clau de sandbox segons les mateixes terminacions.

## Els documents de mostra

> [!WARNING]
>
> No pugis mai documents d'identitat reals al sandbox. Usa els documents de mostra integrats.

El flux allotjat ofereix tres documents de mostra, un per tipus de document:

| País | Tipus de document |
| - | - |
| Espanya | Document nacional d'identitat |
| Argentina | Passaport |
| Polònia | Permís de conduir |

Toca una mostra de la franja per usar-la en lloc d'una captura real. Les dades extretes i el resultat de la sessió sempre provenen de l'escenari o del valor màgic seleccionat, de manera que qualsevol mostra funciona amb qualsevol escenari.

## Identitat de mostra: prova de `expected_details`

Cada document del sandbox és fabricat a partir d'una **identitat fixa**.
Els valors extrets són els mateixos en cada sessió i mai no es deriven de la data actual, de manera que pots omplir `expected_details` amb ells i comprovar de principi a fi la comparació de camps i la gestió d'advertències.
Si passes els valors següents, les comprovacions de comparació es compleixen; si passes qualsevol altre valor, s'activa a propòsit l'advertència `*_MISMATCH_WITH_PROVIDED` corresponent.

Totes les mostres de document comparteixen les dates:

| Camp | Valor |
| - | - |
| `date_of_birth` | `1990-06-15` |
| Data d'emissió | `2025-06-15` |
| Data de caducitat | `2035-06-15` |

La resta de la identitat depèn del document que usis:

| `sandbox_sample` | Document | `first_name` | `last_name` | `gender` | `nationality` | `id_country` | `identification_number` |
| - | - | - | - | - | - | - | - |
| *(per defecte, sense mostra seleccionada)* | ePassport del Brasil | `GUSTAVO` | `MATSUMOTO` | `M` | `BRA` | `BRA` | `YC531181` |
| `spain-id-card-2021` | Document nacional d'identitat d'Espanya | `CARMEN` | `ESPAÑOLA ESPAÑOLA` | `F` | `ESP` | `ESP` | `CAA000000` |
| `argentina-passport-2009` | Passaport d'Argentina | `MARIA VICTORIA` | `VILLAREAL` | `F` | `ARG` | `ARG` | `AAF794880` |
| `poland-driving-license-2019` | Permís de conduir de Polònia | `JAN` | `KOWALSKI` | no apareix en aquest document | `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` i `last_name` són l'excepció: el sandbox copia al document fabricat els noms que envies a `expected_details`, de manera que la comparació de noms té èxit amb qualsevol nom.
Usa el valor màgic `SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED` per provar una discrepància de nom, i `SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED` per a una discrepància de data de naixement.

> [!NOTE]
>
> Si el teu flux de treball restringeix `documents_allowed` a un país o tipus de document que exclou l'ePassport del Brasil, el sandbox fabrica un document a partir del primer país permès. Així, `nationality`, `id_country` i el nom del document corresponen a aquest país. Les dates anteriors no canvien.

### Què no inclou el document fabricat

El document fabricat és la plantilla genèrica del país i del tipus de document permesos, de manera que els camps que només proporciona un document real emès per un estat queden buits. El camp que importa per a l'encaminament és la **regió / estat dels EUA** (`kyc.region`): un permís de conduir o un document d'identitat dels EUA del sandbox no té estat. Per això, una condició de branca com `Region equals IL` mai no coincidirà al sandbox i, si cap altra branca del node tampoc no coincideix, el flux segueix la branca de reserva del node (la branca sense condicions). Això no és una revisió ni un error de la branca: la condició simplement no té res per llegir. Un camp absent també fa fallar `not equals` i `not in`; consulta [com les condicions de branca llegeixen les dades de la sessió](https://docs.didit.me/ca/console/workflows.md#com-llegeixen-les-condicions-de-branca-les-dades-de-la-sessió) per veure la diferència entre un camp absent i una cadena buida.

Per provar un flux que depèn de l'estat al sandbox, decideix a partir d'un valor que controlis a la sessió i no del document:

* Envia l'estat a `metadata` quan crees la sessió (per exemple, `"metadata": {"credential_state": "IL"}`) i fes la branca sobre `metadata.credential_state`. Al sandbox, les metadades s'avaluen exactament igual que en producció.
* Mantén la condició `kyc.region`, derivada del document, per al trànsit en producció si també necessites que el document acrediti l'estat; en mode producció la regió es llegeix del document real.

La resta de l'encaminament és idèntica a producció: el graf del flux de treball, les condicions de branca, els valors de `metadata` i `expected_details`, els nodes d'acció i els nodes d'estat s'executen de veritat. El sandbox mai no força una sessió a revisió per si sol: una sessió del sandbox acaba En revisió només quan el flux de treball l'encamina allà (un escenari `review_*`, un valor màgic assignat a una acció de revisió o un node d'estat al graf).

## Codis OTP i opció d'activar l'enviament de correus electrònics

* **OTP de telèfon:** la comprovació de telèfon del sandbox accepta qualsevol codi ben format (de 4 a 8 dígits; `123456` inclòs). Les entrades mal formades continuen retornant `400`.
* **OTP de correu electrònic:** la comprovació de correu del sandbox accepta qualsevol codi ben format (`123456` inclòs). Les entrades mal formades continuen retornant `400`.

Per defecte, les sessions del sandbox **no** envien correus electrònics (alertes de revisió, canvis d'estat, OTP, reenviaments, enllaços de nova sessió, etc.). Per enviar un correu igualment, usa un d'aquests patrons per activar l'enviament a l'adreça del destinatari:

| Patró d'adhesió | Exemple |
| - | - |
| `<local>+sandbox@<domain>` | `alice+sandbox@example.com` |
| `*@didit.test` | `alice@didit.test` |

## Dirigir els resultats: escenaris, valors màgics, armat i l'endpoint de simulació

Hi ha cinc maneres de controlar el resultat d'una sessió sandbox.

### 1. `sandbox_scenario` en crear la sessió

Defineix el slug de l'escenari en crear la sessió (`POST /v3/session/`). El flux de creació expandeix els valors màgics inclosos a l'escenari als camps d'entrada de la sessió, de manera que els proveïdors simulats emetin el resultat previst a través de la canalització real del flux de treball.

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

### 2. Valors màgics introduïts manualment

Defineix tu mateix els camps d'entrada individuals (per exemple `expected_details.first_name = "SANDBOX_OCR_DOCUMENT_EXPIRED"`, o `user_email = "sandbox+aml_hit@didit.test"`). Consulta el registre complet a la taula de valors màgics de més amunt.

### 3. Armar (o tornar a armar) la sessió abans que comenci el flux

Defineix o substitueix l'escenari armat en una sessió que ja existeix, sempre que no hagi avançat més enllà de `Not Started`. Aquest és l'endpoint que crida el [selector d'escenaris abans del flux](#sandbox-al-flux-de-verificació-allotjat), i tu el pots cridar directament per construir un selector personalitzat o un entorn de prova:

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

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

Resposta 200:

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

* Autentica't amb el `Session-Token` propi de la sessió (que es retorna com a `session_token` en crear la sessió), no amb la clau d'API de la teva aplicació: és un endpoint de cara al client.
* Retorna `400` per a un slug d'escenari desconegut, i també `400` una vegada la sessió ha superat `Not Started` (`"Scenario can only be armed before the verification starts."`).
* Retorna `404` quan el `Session-Token` pertany a una aplicació en producció (no sandbox), o quan no coincideix amb el `session_id` de la ruta.
* **Tornar a armar substitueix l'escenari anterior.** Només esborra els valors màgics que va escriure l'escenari anterior, i deixa intacte tot el que l'usuari ja hagi introduït manualment (correu electrònic, nom, etc.). Per exemple: si armes `decline_phone_high_risk` i després armes `approve`, el número de telèfon torna a no estar definit, però un correu electrònic introduït pel client es conserva en totes dues crides.

### 4. L'endpoint de simulació

Força un estat final a posteriori:

* Consola / clau d'API (requereix el privilegi `write:sessions`; una clau d'API amb àmbit necessita accés d'escriptura a les sessions): `POST /v3/session/{session_id}/simulate/`
* Flux allotjat (capçalera `Session-Token`): `POST /v3/session/{session_id}/sandbox/simulate/`

Tots dos funcionen amb sessions sandbox de KYC i de KYB.
Una sessió en producció (no sandbox) retorna `404`, i també ho fa un `Session-Token` que no coincideixi amb el `session_id` de la ruta.

Cada camp del cos és opcional, però cal almenys un de `new_status`, `scenario` o `risk`:

| Camp | Tipus | Què fa |
| - | - | - |
| `new_status` | string | `Approved`, `Declined`, `In Review`, `Expired` o `Abandoned`. Si l'omets, pren per defecte l'estat per defecte del cas de risc (`risk`, o el primer risc que porten els valors màgics de l'escenari) i, si no n'hi ha, l'estat per defecte de l'escenari. |
| `scenario` | string, fins a 100 caràcters | Un slug d'escenari. Sense `risk`, s'aplica el primer risc que porten els seus valors màgics. |
| `risk` | string, fins a 128 caràcters | Un cas de risc, l'advertència del qual s'afegeix a la sessió. |
| `node_id` | string, fins a 128 caràcters | El node del flux de treball al qual s'adjunta l'advertència. Per defecte, el node actual de la sessió. |
| `comment` | string, fins a 500 caràcters | Nota afegida a l'entrada d'activitat que registra el canvi d'estat. |
| `send_webhooks` | boolean, per defecte `true` | Si el canvi d'estat envia webhooks. |

`send_webhooks: true` envia exactament els webhooks que envia un canvi d'estat real: `status.updated`, i també els esdeveniments `user.status.updated` i `user.data.updated` (o `business.status.updated` i `business.data.updated` en una sessió d'empresa) que el canvi provoca, cap als destins subscrits a aquests esdeveniments.
Amb `send_webhooks: false` l'estat sí que canvia, però no es registra ni s'envia cap webhook.
La recuperació de webhooks perduts mai torna a enviar aquesta decisió, i la consola es continua actualitzant en directe.
El següent canvi d'estat de la sessió envia webhooks com de costum.

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

Resposta 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` és l'estat que ha establert la simulació, i `previous_status` és el que tenia la sessió abans.
* `scenario` repeteix el teu slug i `risk` és el cas de risc aplicat; cadascun és `null` quan no n'hi ha cap.
* `send_webhooks` repeteix el valor aplicat.
* Retorna `400` per a un escenari o un risc desconeguts, quan no es pot derivar cap `new_status`, per a qualsevol altre `new_status`, i quan la sessió ja té l'estat sol·licitat (`["The new status is the same as the current status."]`).

### 5. `sandbox_scenario` a l'API AML independent

El cribratge AML de back-end no té usuari final ni sessió a armar, de manera que el slug va a la mateixa sol·licitud de cribratge (`POST /v3/aml/`):

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

* `decline_aml_hit` retorna una coincidència amb el format de producció i resol el cribratge com a `Declined`; `review_aml_possible_match` el resol com a `In Review`. Un escenari que no arma cap resultat AML deixa el cribratge net.
* Amb `save_api_request: true` (el valor per defecte) el cribratge es persisteix exactament igual que amb una clau de producció, de manera que el `request_id` retornat es pot consultar mitjançant `GET /v3/session/{request_id}/decision/` i `GET /v3/session/{request_id}/generate-pdf/`.
* Retorna `400` per a un slug d'escenari desconegut, i `400` quan la clau d'API pertany a una aplicació en producció.

## On apareix `sandbox_scenario`

El slug de l'escenari armat (`null` si no n'hi ha cap) es retorna en alguns punts i s'omet intencionadament en d'altres:

| Superfície | Exposat? |
| - | - |
| Payload del pas actual (KYC i KYB) | Sí, com a `sandbox_scenario` |
| `GET /v1/session/{id}/decision/` | Sí, com a `sandbox_scenario` |
| `GET /v3/session/{id}/decision/` (consulta [Retrieve Session](https://docs.didit.me/ca/sessions-api/retrieve-session.md)) | Sí, `sandbox_scenario` al nivell superior (null si no està armat) |
| Webhooks de sessió (`status.updated`, `data.updated`) | Sí, com a `sandbox_scenario`; `null` en sessions de producció o en sessions sandbox no armades |

Si la teva integració necessita bifurcar segons l'escenari armat al servidor, llegeix-lo de l'embolcall del webhook o de qualsevol dels dos endpoints de decisió (`v1` o `v3`).

## Ús i facturació

L'ús de sandbox es registra, però mai es cobra:

* Cada crida simulada registra igualment un esdeveniment d'ús (`is_sandbox: true`, amb un preu de `0.0000`), perquè el volum del sandbox sigui visible per a la depuració. Tot i això, mai se suma als teus totals d'ús, mai es descompta del saldo i mai apareix en una factura.
* Les superfícies de saldo, de recàrrega i d'ús en producció de la Business Console filtren l'ús del sandbox per defecte. Els endpoints d'ús de recàrregues accepten el paràmetre `environment` (`live`, el valor per defecte, o `sandbox`), perquè el volum del sandbox es pugui consultar per separat. Això sempre es fa sense cost i sense consumir el pla gratuït.
* La verificació de correu electrònic i de telèfon es factura per sol·licitud, no pel resultat de la sessió, i el sandbox no pot reproduir això del tot a la capa de webhook. Les comprovacions de correu electrònic i de telèfon del sandbox registren igualment un esdeveniment d'ús per sol·licitud, a preu `0.0000`, igual que qualsevol altra funcionalitat simulada. Aquesta és una divergència acceptada i coneguda respecte del comportament de facturació en producció, i no és un error.
* L'estructura de la resposta de la validació de bases de dades en sandbox divergeix intencionadament de la de cada proveïdor en producció, ja que no hi ha cap proveïdor real que reproduir. Considera els payloads de validació de bases de dades del sandbox com un substitut del resultat (estat i codi d'advertència), no com una previsualització byte a byte de la resposta d'un proveïdor en producció.


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