A card payment made in a shop answers one question very efficiently: the card is here, and so is a PIN only the cardholder should know. Online, neither of those is available. There is no card in a terminal and no keypad, just a number typed into a form by somebody who may or may not be entitled to type it.
So the industry assembled three substitutes, added them one at a time over about twenty-five years, and gave none of them a name that explains what it does. They are the security code, the address verification check and the step-up authentication step. Each answers a different question, each fails in a different way, and only one of them actually verifies a person.
Three questions, three mechanisms
Set out side by side, the division of labour is clear.
| Check | The question it answers | What it cannot tell |
|---|---|---|
| Security code | Was the physical card in front of the typist? | Whether the typist owns the card |
| Address check | Does the typed address match the bank’s records? | Whether the typist is at that address |
| Step-up check | Did the cardholder approve this exact payment? | Whether the purchase is a good idea |
The first two verify data. The third verifies a human. That distinction explains almost everything about how the three behave, including why the third is the only one that changes who carries the loss.
The security code and what it proves
The three digits on the back of a card — four on the front, on some issuers — are printed and nothing else. They are not encoded in the magnetic stripe, they are not on the chip, and no seller is permitted to store them after a transaction. That prohibition is the entire basis of their usefulness.
The reasoning goes like this. If a database of card numbers is stolen from a retailer, it will not contain security codes, because keeping them is not allowed. A thief with that database can therefore reproduce a card number but not the code printed on the plastic. Requiring the code at checkout filters out exactly that category of fraud.
What it cannot do is anything else. It does not identify you. It does not prove ownership. A card taken from a wallet carries its own security code on the back, which makes the check completely ineffective against physical theft. And once the code has been written into a message, a note or a spreadsheet, it has been permanently downgraded from a proof of presence to just another string somebody could copy.
The security code only works because it exists in one place. Every time it is typed somewhere that keeps a record, that stops being true — and nobody tells the cardholder, because nobody knows.
The billing address check
The address verification check takes the numeric parts of what you type — usually the street number and the postcode — and compares them with what your issuer holds. It returns one of a few results: full match, partial match, no match, or not checked.
Two things about it surprise people. The first is that it is advisory. The result is returned to the seller's processor, which decides what to do with it; a partial match is often accepted, and a no-match sometimes is too if everything else looks fine. The second is that it is patchy internationally — the check is far more reliable between banks in some markets than others, and on some cross-border payments it simply is not performed.
The practical consequence is the one that catches travellers. The field wants the address your bank has on file, not the place you are standing. Entering a local address while abroad guarantees a mismatch and can convert a payment that would have cleared into one that does not, which is the most common self-inflicted failure described in paying while travelling or living outside your card’s home country.
The step-up check
This is the screen that interrupts a payment to send a code to your phone, or push a confirmation into a banking app. It appeared as a bolt-on years ago, was widely disliked for breaking checkouts, and has since been rebuilt into something mostly invisible.
Modern implementations run silently the majority of the time. The seller's processor passes a bundle of context to your issuer — the amount, the merchant, the device, the history — and the issuer decides whether it needs to interrupt you. If the picture is unremarkable, it approves without showing you anything. If something is unusual, you get the code screen.
That means the appearance of a step-up check is not a judgement about the seller. It is a judgement about the transaction, made by your own bank, and the most common triggers are an unfamiliar merchant, a larger-than-usual amount, or a purchase happening somewhere your card does not normally go. An annual subscription bought cross-border ticks all three, which is why it draws the check so often.
One failure mode matters more than the rest: the code has to reach you. If the number on file with the bank is old, disconnected or roaming badly, the check cannot be completed and the payment dies without ever explaining why. Checking that number is a two-minute job that prevents an entire class of unexplained refusals.
Who carries the loss when one fails
Underneath the security story is a commercial one, and it explains a lot of behaviour that otherwise looks arbitrary.
| Scenario | Who absorbs a fraudulent payment |
|---|---|
| No step-up check performed | Usually the seller |
| Step-up check completed by the cardholder | Usually the issuer |
| Step-up attempted, cardholder did not complete it | Payment does not proceed |
This is why sellers welcome a check that their customers find irritating: it moves the risk off them. It is also why some checkouts push you towards a route that carries the check and others do not bother. As a buyer, none of it changes your own position — your right to dispute an unauthorised payment is not reduced by a check having been skipped. What can be reduced is your position on a payment you did authorise and later regret, which is a different thing entirely and is set out in chargebacks: what a card network will and will not reverse.
Why a legitimate payment fails these checks
Perfectly honest payments fail all three regularly. The usual causes are mundane.
An address that has moved on. You updated the address with the post office and the utility company and not with the card issuer, so the check is measuring you against a house you left two years ago.
Autofill inserting the wrong thing. A browser fills the shipping address it learned somewhere else, and the mismatch is created by software rather than by you.
A code that cannot arrive. The step-up message is sent to a number that no longer works — the single largest cause of an unexplained failure among people who have moved countries.
A postcode in the wrong format. Cross-border checkouts sometimes reject or mangle a home-country postcode, and a mangled value fails the comparison.
Retrying too fast. Repeated attempts are themselves a fraud pattern, so the third attempt is scored worse than the first. The full order of operations for clearing a refusal is in bank declines on a foreign digital purchase.
How each one gets abused
Because these checks are half-understood, they make excellent cover stories. Three patterns are worth recognising on sight.
"We need to re-verify your security code." There is no such process. The code is used once, during the payment, on the payment page, and never stored. Anyone asking for it afterwards — in a chat, an email or a follow-up form — is collecting it, not verifying it. This is the clearest single fraud signal in online payments, and it works because the request sounds procedural.
"Forward us the code we just sent you." A step-up code is a message between you and your bank. It is not routed through a seller and no seller can use it. A request to forward one is an attempt to complete somebody else's payment with your authorisation.
A verification page that is not your bank's. A convincing imitation of a step-up screen, served from the seller's own domain, harvests the code directly. Checking where a payment page is actually hosted takes under two minutes, and the checks that matter are in signs a payment page is not the seller’s own.
The general rule underneath all three: a legitimate seller needs remarkably little information about you, and everything on the list is boring. The full boundary between reasonable and not is drawn in what a seller legitimately needs to know about you.
Where we sit in all of this
We do not run a card form, so none of these three checks happens on our side. There is no field on this site that has ever received a card number, a security code or a billing address, which is a deliberate choice rather than a missing feature — the reasoning is in why there is no checkout button on this site.
When you order, the payment happens on the processor's own page, where the security code goes directly to the people entitled to see it and any step-up check is a conversation between you and your bank that we never observe. Afterwards we know the amount, the date and a reference — enough to identify the payment and nothing more. What that leaves on your statement, and why it will not read as our brand name, is explained in what the descriptor on your statement is telling you.
Our plans are annual and one-time — $69, $97 and $137 a year for one, two and three simultaneous screens, published in full on the pricing page. No card is retained afterwards, so there is no stored instrument for any of these checks to protect twelve months later.
If anything that claims to come from us ever asks for a security code, a step-up code or a password, it is not us. Tell the desk and we will confirm what was actually sent. What safe payment looks like here, end to end, is on the payment safety page.
