Skip to main content
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 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: 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.

​
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 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: Your server receives the same delivered amount as settledAmount in the settlement webhook, 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.

​
Receipts

A receipt for a completed payment can cite two transactions: the one that funded the payment and the one that delivered it. 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 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.

​
Next

Screening

The checks that run before funds move.

Webhooks

Knowing when settlement finished, and reconciling it.
Last modified on October 27, 2026