Beak
Loading ..

table of contents feature [open]

Card-Not-Present Fraud Prevention for Small Merchants

0 Comments
Cover graphic reading Stop Card-Not-Present Fraud, a merchant security guide on 3DS, card testing, PCI DSS and chargebacks

Last reviewed: September 28, 2026. Card network thresholds, SCA rules and processor features were checked against the official Visa, PCI SSC, EBA, FCA, AusPayNet and processor pages listed under Sources. Network programs change often, so confirm current figures with your acquirer before acting on them.

Short answer: Card-not-present fraud prevention for a small online store comes down to layers rather than any single tool. Keep card data off your servers with a hosted or embedded payment form, collect CVV and billing address on every order, use 3-D Secure (mandatory in practice for most UK and EEA customer payments, optional but useful elsewhere), put CAPTCHA and rate limits in front of every endpoint that can charge or save a card, switch on your processor's fraud scoring, and answer disputes with organised evidence. Watch your fraud and dispute counts monthly, because Visa's merchant threshold in the US, Canada, Europe and Asia-Pacific fell to 1.5% on April 1, 2026.

If you sell online, you accept a risk that a shop with a card terminal barely thinks about: you never see the card, and you never see the person holding it. Card networks call these transactions "card-not-present" (CNP), and the fraud that comes with them works very differently from a stolen wallet at a till. For a small merchant the money lost on a single bad order is often the smaller problem. The bigger ones are the dispute fees that follow, the stock that has already shipped, a surge of declined test transactions that makes banks distrust your merchant account, and, at the far end, a network monitoring program that can cost you the ability to take cards at all.

This guide is written for owners and operators of small e-commerce businesses in the United States, the United Kingdom, the European Union, Canada and Australia. It explains how each type of CNP fraud works, who ends up paying, which controls actually move the numbers, and what to do in the first hour of a card-testing attack. It closes with a 30-day plan you can hand to whoever runs your site.

What card-not-present fraud looks like for a small store

CNP fraud is any fraudulent card payment made without the physical card being presented to a terminal: web checkouts, in-app purchases, phone and mail orders, and payments on saved cards. The scale is large wherever it is measured. UK Finance reported that remote purchase fraud losses on UK cards rose 3% to £423.5 million in 2025, with case numbers up 13% to 3.2 million. In Australia, AusPayNet's figures for July 2024 to June 2025 show total card fraud of $854 million, a rate of 71.8 cents per $1,000 spent, with card-not-present fraud making up the largest share. The European Banking Authority and the ECB found that fraud on EU/EEA-issued cards reached €1.329 billion in 2024, up 29% year on year.

Those totals hide four quite different problems. Each one needs its own defence, which is why a single fraud filter rarely solves everything.

Stolen card data used to buy goods

This is the classic version. Card numbers, expiry dates and security codes are harvested through phishing, malware, skimming scripts injected into other websites, or data breaches, then sold in bulk. A buyer uses the details on your checkout, usually for goods that are easy to resell: electronics, gift cards, branded clothing, cosmetics, event tickets. When the real cardholder spots the charge, their bank files a fraud dispute and, unless you are protected by authentication, the money comes out of your account.

Card testing (enumeration)

Before criminals spend stolen card data, they want to know which cards still work. Visa defines enumeration as systematically testing or guessing card numbers, expiry dates, CVV2 values or postcodes to find valid credentials, and notes that the most common method is to target legitimate e-commerce merchants with weak fraud controls. Bots fire hundreds or thousands of small authorisations, or zero-value card checks, through your checkout or your "save card" form. Stripe's documentation notes that testers favour card-saving flows because validation checks usually don't appear on cardholder statements, which makes them less likely to be reported. You may earn nothing from the attack, yet you carry the authorisation fees, the damage to your approval rates and, if some of the tiny charges succeed, a wave of fraud reports.

Account takeover

If your store lets customers create accounts and save cards, a criminal who gets into a customer's account can order with the stored card without ever knowing the card number. Access usually comes from credential stuffing: trying email and password pairs leaked from other sites. The order looks like it comes from a loyal customer, which is exactly why it gets through.

Friendly fraud (first-party misuse)

Here the cardholder made the purchase and then disputes it anyway, claiming it was unauthorised or never arrived. Some cases are deliberate. Many are confusion: a family member used the card, the statement descriptor was unrecognisable, or the customer forgot a subscription renewal. Visa's Compelling Evidence 3.0 rules exist specifically to tackle friendly fraud or first-party misuse, and they are covered in the chargebacks section below. If you want to see disputes from the shopper's side of the counter, our guide on how consumers dispute a credit card charge in the US and UK explains what the cardholder is told to do, which helps you anticipate their claims.

