Changellyexchange Swap IDs and Blockchain Hashes

Exchange IDs and Blockchain Transaction IDs

The exchange ID identifies Changelly’s order record, while a blockchain transaction ID identifies activity on a particular network. Wallets and explorers often use transaction ID, transaction hash or TXID for the blockchain identifier. Changelly also calls its own order reference a transaction ID. The identical wording therefore needs context: an exchange reference belongs in an order lookup, and a blockchain hash belongs in the corresponding network’s explorer.

View image file

A deposit address identifies where payment should go; it does not identify one particular payment. An address can have a transaction history containing multiple entries. The hash selects a transaction from that history, while the order record connects the payment to the requested exchange. Keep the labels beside copied identifiers, especially when sending details through a support conversation. A bare string marked only as an ID leaves its purpose unclear.

Deposit Confirmation and Payment Recognition

A deposit hash establishes which incoming transfer to inspect; payment recognition also depends on matching the order’s asset, network and routing details. The sending wallet’s record describes the payment leaving that wallet. Changelly’s order record describes whether its system has recognized the payment for the exchange. A confirmed transfer on the blockchain and a waiting order can therefore describe different parts of the same unresolved payment issue.

Changelly’s required incoming confirmation count depends on the deposit currency. The Confirming status means the service has received the payment and is waiting for the necessary confirmations. Creating an order or obtaining a hash does not bypass that requirement. Blockchain confirmation also cannot repair a payment sent with incompatible asset or network details.

Can a Blockchain Hash Replace the Swap ID?

A blockchain hash cannot replace the order ID in Changelly Exchange API v2 status requests, although it remains useful payment evidence for support. The API’s getStatus method expects the exchange transaction ID, and its transaction lookup does not offer hash-based retrieval. An explorer search answers a narrower question about the blockchain transfer. If the order ID is missing, explain that in the support request and provide the available transfer details. Support asks for the exchange ID alongside the transfer hash when investigating an unrecognized payment, because the records describe different objects.

View image file

Payout Hashes and Recipient Records

A payout hash identifies the outbound blockchain transaction, which is the relevant transfer when the exchanged asset appears missing. Changelly’s Sending status describes the outbound stage, while Finished reports successful sending to the recipient address. The payout transaction’s own status and recipient details provide the blockchain context behind those exchange labels. An incoming deposit hash cannot supply that context, even when it shows a fully confirmed payment.

Blockchain Transfer Details

The payout record must identify the transferred asset and destination, because a transaction page can contain more than its headline value.

Native Asset Transfers

A native asset transfer moves the blockchain’s own currency. Its transaction record shows the destination and transferred amount, subject to the network’s transaction format. Read the payment to the intended address rather than assuming every amount displayed belongs to the recipient. The transaction fee describes a separate cost and does not represent an additional payment received.

Contract Token Transfers

A contract token transfer can involve a transaction addressed to the token contract rather than directly to the recipient. The explorer’s token transfer details identify the token movement and recipient address. On networks with this structure, a headline native currency value can differ from the amount of tokens transferred.

Wallet Displays and Account Credits

A wallet display may lag behind a valid transfer because the wallet needs to synchronize or update its transaction data. A receiving service can also apply its own deposit-crediting requirements before an account balance changes. These account records differ from the blockchain transaction itself. A successful payout to the intended address establishes the transfer, while an absent account credit needs assessment by the receiving provider. Its accepted asset, network and required routing information determine whether that transfer qualifies for credit.

Missing Hashes and Order States

An order ID can exist before any payment, so an order without a deposit hash does not establish a failed exchange. Successful order creation supplies the tracking reference and payment instructions. It does not show a funded deposit or an executed payout. Similarly, an unavailable payout hash prevents a direct lookup by that identifier; the order’s status provides the context for that absence. Waiting, Confirming and Exchanging describe different stages before successful outbound sending.

A blank field differs from a hash an explorer cannot find. The latter requires checking the full identifier and matching network, then determining whether the transfer has actually reached that network. An empty search result alone does not establish the exchange’s final outcome. A support request should distinguish between a missing hash and an existing hash with no matching explorer result.

API Fields and Request Correlation

Changelly Exchange API v2 separates the exchange reference from transfer hashes, so integrations need to preserve each field’s actual meaning.

Swap References and Transfer Fields

The exchange transaction object’s id identifies the swap. The API exposes separate payinHash and payoutHash fields for deposit and payout transactions. The getTransactions method supplies transaction details, while getStatus returns the exchange’s status. Keeping the swap reference beside each transfer hash lets an integration present both the exchange state and the relevant blockchain record without confusing their functions.

JSON-RPC Request IDs

The outer JSON-RPC id correlates an API request with its response. It belongs to the message exchange between client and server. The order ID returned inside a transaction result belongs to the swap. In a status request, the swap reference goes inside the method parameters. Matching an outer request ID to a response therefore confirms message correlation; it does not identify a blockchain transaction or establish swap completion.

Refund Hashes and Return Destinations

A refund hash identifies a return transfer of the input asset, distinct from a payout of the asset requested in the swap. The Exchange API exposes refundHash for that record. Its refund address and any required additional identifier specify the return destination. That destination must accept the input currency and can differ from the recipient address for the exchanged output. Refund eligibility, an agreed return amount and a completed return transfer describe different states. Support provides the refund amount and expected processing information for the actual case. A refund request or processing estimate does not establish an executed blockchain payment. Network-mismatch recovery still needs its own support assessment.

View image file

Memos and Tags Alongside Swap IDs

A memo or destination tag supplies routing information for a payment, whereas the swap ID identifies the exchange order. These values have different jobs even when an interface calls the memo or tag an additional ID. The required payment instructions determine whether a memo or tag belongs with a deposit address. In the Exchange API, a returned non-null payinExtraId means the deposit needs that additional identifier. For these API deposits, omitting it prevents processing and requires a refund through technical support. Copying the swap ID into that field would supply the wrong information.

Routing details also matter at the receiving end. A payout hash cannot assign funds to an account when the transfer lacks the memo or tag the receiving provider requires.

Support Requests and Transaction Privacy

A useful support request identifies the affected transfer and includes the swap ID, relevant hash and network without exposing wallet credentials. Describe whether the problem concerns deposit recognition, outbound delivery or a refund. Include the actual asset and amount alongside the order status. Distinguish the amount sent into the swap from the output amount expected at the recipient.

Keep complete identifiers in a private support conversation rather than relying on a screenshot with truncated text. A transaction screenshot can show the status and time alongside the relevant transfer details. Crop unrelated account information and keep recovery phrases, private keys and passwords out of the material. Those secrets control access to funds; a transaction identifier describes a record and does not authorize spending.

Public blockchain hashes can expose the participating addresses and their visible activity. Posting a hash together with a name or account screenshot can connect that activity to a person. Share only the details the investigation requires, using the service’s established support interface. The order ID helps locate the exchange record without requiring a public post containing the full payment history.

Recipient Amounts and Transfer Context

A recipient’s received amount belongs to the output asset, so the deposit quantity is not a direct measure of payout delivery. The Exchange API distinguishes an expected output amount from the actual amount sent after processing. In its floating-rate order creation response, amountExpectedTo describes expected output before the network fee. Transaction details use amountTo for the actual amount sent to the payout address. Compare like units and the recipient’s transfer amount, rather than the transaction’s overall value or initial quote. For a token payout, the relevant transfer entry supplies the recipient amount. The exchange record’s amountTo should describe the same payout as the transfer identified by payoutHash.