When a TON transfer appears to bounce back, follow the original message to the failed destination processing and then locate the return message. Do not assume that the full sent value returned to the account you are viewing. A successful sender-side transaction can coexist with a failed downstream payment, and a service's outgoing wallet may be the return destination rather than your personal balance.
Read the transfer as connected events
Open the original operation through a trusted explorer and inspect its trace. TON's trace documentation describes causally related messages and transactions that can span accounts and blocks. The sender's wallet transaction is one event, not a complete verdict on every later event. Follow the outgoing message's destination and the receiving transaction instead of stopping at the first green status.
Record the original message reference, source, destination and attached native value. Then inspect the destination's result and any outgoing return message. Explorer summaries are interpretations, and a trace can be incomplete while related data is unavailable to its indexer. If the return is not visible, distinguish 'not located yet' from a proven absence; neither state justifies automatically paying again.
Five observations that establish a return
| Trace evidence | Question it answers | What remains to verify |
|---|---|---|
| Sender's outgoing message | What was sent and from which account? | Destination processing |
| Destination transaction result | Did the recipient-side execution fail? | Whether a bounce was generated |
| Message marked bounced | Is this a protocol return message? | Its destination and value |
| Return destination | Which account receives the return? | Whether you or a sending service controls it |
| Receiving event and balance evidence | Was the returned value processed there? | Any service-side account crediting |
The official internal-message reference distinguishes bounce, the flag permitting bounce behavior, from bounced, the indication that a message is a return. A permitted bounce is not proof that a return actually occurred. The conditions include handling failure and sufficient value for the return. Current documentation also describes more than one bounce-body format, so the old body prefix alone is not a universal detection rule.
Why an inactive destination can be involved
An address can identify an account whose wallet contract is not deployed. TON's account-status explanation distinguishes nonexist, uninit and active states. Whether a particular incoming message deploys a contract, leaves funds or bounces depends on its initialization data, value and handling. An app's informal Inactive label is therefore a clue, not a complete diagnosis of the message you sent.
Check the account state at the time of the receiving transaction, not just its state today. The owner may have deployed the wallet after your attempt. A later Active status cannot prove the earlier message succeeded. Likewise, changing to a non-bounceable form is not a universal repair for every contract interaction. Preserve the receiving service's exact instructions and ask about the failed attempt before changing message behavior.
Returned value and the original debit need separate arithmetic
A bounce is not a promise of a full refund. TON execution has processing and forwarding costs, described in the execution-phase reference. Reconcile the actual outgoing and return values with the trace and balance effects instead of subtracting one headline amount from another. Wallet interfaces can present the original debit, attached message value and resulting account change differently.
For a fictional record, let the original message be M1 and the returned message be B1. Record the value attached to M1, the value carried by B1, the sender's relevant account events and any visible costs. These labels deliberately contain no invented fee or return deadline. The task is to explain the difference using the actual record, not to assume a fixed percentage or add money until the wallet appears whole again.
Also identify the asset. Native value attached to a message is not automatically the amount of a jetton transfer. A jetton operation can contain several contract interactions, so a small native-value return is not by itself proof that all tokens returned. The native coin and token guide explains the distinction; the USDT-on-TON article covers token-specific receiving context. Do not apply a native-transfer reconciliation blindly to a token payment.
A service-originated return may need the service's reconciliation
Suppose you requested a withdrawal from a custodial platform and its wallet sent the failed message. The protocol return can go to that sending account, not directly to your individual platform balance. Finding the return onchain is useful evidence, but it does not prove when the platform credited your ledger. Keep the withdrawal reference alongside both directions of the trace.
Contact the original sender through its official support channel with the original withdrawal, failed destination event and return reference. Ask it to reconcile the returned value rather than claiming that the recipient kept funds merely because your personal balance has not changed. Do not promise a universal recovery result: the sending account's control and the service's records determine what it can investigate.
- Save the original sending record and open the corresponding TON trace.
- Follow the outgoing message to its destination and inspect the receiving result.
- Identify an actual bounced return, distinguishing the two message flags.
- Verify the return's destination and attached value, then its receiving evidence.
- Separate native value from any jetton movements and reconcile relevant fees.
- If a platform was the sender, submit the connected records for ledger reconciliation before requesting another withdrawal.
Retry only after the first outcome is understood
Before another no-account swap, recheck the current order's destination, network, asset and any required comment. Do not manually edit address prefixes based on a failed attempt or assume the prior order remains valid after a return. Keep the trace evidence and confirm the receiving instructions. A useful final note states where the first message failed, whether a return was found, where its value went, and which service-side question remains open.
FAQ
Does a TON bounceable address mean the transfer already returned?
No, bounceable describes permitted message behavior. An actual return needs its own bounced-message and receiving evidence.
Why can Tonkeeper show a failed transaction after I sent funds?
Inspect the connected message trace rather than a single wallet label. Sender-side submission, destination execution and any returned value are different parts of the operation.
Which Tonkeeper transaction hash should I keep for a bounced transfer?
Keep the original record and the related failed and returning events with their roles labelled. One unexplained hash may omit the leg that support needs to reconcile.