Fraud typeWho commits itTypical signalMain defence
Stolen card purchaseThird party with stolen dataHigh-value order, rushed shipping, mismatched addresses3-D Secure, AVS/CVV, fraud scoring, manual review
Card testingBots checking stolen or guessed cardsSpike in small declines from few IPs or devicesCAPTCHA, rate limits, velocity rules, minimum amounts
Account takeoverThird party using leaked loginsNew device, new shipping address, password reset before orderMFA, bot protection on login, re-authentication for changes
Friendly fraudThe genuine cardholderDispute on an order with matching history and delivery proofClear descriptors, easy refunds, strong evidence files

Who pays when an online card payment turns out to be fraud

On a face-to-face chip payment, fraud losses usually fall on the card issuer. Online, the default runs the other way: when a cardholder reports that they did not authorise a CNP purchase, the issuer raises a fraud chargeback and the merchant's acquirer pulls the funds back from the merchant. Your processor then passes that debit on to you, along with a dispute fee. Stripe, for example, debits the disputed amount plus a dispute fee when a dispute opens, and says the fee is not refundable for most businesses outside Mexico except where the dispute is decided in the merchant's favour.

There are two main ways to move that liability off your books.

  • Authentication through 3-D Secure. Visa describes its 3DS program, Visa Secure, as a way to shift liability for authenticated or attempted-authentication transactions. When a 3DS-authenticated payment is later disputed as fraud, the loss generally sits with the issuer.
  • Evidence that the cardholder made the purchase. For friendly fraud, programs such as Visa Compelling Evidence 3.0 let a merchant show a history of genuine purchases from the same customer and shift liability back to the issuer.

Neither route is absolute. Stripe's 3DS documentation is blunt that successful authentication does not guarantee a liability shift. It can be lost if you ignore an issuer's information request, it may not apply in certain business categories, and it can be withdrawn when a merchant is enrolled in a network fraud monitoring program. And there is a cost that liability shift never covers: fraud reports still count against you.

Why fraud reports matter even when you don't pay

Issuers report suspected fraud to the networks separately from filing disputes. Visa calls these TC40 reports; Stripe surfaces them as "early fraud warnings". Visa's consolidated monitoring program, the Visa Acquirer Monitoring Program (VAMP), counts them. According to Visa's own fact sheet, the VAMP ratio is the count of fraud reports (TC40) plus disputes (TC15), divided by the count of settled transactions, measured on card-not-present transactions. So a store that relies entirely on 3DS to avoid paying for fraud can still breach a network threshold because its fraud report count keeps climbing. Prevention, not just liability transfer, is the goal.

3-D Secure 2 and Strong Customer Authentication

How EMV 3-D Secure works

EMV 3-D Secure (often called 3DS2) is the current version of the protocol behind "Verified by Visa"-style checks, now branded Visa Secure and Mastercard Identity Check. When a customer pays, your checkout sends data about the transaction, the device and the customer to the card issuer. EMVCo, the body that maintains the standard, says the specification defines over 100 data elements and supports two paths:

  • Frictionless flow: the issuer scores the transaction in real time and approves the authentication without asking the shopper to do anything.
  • Challenge flow: for riskier transactions the shopper confirms in their banking app, enters a one-time code or uses a biometric check.

The practical upshot for a small merchant is that 3DS2 is far less disruptive than the old pop-up password pages. The more data your checkout passes (billing address, email, phone, device information), the more likely an issuer is to approve without a challenge. Visa reports that transactions authenticated with Visa Secure had 11 basis points of fraud versus 20 basis points for non-authenticated e-commerce transactions, based on VisaNet data for Q4 2023.

3D Secure for small business: do you have to use it?

That depends on where your customers' cards and your acquirer are located. In the EEA and the UK, Strong Customer Authentication is a legal requirement for most customer-initiated online card payments, and 3DS is how card payments meet it. In the US, Canada and Australia there is no equivalent blanket legal mandate for merchants, so 3DS is a risk tool you can apply selectively: on first orders, high-value baskets, risky product categories, or whenever your fraud score is elevated. Many processors can trigger it automatically based on risk. Stripe, for instance, lists "adaptive 3D Secure" among the features of its higher Radar plans.

Strong Customer Authentication in the EEA and UK

Under PSD2 and its technical standards, SCA means verifying the payer with two of three factor types: something they know, something they have, and something they are. The obligation technically falls on payment service providers (the issuer, and your acquirer on your side), but merchants feel it at checkout: an EEA or UK card payment that should have been authenticated and wasn't may simply be declined. The UK kept the rules after Brexit through the FCA's version of the standards, with some amounts converted to sterling.

A few categories fall outside SCA. The European Banking Authority's Q&A confirms that mail order and telephone order (MOTO) transactions are out of scope, and merchant-initiated transactions, such as a subscription renewal charged without the customer present, can also fall outside it when the original mandate was set up correctly, usually with SCA at sign-up. Keying a web order in as MOTO to dodge authentication is not an acceptable workaround; your acquirer can see the pattern.

Within scope, the rules allow exemptions that an issuer or acquirer may apply. The two that matter most for small stores are the low-value exemption and transaction risk analysis (TRA):

