TON bounceable vs non-bounceable address (EQ and UQ)
A bounceable TON address tells the network to return funds if the destination contract cannot accept them; a non-bounceable one does not.
On TON one account can be written in several ways. The raw form is the workchain and a hex hash, such as 0:… The user-friendly form is a Base64 string that also contains flags and a checksum. Two of these forms matter most: bounceable, which usually starts with EQ, and non-bounceable, which usually starts with UQ. Both point to the same account; only the flag differs. There are also testnet variants.
The flag affects what happens if a message fails. Every transfer on TON is a message to a smart contract. If the message is sent as bounceable and the destination contract does not exist or throws an error, the funds bounce back to the sender, minus fees. If it is sent as non-bounceable, the funds stay at the destination even if no contract is deployed there yet.
This is why wallets now show non-bounceable (UQ) addresses for regular user wallets by default. A new wallet that has never sent a transaction is not yet initialised on-chain. Sending to it with the bounce flag would make the transfer bounce back; sending without it delivers the funds, and the wallet is deployed when the owner first sends something. Bounceable addresses are recommended for smart contracts that are already deployed, so mistakes return money instead of losing it.
For merchants and developers, the main rules are: compare addresses by their raw form, not by the string, since EQ and UQ versions of one account look completely different; do not reject a payment because the customer used the other form; and use a proper TON library to parse and normalise addresses.
Moonvex accepts TON and USDT on TON and gives each payment its own address, so the payment is identified by the address and no comment is required.