> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hypermid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Execution flows

> Two ways a payer actually moves funds — and why the difference is visible in the API.

Independently of mode, a payment executes one of two ways. Which one you get
depends on where the funds start.

## Quote flow

The backend returns **transaction data**; the payer's connected wallet signs and
broadcasts it.

```
quote → transactionRequest { to, data, value } → wallet signs → we settle
```

This is the EVM path, and the one most integrations see.

## Deposit flow

There is no connected wallet to sign with — the payer is sending from Bitcoin,
Solana, TON, or an exchange. The backend mints a **deposit address**; the payer
sends funds to it.

```
mint deposit address → payer sends → we observe → we settle
```

<Warning>
  A deposit flow needs a **refund address up front** — `refundTo` when you mint
  the address. There is no connected wallet to refund to if settlement fails, so
  it cannot be collected after the fact; by then the payer may be long gone. This
  is the one field the deposit flow adds that the quote flow has no use for.

  The swap API spells the same idea `refundRecipient` on `POST /quote`. Two names
  for one concept is a wart rather than a subtlety — check which endpoint you are
  calling.
</Warning>

## Price and fees

For a payment session, the server resolves the destination, amount and fee
terms before the payer executes. The fee configuration is read by the backend's
`resolveFees` path and snapshotted on the session; a browser cannot replace the
recipient or fee by changing a request after creation. The merchant should
display the returned session values and treat the server response as the
contract.

That resolver applies one rule to Checkout, Deposit, and Withdrawal. The
Hypermid fee is the global rate unless a partner override replaces the global
rate outright. An optional developer fee is added on the same input amount; it
defaults to 0 and is restricted to 0–100 basis points. The payer-visible total
is `hypermidBps + partnerBps`.

There are two rail facts to keep visible:

* A same-token EVM transfer quotes a zero fee because a plain token transfer has
  no route that can collect either leg.
* On the Near deposit-address rail, the provider keeps half of each declared app
  fee. Hypermid therefore declares twice each net leg on the provider request;
  the payer-visible provider charge is double the net Hypermid and developer
  amounts shown by the Payments policy. The developer leg is paid directly by
  that provider. On EVM routes, the developer leg is held by Hypermid and
  settled periodically by manual transfer.

## Telling them apart

The SDK makes this a discriminated result rather than something to infer:

```ts theme={"system"}
const quote = await quoteSwap(req);

if (quote.execute.kind === "transaction") {
  await wallet.sendTransaction(quote.execute);
} else {
  showDepositAddress(quote.execute.address, quote.execute.memo);
}
```

`execute` is a union discriminated on `kind`, so the compiler forces the
branch rather than trusting you to remember it. See [Swap](/sdk/swap).

<Note>
  On a non-EVM source the API still returns `{to, data, value}`, but those are an
  **inert placeholder** — broadcasting them does nothing useful. The SDK omits
  them from the returned object entirely so the mistake is not reachable.
</Note>