ExemptionEEA (Delegated Regulation 2018/389)UK (FCA SCA-RTS)
Low-value remote paymentUp to €30 per payment, as long as the total since the last SCA stays at or below €100 or no more than five consecutive payments have skipped SCAUp to £25 per payment, with the cumulative cap at £85 or five consecutive payments
Transaction risk analysis, remote card paymentsUp to €100 if the provider's fraud rate is at or below 0.13%; up to €250 at 0.06%; up to €500 at 0.01%Same tiered approach, with sterling thresholds set in the FCA's version; ask your acquirer which bands it qualifies for
Recurring payments of the same amount to the same payeeSCA at set-up, then exemptSCA at set-up, then exempt
Trusted beneficiariesPayer can whitelist a merchant with their bank after SCASame

The EEA figures come from Articles 16 and 18 and the Annex of the regulation as adopted; the UK amounts come from the FCA Handbook's chapter on SCA exemptions. Two things are easy to miss. First, the fraud rates that qualify a payment for TRA belong to the issuer or acquirer, not to you; a merchant cannot declare its own orders exempt, only ask its provider to request an exemption. Second, the issuer always has the final say and can demand a challenge anyway. EBA and ECB data also show why the rules exist: card payment fraud was 17 times higher when the payment recipient was outside the EEA, where SCA is not legally required, and the same report warns that fraudsters increasingly target exempted transactions.

A practical caution: when your side requests an exemption and the payment skips authentication, you should not assume the fraud liability shift that comes with a completed 3DS authentication. Ask your acquirer how liability is allocated on exempted payments before you optimise for fewer challenges.

AVS and CVV checks: useful, but limited

The card verification value (CVV, CVC or CVV2, depending on the brand) is the three- or four-digit code printed on the card. The Address Verification Service (AVS) compares the numeric parts of the billing address and postcode with what the issuer holds on file. Both are passed to the issuer during authorisation, and the response tells you whether each piece matched.

They are worth collecting on every order for three reasons. CVV can't legally be stored by merchants after authorisation (PCI DSS forbids retaining it, even encrypted), so stolen databases rarely contain it; a CVV match means the buyer at least has the full card details. AVS results feed into your processor's risk score. And Visa's enumeration guidance explicitly tells merchants to require CVV and AVS on all CNP transactions, because doing so raises the cost and complexity of brute-force testing.

Their limits are just as real:

  • Coverage varies. Stripe's documentation says that most cards issued in the US, Canada and the UK support address checks, while some countries don't use postcodes and some issuers don't support AVS at all. Treat "unavailable" as neutral rather than as a failure.
  • Genuine customers fail AVS. People mistype addresses, move house without telling their bank, or pay with a virtual card number tied to a different billing record. If you sell to people who use virtual credit cards, blocking every partial AVS mismatch will turn away real revenue.
  • A pass is not proof. Criminals with a full stolen record, often called a "fullz", have the name, address and CVV. AVS and CVV stop the lazy attacks and the guessing bots, not the well-equipped ones.

A sensible default for most small stores: decline on a CVV mismatch, and send AVS mismatches on higher-value or rushed-shipping orders to review rather than blocking them outright.

Card testing attacks: how to spot and stop them

A card testing attack is the fraud event most likely to hit a small store without warning, and it can do lasting harm within hours. Beyond the fees, a flood of declines tells issuers your merchant ID is risky, which can push down approval rates for real customers afterwards. Visa now tracks this directly: under VAMP, acquirers must take proactive steps to keep merchants below an enumeration ratio of 2,000 basis points (20% of authorisation attempts) and an enumeration count of 300,000 transactions. Most small merchants will never reach those volumes, but your acquirer is under pressure to act well before you do.

What an attack looks like

Stripe lists the most common signs as a sharp rise in failed or blocked payments, a jump in card-error API responses, and a burst of low-value payments, often with nonsense customer names and email addresses. Visa adds that attack transactions are often under US$10, that spikes in declines from a similar BIN range (the first digits of the card number, which identify the issuer) are a warning sign, and that fraudsters sometimes reverse an approved authorisation immediately. Many attacks happen overnight in your time zone, when nobody is watching the dashboard.

Hypothetical example: a small candle shop normally sees about 40 checkout attempts a day. At 2 a.m. on a Sunday, 1,800 attempts arrive in 90 minutes, all for its cheapest $4 item, from a few hundred IP addresses, with guest checkout and randomised email addresses. About 1,700 are declined; 100 are approved. The shop owner wakes to 100 small orders, a decline rate that looks like a broken integration, and a strong chance that some of the 100 cardholders will report fraud in the coming weeks.

