To pay a supplier in the currency of their preferred network, quote a swap from the asset you hold to the asset they accept, then send the output to their address; an Ethereum deposit currently takes about 90 seconds to reach Chainflip’s witnessing threshold. The payment is complete only when the supplier’s wallet receives the right asset on the right network, so treat the destination network and address as payment instructions that need verification. A cross-chain route is useful when your treasury asset and the supplier’s required asset are on different chains.
Why convert when you make the payment?
Your supplier can receive native SOL on Solana, for example, while your application funds the payment with USDC on Ethereum. That avoids asking the supplier to bridge or swap the payment themselves. A useful example of how Chainflip handles native swaps is this kind of source-to-destination conversion, where an asset is deposited on one chain and the requested asset is paid out on another.
Confirm with the supplier that they accept the exact asset and network, and that the destination address belongs to a wallet they control. “USDC” alone is not a complete instruction: USDC on Ethereum and USDC on Solana are separate assets on separate networks. This flow pays a crypto wallet; it does not convert the funds into a bank transfer or guarantee the supplier can cash them out.
How does the integration move the payment?
Chainflip’s SDK lets your application request a quote and open a deposit channel for a specified source asset, destination asset, and destination address. The channel registers the payment details before the source funds are sent. Once the deposit is witnessed, the protocol processes the swap and broadcasts the output to the supplier’s address.
Use a fresh deposit channel for each payment and send the funds promptly: channels expire after 24 hours, and a late deposit may not be recognised. For Ethereum, the documented witnessing threshold is six blocks, around 90 seconds; for Bitcoin, it is three blocks, around 30 minutes. These are source-chain confirmation thresholds, not promises for total settlement time. The destination chain must still process the payout.
For a typical wallet-to-wallet payment, the operational sequence is:
- Ask the supplier for the destination network, exact asset, and receiving address.
- Check that the selected source and destination asset pair is supported on mainnet.
- Request a quote for the payment amount and inspect its estimated output, fees, and recommended slippage settings.
- Open a deposit channel with the supplier’s destination address and the quote’s minimum accepted price parameters.
- Show the user the source-chain deposit address and transaction details, then submit the deposit.
- Track the deposit, swap, and destination payout; mark the invoice paid only after confirming the payout on the destination chain.
Do not derive or show a deposit address before the channel request succeeds. Keep its transaction hash so your support or reconciliation process can verify that the payment details were registered. Also match the supplier’s address format to the destination chain; an address that looks valid on one network may be unusable on another.
How much will the payment cost?
Use the live quote for the amount the supplier must receive; the deposit amount is not necessarily the payout amount. Fees can include source-chain gas, a liquidity fee of typically 0.10%–0.15% per pool, a 0.10% network fee with a $0.50 minimum, destination-chain broadcast gas, and any broker commission your integration adds. The quote’s fee breakdown and estimated output are the practical figures to present before the user sends.
For a quick estimate, suppose a $500 USDC payment to SOL uses one pool. The documented liquidity and network fees alone would be about $1.00–$1.25, before source gas, destination broadcast costs, broker commission, and any price movement. Redo the calculation using the quote’s actual route and fees; don’t assume a one-pool route or add the same fee twice if it is already reflected in the quoted output.
The Bank for International Settlements has highlighted that cross-border digital-asset costs also depend on conversion and withdrawal charges, liquidity, and access to payment rails. For this integration, compare the supplier’s required output with the quote’s net payout and include any separate costs your own product or treasury adds.
What should you confirm before launch?
How do you protect against a changing quote?
Set a minimum acceptable output through the quote’s fill-or-kill parameters, then make the trade-off clear: a tighter limit can reject a payment if the market moves, while a looser limit may accept a worse rate. Show the quote expiry or refresh it before deposit, and handle a rejected or partially failed swap as a payment exception. Reconcile any refund and its fees before allowing a retry.
When should you mark the supplier invoice paid?
Wait for the destination payout transaction and verify its chain, asset, recipient address, and amount against the invoice. Build the next step by storing the quote, deposit-channel request hash, source transaction, and payout transaction under one payment reference. Then test the full flow with a small amount on the intended route before enabling supplier payments at scale.