> ## Documentation Index > Fetch the complete documentation index at: https://docs.dynamic.xyz/docs/llms.txt > Use this file to discover all available pages before exploring further. # Settlements > Choose the token and chain you receive in Flow payments, the strategy used to get there, where the funds land, and how to read what was delivered. Settlement is the half of a Flow payment you control. The payer chooses what they send, you declare what you want to receive, and the flow reconciles the two. ## Settlement currencies You nominate the tokens and chains you want to be paid in. If the payer sends something else, the flow [converts](https://docs.dynamic.xyz/docs/flow/conversions.md) it on the way, and you receive a token you configured. More than one settlement can be configured on a flow. Each needs a matching destination on the same chain, so a flow that accepts USDC on two chains needs somewhere for each to land. ## Routing strategy When several routes could satisfy a settlement, a strategy decides which one is used: | Strategy | What it optimizes for | | - | - | | **Cheapest** | Lowest total cost, counting gas and fees | | **Fastest** | Fewest steps | | **Preferred order** | The first available quote, in the order your settlements are listed | Preferred order is the one to reach for when you have a genuine preference between tokens or chains rather than a preference about cost or speed. To keep every payment on the token and chain the payer already holds, without conversion, set `disableSwaps` on the flow. See [Requiring an exact match](https://docs.dynamic.xyz/docs/flow/conversions.md#requiring-an-exact-match). ## Source chains A payer can pay from EVM chains, Solana, Sui, Bitcoin, or TRON, depending on the payment source. That is independent of what you settle in, so a payer holding an asset on one chain can pay a merchant settling on another without bridging anything themselves. [Supported chains](https://docs.dynamic.xyz/docs/flow/supported-chains.md) lists the chains per source and the supported testnet. ## Destinations Funds settle to an address you provide. That can be a Fireblocks vault, a Dynamic embedded wallet, or any other address you control. Each destination is matched to a settlement by chain. For a withdrawal, the destination is the end user's wallet and is supplied per flow, which is how a shared treasury pays out to many different users. ## What was delivered When settlement reaches `completed`, the flow records what reached your destination in its `settlement` object: | Field | Meaning | | - | - | | `amount` | The delivered amount, in the settlement token's smallest unit | | `amountUsd` | The USD value of the delivered amount | | `toTokenInfo` | The settlement token's symbol and decimals | | `toChainId` | The chain the funds were delivered on | | `toToken` | The settlement token's address | | `completedAt` | When settlement completed | Your server receives the same delivered amount as `settledAmount` in the [settlement webhook](https://docs.dynamic.xyz/docs/flow/webhooks.md#settlement), together with the settlement transaction hash. Show the payer the delivered amount when the flow reports one, not only the amount you requested. The delivered amount has limits: * The `settlement` object is written only when settlement reaches `completed`. * `amount` is present only when the provider or the chain reports it. Dynamic does not estimate it. * `amountUsd` and `toTokenInfo` can be absent even when `amount` is present. The mode decides whether a payment that arrives short is accepted. A `deposit` flow accepts it and records the smaller amount in `settlement.amount`, while a `payment` flow does not settle a short payment. See [Short payments depend on the mode](https://docs.dynamic.xyz/docs/flow/lifecycle-walkthrough.md#short-payments-depend-on-the-mode). ### Receipts A receipt for a completed payment can cite two transactions: the one that funded the payment and the one that delivered it. | Payment source | Funding transaction | Delivery transaction | | - | - | - | | Wallet | `txHash`, the transaction the payer's wallet sent | `settlementTxHash` | | Deposit address | `txHash`, the deposit as reported by the provider, when it reports one | `settlementTxHash` | | Exchange | None. Use `exchangeTransactionId`, the exchange's ID for the payment | `settlementTxHash` | `settlementTxHash` can be absent when the provider does not report it. It is available to your server and in webhooks, but not in the payer's view of the flow. `exchangeTransactionId` arrives only in webhooks. [Webhooks](https://docs.dynamic.xyz/docs/flow/webhooks.md#what-each-event-carries) lists where each field appears. ## Memos and reconciliation Any flow can carry a memo, which ties a payment back to something in your own system: an order ID, a user account, an invoice number. The memo is fixed when the flow is created and stays on the flow for its whole lifecycle. Webhook payloads do not include the memo. To reconcile, match a webhook to your records by `flowId`, and read the memo from the flow with your server's API token when you need it. The payer's view of the flow also includes the memo, so do not put secrets or personal data in it. See [Reconciling a completed payment](https://docs.dynamic.xyz/docs/flow/webhooks.md#reconciling-a-completed-payment). ## Next > [card] [Screening](https://docs.dynamic.xyz/docs/flow/screening.md) > > The checks that run before funds move. > [card] [Webhooks](https://docs.dynamic.xyz/docs/flow/webhooks.md) > > Knowing when settlement finished, and reconciling it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.