A convincing fake costs nothing to build. Logos, fonts, layout and even the padlock in the address bar can all be copied in an afternoon. The one thing an attacker cannot copy is the domain name, which is why every reliable check comes back to reading the URL correctly.
Adult subscriptions attract this attack for a specific reason: the target is unlikely to phone customer support, forward the email to a colleague, or make noise about it afterwards. Discretion is the leverage. Recognising that the embarrassment is part of the attack design is itself a defence.
How do you read a URL correctly?
Read from the right, not the left. The domain that matters is the label immediately before the top-level domain.
Everything to the left of that can be chosen freely by whoever controls the domain, including words that look reassuring:
| URL as displayed | Registered domain | Verdict |
|---|---|---|
account.example.com/billing |
example.com |
Belongs to example.com |
example.com.billing-secure.xyz |
billing-secure.xyz |
Attacker's domain |
example-billing.com |
example-billing.com |
Different domain entirely |
examp1e.com |
examp1e.com |
Homoglyph — digit one for the letter l |
example.com@evil.tld/pay |
evil.tld |
Everything before @ is ignored |
Two additional traps. Internationalised domains can render Cyrillic or Greek
characters that are visually identical to Latin ones; browsers usually display
these as xn-- punycode, so an address bar showing xn-- on a familiar brand
is a definite fake. And on mobile, the address bar truncates — tap it to expand
the full URL before judging anything.
Where should the card form actually live?
On a page you did not navigate to yourself, it should not exist at all.
Most legitimate merchants do not want to touch your card number, because handling it directly imposes a much heavier compliance burden. They either redirect you to a payment processor's own domain, or embed the card fields in an iframe served by the processor. Either way, the number is entered into the processor's page, not the merchant's.
The practical checks:
- Did you start this? A billing page you reached by clicking a link in an email is a different thing from one you reached by typing the site's address and logging in. Only the second is verifiable.
- Does the site already have your card? Existing subscribers are almost never asked to re-key a full card number. "Please re-confirm your payment details" is one of the strongest single indicators of a fake.
- Does the form ask for more than a payment needs? Card number, expiry, CVC and postcode are a payment. Adding date of birth, ID number, account password, mother's maiden name or a photo of the card is credential harvesting.
- Does the CVC request repeat? A genuine flow asks once.
Which signals separate a fake from a real billing page?
Compare against what the legitimate version does, rather than looking for mistakes — modern fakes have very few.
| Signal | Phishing page | Legitimate page |
|---|---|---|
| How you arrived | Link in an email, DM or ad | You typed the address and signed in |
| Domain | Lookalike, hyphenated or unrelated | The site's own registered domain |
| Tone | Deadline, suspension threat, "final notice" | Neutral, no countdown |
| Data requested | Card plus password plus identity documents | Card fields only |
| Card entry | Fields hosted on the same page | Processor domain or processor iframe |
| Support route | Phone number or chat link on the page itself | Contact route inside your logged-in account |
| Login state | Asks you to sign in again to "verify" | You are already signed in |
| Language | Small grammatical drift, inconsistent currency | Consistent with the rest of the site |
What about emails claiming they have footage of you?
Treat sextortion mail as spam with a threat attached. The standard version quotes a password you recognise — taken from an old breach list, not from your device — and claims to have webcam recordings.
The tell is that these messages never contain the material, because it does not exist. They contain a password, a deadline and a wallet address. If a real attacker had genuine footage, the first message would include a frame of it.
The correct response is to pay nothing, reply to nothing, and change any account still using the quoted password. Paying identifies you as someone who pays and reliably produces a second demand.
What if you already entered your details?
Order matters more than speed here, though both help.
| Step | Why it comes where it does |
|---|---|
| 1. Call your card issuer on the number on the card | Blocking the number stops the loss; never use a number from the suspicious page or email |
| 2. Change the password you entered, on the real site | Assume the credentials were captured the moment you submitted them |
| 3. Change that password anywhere else you reused it | Credential stuffing against other services follows within hours |
| 4. Sign out all sessions in the real account | A stolen session token survives a password change on some platforms |
| 5. Check account recovery settings | Attackers add a recovery email or phone to retain access |
| 6. Review statements for small test charges | Card testing precedes the real charge |
One deliberate omission: do not respond by installing a "security" tool the page or email recommends. That is a recognised second stage of the same attack, and it converts a card problem into a device problem.