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

# Lifecycle Walkthrough

> How a transfer moves through Connections, Conversions, and Settlements, the three modes, and the rules that govern retrying or resuming one.

Moving value creates a flow: one object representing one transfer attempt. Your backend creates it, your client advances it, and Dynamic settles it.

## Step 1: Connections

Decide what the connection is for before making one.

**Standalone.** A wallet or an [exchange account](/docs/flow/exchange-connections) connects on its own. No flow is involved. Connect a wallet [natively](/docs/external-wallets/native) or [through a hosted page](/docs/connections/overview) to authenticate a user, or authorise an exchange account to read balances or send a direct withdrawal. Nothing here is quoted or settled, so none of the steps below apply.

**As part of a flow.** Paying, depositing, converting, or settling all move through a flow object. A wallet, an exchange account, or a deposit address funds it. Your backend creates the flow first; nothing attaches before that.

1. **Create the flow.** Your backend sets the mode, the amount, the settlement token and chain, and the destination. This is the only call your API token authenticates, so a browser client never holds an endpoint that accepts those fields. Everything after runs on a session token.
2. **Attach the connection.** A [wallet](/docs/flow/connections) the user connects, an [exchange account](/docs/flow/exchange-connections) they authorise, or a deposit address. Flow generates the deposit address as part of this step, not before. Attaching it declares where the value is coming from. It also mints the session token.

## Step 2: Conversions

With a connection attached, Flow can price the transfer and request the funds. If it holds something other than what you settle in, this is where the [conversion](/docs/flow/conversions) happens.

3. **Get a quote.** Dynamic returns the route, the fees, and an estimated time.
4. **Prepare signing.** The quote is locked in and a signing payload is returned.
5. **Sign and broadcast.** The payer's wallet signs and submits to the network.
6. **Report the transaction.** Hand back the transaction hash so Dynamic can watch the chain.

A deposit address skips steps 4 to 6 entirely, because the payer sends funds externally rather than signing anything. A withdrawal is signed by your wallet rather than the end user's.

## Step 3: Settlements

7. **Settle.** Dynamic watches the chain and routes the funds to your destination, in the token and on the chain you configured. See [Settlements](/docs/flow/settlements).

<Warning>
  Reaching `source_confirmed` does not mean the transfer is finished. Settlement can still be in progress: keep polling or processing webhooks until it reports `completed` or `failed`.
</Warning>

```mermaid theme={"system"}
sequenceDiagram
    participant Backend as Your backend
    participant Dynamic
    participant Payer

    rect rgb(238, 242, 255)
    Note over Backend,Payer: Connections
    Backend->>Dynamic: Create the flow
    Payer->>Dynamic: Attach the connection
    end

    rect rgb(238, 242, 255)
    Note over Dynamic,Payer: Conversions
    Payer->>Dynamic: Request a quote
    Payer->>Dynamic: Prepare signing
    Note over Payer: Sign and broadcast on-chain
    Payer->>Dynamic: Report the transaction
    end

    rect rgb(238, 242, 255)
    Note over Backend,Dynamic: Settlements
    Note over Dynamic: Watch the chain, route settlement
    Dynamic-->>Backend: Settlement completed
    end
```

## Modes and direction

One mode is chosen at creation and cannot change afterwards.

| Mode           | Amount set by | Source                                 | Destination                              |
| -------------- | ------------- | -------------------------------------- | ---------------------------------------- |
| **Payment**    | You           | The user's wallet or exchange          | Your treasury, vault, or merchant wallet |
| **Deposit**    | The user      | The user's wallet or exchange          | Your treasury, vault, or merchant wallet |
| **Withdrawal** | You           | Your treasury, vault, or server wallet | The user's wallet                        |

The same steps also move value between your own wallets on different chains, for example wallet A on chain X to wallet B on chain Y: that's a payment or deposit configured cross-chain, not a fourth mode.

Payments can also be created as a shareable [payer URL](/docs/flow/payment-links) instead of a flow you wire into your own UI, which suits invoices sent by email or chat.

## Flow state and retries

A flow is a state machine: each action is valid only from certain states, and one called out of order is rejected. Before retrying a request or resuming an interrupted session, read the flow's current state and act on that instead of replaying the last call. Cancel any time before broadcast; not after.

See [Resume and retry by state](/docs/flow/api#resume-and-retry-by-state) for every state and what it allows next.

## Next

<Columns cols={2}>
  <Card title="Connections" href="/docs/flow/connections">
    What a payer can pay from, and which to offer.
  </Card>

  <Card title="Webhooks and events" href="/docs/flow/webhooks">
    How a flow reports its own progress.
  </Card>
</Columns>