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

# Withdrawal

> Send funds back out to a payer.

The inverse of a deposit: the connected wallet is the **source**, and the payer
receives.

Creating the session does not move funds. The session becomes a payment only
when the connected source wallet signs and broadcasts the transaction. The
server binds the recipient into the session and the transaction data, so a
stolen `sk_` key can create a withdrawal request but cannot move a payer's
funds by itself. The payer should review the recipient before signing; never
sign a withdrawal link you did not expect.

## Fees

Withdrawal resolves the same two rates as Checkout and Deposit: Hypermid's fee
plus an optional developer fee on the same payer-input amount. The developer fee
defaults to 0, is limited to 0–100 basis points, and requires a recipient when
positive. A partner-specific Hypermid override replaces the global rate
outright.

A same-token EVM transfer is the zero fee exception because its plain transfer
has no fee-taking route. Cross-asset EVM developer earnings are held by Hypermid
and settled periodically by manual transfer. If a Near deposit-address route is
used, its provider keeps half of each declared app fee and pays the developer
leg directly.

```ts theme={"system"}
import { createWithdrawal } from "@hypermid/sdk";

const session = await createWithdrawal(
  {
    chain: 8453,
    token: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    recipient: payoutAddress,       // recipient for this withdrawal session
    amount: "25000000",
    orderId: `withdrawal_${request.id}`,
  },
  { secretKey: process.env.HYPERMID_SECRET_KEY! },
);
```

## Payout addresses

Withdrawal recipients are supplied per session and are **not** checked against
the checkout payout allowlist. The payout-address screen is for proving
merchant-controlled checkout destinations; it is not a prerequisite for this
withdrawal request. Validate the recipient for its chain before creating the
session and use the appropriate operational controls for your product.

For checkout destinations, add an address through **Payout addresses** in the
partner portal. The portal sends an emailed verification code bound to the
exact address, chain, action, and environment; enter that code to approve the
change. The backend applies the change and its audit record together.

<Steps>
  <Step title="Request a verification code">
    Enter the address in the portal and request a code. It is bound to this
    exact payout-address change.
  </Step>

  <Step title="Enter the emailed code">
    Enter the code from the merchant security email in the portal.
  </Step>

  <Step title="Confirm the change">
    The address is added to the environment-specific checkout allowlist after
    the code is verified.
  </Step>
</Steps>

This protects merchant checkout payouts. It does not turn the checkout
allowlist into a withdrawal restriction.

<Warning>
  Payout addresses are self-custody only. An exchange deposit address cannot be
  allowlisted because the exchange controls its signing key, not the merchant.
</Warning>

List with `GET /v1/payments/payout-addresses`; remove with
`DELETE /v1/payments/payout-addresses/{chain}/{address}`.

<Note>
  Withdrawals never offer the send-to-an-address flow. The wallet is the source,
  so there is nothing to mint a deposit address for, and the backend rejects the
  attempt rather than failing later.
</Note>