A missing jetton deposit can be a missing-notification problem even when the tokens reached the service's jetton wallet. In the standard flow, forward_ton_amount controls the native amount attached to a transfer notification; a zero value means that notification is not sent. Verify the token receipt and message trace, then ask the receiving service how it handles that case before sending again.
Follow the token leg and the notification leg separately
The token transfer changes the balance at the recipient's jetton-wallet contract. A notification is a separate message toward the owner or service account. An automated deposit system may watch that message to recognize and allocate a receipt. If the message is absent, the service's expected trigger can be missing without making the token movement imaginary.
The jetton standard explicitly distinguishes a transferred token amount from forward_ton_amount and states that zero suppresses the notification. This is why a success badge on an earlier step cannot answer the entire crediting question. It is also why an attached native-currency amount should not be read as the number of tokens received.
Do not infer the service's implementation solely from this explanation. Some receivers use other deposit-processing arrangements. The TON payment-processing guide discusses a notification-based workflow and recommends notification-compatible sending. That integration guidance should not be turned into the broader claim that every token transfer without a notification failed to move tokens.
Build a trace with one row per event
| Stage or field | Evidence to record | Question it resolves |
|---|---|---|
| Expected token master | The legitimate asset identifier | Was the intended jetton involved? |
| Receiving token wallet | Verified link to the service owner and master | Did the token leg reach the expected holding? |
| Token amount | The amount in the receiving token movement | How many jettons were actually delivered? |
| forward_ton_amount | The native value specified for forwarding | Was a notification requested under this flow? |
| transfer_notification | Presence, sender and result of that message | Did the service receive the expected trigger? |
| forward_payload | Routing data expected by the receiving service | Could the service associate the deposit? |
| Service account entry | The receiver's internal record | Was the verified receipt credited to this order? |
Use a trusted explorer and follow the message tree instead of copying only the sender's overview. The official explorer guide describes checking receiving execution and resulting state. Keep execution failures or bounces in the record. A requested notification and a successfully delivered notification are not the same piece of evidence.
A nonzero forwarding amount is not the whole fee budget
The forwarded native amount serves a different role from the jetton quantity. The transfer also needs sufficient attached native value for its processing, including relevant contract activity. Do not replace the complete transfer estimate with a tiny forwarding amount from a technical example. Conversely, increasing an unrelated fee field does not prove that the wallet encoded the required notification setting.
The receiving service may publish requirements that the sending wallet normally handles. Follow those instructions through an officially supported sending flow. If your app exposes advanced fields, check their documented units and effect before changing them. Do not edit a raw payload from an online comment just because the field name contains TON.
A deposit comment is another separate element. Notification delivery without the required order routing data may still leave allocation unresolved. Adding text somewhere else in the sending wallet does not prove it became the forward_payload expected by the service. Preserve the original instructions and compare them with the actual message body rather than a screenshot of the draft.
Two fictional deposits show why the distinction matters
Imagine Deposit Aspen and Deposit Cedar, each intended to deliver 20 units of the same verified jetton to a service. Aspen's token wallet receipt exists, but the relevant forwarding value is zero and no notification appears. Cedar's notification exists, but its order reference does not match the intended order. These illustrative cases can both show an uncredited service balance, yet they require different investigation.
For Aspen, ask whether the receiver can recognize the already delivered token receipt under its procedures. For Cedar, investigate allocation and the actual routing payload. Neither case is solved by assuming that an additional 20-unit transfer will repair the record. A repeat could create another unresolved receipt or a duplicate payment.
Sending native coins afterward is not a retroactive edit of the original jetton instruction. It creates another operation and does not automatically recreate the missing message with its original context. If a verified service proposes a recovery procedure, obtain the details and scope from its official channel. Do not interpret an unsolicited top-up demand as evidence that the process is legitimate.
Ask support a specific crediting question
- Save the order reference, original sending record, expected token master and receiving owner address.
- Verify the receiving jetton-wallet relationship and actual token receipt first.
- Locate the notification leg, its forwarding amount and any execution error; record an absent notification explicitly.
- Compare the routing payload with the original receiving instructions.
- Ask the official service whether it recognizes this receipt and what its supported review or recovery process is.
- Keep any proposed cost or further transaction separate from the evidence; do not send again until the existing receipt is accounted for.
A useful message says that the verified token receipt exists, names the trace, and states whether the notification is missing or failed. It does not merely insist that the sender screen says success. Support can then distinguish a chain-execution issue, a notification requirement and internal account allocation. The receiver controls its own crediting process, so manual recovery and its timing should not be promised.
Read USDT on TON and deposit comments for the separate routing requirement. The exchange workflow describes the service-level order process. For a no-account swap, follow the actual order instructions; this protocol explanation does not disclose or certify that order's internal deposit-monitoring implementation. Establish what was delivered before deciding whether another transaction is appropriate.
FAQ
What is a jetton transfer notification used for?
It is a separate message that a receiving application may use to detect and process a token receipt. Its existence and successful handling should be checked separately from the token movement.
Is the TON value forwarded in a jetton transfer the token amount?
No; forward_ton_amount concerns native value attached to the notification flow. The jetton quantity and the overall processing budget are separate values.
Does another jetton transfer fix an uncredited deposit?
Not automatically; it creates another transfer rather than editing the first. Ask the official receiver to account for the existing receipt before sending again.