Controls that work

  • Put CAPTCHA on every card endpoint, not just the checkout page. Visa's guidance says the CAPTCHA must be validated on all requests that enable card validation or payments. Stripe's advice adds that the check must be verified server-side; a CAPTCHA that only runs in the browser can be skipped by a script calling your API directly.
  • Rate-limit by more than IP address. Visa gives the example of blocking bots after five authorisations from one IP address or card number in a set timeframe, and recommends velocity checks on email, device and IP together. Attackers rotate IPs cheaply, so an IP-only rule will not hold for long.
  • Combine friction smartly. Stripe suggests letting a customer's first payment attempt from an IP address through, then requiring a CAPTCHA for further attempts from the same IP for the next several hours. Legitimate shoppers rarely notice; bots stall.
  • Protect the "add card" flow. Limit the number of cards per account and per session, the number of accounts per IP address in a time window, and how often payment methods can change, all measures Visa lists. Requiring login before saving a card also helps.
  • Set sensible minimums. Donation pages and "pay what you want" fields are favourite targets. Visa recommends a minimum amount set as high as your genuine customers will tolerate.
  • Use a web application firewall. A WAF can limit repeated form submissions and block traffic from known malicious sources before it reaches your payment code.
  • Guard your API keys. If an attacker has your secret key, no front-end control will help. Visa advises rolling API keys if attacks are hitting your API directly rather than your web form, and it names phishing of gateway credentials as one route attackers use to run enumeration through a real merchant's account.

One subtle point from Stripe's guidance: aggressive payment retries on failed subscription renewals can look like card testing to issuers. After an attack, make sure your billing system is not retrying the fraudulent cards the bots attached to fake accounts.

Account takeover and saved cards

Saved cards make repeat purchases easy, and that convenience is precisely what an account takeover exploits. The OWASP credential stuffing cheat sheet, a widely used developer reference, treats multi-factor authentication as the most effective defence, backed by CAPTCHA, device fingerprinting, checks against known breached passwords, and notifications to users about unusual activity. For a small store, a realistic version looks like this:

  • Offer (and nudge customers towards) a second factor such as an emailed or app-based code, at least for accounts with saved cards.
  • Rate-limit login attempts and put bot protection on the login and password-reset forms, not just checkout.
  • Ask for re-authentication, or the card's CVV, when someone adds a new shipping address and then orders with a saved card in the same session.
  • Email the customer whenever the password, email address, or default shipping address changes. The real owner is often your fastest fraud detector.
  • Turn on multi-factor authentication for your own admin, e-commerce platform and payment dashboard logins. Australia's Cyber Security Centre advises small businesses to turn on MFA for all accounts with administration privileges for your website and to keep the content management system and plugins updated.

The last item deserves emphasis. An attacker who gets into your store's admin panel can inject a skimming script into your checkout or change payout details, which is a far larger problem than one bad order.

Fraud scoring tools from your processor

Almost every mainstream payment processor now scores each transaction for fraud risk using machine learning trained across many merchants. That network effect is something no small shop can build alone: a card that was used for fraud at a different merchant an hour ago can be flagged on yours. The tools generally share a pattern:

  • A risk score or level for each payment.
  • Default rules that block the highest-risk payments automatically.
  • Custom rules you can write, for example "review if the shipping country differs from the card country and the order is above a set amount".
  • Allow and block lists for emails, cards, IP addresses or devices.
  • A manual review queue for payments you want a human to check before shipping.

Three examples, as described in each company's official documentation at the time of writing:

Whichever provider you use, the quality of the score depends on what you send. Stripe states plainly that its card-testing controls rely on signals your integration supplies, and lists IP address, customer email, name and billing address as useful inputs. A checkout that sends only the card number and amount forces the model to guess.

Start with the defaults for two to four weeks, then look at what was blocked and what got through before writing custom rules. Rules written in a panic after one bad order tend to block good customers for months.

PCI DSS v4.0.1 basics for small merchants

The Payment Card Industry Data Security Standard is the security baseline the card brands require from anyone who stores, processes or transmits card data. It is a contractual requirement through your acquirer rather than a law, but ignoring it can cost you fines passed on by your acquirer and, after a breach, very expensive forensic work. PCI compliance for a small business is mostly about reducing scope: the less card data touches your systems, the shorter your questionnaire.

Which version applies

The PCI Security Standards Council published PCI DSS v4.0.1 on June 11, 2024 as a limited revision with no added or deleted requirements. Version 4.0 was retired on December 31, 2024, and the requirements that had been "future-dated" became mandatory on March 31, 2025. If your last self-assessment was on v3.2.1 or v4.0, your next one should be on v4.0.1.

Who decides what you must do

Validation rules are set by the card brands and enforced by your acquirer. The Council itself says that whether a small merchant is required to validate compliance is determined by the individual payment brands, and directs merchants to their acquirer. In practice most small online merchants complete a Self-Assessment Questionnaire (SAQ) once a year, often through a portal the processor provides.

SAQTypical e-commerce setupRough effort
SAQ AAll card data functions outsourced: customer is redirected to the processor's hosted payment page, or the card fields sit in the processor's iframe. No card data stored electronically.Shortest
SAQ A-EPYour website doesn't receive card data but controls how it reaches the processor, for example a JavaScript form or "direct post" served from your own page.Substantially longer; your web server is in scope
SAQ D (merchant)Your systems store, process or transmit card data, for example a custom checkout that sends card numbers through your server.Full set of applicable requirements

