> For the complete documentation index, see [llms.txt](https://developer.branta.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.branta.pro/setup/send.md).

# Send

### Before send

When the user scans a QR or pastes a destination, pass that string to the SDK. Scan and paste are the same call. No Branta account.

Install from the [SDK](/tech/sdk.md) page. Use [staging](/tech/environments.md) until you go live.

| Destination                 | Pass                                                                                                                                                                          |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| On-chain Bitcoin            | A `bitcoin:` URI with `branta_id` and `branta_secret`. A bare address is `unknown`.                                                                                           |
| Stablecoin rails            | A chain URI with `branta_id` and `branta_secret`. Token is the matched destination type — do not infer it from the scheme. A bare address (including bare `0x`) is `unknown`. |
| bolt11, Ark, silent payment | The value (`ark1` / `tark1`, `sp1` / `tsp1`).                                                                                                                                 |
| Unified BIP-21              | The full URI. Do not split.                                                                                                                                                   |

Full enum list and stablecoin schemes: [Destination types](/destination-types.md).

### Status handling

| Status       | When                                                         | Do                                                                                                    |
| ------------ | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- |
| `match`      | Destination is in Branta                                     | Show name and logo from `payments[0]`. Link to `verifyUrl`. Send using `matchedDestinations` (below). |
| `unknown`    | Not in Branta, including 404                                 | Show nothing.                                                                                         |
| `tampered`   | Destination was altered                                      | Warn. Do not show a verified card.                                                                    |
| `incomplete` | 5xx, 429, unreachable, or HTTP timeout (SDKs default to 30s) | Tell the user Branta could not complete the check. Do not block send.                                 |

### On `match`

A `match` gives you two things. Keep them separate:

| Field                 | Use for                                                   |
| --------------------- | --------------------------------------------------------- |
| `payments[0]`         | Counterparty card — name, logo, `verifyUrl`               |
| `matchedDestinations` | What to send — each item has `type` and plaintext `value` |

**Recipe**

1. Show the verified card from `payments[0]`.
2. Take `matchedDestinations[0]` for a single-rail QR (most scans). Use `type` for the asset and `value` for the address or invoice.
3. If the QR had multiple payable instructions (for example unified BIP-21 with on-chain + bolt11), `matchedDestinations` may have more than one entry — honor each `type`.

**Do not**

* Infer the token from the URI scheme — use `matchedDestinations[].type`.
* Dig through `payments[].destinations` or filter on encryption flags. Sibling rails on the same payment may still be encrypted; `matchedDestinations` is already what this scan bound.

### Payment history

Once a payment resolves to a counterparty, render the counterparty name and logo in your transaction history, too.

**This is recommended for all send integrations:**

* **Persist at send time.** When the send-flow lookup returns a `match`, store the counterparty `name` and `logo` on your transaction record. History rendering is then a local read — no extra network calls, and it works offline.
* **Make it searchable.** Include the stored counterparty `name` in whatever your history search already indexes. Search stays local — the field is already on the record.

### Test your integration

Scan the [production](/setup/send/production.md) or [staging](/setup/send/staging.md) QR codes. Match the environment your SDK is pointed at. Each tab says the status to expect.

After a `match`, confirm the counterparty still shows in payment history, and that searching for that name finds it.