Every keyed-in card payment — a phone order for a wholesale reorder, an emailed invoice paid by link, a checkout form on a website — arrives at the processor carrying more than a card number. Two small pieces of supporting data travel with it: the billing address and the security code printed on the card. They are easy to overlook and easy to misread, yet together they shape the overwhelming majority of approve-or-decline decisions for transactions where no card is physically presented.
Understanding what each check actually verifies — and, just as importantly, what it cannot verify — is the difference between blocking genuine fraud and quietly turning away good customers who simply typed their address in an unexpected format.
What AVS Actually Checks — and What It Leaves Out
AVS stands for Address Verification System, a check that compares the numeric portions of the billing address a customer supplies against the address the card issuer has on file for that account. It is not a full address comparison. The system looks at the street number and the ZIP or postal code — not the street name, not the city, not the apartment or unit number, and not the cardholder’s name. That narrow scope matters, because many merchants interpret an AVS mismatch as proof of fraud when it is usually just a data discrepancy.
The issuer returns one of a small set of responses: a full match, a partial match (street number only, or ZIP only), no match at all, an “unavailable” response when the issuer cannot or will not verify, or an “unsupported” response for card types and regions where the system does not apply. Each of these means something different, and treating them identically is where approval policies go wrong.
Partial matches deserve particular attention. In Canada, postal codes are more granular than many people assume when they belong to a single house, but they are frequently shared by every unit in an apartment building or every suite on a commercial floor. A customer living in a condo can therefore produce a ZIP-only match simply by omitting a unit number, or because the unit is recorded differently with the issuer. Likewise, a business card registered to a head office will never match a shipping address at a branch location.
AVS is also not universally supported. Cross-border transactions — a Canadian merchant charging a U.S. or overseas card, or the reverse — regularly return “not available” because the issuer’s system does not participate fully. Declining every transaction that comes back unavailable is one of the most common and most expensive mistakes in card-not-present processing, because it filters out legitimate international customers far more often than it stops fraud.
The practical takeaway: AVS is a verification signal, not an authentication method. It tells you whether the address typed in plausibly matches what the issuer holds. It does not tell you who is typing.
CVV Checks: What the Code on the Card Proves
The CVV — Card Verification Value, also printed as CVC, CVV2 or CID depending on the card network and card type — is the three-digit code on the back of most cards or the four-digit code on the front of some. It is generated by the issuer when the card is produced and is deliberately not encoded on the magnetic stripe or the EMV chip. That single design decision is what gives the check its value: anyone who copies stripe data, whether through a skimmer or a breach, still does not have the code.
When a transaction is submitted with a CVV, the issuer responds with a match, a mismatch, “not processed,” or “not present.” A match is meaningful because it demonstrates that whoever is entering the payment has the physical card in hand, or has had access to both sides of it. What it does not demonstrate is that the person is the cardholder or that the purchase is authorized. A stolen card photographed by a fraudster produces a perfectly valid CVV match.
There is a compliance dimension that is easy to miss. PCI DSS forbids storing the CVV in any form after authorization — not in a database, not in an order record, not on a sticky note beside the phone. Systems may retain the result of the check (matched or not), but never the code itself. This is why card numbers should be keyed straight into the terminal or gateway at the moment of sale. Any workflow that has a staff member writing a card number and security code onto paper, or pasting it into a CRM, creates a storage problem no merchant wants to explain. It is also why recurring and card-on-file charges cannot rely on CVV at all: once the code is gone, ongoing authorization has to be built on a token and the original transaction record instead.
From a fraud-operations perspective, CVV is one of the strongest defenses against card testing — the automated guessing attacks that hammer checkout pages with thousands of low-value attempts. A brute-force script might land on a valid card number occasionally, but it will almost never guess the matching code. A sudden run of CVV mismatches from one IP range or device is a clear signal to throttle or block, rather than to keep approving and hoping.
Turning AVS and CVV Into a Working Approval Policy
AVS and CVV are far more useful together than apart, because each covers a weakness in the other. A CVV match tells you the card was in hand; AVS tells you the billing details line up with the account. A fraudster holding a stolen card can pass one and fail the other, and legitimate customers routinely fail one for entirely innocent reasons.
A workable policy treats the two results as a scorecard rather than a switch. Full AVS match plus CVV match is a low-risk combination and should be approved without friction. A partial AVS match with a CVV match is usually a data-entry nuance, worth approving and worth a second look only on unusually high-ticket orders. A CVV mismatch should stop a keyed order cold — the operator can ask the caller to read the digits again, since miskeys happen, but a second mismatch means the transaction should not proceed. A CVV mismatch combined with an AVS mismatch is about as close to a red flag as card-not-present processing offers, and it warrants a decline or an explicit manual review.
Consider a wholesale distributor taking a phone reorder from a long-standing account. The buyer’s accounting department has the card registered to a corporate address, but the order is shipping to a warehouse in another province. AVS comes back with a street mismatch and a matching ZIP; CVV matches; the order value is consistent with the account’s history; the buyer’s PO number is captured on the invoice. That is a straightforward approval, and the sensible follow-up is to correct the billing address on the card vault record so the next order is cleaner.
Now reverse it: a first-time order for several thousand dollars, a billing address that does not resolve, a CVV mismatch, and a shipping destination in a different region from the billing city. No automated policy should push that through. The right response is to hold it, contact the customer through a channel independent of the order, and consider requiring a stronger authentication step or an alternative payment method.
Enforcement, though, is an operational problem as much as a risk problem. A policy only works if the staff keying orders can enter the billing address and security code reliably, if refund and void permissions are restricted to the people who should have them, if inactive sessions time out, and if every keyed transaction leaves an audit trail you can export. That is a large part of why merchants ask, “Which provider has the best virtual terminal features?” — because a terminal that captures AVS and CVV at the point of entry, enforces role permissions, and logs every action turns a written policy into something that actually happens. RapidCents’ virtual terminal, for instance, pairs those checks with tokenization, a customer card vault for repeat charges, session timeouts and exportable audit logs, so phone and invoice orders can follow the same rules as counter sales. It also matters downstream in disputes: the issuer sees the AVS and CVV response codes recorded at the time of sale, and a clean match record is a genuine asset when assembling evidence for a chargeback response.
Novosibirsk-born data scientist living in Tbilisi for the wine and Wi-Fi. Anton’s specialties span predictive modeling, Georgian polyphonic singing, and sci-fi book dissections. He 3-D prints chess sets and rides a unicycle to coworking spaces—helmet mandatory.