Abans de començar
- Utilitza la clau d’API d’una aplicació sandbox. Les aplicacions en producció mai no arriben al Didit Test VASP.
- Activa la Travel Rule amb un nom legal:
- Opcionalment, subscriu una destinació del webhook a
travel_rule.status.updated. Sandbox l’envia, marcat com a"environment": "sandbox".
El Didit Test VASP
GET /v1/sandbox/scenarios/ retorna el perfil del VASP de prova i tots els escenaris de l’objecte travel_rule, de manera que les proves poden llegir els valors dels activadors en lloc de codificar-los.
Tots els valors són dades de prova. El VASP de prova no és membre de cap xarxa de la Travel Rule, i cap resultat en sandbox demostra que es pugui arribar a una contrapart o xarxa real.
Escenaris de sortida
Cada transacciótravelRule de sortida d’una aplicació sandbox que necessiti un intercanvi va al VASP de prova. Tria el resultat amb l’adreça de cartera del beneficiari (les majúscules i minúscules no importen), o amb un nom de beneficiari amb el format Didit Test VASP <suffix>; la cartera preval quan s’indiquen totes dues coses. Sense cap de les dues, o amb un sufix que la taula no llista, la transferència es completa (accept).
Una transferència que no necessita cap intercanvi mai no arriba al VASP de prova: una per sota del teu threshold_amount, una a la cartera verificada del teu usuari, i una a la cartera de la contrapart de la qual has declarat que és autoallotjada. Un VASP de contrapart que tu o el teu usuari final heu triat manualment del directori es jutja segons les rutes que tindria una aplicació en producció: quan la seva entrada en té alguna (un endpoint TRP verificat, una xarxa per on envia la teva aplicació o un contacte de compliment), la transferència va al VASP de prova; quan no en té cap, la transacció acaba amb COUNTERPARTY_VASP_NOT_FOUND, com passaria en una aplicació en producció.
rail de la transferència és TEST_VASP, i la llista de transferències indica Didit Test VASP com a VASP del beneficiari. Segueix-la als webhooks travel_rule.status.updated, o llegeix GET /v3/transactions/{transaction_id}/.
name_mismatchcompara el nom del beneficiari que has enviat amb el nom del titular que respon el VASP de prova, segons la teva regla de noms per al tipus d’entitat del beneficiari (matching_rules.individual.nameomatching_rules.company.name, que segueixenname_matching_strictnessfins que els defineixis). La transferència i l’entrada de la cronologia que la va decidir portenname_match(ambcompared_with: "counterparty_vasp") idata_matchambmismatched_fields: ["name"].not_reachablemanté la transferència enAWAITING_COUNTERPARTYmentre reintenta, ambdelivery.statusRETRYINGilast_errortest VASP is not answering, i després la passa aCOUNTERPARTY_VASP_NOT_REACHABLE. Envia{"action": "resend"}després per tornar-la a executar.self_hostedfa que el VASP de prova respongui que la cartera és autoallotjada. Registra la prova amb el widget de titularitat de la cartera (generat per a tu mentreauto_wallet_verificationestà activat) o ambPOST .../travel-rule/ownership/amb{"confirmed": true}: la cartera s’afegeix a la teva llibreta d’adreces amb el nom del beneficiari, i la coincidència de noms decideix la transferència. Una coincidència la completa i marca la cartera com a verificada;{"confirmed": false}la rebutja.
Transferències entrants del VASP de prova
Per provar el costat receptor, demana al VASP de prova que t’enviï una transferència ambPOST /v3/travel-rule/test-vasp/inbound/. Indica una de les carteres de la llibreta d’adreces de la teva pròpia aplicació: la transferència es decideix pel mateix camí d’entrada que una transferència real, amb la teva llibreta d’adreces, el teu mode de titularitat i les teves regles de nom.
La resposta
201 inclou transaction_id, txn_id, scenario, travel_rule_status, detail, test_vasp: true i la transferència travel_rule. Una aplicació de producció rep 400 ("The Didit Test VASP is only available on sandbox applications."), un altre scenario rep 400, i una aplicació amb Travel Rule desactivat rep 409.
Decideix una transferència que està pendent mitjançant
POST .../travel-rule/ownership/, com faries amb una de real: {"confirmed": true} la completa i {"confirmed": false} la rebutja.
Un dipòsit que informes tu mateix amb POST /v3/transactions/ no és un que hagi enviat el VASP de prova: es manté a AWAITING_COUNTERPARTY esperant el seu VASP d’origen, i la seva cronologia indica l’endpoint anterior. No dispara cap webhook fins que caduca després de confirmation_timeout_hours. POST /v3/travel-rule/inbound/ continua liquidant un registre posterior al dipòsit contra la teva llibreta d’adreces, igual que en una aplicació de producció.
Webhooks al sandbox
travel_rule.status.updated s’envia en les aplicacions sandbox a cada canvi d’estat, amb "environment": "sandbox". Una transferència que ha respost el VASP de prova també porta rail: "TEST_VASP", test_vasp: true i test_vasp_scenario. La resta del sandbox es comporta tal com es descriu a Monitoratge de transaccions al sandbox: les regles no s’avaluen, no s’envien transaction.created ni transaction.status.updated, i no es factura res.
Què no demostra el sandbox
- Que una contrapart real, una pertinença a una xarxa o l’amfitrió TRP públic de Didit funcionin. Cap d’ells no és contactat.
- Que les teves credencials de xarxa siguin vàlides. Una connexió a una xarxa es demostra amb el seu primer intercanvi en producció.
- Les rutes del directori de VASP reals: en una aplicació sandbox cada ruta apareix com a
unavailableambreason: sandbox_application, i cada fila ambreachable: false.