# 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:

| Action | Endpoint under `/api/v1` | Body |
|---|---|---|
| Get receiving address | `POST /transactions/{id}/travel-rule/exchanges/invitations` | `{ "connectionId": "reviewed-sender", "expectedRevision": 1 }` |
| Prepare decline | `POST /transactions/{id}/travel-rule/exchanges/{incomingMessageId}/rejection` | `{ "expectedRevision": 1 }` |
| Prepare approval | `POST /transactions/{id}/travel-rule/exchanges/{incomingMessageId}/approval` | `{ "expectedRevision": 1 }` |
| Compare selected information | `POST /transactions/{id}/travel-rule/exchanges/{incomingMessageId}/review` | `{ "expectedRevision": 1 }` |
| Send prepared response | `POST /transactions/{id}/travel-rule/exchanges/{responseMessageId}/send` | `{}` |

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](https://trust.myaza.co/documentation/travel-rule-execution/markdown). 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.

```json
{
  "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.