Why a TON deposit address can have two friendly spellings
A support ticket shows different strings for the address displayed at checkout and the one printed by a wallet. Decode both before deciding whether the customer sent to another account.
Separate recipient identity from delivery flags
Run this example in a project with @ton/core. Each iteration prints a different friendly address and the value true. Both wrappers carry the same workchain and account ID. The bounceable flag tells a wallet how to construct the transfer. It does not create a second account.
import { Address } from "@ton/core";
const a = Address.parseRaw("0:" + "12".repeat(32));
for (const bounceable of [true, false]) {
const encoded = a.toString({ bounceable, testOnly: false });
console.log(encoded, Address.parseFriendly(encoded).address.equals(a));
}
Keep both pieces when importing addresses
To match deposits, compare parsed identities within the selected network. To initiate a payment, retain the user's original flags and apply the network check, including the test-only flag. Deduplicating rows by a normalized address is useful for accounting, but regenerating every outgoing link from that key with default flags can change the intended delivery behavior.