TON payment troubleshooting requires looking at the receiving account, not just copying the first hash shown by the sender. Address representations and message-based transactions can make a valid-looking reference insufficient to identify the native transfer expected by a merchant invoice.
Preserve the receiving address representation
TON has raw and user-friendly address formats. Friendly forms can encode bounce behavior and testnet-related flags as well as a checksum. A merchant should use compatible wallet tooling to validate addresses, rather than editing prefixes to make them look familiar.
For example, two displayed addresses can represent the same account with different flags. Conversely, a short visual comparison can miss a real account difference. Checkout and verification should normalize addresses correctly while preserving safe customer-facing instructions. The buyer should copy from the current checkout rather than an old chat message.
Understand sender and recipient transactions
TON uses messages between accounts. The sender-side transaction reference and the receiving account’s transaction reference can differ. Coinvay’s native TON verification expects the recipient transaction associated with the configured receiving address.
If a buyer says the payment was sent but manual verification cannot locate it, find the receiving account in a suitable explorer and inspect the incoming transfer. Do not repeatedly paste unrelated sender-stage hashes or change invoice state simply because the sender’s wallet shows an outbound action.
Check successful receipt, not just activity
A bounced, aborted or otherwise unsuccessful attempt is not the same as an accepted payment. Coinvay checks finalized recipient-side evidence, the expected native amount and the quote window. Its configured route does not reconcile arbitrary jettons based on a matching display name.
Support records should include the invoice reference, network, receiving address and correct transaction reference. Avoid exposing private customer details in public notes. A plain explanation of why the recipient hash matters is usually more helpful than asking a customer to resend before investigating the first attempt.
Practical checklist
- Keep address flags and checksums intact.
- Inspect the receiving account’s incoming transaction.
- Reject bounced or unsuccessful evidence and verify the native amount.
Common questions
Why does the hash in my sending wallet differ from another explorer reference?+
The transfer can involve different account transactions connected by messages. Identify the recipient-side transaction required by the verifier rather than assuming every displayed reference is interchangeable.
Does the interface label Gram change how addresses work?+
No. Coinvay’s current label maps to the native TON route. It does not change the underlying network, address formats or requirement to verify the expected native transfer.
Sources and further reading
Primary references and Coinvay product documentation. Check the linked pages for current details.
AI-assisted drafting, published by Coinvay. Examples are illustrative. Read our editorial approach.