AVS and the security code: two checks your terminal already offers

The Address Verification Service compares the numeric part of a billing address against what the card issuer has on file, and the card security code is the three digits printed on the back — four on American Express — that prove whoever is paying has the physical card in front of them. Both run at authorization, both take seconds, and both are already built into the terminal you own.

They are also routinely skipped, because skipping is faster and the sale approves either way.

What does an address match actually prove?

Less than the name suggests. AVS checks digits: the street number and the ZIP code, not the street name, not the city. A response saying the address matched means those numbers line up with the issuer's record. It does not mean the person paying lives there, and it does not mean the card is being used with permission.

What it is genuinely good for is catching the mismatch. Card data sold in bulk often travels without a current billing address, so a thief typing a number from a list frequently cannot supply one that matches. The check is a filter, not a verdict.

What does the security code prove, and what may you do with it?

It proves the card was physically in someone's hand when the number was entered, because the code is printed on the card and is not carried in the magnetic stripe or the chip. That is a meaningful signal for a keyed or phone transaction.

There is a hard rule attached to it: the security code may never be stored after the transaction is authorized. Not in a note, not in a spreadsheet, not in a customer file, not on a pad by the phone. That prohibition is part of the card data security standards maintained by the PCI Security Standards Council, and it is one of the few rules in payments with no exceptions and no grey area.

Why do sales still approve when the checks fail?

Because the checks and the authorization are separate questions. The issuer answers "are there funds and is this card in good standing" and, separately, reports how the address and security code compared. A transaction can approve with a full AVS mismatch, and most terminals will complete it without a word.

That is the part worth telling a cashier. The machine saying "approved" is not the machine saying "this is fine." Somebody has to read the mismatch and decide, and if nobody is looking, the check might as well not exist.

How should a counter actually use them?

Set a rule with three parts. Answer the prompts every time a card is keyed. Look at the response before handing over the goods. And treat a full mismatch on a high-value keyed sale as a stop, not a shrug.

A store that keys three cards a week can afford that rule easily. A store that keys thirty a day needs a proper card-not-present setup rather than a counter habit, because at that volume the exception has become the workflow and deserves to be configured as one.

Does using them change what a transaction costs?

It can. Keyed transactions price higher than card-present ones because the issuer has less assurance, and supplying verification data gives back some of that assurance. A keyed sale with address and security-code data attached generally settles better than one without.

Do not oversell this to yourself, though. The savings are small and the fraud protection is the real reason to do it. Framing a security habit as a cost-saving measure tends to get the habit dropped the first time somebody is busy.