Payments

Simulate an inbound travel-rule exchange with a counterparty VASP (non-production only)

Changed on

Has a Tesser-operated simulator VASP originate a real Notabene travel-rule transfer into one of your managed wallets, so you can rehearse your travel-rule handling without a second VASP. Where the transfer is authorized, testnet USDC is broadcast shortly after this responds and the destination balance is credited a few seconds later; a rejected transfer moves no money. Use POST /v1/payments/simulate-inbound to simulate a credited deposit without a travel-rule exchange. Not available in production.

post/v1/payments/simulate-travel-rule-inbound

Request

Request body

to_accountstring uuid required

Managed account ID the simulated counterparty should claim to be paying.

claimed_beneficiary_namestring

Name the simulated counterparty claims for the beneficiary. Omitted, it claims the destination owner's own name and the transfer is authorized; supplied and wrong, name matching refuses it.

network'BASE_SEPOLIA' | 'ETHEREUM_SEPOLIA' | 'POLYGON_AMOY'

EVM testnet the simulated transfer settles on. Defaults to BASE_SEPOLIA.

presentation'full' | 'partial'

How completely the simulated counterparty satisfies your presentation policies. full answers the only policy raised. partial raises a second policy the counterparty can never answer alongside it, so the exchange comes back partially satisfied. Defaults to full.

mocked_risk_status'automatically_approved' | 'awaiting_decision' | 'automatically_rejected'

Forces the risk_status of the screening that runs once the simulated money arrives. Omitted, the inbound is screened for real. Only meaningful on the authorized branch — a rejected transfer sends no money and is never screened.

Response

The compliance round trip finished and the inbound payment exists. This is not by itself a sign the transfer was authorized — a REJECTED transfer also produces a payment here. In both cases the step stays created, because its status only follows the money. Read the decision from the step's status_reasons on GET /v1/payments/{id}: transfers-9216 where the transfer was authorized, transfers-9215 or transfers-9203 where it was rejected. The last one is in force. provider_metadata carries the raw Notabene transfer, whose own status is not updated for every decision Tesser takes, and participants carries the name match once payment.participants_updated publishes it, right after payment.created. Where the transfer was authorized, testnet USDC is broadcast just after this response and the payment confirms and credits a few seconds later, which payment.updated announces.

Example response

{
  "data": {
    "id": "5a9c3e7f-2b1d-4f48-a6e0-8c4b2d1f9a3e",
    "workspace_id": "b53f6690-3242-4942-9907-885779632832",
    "organization_reference_id": "ref_123",
    "direction": "inbound",
    "funding_account_id": "2a8f4c1e-9b3d-4e56-b7a0-5c6d2e1f9b3a",
    "risk_status": "automatically_approved",
    "risk_status_reasons": [
      {
        "risk_status_reason_type": "OWNERSHIP",
        "risk_status_reason_category": "Exchange",
        "risk_status_reason_participant_id": null,
        "risk_status_reason_message": "Address has OWNERSHIP activity for Exchange over its threshold",
        "risk_status_reason_severity": "Low",
        "risk_status_reason_significance": "DECISIVE",
        "volume_usd_percent": "60.00",
        "volume_usd_percent_threshold": "1",
        "volume_usd_amount": "30000.00",
        "volume_usd_amount_threshold": null,
        "confidence_score": null,
        "confidence_score_threshold": null
      },
      {
        "risk_status_reason_type": "COUNTERPARTY",
        "risk_status_reason_category": "Gaming",
        "risk_status_reason_participant_id": null,
        "risk_status_reason_message": "Address has COUNTERPARTY exposure to Gaming over its threshold",
        "risk_status_reason_severity": "Low",
        "risk_status_reason_significance": "DECISIVE",
        "volume_usd_percent": "12.00",
        "volume_usd_percent_threshold": "2",
        "volume_usd_amount": "6000.00",
        "volume_usd_amount_threshold": null,
        "confidence_score": null,
        "confidence_score_threshold": null
      }
    ],
    "provider_metadata": [],
    "participants": [
      {
        "role": "BENEFICIARY",
        "resource": {
          "resource_type": "WORKSPACE",
          "id": "b53f6690-3242-4942-9907-885779632832",
          "name_match_score": null,
          "name_match_threshold": null,
          "name_match_comparison_id": null,
          "resolution": "USER_SUPPLIED_ID"
        }
      },
      {
        "role": "ORIGINATOR_VASP",
        "resource": {
          "resource_type": "COUNTERPARTY",
          "id": "a4c1f0b8-2e9d-4a63-b7c5-1d8f6e0a3c92",
          "name_match_score": "100",
          "name_match_threshold": "85",
          "name_match_comparison_id": "a4c1f0b8-2e9d-4a63-b7c5-1d8f6e0a3c92",
          "resolution": "EXACT_MATCH"
        }
      }
    ],
    "balance_status": "unreserved",
    "steps": [],
    "created_at": "2024-03-01T10:00:00.000Z",
    "updated_at": "2024-03-01T10:00:00.000Z",
    "expires_at": "2024-03-02T10:00:00.000Z"
  }
}

Changes

    • warning

      added the new BENEFICIARY_UPDATED enum value to the /////// response property for the response status

    • warning

      added the new ORIGINATOR_UPDATED enum value to the /////// response property for the response status

    • warning

      added the new ORIGINATOR_VASP_UPDATED enum value to the /////// response property for the response status

    • info

      endpoint added