Validating a USDT address before you send: TRON checksums vs EVM addresses

ZikCards — Tue, 20 Oct 2026 20:43:22 +0000

Crypto transfers cannot be reversed. If a user pastes the wrong address, or the right address on the wrong network, the money is usually gone. If your app takes a USDT address from a user, a few checks in the form catch most of these mistakes before anything is sent.

Two very different address formats

USDT exists on several networks, and their addresses look nothing alike:

TRON (TRC-20): starts with T, 34 characters, base58 encoded, with a built-in checksum.
EVM networks (Ethereum, BNB Smart Chain, Polygon): start with 0x, followed by 40 hexadecimal characters.

That difference is useful: a TRON address can never pass as an EVM address, and the other way round. So the first check is simply "does this address belong to the network the user picked?"

TRON: decode and verify the checksum

A TRON address is base58check: decode it and you get 25 bytes.

The first byte must be 0x41, the TRON mainnet prefix.
The last 4 bytes are a checksum: the first 4 bytes of SHA-256 applied twice to the first 21 bytes.
If the checksum does not match, the address has a typo.

The checksum is what makes this strong: change one character in a valid TRON address and the check almost always fails. Length and prefix checks alone would miss that.

EVM: format first, then the optional checksum

For 0x addresses the minimum check is the format: 0x plus exactly 40 hex characters.

On top of that, EIP-55 defines a checksum written into the letter case: in a mixed-case address, each letter is upper or lower case depending on the Keccak-256 hash of the lowercase address. So:

an all-lowercase or all-uppercase address carries no checksum, and you can only check its format;
a mixed-case address that fails EIP-55 contains a typo, so reject it.

The mistake no validator can catch

Ethereum, BNB Smart Chain and Polygon use the same address format. The same string is valid on all three, and often it is even the same wallet. So no code can tell whether a user meant BNB Smart Chain or Ethereum.

What helps instead:

show the selected network prominently next to the address field;
ask the user to confirm the network with a checkbox, enforced on the server, not just in the browser;
store the network with the transaction, so support can see what was chosen.

Try it

I built a free checker that does all of the above in the browser: TRON base58 checksum validation, EVM format and EIP-55 checks, and a warning when the address belongs to a different network than the one selected: https://zikcards.com/tools/usdt-address-checker

If you are not sure which network to use in the first place, this short answer compares the fees and speed of each: https://zikcards.com/faq/which-network-should-i-send-usdt-on

I am the founder of ZikCards, which issues US Visa and Mastercard virtual cards funded with USDT or USDC. The checker is free and needs no sign-up.

What the first digits of a card number tell you (BIN basics for developers)

ZikCards — Sat, 10 Oct 2026 11:56:57 +0000

If you have ever built a checkout form, you have probably shown a Visa or Mastercard logo as the user types. That logo comes from the first few digits of the card number: the BIN, or Bank Identification Number. This post covers what a BIN tells you, how to detect the brand and validate a number in a few lines of JavaScript, and what you are allowed to keep.

What a BIN is

The first 6 to 8 digits of a card number identify the institution that issued it. The standard (ISO/IEC 7812) calls it the IIN, Issuer Identification Number; the payments industry still says BIN. Since 2022, Visa and Mastercard allocate 8-digit BINs, so code that assumes exactly 6 digits will slowly get less accurate.

A BIN lookup can tell you:

Network: Visa, Mastercard, American Express, Discover, JCB, UnionPay
Issuer: the bank or card programme
Country where the card was issued
Type: credit, debit or prepaid
Level: for example classic, gold, business

What it can't tell you: the cardholder, the balance, or whether a payment will succeed.

Detecting the brand

The first digit narrows it down; a few more settle it. The common ranges:

Network	Starts with	Length
Visa	4	16 (also 13, 19)
Mastercard	51–55, 2221–2720	16
American Express	34, 37	15
Discover	6011, 644–649, 65	16–19
JCB	3528–3589	16–19
UnionPay	62	16–19
Diners Club	36, 300–305	14–19

Ranges overlap in places, so check the most specific prefix first:

function cardBrand(number) {
  const n = number.replace(/\D/g, '');
  const p = (len) => Number(n.slice(0, len));

  if (/^3[47]/.test(n)) return 'amex';
  if (/^(36|30[0-5])/.test(n)) return 'diners';
  if (p(4) >= 3528 && p(4) <= 3589) return 'jcb';
  if (/^(6011|64[4-9]|65)/.test(n)) return 'discover';
  if (/^62/.test(n)) return 'unionpay';
  if (/^5[1-5]/.test(n) || (p(4) >= 2221 && p(4) <= 2720)) return 'mastercard';
  if (/^4/.test(n)) return 'visa';
  return 'unknown';
}

This is enough for a logo. For anything that matters (fraud rules, routing, telling credit from debit), use a BIN database, because the type and country can't be read from the digits alone.

Catching typos with the Luhn check

The last digit of a card number is a check digit. The Luhn algorithm catches any single mistyped digit and most swapped neighbours, so you can tell the user before the payment provider does:

function luhnValid(number) {
  const digits = number.replace(/\D/g, '');
  if (digits.length < 12 || digits.length > 19) return false;

  let sum = 0;
  let double = false;
  for (let i = digits.length - 1; i >= 0; i--) {
    let d = Number(digits[i]);
    if (double) {
      d *= 2;
      if (d > 9) d -= 9;
    }
    sum += d;
    double = !double;
  }
  return sum % 10 === 0;
}

luhnValid('4242 4242 4242 4242'); // true  (a well-known test number)
luhnValid('4242 4242 4242 4241'); // false

A number that passes Luhn is only well-formed. It says nothing about whether the card exists.

What you may store

Under PCI DSS you must never store the CVV, and you shouldn't keep the full card number unless you are set up to protect it. The BIN and the last four digits are the usual "safe" pair for receipts, support and fraud rules. Check the PCI Security Standards Council's current truncation guidance for how many leading digits are allowed now that BINs are 8 digits long.

If you take payments through a hosted field or iframe (Stripe Elements and similar), the full number never reaches your server at all. That is the simplest way to stay out of most of PCI's scope.

Testing without real cards

Payment providers publish test numbers that pass Luhn and trigger specific results (approved, declined, 3D Secure challenge). Use those in development and CI, never a real card.

Tools if you just need an answer

I work on ZikCards, and we keep a few free tools for exactly these questions. No sign-up:

BIN lookup: network, issuer, country and type for the first digits
Card brand checker: which network a number belongs to
Test card numbers: sandbox numbers by provider

What's the oddest card-number edge case you've hit in a checkout form?

DEV Community: ZikCards