Callback Server Implementation

Regardless of the specific solution callback you're handling, the callback server uses the same endpoint to receive callback or result data from the GTR server. It is typically a beneficiary role to handle verifications or travel rules.

• Before On-Chain
• Challenge Verify

The completed callback server may look like the following code:

@PostMapping("/my_callback")
public Object requests(@RequestBody CommonCallbackRequestOuter < ? > vaspCallback) {
    // convert to wild map
    Map callbackData = (Map) vaspCallback.getCallbackData();

    // wild type converter
    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.configure(
      DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

    Integer callbackType = vaspCallback.getCallbackType()
    switch (callbackType) {
      case 0: // 0 is for network check
        break;
      case 4:
        break;
      case 6:
        break;
      case 7:
        break;
      case 8:
        break;
    }
}

All callback requests (from GTR to your service) follow the same structure:

CommonCallbackRequestOuter. However, CommonCallbackRequestOuter > data uses a different structure depending on the case. And the callback type decides which function to interactive, for more details please see [CallbackTypeEnum].

All callback servers (not only before on chain) use the same endpoint but can recognize the different callbackType. You will enter the URL during login.

All callback responses (from your service to GTR) should follow the basic structure of VaspServerResult and http status code is 200, more detail we will introduce in next section About HTTP Model.

Following table lists each available callback type and reference.

• The network test callback does not contain any data, just responds to the empty data of VaspServerResult.