Other SAQs cover card terminals and virtual terminals. If you take card details by phone and key them into a processor's web portal, ask your acquirer which one applies to that channel.

The SAQ A change that affects many small stores

Version 4.0 added two requirements aimed at "e-skimming", where malicious scripts on a checkout page copy card details as customers type them. Requirement 6.4.3 covers authorising and checking the integrity of scripts on payment pages, and 11.6.1 covers detecting unauthorised changes to those pages. In January 2025 the Council removed both, along with 12.3.1, from SAQ A, and replaced them with a new eligibility criterion: the merchant must confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).

A follow-up FAQ explained that this criterion applies to merchants that embed a processor's payment form in an iframe, not to those that redirect customers to a hosted page. An iframe merchant can meet it either by applying the script protections in 6.4.3 and 11.6.1 (or equivalent methods) or by getting written confirmation from a PCI-compliant processor that its embedded solution includes script-attack protection when implemented as instructed. The requirements themselves are still in the standard for merchants on SAQ A-EP and SAQ D.

Things no SAQ lets you do

  • Store the CVV after authorisation. The PCI SSC's guidance is that card verification codes cannot be retained once the transaction has been authorised, even for recurring billing.
  • Keep card numbers in email, spreadsheets, CRM notes or chat logs. If staff take card details by phone, write them straight into the processor's tool and nowhere else.
  • Assume your processor's compliance covers you. It covers their systems; your website, admin accounts and plugins are still yours.

Handling chargebacks from the merchant side

A chargeback is the formal reversal an issuer initiates when a cardholder disputes a payment. Knowing how to prevent chargebacks as a merchant starts with understanding the timeline, because most losses come from missed deadlines and thin evidence, not from strong customer claims.

The dispute lifecycle

  1. Early warning (sometimes). A fraud report or an issuer inquiry arrives. Stripe notes that inquiries are now mostly used by American Express and Discover, and that ignoring one can lead to a chargeback you are unlikely to win.
  2. Chargeback opened. Card networks generally let cardholders dispute within 120 days of the payment, and longer for goods or services delivered later, such as event tickets, where the clock usually starts from the delivery date.
  3. Your response. You typically have 7 to 21 days, depending on the network and processor, to submit evidence.
  4. Issuer decision. The issuer usually takes 60 to 75 days to review. The whole process can run two to three months.
  5. Further stages. Some disputes go to pre-arbitration and arbitration, with extra fees. Not every processor supports those stages.

What good evidence looks like

Match the evidence to the reason code. For fraud claims, show that the cardholder or someone they authorised made the purchase. For "not received", show delivery. For "not as described" or cancelled subscriptions, show what the customer agreed to. A useful evidence file for a physical-goods order contains:

  • Order details: items, amounts, date and time, IP address and device information.
  • Authentication results: 3DS outcome, AVS and CVV responses.
  • Delivery proof: carrier tracking with a delivery confirmation to the AVS-matched address, and a signature for high-value orders. Stripe points out that issuers don't open links, so include screenshots.
  • Customer communications: emails or chats that show the customer acknowledged the order.
  • Policy acceptance: evidence the customer saw your refund and cancellation terms at checkout, ideally displayed in full rather than hidden behind a link.
  • Purchase history: earlier undisputed orders from the same account, email, device or address.

Keep the write-up short and factual. A one-page summary that points to labelled attachments is easier for an issuer's analyst than twenty pages of unexplained screenshots.

Visa Compelling Evidence 3.0

Since April 15, 2023, Visa has applied updated rules to fraud disputes under condition 10.4 (fraud in a card-absent environment). Visa's merchant readiness document sets out the qualifying criteria. You need two previous transactions from the same merchant, at least 120 days and no more than 365 days old at the dispute date, with no active fraud report or fraud dispute on them. At least two of four data elements (user ID, IP address, shipping address, device ID or fingerprint) must match between the earlier transactions and the disputed one, and one of the two must be the IP address or the device ID. When the criteria are met, liability shifts back to the issuer.

The rule only helps if you capture and keep that data. Record IP address and a stable account identifier on every order, retain it for at least a year, and make sure your processor or dispute tool can pull it together. Visa also lets merchants submit the same data before a dispute is filed through Verifi's Order Insight service. Qualifying CE3.0 fraud reports are also excluded from the VAMP ratio, so good data hygiene helps on two fronts.

Mastercard's approach

Mastercard's comparable program, First-Party Trust, was announced in October 2023 with a US rollout from 2024. Mastercard says it provides merchant chargeback protection for disputes that meet First Party Trust data sharing requirements, using data such as purchase history, device information and delivery details. Ask your processor whether it participates and what data it needs from you.

Network monitoring programs

Both major networks watch merchants whose fraud or dispute levels run high. Being placed in a program brings fees, mandatory remediation plans and, if it continues, loss of card acceptance.

