Dades de prova del sandbox: escenaris, valors i documents

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.

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; 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”.

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, 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 passa a UNCONFIRMED_OWNERSHIP sense cap enviament, i la pots completar en sandbox amb el widget de verificació de titularitat de la cartera, o amb confirmar la titularitat 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 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 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 enumera la cartera de cada escenari i el resultat exacte. L’activador de Test VASP entrant només accepta accept i name_mismatch al seu camp scenario.

Com provar una regla abans de posar-la en producció. Fes servir el Backtest: 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 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 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 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; 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 per veure totes les terminacions i un compte vàlid per format. L’API de comprovació de compte respon amb una clau de sandbox segons les mateixes terminacions.

Els documents de mostra

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`

{
  "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.

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

{
  "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, 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>

{
  "scenario": "decline_document_expired"
}

Resposta 200:

{
  "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.

{
  "scenario": "decline_aml_hit",
  "send_webhooks": false
}

Resposta 200:

{
  "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/):

{
  "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)	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ó.

Guies

Autenticació

Model Context Protocol (MCP)

SDK web

SDK natius

SDK de servidor

Integracions

Dades de prova del sandbox: escenaris, valors i documents

Model d’entorn

Monitoratge de transaccions en sandbox

Escenaris del Test VASP de la Travel Rule

Com canviar entre producció i sandbox

Sandbox al flux de verificació allotjat

Escenaris

Valors màgics

Consulta sense document i carteres d’identitat

Comprovació del compte de verificació bancària

Els documents de mostra

Identitat de mostra: prova de `expected_details`

Què no inclou el document fabricat

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

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

1. `sandbox_scenario` en crear la sessió

2. Valors màgics introduïts manualment

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

4. L’endpoint de simulació

5. `sandbox_scenario` a l’API AML independent

On apareix `sandbox_scenario`

Ús i facturació

​Model d’entorn

​Monitoratge de transaccions en sandbox

​Escenaris del Test VASP de la Travel Rule

​Com canviar entre producció i sandbox

​Sandbox al flux de verificació allotjat

​Escenaris

​Valors màgics

​Consulta sense document i carteres d’identitat

​Comprovació del compte de verificació bancària

​Els documents de mostra

​Identitat de mostra: prova de expected_details

​Què no inclou el document fabricat

​Codis OTP i opció d’activar l’enviament de correus electrònics

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

​1. sandbox_scenario en crear la sessió

​2. Valors màgics introduïts manualment

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

​4. L’endpoint de simulació

​5. sandbox_scenario a l’API AML independent

​On apareix sandbox_scenario

​Ús i facturació

Model d’entorn

Monitoratge de transaccions en sandbox

Escenaris del Test VASP de la Travel Rule

Com canviar entre producció i sandbox

Sandbox al flux de verificació allotjat

Escenaris

Valors màgics

Consulta sense document i carteres d’identitat

Comprovació del compte de verificació bancària

Els documents de mostra

Identitat de mostra: prova de `expected_details`

Què no inclou el document fabricat

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

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

1. `sandbox_scenario` en crear la sessió

2. Valors màgics introduïts manualment

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

4. L’endpoint de simulació

5. `sandbox_scenario` a l’API AML independent

On apareix `sandbox_scenario`

Ús i facturació