Changelly fixed rate quote conditions, payment deadlines and late deposits
Updated ·
Changelly fixed rate locks an instant crypto swap's quoted exchange rate when the exact required deposit appears on-chain before the payment deadline. The amount that Changelly receives matters, including any deductions by the sending wallet or exchange. A late deposit falls outside the normal fixed-rate conditions and requires manual assessment. Market conditions may still allow completion at the original rate; otherwise, a refund may be possible after applicable fees. The funding window governs payment, while blockchain confirmations and payout processing determine delivery time.
Funding the quoted order through to wallet delivery
A fixed-rate exchange needs a spendable input balance and a sending method that can deliver the required deposit within the payment window. An unresolved withdrawal restriction can prevent timely funding even when the account shows enough cryptocurrency. The order also needs a recipient address that supports the output currency and network, plus a refund address that supports the input currency and network. Supply any memo, message or tag required for either address. On the website, the confirmation step starts the funding clock after those details are set. Use the specified input currency and network when paying. Include any memo, message or tag that Changelly provides so it can match the payment automatically.
Changelly generates a payment address for the particular exchange. That address identifies where the input must arrive; the recipient address identifies where the output should go. Creating the order establishes payment instructions. Its Finished status reports a successful exchange. Use the payout hash to check the outbound transfer's destination, amount and confirmations on the output network. A withdrawal request at the sending service leaves the deposit's actual transmission and receipt unresolved.
What does the fixed quote actually lock?
The fixed option preserves the quoted conversion against market movements when the incoming payment satisfies the order's amount and timing conditions. The agreement concerns the exchange between the selected cryptocurrencies. It does not fix their value in government-issued money after delivery. A later market move can make a fresh quote more or less attractive without changing a compliant order's agreed conversion. The rate expresses the conversion, while the expected receiving amount reflects the quantity and applicable deductions.
Exact deposits and withdrawal deductions
The required input is the amount that Changelly receives, which can differ from the amount that a sending service removes from an account. A wallet or exchange may charge a transfer fee separately or deduct it from a withdrawal. A deduction reduces the quantity that reaches the payment address. The sending service's final transfer details therefore need to match the order's requested deposit after its charges. An account debit that matches the requested input does not establish an exact deposit.
Overpayment exceeds the quoted input amount; underpayment falls below it. A fixed order does not automatically resize the agreed conversion to accommodate a different quantity. An amount mismatch can prevent normal execution even when the received deposit exceeds the pair's minimum. The exact amount belongs to the individual order; the minimum only establishes whether an exchange meets the pair's lower limit.
Fixed-order parameters in Exchange API v2
Exchange API v2 returns a transaction ID and a pay-in address when fixed-order creation succeeds. The ID tracks that exchange, while the address accepts its input funds. The returned quantities refer to the selected input and output currencies. These fields describe an order that still needs funding, so a successful creation response alone does not establish deposit receipt.
| Order parameter | Value and meaning |
|---|---|
type
|
fixed, identifying the fixed-rate transaction mode.
|
amountExpectedFrom
|
The expected deposit quantity in the selected input currency. |
amountExpectedTo
|
The expected output quantity before the network-fee deduction, in the selected output currency. |
payTill
|
The payment deadline for the created fixed-rate order. |
| Shared scope | Each value describes this order; none confirms that funding or payout has occurred. |
Can the quote expire before an API order exists?
Yes, the fixed-rate quotation can expire before an integration creates an order, because quotation validity and the order's payment deadline govern different actions. The amount-based estimate returns a quote identifier and an expiry timestamp named
expiredAt. The identifier carries the quoted terms into order creation while it remains valid. It does not create a payment address or establish that an exchange has received funds.
Order creation uses the quote identifier as
rateId
and produces the separate funding deadline,
payTill. An expired or already used identifier cannot create another fixed-rate transaction. The integration needs a fresh quotation in that case.
Both
new
in the creation response and
waiting
in a status request describe an order awaiting payment.
Network fees and the amount that reaches the wallet
Fixed-rate pricing includes a dynamic exchange charge that covers the conversion's exposure to market movements. Its quoted pricing differs from a sending wallet's withdrawal or transfer charge. Transaction details show the exchange and network-fee information for the selected order. Comparing receiving amounts requires the same currency pair and input quantity, with the deductions included. A fixed quote can differ from a floating quote even before any further market movement occurs.
In the fixed-order API response,
amountExpectedTo
describes output before withholding
networkFee. The expected net payout equals that output quantity minus the network fee, with both values expressed in the payout currency. Changelly estimates the payout network charge when the order is created, and the final charge can sometimes differ. A different final network charge can change the amount that Changelly sends to the receiving wallet. The gross output field therefore cannot stand alone as the wallet's expected receipt.
Asset availability and amount limits
Fixed-rate availability depends on the selected pair and requested amount, so an asset listing alone does not establish an executable fixed quote. Each pair has an applicable minimum and maximum for fixed exchanges. An amount outside those limits causes the fixed-rate estimate request to return an error. The minimum must cover network costs and the market's minimum exchangeable lot. API responses can distinguish an unavailable pair from a currency temporarily disabled specifically for fixed-rate transactions. They also distinguish restrictions on an asset as input or output. Those differences matter because general currency support, fixed-mode availability and permission to use a currency in a particular direction are separate conditions.
Confirmation time continues after the funding window
The payment window concerns the incoming transfer's timely appearance, while blockchain confirmations determine when the exchange can move beyond its Confirming stage. Changelly uses that stage after receiving the payment and while waiting for the input currency's required confirmations. A timely deposit can therefore remain in processing after the funding countdown ends. The countdown's end alone does not turn an already compliant deposit into a late one.
Confirmation requirements depend on the incoming currency, and network congestion can extend processing. Changelly cannot accelerate the blockchain's confirmation process. After confirmation, the exchange still needs to perform the conversion and deliver the output. A payment deadline therefore supplies no total delivery duration. A processing estimate describes expected elapsed time; it does not replace the chain's confirmation requirements or prove that the recipient already has the payout.
What can Changelly do with a late fixed-rate deposit?
Changelly may complete a late fixed-rate deposit manually at the original rate if market conditions allow the exchange. If execution is no longer possible, a refund may be available after applicable fees. This conditional handling does not turn every late fixed order into an automatic floating-rate swap.
The
expired
API status records missed fixed-rate funding;
refunded
records a separate outcome.
A support request about late funding concerns the existing exchange and the transfer already sent to its payment address. Include the Changelly transaction ID and the deposit's blockchain hash so support can identify both records. The transfer details establish its amount and destination. A new order does not restore the earlier deposit's expired funding window.
Refund conditions and the return address
A fixed-rate refund returns the input cryptocurrency to the refund address, which must match the currency originally sent. That address has a different purpose from the recipient address for a successful conversion. Refund eligibility also depends on the funds reaching Changelly and the exchange remaining incomplete. A very small deposit may fail to cover the network cost of returning it, leaving no refundable amount. A refund has its own blockchain transaction and hash, and returns the recoverable input funds after applicable deductions.
Floating-rate funding when a fixed deadline is impractical
A floating quote offers an alternative when exact, prompt funding is uncertain, with a conversion result that can change during processing. Its eventual output may rise or fall with market conditions. Floating mode still has a payment deadline and requires the correct input currency and network. It therefore changes the pricing commitment without making a payment address a permanent deposit destination. The order's displayed conditions remain relevant even when the receiving amount starts as an estimate.
Floating-rate exchanges may process a deposit that differs from the initial estimate when it remains above the applicable minimum. Fixed-rate funding requires the quoted input quantity. That distinction can matter when a sending service deducts a withdrawal charge from the transfer. Either mode still needs a deposit large enough to satisfy the exchange's requirements.
Answers to common questions
Can an underpaid fixed-rate order accept a later top-up?
You cannot pay a fixed-rate order's missing balance with a later transfer. An insufficient deposit can cause the exchange to fail. The original exchange ID identifies the underpaid order when requesting help. An additional payment to the same deposit address can create a reused-address problem, so it does not provide a routine way to repair the shortfall.
Do I still need identity verification for a fixed-rate swap?
A fixed quote does not exempt an exchange from identity checks. Changelly can place a transaction on hold when its risk-scoring system requires verification. The rate choice concerns conversion pricing, while the hold concerns processing eligibility. An on-time deposit does not establish that every other requirement has passed or that payout can proceed immediately.
Should I resend a pending fixed-rate deposit with a higher network fee?
Changelly warns against resending an existing deposit with a higher fee because it can treat the payment address as reused. A replacement transfer may create an order-matching problem even if the aim is faster confirmation. Its guidance about higher fees for future transfers does not establish that replacing the current deposit preserves the fixed quote.
How should I interpret a fixed-rate order that still says not paid after a transfer?
Not paid means the order has no recognized matching payment, even if the sending service shows a withdrawal request. Possible causes include delayed recognition, a failed network transfer or missing payment details. The Changelly transaction ID identifies the order, while the deposit hash identifies the blockchain transfer. Support needs both identifiers to investigate the mismatch.
Is getFixRate suitable for a new fixed-rate API integration?
The getFixRate method is deprecated, and Exchange API v2 directs new integrations to getFixRateForAmount. The replacement estimates a fixed conversion for a specified amount. This distinction concerns how an integration requests its quotation; it does not mean that Changelly has discontinued fixed-rate exchanges.
Where can I check the amounts that a completed fixed-rate API exchange actually processed?
The getTransactions response reports the actual input in amountFrom and the actual output sent to the payout address in amountTo. These values have different roles from the expected-amount fields recorded before processing. Read them alongside the completed transaction's currencies and status. The payout hash identifies the outbound transfer, while the pay-in hash identifies the deposit.
When should I expect a refund from a failed fixed-rate order?
Refund timing depends on the failure and the work needed to return the funds. A straightforward late or mismatched deposit differs from a reused address or a transfer requiring recovery. Support can assess the case's expected timing and refundable amount. An Expired status alone does not confirm that a refund has started or supply a return date.
Does the fixed-rate API accept a requested receiving amount instead of a sending amount?
The amount-based fixed-rate estimate accepts amountTo as an alternative to amountFrom. The request must supply exactly one of those amount parameters; supplying neither or both produces an error. When the integration creates the order, its amountExpectedTo field reports output before deducting networkFee. For a target wallet receipt, compare that target with the expected net payout, amountExpectedTo minus networkFee.