ProgramMetricMerchant threshold
Visa Acquirer Monitoring Program (VAMP)(Fraud reports + disputes) ÷ settled CNP transactions, monthlyExcessive at 150 bps (1.5%) or more with at least 1,500 fraud reports plus disputes a month, in Asia-Pacific, Canada, Europe and the US from April 1, 2026 (previously 220 bps)
VAMP enumerationEnumerated authorisations ÷ all authorisations2,000 bps (20%) or more, and 300,000 or more enumerated transactions
Mastercard Excessive Chargeback MerchantChargebacks this month ÷ sales transactions last month100 to 299 chargebacks and a ratio of 1.5% to 2.99%
Mastercard High Excessive Chargeback MerchantSame300 or more chargebacks and a ratio of 3% or more

The Visa figures come from Visa's VAMP fact sheet, which notes that the Latin America region uses 150 bps and the CEMEA region uses different minimum counts. The Mastercard figures come from Braintree's summary of the Excessive Chargeback Program, which says a merchant exits only after three consecutive months below the thresholds. The minimum counts mean a very small store is unlikely to be named in these programs directly, but acquirers set their own, often tighter, internal limits and can hold funds, add reserves or close accounts well before a network threshold is reached. Track your ratios monthly regardless of size.

Refunds vs disputes: when to give the money back

A refund is a transaction you initiate; a dispute is one the issuer initiates against you. That difference matters more than the money. A refund costs you the sale. A dispute costs you the sale, a fee, time, and a mark against your dispute ratio.

Some rules of thumb from processor documentation:

  • Refund fraud you're sure about, straight away. Stripe recommends refunding payments you are certain are fraudulent, unless they are covered by a liability shift, because a fully refunded payment cannot be disputed. Visa's enumeration guidance gives the same advice for card-testing charges.
  • Partial refunds don't block disputes. Stripe notes that under network rules a partially refunded payment can still be disputed, even for the full amount.
  • Once a dispute is open, the refund route closes. On Stripe you cannot issue a separate refund while a dispute is open; the dispute process decides where the money goes. Refunding anyway on other systems risks the customer being credited twice.
  • Weigh early fraud warnings against your dispute fee. Stripe says roughly 40% of Visa and Mastercard early fraud warnings turn into fraud disputes if the payment isn't refunded, and that its analysis suggests refunding warned payments that are roughly equal to or below your dispute fee. It also notes a refund stops the fraud report itself only if processed as a reversal, typically within about two hours of capture.
  • Be more generous when you're small or under pressure. Stripe suggests refunding more aggressively if the order hasn't shipped, if you're already near a monitoring threshold, or if you process fewer than about 100 payments a month, where one or two disputes swing your ratio sharply.

Friendly fraud is often a customer service failure in disguise. A clear statement descriptor, a visible contact email, prompt replies and an easy refund process prevent many disputes before they start. Unexpected currency conversion is another source of confusion for cross-border shoppers; if you sell internationally, our explainer on foreign transaction fees and dynamic currency conversion covers what customers see on their statements and why charges can differ from the checkout total.

Red flags checklist for online orders

No single signal proves fraud, and plenty of honest customers trip one or two. Look for clusters. The list below draws on the review questions in Stripe's dispute prevention guidance and on Visa's enumeration guidance.

  • Billing and shipping addresses differ, especially across countries, or the ship-to address is a freight forwarder.
  • AVS fails or CVV doesn't match.
  • The card's issuing country, the IP address location and the shipping country are all different.
  • Express or overnight shipping requested on a first order, particularly for high-resale goods.
  • An unusually large basket, or one made up only of your most expensive or easily resold items.
  • Several declined attempts with different cards before one succeeds, or several cards used from the same device or IP address.
  • The shipping address changed after the order was placed.
  • The email address looks machine-generated or doesn't relate to the cardholder name.
  • Browser language and time zone don't fit the IP location, a mismatch Visa suggests treating as higher risk.
  • A password reset or new device login shortly before an order on a saved card.
  • A surge of small-value orders or declines from a narrow BIN range.

For orders that show several flags, contact the customer by phone or email before shipping, use authorise-then-capture so the card is held but not charged until you're satisfied, or delay dispatch by a day or two. Stripe points out that uncaptured authorisations cannot be disputed and that a 24 to 48 hour shipping delay gives cardholders time to spot and report fraud before goods leave your warehouse.

Incident response when a card-testing attack hits

Write this down before you need it and keep it where the on-call person can find it. The steps below combine Stripe's active card-testing checklist with Visa's enumeration recommendations.

In the first hour

  1. Confirm it's an attack. Look for a spike in declined payments, many small charges, repeated card-error responses, or a cluster of new guest customers with junk details.
  2. Close the door. Turn on or tighten CAPTCHA on checkout and card-saving endpoints, add temporary rate limits at your WAF or hosting layer, or switch off guest checkout for an hour. If the traffic is hitting your API directly, roll your API keys.
  3. Stop fulfilment. Pause automatic dispatch of any orders placed during the attack window until they have been reviewed.
  4. Tell your processor. Many can apply extra blocks from their side and will want to know before their own systems flag your account.

