Changelly address changes depend on whether the payout has left the service

Unfunded website orders and funded swaps leave different options

An unfunded website order can expire without moving coins, while a funded exchange requires support to assess a recipient correction.

Before the deposit

If you have not submitted a deposit, withhold payment from the incorrect order. Floating-rate website users can create a replacement immediately. For a fixed-rate website order, wait until the old request expires before creating another. Review the replacement's recipient, selected network and funding instructions before committing funds. The earlier order's details remain unchanged when you create another request.

After the deposit

Once you have transferred the input funds, contact support about the existing exchange. Ask whether it can still stop the payout. A new order has its own recipient details; creating it does not edit the funded swap. Keep the original exchange ID available so the request concerns the funds that you already sent.

Can I redirect a swap after a payout hash appears?

Changelly cannot redirect a payout after the exchange receives a payout hash. That hash identifies the outgoing blockchain transfer. A delayed confirmation or a receiving account that has not credited the deposit does not reopen the address-change option.

A deposit hash identifies the incoming payment to the exchange. It can exist before any resulting currency leaves for the recipient. Check which transfer a hash describes before interpreting it as proof of dispatch.

The Sending label can include a blocked payout

A Sending status describes payout processing and can accompany an address problem, a missing identifier or a network delay. An unusable destination can prevent dispatch, while congestion can delay a transfer for reasons unrelated to the recipient. Support needs to establish whether delivery failed before dispatch or whether an outgoing transaction already exists. An empty payout-hash field alone does not guarantee time to make a correction. Describe the actual error and ask support whether the specific payout has left.

View image file

The exchange ID ties an address request to the correct order

A support request needs the exchange's own transaction ID so the team can locate the order with the inaccurate destination. Explain which recipient detail is wrong. Include the address currently recorded, the proposed replacement and the selected payout asset and network. If the destination needs a memo or tag, identify that requirement explicitly. The deposit hash can help locate incoming funds, and any payout hash helps distinguish dispatch from an earlier processing problem.

A ticket receipt confirms that you contacted support. It does not confirm that support stopped delivery or accepted a replacement address.

View image file

Does a valid address guarantee the correct network?

Address validation does not establish that the receiving account supports the selected payout asset on the selected network. The replacement must satisfy both requirements. A familiar address format cannot settle whether a particular wallet provider will credit that transfer or whether you control the destination.

Format checks catch only some mistakes

The Exchange API v2 validates an address for a specified currency and can also validate an extra identifier for certain currencies. A successful format check does not prove access to the receiving account. The extra identifier remains optional for the validation request even when the recipient needs it for delivery.

The receiving wallet must support the payout asset and network

Some networks use the same address format, which can let an incompatible destination pass a format check. Match the selected payout network with the receiving wallet's deposit instructions. If a provider manages the destination, its supported deposit asset and network determine account crediting. Resolve that compatibility question before supplying a replacement; changing the address text alone cannot resolve an unsupported receiving arrangement.

Memo corrections follow the payout's actual state

A memo, message or destination tag supplies additional receiving information where the selected destination requires it. Replacing the main address can leave that information wrong.

Dispatch has not succeeded

When incorrect receiving data blocks the Sending stage, support may request a suitable address or the correct extra identifier. It may also need confirmation that the recipient requires no identifier. Supply the receiving wallet's actual requirement. Arbitrary text or a tag from another account can introduce a different delivery error. Support must establish that it can correct the unsent payout.

The receiving provider already has the transfer

A payout that arrives at a provider without the required memo can remain unassigned to your account. The provider's support team must assess that deposit. Its account-crediting process is separate from the exchange's ability to change an unsent recipient. The provider may be able to assign the received deposit to the correct account, subject to its own recovery conditions.

View image file

Who can help after coins reach an unintended recipient?

Recovery depends on whoever controls the destination and whether they can access the transferred asset on its actual network. Contact the receiving wallet provider about an unsupported asset, an incorrect network or an unassigned deposit that reached its address. An address outside Changelly's control prevents the service from simply retrieving the coins. Recovery may be unavailable even when an address has a valid format. Keep the payout details associated with the recovery request so the provider can investigate the actual transfer.

If the mistaken recipient was another Changelly-generated address, contact the service about that specific case. If the address was generated for a different currency on the same network, technical recovery may be possible. If the networks differ, support may have no recovery estimate, or the funds may be non-refundable. This exception concerns funds that reached an address the service controls; it does not provide a way to rewrite a completed blockchain transfer.

The refund address serves the input currency

A swap's refund address must support the input currency. The payout recipient must support the asset that the exchange produces. Exchange API v2 records those destinations separately, including their extra identifiers when applicable. Its fixed-rate creation method requires a refund address, while the floating-rate method makes that field optional. Identify the destination you want corrected, because a payout address and a refund address have different purposes.

Stopping a payout does not guarantee a refund. In many stopped exchanges, support may be able to change the recipient even when a refund is unavailable.

A recipient edit leaves deposit errors unresolved

Replacing the payout recipient cannot repair the network or identifier used for the original incoming payment. A wrong input network or a missing deposit tag requires investigation of that transfer. A deposit missing a required Extra ID, such as a memo or destination tag, must be worth at least $50 for refund or processing. Changelly estimates its USD value using the conversion rate on the date of the customer's request. Below $50, Changelly cannot refund or process such deposits. Recovery can also involve network fees and supplementary operating costs. Changelly limits possible wrong-chain recovery to the asset and network combinations listed in its technical recovery terms, with a minimum fixed fee of $100. It cannot refund or process other combinations sent through unsupported or unrecommended networks. Those conditions concern retrieving incorrectly sent funds, so they do not establish a universal fee for recipient edits. Describe the deposit error separately when it accompanies a destination error, and ask which recovery options apply to the actual payment.

Correction requests need transaction details without wallet secrets

A recipient address supplies a destination for incoming funds; a private key gives spending access. Never share private keys or a recovery phrase while requesting an address change. Order details and public transfer identifiers describe the exchange without supplying that access. On public ledgers, sharing a transaction hash can also reveal transfer details, so limit screenshots to the affected order. Identity verification, when required, remains a separate process. An address-correction request does not remove that requirement or make wallet secrets appropriate support information.