This document will suggest different scenarios that you can test once the integration of an API is completed. The tests outlined below are meant to be performed in the testing environment

API-specific tests

🚧

Be aware!

Make sure to use a customerToken for txValide or the widget

txValidate/widget Tests

Test V1 - test beneficiary VASP resolution using blockchain analytics

Call txValidate by using the following destination address that should be resolved with the correspondent VASP

Expected result: the widget or txValidate should respond something like the below:

 {
    "isValid": true,
    "type": "TRAVELRULE",
    "beneficiaryAddressType": "HOSTED",
    "addressSource": "{{yourAlockchainAnalytics}}",
    "beneficiaryVASPname": "{{beneficiaryVASP}}",
    "warnings": [
        "optional-beneficiaryAccountNumber",
        "optional-beneficiaryGeographicAddress",
        "optional-beneficiaryCountryOfResidence"
    ]
}

Test V2 - test the discovery of an addres saved in your address graph

1. First complete test T1 ;
2. Query txValidate or use the widget and make sure to provide the following: Destination address: 0x71C76B6EC7ab8defB751B7401THISISATEST8976F
3. Expected result: you should get a response containing the following line:

 {
    "isValid": true,
    "type": "TRAVELRULE",
    "beneficiaryAddressType": "HOSTED",
    "addressSource": "ADDRESS_GRAPH",
    "beneficiaryVASPname": "Notabene RoboVASP ACCEPT",
    "warnings": [
        "optional-beneficiaryAccountNumber",
        "optional-beneficiaryGeographicAddress",
        "optional-beneficiaryCountryOfResidence"
    ]
}

txCreate Tests

Test C1 - successful transfer

Test a successful travel rule transfer by rending a TR transfer to RoboVASP ACCEPT with Destination address: 0x71C76B6EC7ab8defB751B7401THISISATEST8976F

Expected result: Transaction Accepted

Test C2 - Test a declined travel rule transfer by rending a TR transfer to RoboVASP DECLINE

Expected result: Transaction Declined

Test C3 - Test Not ready response by rending a TR transfer to RoboVASP NOT READY

Expected result: Transaction in NOT READY status

Test C4 - Test the creation of a TR transfer directed to a non-custodial wallet

Expected result: Transaction in SAVED stauts

end2end withdrawal flow tests

This flow is meant to replicate the actual flow starting from the originatorVASP withdrawal screen. It comes in two flavors, with automatic identification of the beneficiaryVASP and without.

T1 - without automatic discovery of beneficiaryVASP

1. Go to the withdrawal screen of your application;
2. create a transfer from your withdrawal screen with the following data:

       "transactionAsset": "ETH",
       "transactionAmount": "10000000000000000",
       "originatorVASPdid": "{{originatorVASPdid}}",
       "beneficiaryVASPdid": "did:ethr:0x5cb7821acae54a5a94939fd35db91f4b11d8cd85",
       "transactionBlockchainInfo": {
           "txHash": "",
           "origin": "",
           "destination": "0x71C76B6EC7ab8defB751B7401THISISATEST8976F"
       },
   

1. Manually approve the created TR transfer in your VASP transaction dashboard

Expected result:

You should see the transaction in ACCEPTED status in the dashboard and should have received 4 notifications via the notification webhook

T2 - with automatic discovery based on the address book

🚧

Be aware!

To successfully perform this test make sure to have completed T1 before;

1. Go to the withdrawal screen of your application;
2. Create a transfer from your withdrawal screen with the following data:
   Asset: ETH
   Destination address: 0x71C76B6EC7ab8defB751B7401THISISATEST8976F
   Amount: 10
3. Manually approve the created TR transfer in your VASP transaction dashboard

Expected result:

You should see the transaction in ACCEPTED status in the dashboard and should have received four notifications via the notification webhook

T3 - with automatic discovery based on the blockchain analytics

1. Go to the withdrawal screen of your application;
2. Create a transfer from your withdrawal screen to one of the destination address outlined in this chart.

Expected results: you should see the transaction appearing in the dashboard directed to the VASP that is related to the destination address you used in the chart

end2end deposit tests

Deposit tests

D1 - test the deposit confirmation

1. Create a deposit transaction from your Account Setup VASP to your primaryVASP;
2. make sure the beneficiary address is an address that belong to the _primaryVASP

Expected result: the transactions should be automatically confirmed unig one of the address confirmations flows

D2 - test txNotify and add data with txUpdate

1. Simulate the receive of a blockchain transaction or manually trigger txNotify, make sure the transaction hash does not match any TR transfer you already have in your transaction log;
   1. If you use an originator address, that can be resolved by the address graph or the blockchain analytics, you should expect the originator VASP to be automatically identified;
2. Expected result: an incomplete incoming transaction should be displayed in your dashboard;
3. Collect the missing data using the post transaction widget or other means, and use txUpdate to provide the missing information to the TR transfer.
4. Expected result: the transaction should be in SENT or any subsequent status.

How to test different travel rule statuses

1. NEW -- A successful call to txCreate will create a new travel rule message with this status.
   1. Call txCreate
2. SENT — Once the rules engine has processed a NEW travel rule message, it might be automatically moved to SENT. If not, it can be moved there using txApprove.
   1. Set the rules engine to “Basic”, and/or;
   2. Call txCreate
   3. Call txApprove with the ID from txCreate
3. ACK — This status can only be triggered by the VASP receiving the travel rule message. They can use txConfirm, or if the address is already in their Notabene address book, it will happen automatically.
   1. Call txCreate with Notabene RoboVASP ACKNOWLEDGE as the beneficiary VASP
4. ACCEPTED — After a travel rule message has moved to ACK, it can be processed by the rules engine and automatically ACCEPTED if there is no potential risk detected. If not, it can be done using txAccept.
   1. Similar to ACK, use Notabene RoboVASP ACCEPT
5. DECLINED — Same as above, except Notabene RoboVASP DECLINE
6. REJECTED — This is the status that happens if the beneficiary VASP does not recognize the destination wallet as one they control. The status is triggered by calling txReject.
   1. Notabene RoboVASP REJECT
7. NOT_READY — This will be an automatic status for every travel rule message the beneficiary VASP receives if they have enabled this in the rules engine.
   1. [Notabene RoboVASP NOT READY](Notabene RoboVASP NOT READY)
8. INCOMPLETE — This status can only be triggered by txNotify when no travel rule message matches the blockchain information of a deposit.
   1. Call txNotify with random blockchain information.
9. MISSING BENEFICIARY DATA — This status is usually triggered when txUpdate is used to append information to an INCOMPLETE travel rule message. If the payload only contains information about the originator, it will have this status. It can also be triggered by txCreate if the option skipBeneficiaryDataValidation=true and you only send originator information in the payload.
   1. Call txNotify,
   2. Call txUpdate with the ID from the txNotify response where you only add originator information.
10. WAITING FOR INFORMATION — This status happens if the beneficiary VASP doesn’t have a way for us to notify them about the travel rule message that they have received.
    1. In txCreate, select a beneficiary VASP name or DID that have “in network”-status.
11. CANCELLED — This status can be triggered by the rules engine or manually using txCancel.
    1. After txCreate, manually cancel the transaction by using the dashboard or calling txCancel on the ID from the txCreate response.