In the next 24 hours

  1. Refund the successful test charges. Refunding before cardholders notice avoids disputes and fees.
  2. Clean up. Delete or disable fake customer accounts and saved cards the bots created, and make sure no subscription or retry logic will charge those cards again.
  3. Collect the evidence. Export IP addresses, user agents, email addresses and timestamps. Visa asks for these details on attack transactions, and your acquirer may want them too.
  4. Find the weak point. Was it a public endpoint without CAPTCHA, a donation form without a minimum, an exposed key or a compromised admin login?

If card data may have been stolen from you

Card testing on your site doesn't mean your site leaked the cards. But if you find an unknown script on your checkout or signs of intrusion in your admin panel, treat it as a possible data breach. Contact your acquirer immediately; the card brands have specific forensic procedures. The FTC's data breach response guide advises taking affected equipment offline without switching machines off until forensic investigators arrive, bringing in independent forensic help, and notifying law enforcement and affected parties as the law requires. Report the crime too: in England, Wales and Northern Ireland through Report Fraud, which replaced Action Fraud from December 4, 2025; in Canada through the Canadian Anti-Fraud Centre; and in the US and Australia through the national cybercrime reporting services.

A practical 30-day hardening plan

This plan assumes a small team and an off-the-shelf platform or a modest custom site. Adjust the order to fit your biggest current problem: if you are mid-attack, start with week two.

Days 1 to 7: know your baseline

  • Pull the last six months of payments, declines, refunds, fraud warnings and disputes. Work out your monthly dispute count and ratio by card brand.
  • Map every place a card can be entered or charged: checkout, "add card" in accounts, donation or gift card pages, invoice links, phone orders, mobile app, test pages you forgot to remove.
  • Confirm which SAQ applies to you and check the date of your last attestation. Ask your processor for its written confirmation on script-attack protection if you use an embedded payment form.
  • Turn on multi-factor authentication for every admin, platform, hosting, domain and payment dashboard account. Remove old staff logins.
  • Check who holds API keys, whether any secret key sits in front-end code or a public repository, and rotate any key you're unsure about.

Days 8 to 14: close the obvious gaps

  • Require CVV and full billing address and postcode on every card payment.
  • Add server-verified CAPTCHA to every card-accepting endpoint, or move to your processor's recommended hosted or embedded checkout, which often includes bot protection.
  • Set rate limits on payment attempts and on card additions per IP address, device, email and account.
  • Set a minimum amount on donation or open-amount fields.
  • Switch on your processor's default fraud rules and check what it blocks for you by default.
  • Update your platform, theme and plugins, and remove plugins you no longer use.

Days 15 to 21: add authentication and evidence

  • Enable 3-D Secure. For UK and EEA customers make sure it runs whenever SCA is needed; elsewhere, trigger it by risk or for first orders above a chosen value.
  • Pass as much data as possible to your processor for scoring and 3DS: email, phone, shipping address, IP address.
  • Store order-level evidence (IP address, device ID, account ID, shipping address, tracking numbers) for at least 13 months so you can use Visa CE3.0 and similar programs.
  • Rewrite your statement descriptor so customers recognise it, and add a support email or website to it where your processor allows.
  • Show your refund and cancellation policy in full at checkout and record acceptance.

Days 22 to 30: set up the routine

  • Create simple alerts: declines above a set multiple of your normal hourly level, any hour with an unusual number of small payments, and any new fraud warning.
  • Write the one-page incident response checklist from the section above and test it with a tabletop run-through.
  • Write a dispute evidence template for each common reason: fraud, not received, not as described, subscription cancelled.
  • Review what the fraud tool blocked and approved in its first weeks; only then add one or two custom rules targeting patterns you have actually seen.
  • Book a monthly 30-minute review of fraud warnings, disputes and ratios, and a quarterly check of plugins, admin users and keys.

Country notes: US, UK, EU, Canada and Australia

United States

There is no legal requirement for merchants to use 3DS, so authentication is a business decision: use it where the fraud risk justifies the extra step, and test the effect on approvals with your own traffic. AVS is well supported on US cards and is one of the most useful cheap signals available. VAMP's 1.5% merchant threshold applies to the US region. US state data breach laws vary, so if you suspect card data was exposed, involve a lawyer alongside your acquirer.

United Kingdom

SCA applies under the FCA's version of the technical standards, with a £25 low-value limit and an £85 cumulative cap. UK issuers will decline many unauthenticated remote payments that aren't exempt, so 3DS needs to be working reliably, including on mobile. AVS is widely supported on UK cards. UK Finance's figures show remote purchase fraud still growing in value and volume in 2025. For monitoring purposes the UK sits within Visa's Europe region, which uses the same 1.5% merchant threshold.

European Union and EEA

