Signs a payment page is not the seller's own

A payment page is the one screen in an online purchase where being wrong is expensive. It is also, unhelpfully, the screen that is easiest to imitate. The visual layer of any website can be copied in a few minutes by someone with no particular skill, which means everything that makes a checkout feel familiar — the logo, the fonts, the wording, the little card-brand icons in a row — is exactly the part that proves nothing.

What follows is the short list of things that cannot be copied that easily, and the order to check them in.

Why a copied checkout works at all

People do not read payment pages. They recognise them. After a few hundred online purchases the brain has built a template — a box for the long number, a smaller box for the expiry, a total in bold, a button on the right — and a page that matches the template gets waved through without conscious inspection.

That reflex is normally useful, and it is the exact mechanism a copied checkout exploits. Nothing on the page needs to be convincing on close reading, because close reading is not what happens. It needs to survive two seconds.

Which is why the checks below are deliberately mechanical. They are not judgements about whether a page looks trustworthy. They are three or four factual questions with yes or no answers, because a feeling of trust is precisely the thing being manufactured.

The address bar is the whole test

Read the domain from right to left, starting at the last slash and working backwards to the first dot before it. That fragment — the two or three words immediately before the first single slash — is the only part that identifies who owns the page. Everything to the left of it can be set to anything at all.

This matters because the common trick is to put the real name somewhere it looks right but carries no weight: as a subdomain, as a folder, or as a query string. A page whose address begins with a seller's name and ends on an unrelated domain belongs to the unrelated domain.

The fifth row is the one that catches careful people. A doubled letter, a capital I standing in for a lowercase L, a hyphen inserted or removed — these are invisible at a glance and completely decisive. If a payment page arrived from anywhere other than your own typing, put the cursor in the address bar and read the domain character by character once. It takes four seconds.

How you arrived at the page

The address is the strongest signal. The second strongest is the route, and it is worth more than most people give it credit for, because the route is what determines whether you had any control over where you ended up.

You typed the seller's domain yourself and navigated to the checkout. Strong position. There is no interception point.

You clicked a link in a thread you started with the seller. Ordinary and fine, provided the thread really is the one you opened. This is how the majority of small-seller purchases work, including ours.

A payment request arrived unprompted. An email, a message from an unfamiliar number, a notification about a subscription you do not remember starting. Treat every one of these as untrusted regardless of how correct it looks. An unrequested payment request is the single most common opening move in payment fraud, and its whole design is to make the address bar irrelevant by getting you to a page you did not choose.

A useful rule that costs nothing: never pay from a link that arrived. Note what the message wants, close it, reach the seller through a route you already had, and ask whether the request was theirs. If it was, you lose forty seconds. If it was not, you have just avoided the entire problem.

What the padlock actually proves

It proves that the connection between your browser and that server is encrypted. That is genuinely useful — it means nobody sitting on the same network can read the card number as it travels — and it is also the entire scope of the claim.

It does not say who owns the server, whether they are trading honestly, or whether the goods exist. Certificates are free, automated and issued in minutes with no examination of the operator, so a page built specifically to harvest card numbers has one too. Treating the padlock as a safety verdict is the most widespread misunderstanding in consumer payments, and it has outlived every attempt to correct it.

The inverse is still worth acting on. A payment page served without encryption at all is disqualifying, no explanation required — that failure sits alongside the other structural warnings described in why a seller who only accepts irreversible payment is telling you something.

What the page is asking for

A card payment is a small, fixed set of fields. Number, expiry, security code, name, billing address, and in many cases a step-up authentication prompt handled by your own bank. That is the complete list.

So the fields themselves are evidence. Anything on this list has no role in taking a single payment, and its presence means the page is collecting material for a second purpose:

• A password for an account — email, streaming, anything. No checkout needs one.
• The one-time code your bank has just sent you, typed into the page rather than into your banking app.
• A photograph of the card, or of the card next to your face.
• A full date of birth, a national insurance or social security number, or a passport scan.
• Your online banking sign-in, presented as "verification".
• A second card "to confirm the first one".

The one-time code deserves emphasis because it defeats the protection it is supposed to provide. That code exists so your bank can confirm the payment with you directly. Typed into a page that then relays it, it authorises whatever the other side is doing at that moment. No genuine checkout asks you to hand it over; the prompt comes from your bank's own app or page. The wider list of what a seller legitimately needs is in what a seller legitimately needs to know about you.

The amount, the currency and the descriptor

Three numbers on the page should reconcile with three things you already know, and it takes ten seconds to check.

The amount. It should match what was quoted, exactly. A figure a few units higher is sometimes a legitimate cross-border cost, but that belongs on your bank's side of the transaction rather than added silently to a checkout total — the mechanics of which are in foreign transaction fees on a yearly subscription.

The currency. A page that has quietly switched from the currency you were quoted to another one, without saying so, is either poorly built or converting at a rate that favours somebody who is not you. What happens when the currencies genuinely differ is covered in paying for a subscription in a currency that is not your own.

The descriptor. This is the name that will appear on your statement, and a good checkout tells you what it will be. A mismatch is not automatically sinister — many small sellers bill under a processor's name — but a descriptor you cannot connect to anything makes a later dispute considerably harder to explain, and it is worth asking about before rather than after.

When a third-party page is entirely normal

None of this means a payment page on someone else's domain is a problem. For most small sellers it is the correct arrangement, and it is safer than the alternative.

Building and maintaining a card form means holding card data, and a small operation should not be doing that. Handing the payment step to an established processor keeps the numbers away from the seller entirely. So a checkout that sits on a well-known payment company's domain, that you can look up independently, and that the seller told you to expect, is functioning exactly as designed.

The distinction is between a recognised payment brand and an unfamiliar domain that is neither the seller nor anything you can identify. The first is infrastructure. The second is a question with no answer.

We took the argument one step further and removed the form entirely; the reasoning is in why there is no checkout button on this site. A page that does not exist cannot be copied, and a seller who never sends unsolicited payment requests gives you a simple rule for spotting one that claims to be from them.

What to do when something is off

Do not try to resolve it on the page. Studying a suspicious checkout more closely is the wrong response, because the page is the thing you cannot trust and no amount of looking at it changes that.

Close it. Go to the seller by a route you control — the domain you typed before, the thread you opened, the address on your last receipt. Ask whether the request came from them, and quote the amount and the address you saw. That is a forty-second exchange that resolves the question completely, and no legitimate seller is annoyed by it. Ours is on the contact page, and our prices are published in full on the pricing page so that any figure quoted to you can be checked against a public one before you pay anything.

If you have already entered a card, act rather than deliberate. Call your bank on the number printed on the card — not one supplied by any message — say the card may be compromised, and ask for it to be blocked and reissued. Then change any password you typed. The cost of doing this unnecessarily is a few days without a card. The cost of not doing it when it was necessary is considerably higher, and unlike most decisions in this article, it gets worse with delay.