Receive a transfer

Receive information for an incoming transfer

First record the incoming transfer through the transaction API with the exact customer, recipient wallet, network, asset, amount and available party details. Keep its current transfer evidence unexpired. Myaza matches one recorded intent; a saved external address or shared wallet alone cannot identify the receiving customer. Your organisation's deposit ledger remains authoritative.

CodeVASP

For an approved CodeVASP destination, Myaza manages the receiving endpoint. Do not generate a TRP receiving address. The gateway compares the sender's selected claims with the recorded incoming transfer and checks the current policy and reviews. It saves the encrypted response before replying; exact retries reuse that response. Rejected requests do not occupy the transfer's incoming-message slot.

The transaction page shows received information and the recorded response separately. Response recorded does not prove that the sender received it. Use Compare information for an audited view; do not send a TRP approval for a CodeVASP inquiry. Wait for the authenticated sender confirmation and your own wallet's chain checks before the incoming authorisation step below. Unknown or ambiguous recipients remain held.

Direct TRP

Open the incoming crypto transaction and find Receive required information. Choose Get receiving address, select a verified messaging connection and give the address to the sending institution. It is an information address, not a wallet address. It is limited to that institution and the current transfer revision.

When information arrives, the page shows Information received and your webhook receives travel_rule.exchange.updated with change: inquiry_received. The transfer stays on hold. Receiving a message does not confirm the information is complete, authorise a deposit, or prove that funds arrived.

Choose Compare information to see the sender's supplied values alongside your current record. Only fields required by the policy are shown, and access is recorded in the audit trail. Differences, missing values and formats needing specialist review are explicit. A match does not verify an identity, update your records or approve the transfer. Read-only team members do not have access to this sensitive comparison.

To decline, choose Decline request, then Prepare decline. Review the transfer and select Send decline response when ready. The local decision and delivery status are shown separately. If a response is lost, use Check delivery or refresh; do not start a new exchange to work around uncertainty.

To approve matching information, choose Prepare approval in the comparison. The server checks the current decisions, country reviews, recorded recipient wallet and network again. You cannot override the wallet or enter a callback URL here. Then choose Send approval response. Preparation and delivery are separate, so an interrupted response can be retried using the same operation without another approval.

For backend integrations:

Use your secret API key. Receiving-address and approval/decline preparation require their own UUIDv4 Idempotency-Key; preserve the exact key and body across retries. Read the current transfer for the correct revision and message IDs. Only a configured, independently verified connection can submit a message to the native mutual-TLS receiver. No customer API accepts an arbitrary peer callback or raw approval.

The approved sender can confirm its transaction through the authenticated receiving connection. exchangeProgress.confirmation distinguishes CONFIRMED, CANCELLED and CONFLICT, with settlementStatus: "UNKNOWN". This is the sender's report, not proof that a deposit arrived. Use the separate incoming authorisation gate in this guide after your wallet independently verifies the deposit. Never credit or release funds from message status alone.

Authorise an incoming deposit

After the information review and approval, wait for the authenticated sender confirmation. Your wallet must independently verify its transaction identifier, amount, asset, network, recipient, finality and whether it was already credited. The sender's report alone is not chain evidence.

Use the issue and consume endpoints. Include incomingTxid in both requests, with the exact transaction identifier your wallet checked. It must match the retained sender confirmation for this transfer revision and approval. Keep the same recipientAddress and persist one UUID externalExecutionId for the credit job.

{
  "expectedRevision": 3,
  "recipientAddress": "<exact-assessed-wallet-address>",
  "incomingTxid": "<confirmed-chain-transaction-identifier>"
}

Consumption also includes token and externalExecutionId, as in the execution guide. An incoming receipt has purpose: "INBOUND_CREDIT"; outgoing receipts have purpose: "OUTBOUND_TRANSFER". Only a fresh execute_once result can admit the bound job. Your wallet must enforce duplicate prevention for credits as well as sends. On a replay or missing response, reconcile the existing job instead of crediting again. Myaza does not credit balances, and settlement remains UNKNOWN in its receipt.

Cancellation, conflicting sender reports, stale policy or country reviews, paused connections and changed recipient evidence block consumption. A message acknowledgement without a sender confirmation is insufficient. Do not send incomingTxid for an outgoing transfer or use the outbound confirmation endpoint for an incoming job.