PSD2 SCA applies to most customer-initiated online card payments where both the issuer and the acquirer are in the EEA. Expect frequent challenges on higher-value orders and learn which exemptions your acquirer supports. Stripe's documentation names the US, Canada and the UK as the places where most cards support address checks, so don't count on AVS for continental European cards; lean on 3DS and fraud scoring instead. The EBA's latest figures show fraud rates much higher on payments to recipients outside the EEA, which matters if you sell to European customers from a non-EEA entity.

Canada

Canada has no PSD2-style SCA mandate for merchants, so 3DS is used on a risk basis as in the US. Stripe's documentation lists Canadian cards among those that mostly support address verification. Visa's VAMP thresholds apply to the Canada region at the same 1.5% level. Report fraud and cybercrime to the Canadian Anti-Fraud Centre.

Australia

Instead of a legal SCA mandate, Australia uses an industry framework run by the Australian Payments Network. The CNP Fraud Mitigation Framework took effect on July 1, 2019, covers Australian-acquired transactions on Australian-issued cards (MOTO transactions are out of scope), and requires stronger authentication from merchants whose fraud breaches set thresholds. AusPayNet's summary lists the initial merchant threshold as 20 basis points and $50,000 in fraud losses per quarter; the framework says thresholds are reviewed annually, so ask your acquirer for the current figure. Don't assume AVS will be available on Australian cards the way it is in North America and the UK. Visa's Asia-Pacific region uses the same 1.5% VAMP merchant threshold.

When this doesn't apply

  • You only take payments in person. Chip, contactless and wallet payments at a terminal are card-present transactions with a different liability model. This guide covers the online channel only, though phone orders you key in yourself are CNP.
  • You sell only through a marketplace. If Amazon, Etsy, eBay or a similar platform is the merchant of record and processes payments, fraud screening, chargebacks and PCI obligations for those payments largely sit with the platform under its own rules. Read its seller protection terms instead.
  • You're a payment facilitator, platform or high-volume merchant. Different PCI validation levels, network registration duties and monitoring thresholds apply. You'll need a qualified security assessor and direct conversations with your acquirer.
  • Your customers pay by bank transfer, open banking, or buy now, pay later. Those methods have their own fraud patterns and dispute processes. Stripe notes, for example, that providers such as Klarna and PayPal decide disputes themselves and may allow up to 180 days.
  • You've already had a confirmed data breach. Stop using this guide as a checklist and follow your acquirer's breach procedures and legal advice.

FAQ

Is card-not-present fraud the merchant's fault if the card was stolen elsewhere?

No, but it is often the merchant's cost. Network rules place most CNP fraud losses on the merchant unless the payment was authenticated with 3DS or another liability-shifting mechanism applies. Where the card was stolen doesn't change who pays for the chargeback.

Will 3-D Secure hurt my conversion rate?

It can, if challenges appear often or the integration is clumsy on mobile. EMV 3DS was designed so that most low-risk payments pass through the frictionless flow. Send rich data, use your processor's current integration, and compare conversion before and after on your own traffic rather than relying on general claims.

Can I block entire countries to stop fraud?

You can. Processors such as Stripe let you write rules using IP country and card country. It is a blunt tool: it blocks genuine travellers and expats, and fraudsters use proxies and domestic cards. It makes most sense when you don't ship to those countries anyway.

Do I need a separate fraud prevention vendor?

Most small stores don't at first. Your processor's built-in scoring, 3DS, sensible velocity limits and good evidence handling cover the majority of risk. Consider a specialist when you process through several providers, need consistent rules across them, or your dispute rate stays high after the basics are in place.

Is it legal to ask customers for ID before shipping an order?

Generally you can ask for extra verification on risky orders, but you take on data protection duties for anything you collect, and rules differ by country. Keep requests proportionate, collect only what you need, and delete it when you no longer need it. Many merchants prefer a phone call or 3DS challenge over ID uploads.

How long should I keep order data for disputes?

At least long enough to cover the dispute window plus Visa CE3.0's 365-day look-back, so roughly 13 months or more for IP address, device, account and delivery data. Check the data protection rules that apply to you and state the retention period in your privacy notice.

What should I do if my processor freezes my payouts after a fraud spike?

Respond quickly and in writing. Explain what happened, what you have done (refunds, new controls, cleaned accounts) and send the evidence you gathered. Processors are mostly looking for proof that the problem is contained. Keep a copy of every message.

Bottom line and next step

Card-not-present fraud prevention is not one decision but a set of small, dull controls that add up: keep card data off your servers, verify CVV and address, use 3-D Secure where it pays off or where the law requires it, stop bots at every card endpoint, let your processor's scoring do the heavy lifting, and keep enough order data to win the disputes you should win. Watch your fraud and dispute counts every month, because network thresholds tightened in 2026 and acquirers act before the networks do.

Your next step: this week, map every place on your site where a card can be entered or saved, and check that each one has server-verified CAPTCHA and a rate limit. That single exercise closes the gap card testers look for first. Then work through the 30-day plan above, one week at a time.

Sources

All sources accessed September 28, 2026.

Labels
Previous Post Next Post