Types of Payment Fraud
Fraud terminology becomes confusing when a merchant tries to make every label answer the same question. It cannot. Card-not-present describes a payment context. Stolen-card fraud describes what credential was compromised. Bot attack describes how activity was automated. Card test
Types of Payment Fraud: A Practical Taxonomy for Merchants
Fraud terminology becomes confusing when a merchant tries to make every label answer the same question.
It cannot.
Card-not-present describes a payment context.
Stolen-card fraud describes what credential was compromised.
Bot attack describes how activity was automated.
Card testing describes what the attacker was trying to do at a particular stage.
These labels can overlap without contradicting one another.
The problem is therefore not that fraud teams have too many names.
It is that the names often describe different dimensions of the same incident.
A useful payment-fraud taxonomy should work more like coordinates than filing drawers.
Instead of asking:
“Which one fraud type is this?”
ask:
“What was compromised, how was it attacked, who was acting, where did it enter the lifecycle, and how did the merchant lose value?”
That produces a classification system merchants can actually use.
Why flat fraud lists break down
Consider the terms merchants routinely encounter:
CNP fraud;
stolen-card fraud;
account takeover;
card testing;
bots;
synthetic identity fraud;
promo abuse;
refund abuse;
friendly fraud;
subscription fraud;
marketplace fraud.
The terms do not share one classification rule.
Some describe an instrument or transaction context.
Some describe a compromised asset.
Some describe an attack mechanism.
Some describe an actor.
Others describe an abused merchant process or business model.
That is why trying to place them in one mutually exclusive list creates contradictions.
The brief's taxonomy discipline explicitly requires merchants to classify fraud across dimensions such as payment instrument, compromised object, attack mechanism, actor, and merchant loss mechanism.
Official fraud reporting also illustrates why definitions need dimensions and denominators. The latest EBA/ECB fraud report separates payment instruments and analyzes fraudulent transactions by both value and volume rather than treating “payment fraud” as one undifferentiated statistic. That does not create a universal merchant taxonomy, but it reinforces the need to state what is being classified and measured.
Axis 1: what was compromised or abused?
Start with the object.
Card credential
Valid card information belonging to another person is used without authorization.
This leads toward:
stolen-card fraud.
It can occur inside a CNP environment, but:
stolen card ≠ CNP.
One describes the credential problem.
The other describes the transaction context.
Customer account
An existing legitimate customer account is compromised.
The attacker may gain access to:
stored payment credentials;
balances;
loyalty value;
profile information;
addresses;
subscription entitlements;
marketplace payout settings.
This is the distinguishing object in:
account takeover.
The trusted account is compromised, not merely one payment credential.
Identity
The relevant problem can be:
stolen identity;
impersonation;
constructed/composite identity.
Synthetic identity fraud should remain narrow: the distinguishing characteristic is a constructed identity incorporating fabricated and potentially real elements, not simply any fake account.
Promotion or commercial entitlement
The abused object may be:
new-customer discount;
coupon;
referral reward;
signup bonus.
This is usually better classified as:
promo abuse
than as stolen-payment fraud when the customer is manipulating commercial eligibility rather than using an unauthorized instrument.
Refund process
The merchant's returns or refund workflow itself may be exploited.
That points to:
refund abuse.
Marketplace account or payout
In a marketplace, the targeted value may sit beyond the original payment:
buyer account;
seller account;
platform balance;
seller payout.
That changes both the actors and the loss path.
Axis 2: how did the activity occur?
The second axis is the mechanism.
Do not confuse mechanism with objective.
Manual activity
An individual may attempt fraudulent transactions directly.
“Manual” describes execution, not the fraud objective.
Bot or automated activity
Automation can increase:
speed;
scale;
repetition;
distribution.
Bots may be involved in:
card testing;
login attempts;
account creation;
promo abuse;
checkout activity.
Therefore:
Bot attack is an execution mechanism, not a synonym for card testing.
The dedicated Bot Payment Attacks article owns how automation changes scale and operational impact.
Credential stuffing
Automation or repeated attempts may use previously compromised account credentials against customer login systems.
The resulting fraud category may become:
account takeover
if an existing account is actually compromised.
Again:
credential stuffing = mechanism
while:
account takeover = compromised state/outcome.
Card testing
Card testing is more than “bot fraud.”
It describes an activity intended to establish whether payment credentials appear valid or usable.
It may be automated or manual.
The brief places it at the validation stage of the attack lifecycle and distinguishes it from the later fraudulent purchase itself.
A current Mastercard fraud/security article similarly treats card testing as a distinct early-stage fraud activity that can be associated with later forms of compromise, rather than using “card testing” as a synonym for every unauthorized card payment.
Axis 3: who is acting?
Actor matters because similar events can have very different meanings.
External attacker
A third party with no legitimate authority over the payment/account.
This is common in classic:
stolen-card fraud;
account takeover;
credential testing.
Legitimate customer or cardholder
The person may genuinely own the account or payment instrument but abuse:
a promotion;
refund process;
dispute process;
subscription terms.
That is why customer abuse cannot always be described using stolen-credential language.
Buyer or seller
Marketplace fraud requires side-specific classification.
A buyer can abuse one workflow.
A seller can abuse another.
A compromised seller account creates yet another problem.
Coordinated group
Several accounts or actors may work together.
But use that label only where evidence supports coordination.
Do not infer organized activity merely from similar transactions.
Axis 4: how does the merchant lose value?
Fraud type and loss type are not necessarily the same thing.
Unauthorized transaction loss
Payment proceeds but was not legitimately authorized by the proper customer/cardholder.
Goods or service loss
The merchant provides:
physical goods;
digital value;
services;
that cannot be economically recovered.
Chargeback or dispute loss
A transaction is later reversed through a dispute process.
Important:
chargeback is a payment dispute mechanism, not a fraud type.
Some chargebacks involve fraud.
Some do not.
And some fraud never generates a chargeback.
Refund loss
The merchant returns funds through its own refund process.
That refund might be:
legitimate;
fraud remediation;
the result of refund abuse.
Therefore:
refund ≠ fraud.
Incentive loss
A promotion is consumed by a customer/account that did not satisfy the merchant's intended eligibility rules.
Payout loss
Especially in marketplaces, the fraudulent value can leave through the payout side rather than the initial customer payment.
Add two supporting dimensions
The four axes above should form the core taxonomy.
Two additional dimensions make the merchant record substantially more useful.
Payment or business context
Examples:
card-not-present;
card-present;
subscription;
marketplace;
local payment method.
A context can contain several fraud types.
Lifecycle stage
Map where the behavior entered:
acquisition/access → validation → payment attempt → fulfillment → refund/dispute → payout → repeat/scale
The stage often tells the merchant which data source is most useful.
The Payment Fraud Taxonomy
A merchant-friendly taxonomy can be represented as follows:
Fraud label
Primary dimension
What it principally describes
Card-not-present fraud
Payment context
Fraud in remote card-payment environment
Stolen-card fraud
Compromised object
Unauthorized use of genuine card credentials
Account takeover
Compromised object
Existing trusted customer account is compromised
Card testing
Attack action/lifecycle
Credential validation activity
Bot payment attack
Attack mechanism
Automated execution/scale
Synthetic identity fraud
Identity/object
Abuse using a constructed identity
Promo abuse
Merchant process
Commercial-incentive eligibility is exploited
Refund abuse
Merchant process
Refund/return workflow is exploited
Friendly fraud
Actor + dispute behavior
Cardholder/first-party dispute behavior
Subscription fraud
Business-model context
Fraud or abuse exploiting recurring lifecycle
Marketplace fraud
Ecosystem context
Buyer/seller/account/payout risk in multi-party platform
The classifications are intentionally not mutually exclusive.
Card-not-present fraud: a context, not one mechanism
CNP fraud occurs in remote card-payment contexts where the traditional physical presentation of card/cardholder at the point of sale is absent.
Within that environment, fraud may involve:
stolen card credentials;
account takeover using stored credentials;
card testing;
automation.
The brief explicitly warns against turning:
CNP transaction
into:
fraudulent transaction.
Most legitimate ecommerce card purchases are also card-not-present.
EMVCo's current EMV 3-D Secure material likewise describes EMV 3DS as an authentication technology for card-not-present ecommerce payments, illustrating that “CNP” is fundamentally a remote payment environment in which legitimate and fraudulent transactions can both occur.
Stolen-card fraud: what credential is being misused
Stolen-card fraud is narrower.
It concerns unauthorized use of valid payment-card credentials belonging to someone else.
Potential credential compromise can originate from several sources, but the merchant article should stay focused on:
the unauthorized use;
merchant-visible evidence;
economic consequences.
Do not turn the page into instructions for acquiring or validating stolen credentials.
Account takeover: the account itself is the asset
Account takeover becomes distinct when the attacker compromises a legitimate customer account.
That can expose more than payment.
Depending on the product, the account could contain:
stored cards;
balance;
loyalty value;
subscriptions;
addresses;
marketplace details.
Payment events may be only one symptom.
The dedicated account-takeover article therefore needs account-security evidence as well as payment data.
Card testing: an action at the validation stage
A card-testing attack attempts to determine whether compromised or generated payment credentials are usable.
Merchant-visible characteristics may include combinations of:
unusual attempt velocity;
multiple payment credentials;
unusual decline patterns;
low-value activity;
automation indicators.
Those are signals.
They are not individually proof.
The article should avoid publishing thresholds or operational bypass/evasion detail.
Bot payment attacks: automation, not motive
A bot can automate:
card testing;
login attempts;
account creation;
promo abuse;
checkout activity.
So this taxonomy should store:
automation suspected/confirmed
as a separate attribute from:
fraud objective.
A transaction could be:
payment_context = card-not-present
compromised_object = card credential
attack_mechanism = automated/bot
attack_action = card testing
actor = external attacker
lifecycle_stage = credential validation
Every label contributes different information.
That is the central logic of the article.
Synthetic identity fraud: identity construction matters
Synthetic identity fraud should not become a catch-all for:
fake account;
stolen identity;
unusual identity data.
The distinguishing feature is a constructed identity, potentially built from a combination of real and fabricated information.
Its time horizon can also differ from immediate stolen-card misuse because a constructed identity may establish history before later abuse.
Promo abuse: commercial rules rather than stolen credentials
Promo abuse typically concerns exploitation of the merchant's offer rules.
Examples at a high level may include:
repeated new-customer eligibility;
manipulated referrals;
prohibited stacking;
incentive farming.
But heavy promotional use is not automatically abuse.
The commercial test is:
Did the behavior violate the intended eligibility or rules of the offer?
And the economic test is not simply:
“Did promo redemption rise?”
A highly redeemed promotion can still create profitable customer acquisition.
Refund abuse: abuse of the merchant-controlled return path
Refund abuse concerns intentional exploitation of:
return policies;
non-delivery claims;
damage claims;
partial refunds;
digital-goods refund processes.
Frequent legitimate returns are not sufficient evidence.
Merchant vertical, customer history, fulfillment records, and refund reasons matter.
Friendly fraud: dispute behavior needs careful language
“Friendly fraud” is especially easy to over-classify.
Potential first-party disputes can arise from:
genuine purchase confusion;
family/household use;
dissatisfaction;
buyer's remorse;
intentional attempts to retain goods/value while obtaining reversal.
Intent is often difficult to establish from a chargeback alone.
Where evidence is incomplete, prefer:
first-party dispute;
cardholder-initiated dispute;
suspected friendly fraud.
Do not accuse the customer beyond the evidence.
Subscription fraud: a lifecycle context
Subscriptions create fraud and abuse opportunities across:
signup → trial → initial payment → recurring billing → account use → renewal → cancellation/refund → dispute
The category can therefore include:
stolen-card signup;
repeated trial abuse;
account takeover;
recurring dispute behavior.
That is why “subscription fraud” is best treated as a business-model/lifecycle category, not one universal attack mechanism.
Marketplace fraud: an ecosystem category
Marketplace risk differs because the payment system involves multiple parties.
Potential actors include:
buyer;
seller;
compromised buyer account;
compromised seller account;
colluding parties;
external attacker.
Potential value movement can run:
buyer payment → platform → seller balance → payout
Fraud can therefore exist at:
pay-in;
order/fulfillment;
refund;
dispute;
seller account;
payout.
Marketplace fraud is not simply ecommerce card fraud with more participants.
Fraud and abuse should not be forced into one legalistic label
For risk operations, the taxonomy can maintain separate top-level states such as:
unauthorized_fraud
merchant_policy_abuse
suspicious_activity
customer_dispute
legitimate_activity
unresolved
That allows a merchant to say:
“This behavior violates our promo rules.”
without making the stronger unsupported claim:
“This customer committed payment fraud.”
Classification quality matters operationally and reputationally.
Suspicious is not confirmed
A risk signal can indicate elevated probability.
It does not establish fraud.
The brief requires explicit separation among:
risk signal;
anomaly;
suspicious activity;
confirmed fraud;
merchant policy abuse;
disputed transaction.
That distinction should exist in both editorial language and merchant data models.
Poor taxonomy
fraud = true
Better taxonomy
risk_status = suspicious
fraud_family = suspected_account_takeover
confirmation_source = none_yet
confidence = merchant_defined
Later, evidence may change the classification.
Chargeback data is evidence—not perfect truth
A chargeback can provide useful post-payment information.
But chargebacks are delayed and incomplete.
Fraud blocked before completion never becomes a chargeback.
And many chargebacks concern issues other than fraud.
The brief specifically warns against making chargeback outcomes the ground-truth definition of fraud.
Refund data has the same limitation
High refund activity can mean:
legitimate returns;
product/service failure;
cancellation;
fraud remediation;
refund abuse.
The refund event alone does not identify the cause.
A signal is not a fraud category
This distinction prevents an enormous amount of sloppy fraud reporting.
Signal
An observed fact or feature.
Examples:
new device;
address change;
unusual velocity.
Rule/model
Logic that evaluates signals.
Decision
Operational action:
approve;
decline;
review;
challenge;
limit.
A new device should therefore not appear in a fraud taxonomy as:
“new-device fraud.”
It is evidence the risk system may evaluate.
The brief explicitly states that a new device is a signal, not a universal block rule.
Signals can legitimately occur in good transactions
Device and network anomalies can be caused by:
travel;
VPN use;
shared devices;
shared networks;
device replacement;
privacy technology.
Identity differences can also reflect legitimate international naming/address conventions.
Therefore signals should normally be combined with context and baseline behavior rather than interpreted in isolation.
Detection and prevention are separate
This article owns taxonomy, not a fraud-prevention playbook.
But one distinction is necessary.
Detection
Identifying that activity appears unusual or higher risk.
Control
Taking an action in response.
Possible high-level responses can include:
authentication;
additional verification;
review;
limits;
delayed fulfillment;
decline.
The right control depends on the fraud category and merchant context.
Do not jump directly from one risk signal to a permanent block.
Classification changes which control makes sense
Consider the differences conceptually.
Stolen credential
Relevant merchant problem:
Is the person using the credential authorized?
Account takeover
Problem:
Has the trusted account itself been compromised?
Card testing
Problem:
Is the payment endpoint being used to validate credentials at scale or unusual velocity?
Promo abuse
Problem:
Is the customer legitimately eligible for the incentive?
Refund abuse
Problem:
Is the refund claim consistent with fulfillment/customer history?
Applying one universal “fraud rule” across all five would miss the point.
Authentication does not solve every category
Cardholder authentication can help with some unauthorized payment scenarios.
EMVCo currently describes EMV 3DS as enabling authentication in CNP ecommerce transactions while aiming to balance security with unnecessary checkout friction.
But authentication does not automatically solve:
promo abuse;
refund abuse;
some first-party disputes;
because the customer may genuinely control the account or card.
That is another reason the merchant must classify the problem before selecting a control.
The Payment Fraud Taxonomy
The article's primary practical asset should be a four-axis map.
Axis A — Compromised/abused object
card credential;
customer account;
identity;
promo entitlement;
refund process;
marketplace buyer/seller account;
payout.
Axis B — Attack mechanism
manual;
bot/automation;
credential stuffing;
card testing;
social engineering at a high level.
Axis C — Actor
external attacker;
legitimate customer/cardholder;
buyer;
seller;
coordinated actor set;
unknown.
Axis D — Loss/process outcome
unauthorized purchase;
fulfillment loss;
dispute;
refund;
incentive loss;
payout loss;
operational attack cost.
Then add metadata:
Payment context
CNP;
card-present where applicable;
bank/wallet/method;
subscription;
marketplace.
Lifecycle stage
account/credential acquisition;
validation;
transaction;
fulfillment;
refund/dispute;
payout.
Evidence status
signal only;
suspected;
confirmed;
disputed;
unresolved.
This converts the taxonomy from editorial vocabulary into an operational data model.
A practical multi-label incident record
Instead of:
fraud_type = card_testing
store something closer to:
payment_context = card_not_present
compromised_object = card_credential
attack_mechanism = automated
attack_action = card_testing
actor_class = external_attacker
lifecycle_stage = credential_validation
merchant_loss_type = operational_cost
confirmation_status = suspected
If a later unauthorized purchase occurs, that may become a separate event linked to the same credential or incident.
The point is not to force every merchant into these exact field names.
The point is to stop overwriting one useful label with another.
Which fraud metric belongs to which problem?
A good taxonomy should also prevent KPI misuse.
Confirmed payment fraud
Useful metrics:
Fraud rate by count
confirmed fraudulent transactions
÷ defined relevant transaction count
Fraud rate by value
confirmed fraudulent payment value
÷ defined relevant payment value
Do not compare these as if they were the same rate.
Card testing or bot activity
Transaction fraud rate can miss the real operational problem.
Potential metrics include:
suspicious attempts;
attempt velocity;
unusual decline bursts;
payment-endpoint attack traffic.
Do not call every failed attempt fraud.
Promo abuse
Potentially track:
incentive cost;
repeat-account patterns;
retained acquisition;
post-promo customer value.
The goal is not simply fewer redemptions.
Refund abuse
Potentially track:
refund rate by account;
repeated refund behavior;
refund reasons;
fulfillment evidence.
No universal “too many refunds” threshold should be published.
Account takeover
Potential metrics can include:
confirmed takeover incidents;
account-change anomalies;
takeover-confirmed loss;
post-login payment anomalies.
Do not measure ATO solely from chargebacks.
Fraud rate is not financial loss
Even confirmed fraud does not always equal merchant loss.
A merchant may recover:
funds;
goods;
disputed amounts;
fulfillment before delivery.
Where possible define:
Net fraud loss
gross fraud-associated loss − recoveries
and state exactly what is included.
The dedicated True Cost and Net Revenue cluster should own the deeper financial waterfall.
Industry changes the importance of the categories
The taxonomy remains stable, but exposure changes by business model.
Digital goods and gaming
Potentially important:
stolen credentials;
account takeover;
testing;
rapid/irreversible digital fulfillment.
SaaS/subscriptions
Potentially important:
trial abuse;
account compromise;
recurring-payment disputes;
repeated promotional signup behavior.
Retail
Potentially important:
stolen-card fraud;
refund abuse;
promo abuse.
Travel
Potentially important:
high-ticket unauthorized payments;
disputes;
delayed fulfillment.
Marketplaces
Potentially important:
buyer fraud;
seller fraud;
account compromise;
payout manipulation.
These are causal examples from the brief, not universal prevalence rankings.
Geography should modify the evidence, not stereotype customers
Fraud controls and observed behavior can differ because of:
payment methods;
authentication requirements;
regulations;
identity infrastructure;
ecommerce/payment norms.
Do not convert that into:
“Country X is fraudulent.”
Use merchant- and market-specific evidence.
Current official fraud reporting illustrates denominator discipline
The EBA/ECB's latest joint payment-fraud report covers EEA data for 2022–2024 and reports fraud separately across payment instruments, including card payments and credit transfers, while distinguishing value from volume.
The editorial lesson for merchants is not to import EEA aggregate rates as their benchmark.
It is:
Fraud statistics are meaningless without fraud definition, payment method, geography, period, and denominator.
That rule is directly required by the brief.
chargeback;
credit-card fraud;
other fraud;
cancellation/refund;
rather than collapsing all negative payment events into a single generic fraud state.
That supports a careful merchant-facing point:
Operational payment systems benefit from preserving event type and context instead of storing one generic “fraud” label.
risk evaluation;
merchant-configurable/custom rules;
alert/decline actions;
human review of higher-risk transactions;
transaction tracking and reporting.
Those capabilities fit naturally after the article has established that merchants need:
signals → classification → decision
rather than before it.
Do not convert the public product description into claims about:
fraud reduction percentages;
false-positive performance;
detection accuracy.
Those require approved evidence.
A merchant taxonomy should preserve uncertainty
An operational schema should allow:
classification = suspected_card_testing
instead of forcing:
classification = confirmed_fraud
when only risk evidence exists.
Suggested evidence fields:
classification_status
evidence_source
first_observed_at
confirmed_at
confirmation_method
related_payment_id
related_account_id
related_dispute_id
This helps data teams distinguish a model's decision from the final outcome.
Ground-truth labels have different strengths
Possible evidence sources include:
customer-confirmed unauthorized activity;
merchant investigation;
chargeback;
refund;
abuse-policy determination;
risk-engine output.
These are not interchangeable.
A risk-model decline is evidence of a decision.
It is not automatically evidence that the payment was actually fraudulent.
Why taxonomy quality affects legitimate growth
A merchant with poor labels may respond to the wrong problem.
For example:
Observed problem: increased automated payment attempts.
Incorrect conclusion:
“Card fraud is rising, so tighten every checkout rule.”
Better questions:
Are the attempts actually card testing?
Are they account-login automation?
Are they promo-account creation?
Which customer cohort is affected?
What percentage is merely suspicious rather than confirmed?
Which controls could affect legitimate customers?
The objective across the cluster is not zero suspicious activity.
It is profitable legitimate growth after fraud and control friction.
Classification should come before escalation
A practical response sequence is:
OBSERVE
↓
CLASSIFY SIGNAL
↓
IDENTIFY POSSIBLE FRAUD FAMILY
↓
ASSESS EVIDENCE
↓
SELECT PROPORTIONATE CONTROL
↓
MEASURE FRAUD + LEGITIMATE CUSTOMER EFFECT
This keeps a risk signal from becoming an automatic permanent decision.
What this article does not own
This page should link rather than expand deeply into:
how to optimize fraud tools;
detailed 3DS strategy;
fraud-model precision/recall;
chargeback economics;
refund-fee mechanics;
net-revenue modeling.
Its job is to give every subsequent fraud article a common language.
This brief gives Article 2 a very specific job: build the classification system for the entire Payment Fraud Fundamentals cluster. It should explain why categories overlap, teach merchants what dimension each label describes, and then hand detailed mechanics to the dedicated articles.
The strongest differentiator is to treat fraud terminology as a coordinate system rather than a set of mutually exclusive boxes. That preserves the brief’s thesis while giving the article a more distinctive opening than another transaction scenario.
This gives Article 2 a clear cluster role: the common language and data model that every later fraud article can inherit, rather than another broad fraud explainer or prevention checklist.
Types of Payment Fraud — Editorial, SEO and Publication Package
Editorial interpretation
Article: Types of Payment Fraud
Working title: Types of Payment Fraud: A Practical Taxonomy for Merchants
Search intent: fraud classification and comparison.
Fraud/abuse definition
For this article, payment fraud is deceptive or unauthorized activity intended to obtain value through a payment, payment instrument, customer account, identity, or related merchant process.
But the cluster also needs to recognize payment abuse: harmful use of legitimate merchant functionality in ways that violate intended commercial rules, such as some promo, refund, or subscription abuse.
The distinction matters because not every harmful customer action involves stolen credentials or an external attacker.
Fraud actors
Potential actors include:
external attacker;
automated attacker;
legitimate cardholder/customer;
buyer;
seller;
coordinated group;
compromised legitimate account.
The article should classify the actor without assuming motive or criminality where evidence is incomplete.
Targeted assets/processes
The main taxonomy needs to distinguish what is actually being compromised or abused:
payment-card credential;
customer account;
identity;
merchant promotion;
refund process;
subscription lifecycle;
marketplace buyer/seller account;
payout process.
Attack mechanism
Mechanism is a separate axis:
manual;
bot/automation;
credential stuffing;
card testing;
social engineering at a high level.
The crucial point:
“bot” describes how activity is executed, not necessarily what fraud objective the attacker is pursuing.
The brief expressly assigns bots ownership as an attack mechanism rather than one fraud objective.
Entry point in the lifecycle
Fraud can enter at different stages:
reconnaissance → credential/account acquisition → validation → account/payment preparation → transaction → fulfillment/value extraction → refund/dispute/payout → repeat/scale.
Different labels can therefore describe different parts of one incident.
Merchant loss mechanism
Potential consequences include:
unauthorized payment;
goods/service delivered;
payout loss;
refund loss;
promo/incentive loss;
chargeback;
operating expense.
This article identifies the loss category but does not recreate the full net-revenue economics owned by the True Cost and Net Revenue cluster.
False-positive/customer-friction risk
The classification error itself can create false positives.
If a merchant treats:
a new device;
unusual geography;
high velocity;
a dispute;
as proof of one fraud category, it can choose controls that unnecessarily block legitimate customers.
The article must consistently distinguish:
signal → rule/model → decision
rather than treating a signal as a verdict.
Unique evidence anchor
One incident may correctly be described as:
card-not-present;
stolen-card;
bot-assisted;
card testing.
Those labels are not competing answers.
They describe different dimensions.
Unique thesis
There is no single flat list of payment fraud types. A useful merchant taxonomy separates what was compromised, how the activity occurred, who performed it, and which merchant process or loss mechanism was abused.
Editorial position
Merchants should store multiple fraud attributes rather than forcing each incident into one catch-all category.
Common assumption challenged
“Every fraud incident belongs to exactly one fraud category.”
Merchant decision
Design a fraud taxonomy that helps risk, payments, operations, finance, and data teams answer:
what happened;
what was targeted;
how it happened;
who appears to have acted;
where it entered the lifecycle;
how the merchant lost value;
how confident the label is.
Selected format
Fraud taxonomy map.
Structural rationale
The page should move from:
language problem → classification axes → category map → overlap examples → evidence quality → signals → merchant loss → safe control boundary
rather than becoming thirteen mini fraud articles.
Proposed architecture
Fraud types are coordinates, not boxes
Why payment-fraud labels overlap
Axis 1: what was compromised?
Axis 2: how did the activity occur?
Axis 3: who performed it?
Axis 4: which merchant process or loss mechanism was abused?
Add lifecycle stage and payment context
The major payment-fraud families
Why CNP, stolen-card, bots, and card testing are not synonyms
Fraud vs abuse
Fraud vs chargeback and refund
Suspicion vs confirmed fraud
Signals do not belong in the taxonomy as outcomes
Payment Fraud Taxonomy
How to store fraud labels operationally
Which metric belongs to which fraud problem
Industry and business-model context
What taxonomy changes about controls
Final classification test
Original practical asset — Payment Fraud Taxonomy
Core taxonomy matrix
Axis
Merchant question
Example values
Compromised/abused object
What is being targeted?
Card credential, account, identity, promo, refund process, marketplace account
Attack mechanism
How is it being executed?
Manual, automation/bot, credential stuffing, card testing
Actor
Who is acting?
External attacker, customer/cardholder, buyer, seller, coordinated group
Loss/process mechanism
How does merchant value disappear?
Unauthorized purchase, dispute, refund, promo loss, payout loss, fulfillment loss
Add:
Context
Merchant question
Payment/business context
Where does this happen?
Lifecycle stage
When does it enter?
Evidence status
How certain is the label?
Taxonomy crosswalk
Term
What it tells you
What it does not tell you
CNP fraud
Remote card-payment context
Which credential attack occurred
Stolen-card fraud
Card credential belongs to another person
Whether bots were involved
Account takeover
Existing customer account compromised
Whether payment credential itself was stolen independently
Card testing
Credential-validation action
Whether it was automated
Bot attack
Automation mechanism
Underlying fraud objective
Synthetic identity
Constructed identity
That every identity mismatch is fraud
Promo abuse
Promotion rules exploited
That payment credential is unauthorized
Refund abuse
Merchant refund process exploited
That a chargeback occurred
Friendly fraud
Cardholder/first-party dispute behavior
That every dispute is malicious
Subscription fraud
Recurring-business context
One specific attack mechanism
Marketplace fraud
Multi-party ecosystem context
One specific actor or payment method
This table should be the page's primary scan-friendly asset.
Fraud taxonomy data model
A merchant could implement fields such as:
fraud_family
payment_context
compromised_object
attack_mechanism
attack_action
actor_class
merchant_process_abused
lifecycle_stage
loss_mechanism
risk_status
confirmation_status
confirmation_source
related_payment
related_account
related_refund
related_dispute
The field names are illustrative.
The important design choice is multi-label storage.
Classification decision aid
When an analyst encounters an incident, ask in this order:
What object or process is compromised?
Card? Account? Identity? Promotion? Refund? Payout?
What activity occurred?
Purchase? Login? Validation? Refund claim? Dispute? Payout change?
How was it performed?
Human? Automated? Credential stuffing? Repeated testing?
Who appears to be acting?
External party? Actual customer? Buyer? Seller? Unknown?
Where is the merchant loss?
Payment? Goods? Refund? Promotion? Chargeback? Payout?
What is the evidence state?
Signal? Suspicion? Confirmed fraud? Confirmed policy abuse? Unresolved?
Only then assign operational labels.
SEO metadata
Recommended SEO title
Types of Payment Fraud: A Merchant Taxonomy
Alternative:
Types of Payment Fraud Explained for Merchants
H1
Types of Payment Fraud: A Practical Taxonomy for Merchants
Meta description
Understand the main types of payment fraud and how CNP fraud, stolen cards, account takeover, bots, card testing, abuse, refunds and disputes overlap.
URL slug
/solve/fraud-is-blocking-growth/payment-fraud-fundamentals/types-of-payment-fraud/
types of payment fraud
Secondary keywords
payment fraud types
types of online payment fraud
ecommerce fraud types
digital payment fraud
card fraud types
merchant fraud examples
payment abuse types
These are the assigned terms in the creative brief.
Related entities
payment fraud
ecommerce fraud
card-not-present
stolen card
card testing
account takeover
bots
synthetic identity
promo abuse
refund abuse
chargeback
friendly fraud
subscription fraud
marketplace fraud
risk signal
fraud detection
Article excerpt
Payment-fraud categories overlap because they often answer different questions. CNP describes context, stolen-card fraud describes the compromised credential, bots describe an attack mechanism, and card testing describes an activity. A useful merchant taxonomy stores these dimensions separately instead of forcing every incident into one label.
Search-intent coverage
Search intent
Answer location
types of payment fraud
Taxonomy overview
payment fraud types
Core taxonomy
types of online payment fraud
CNP + digital categories
ecommerce fraud types
Category crosswalk
card fraud types
CNP, stolen card, card testing
difference between CNP and stolen card fraud
Dedicated distinction
bot fraud vs card testing
Mechanism distinction
account takeover vs stolen card
Compromised-object distinction
friendly fraud vs refund abuse
Merchant-process distinction
fraud vs chargeback
Evidence/loss section
payment abuse types
Fraud vs abuse
synthetic identity vs identity theft
Synthetic identity section
Internal-link architecture
Because this is the taxonomy article, it should act as the navigation hub for the specialized pages.
What Is Payment Fraud?
Link when defining the conceptual boundary.
Suggested anchor:
what payment fraud means
Card-Not-Present Fraud
Anchor:
card-not-present fraud
Stolen Card Fraud
Anchor:
stolen-card fraud
Account Takeover Fraud
Anchor:
account takeover fraud
Card Testing Attacks
Anchor:
card testing attacks
Bot Payment Attacks
Anchor:
bot payment attacks
Synthetic Identity Fraud
Anchor:
synthetic identity fraud
Promo Abuse
Anchor:
promotion and incentive abuse
Refund Abuse
Anchor:
refund abuse
Friendly Fraud
Anchor:
friendly fraud and first-party disputes
Subscription Fraud
Anchor:
subscription fraud and abuse
Marketplace Fraud
Anchor:
marketplace fraud
Do not reproduce each destination article's mechanics here.
Google's current Search Essentials recommend helpful people-first content and natural use of the terms people search for in titles, headings, alt text, and link text.
Supporting visual
Payment Fraud Taxonomy Map
Use a four-quadrant/grid structure.
Column 1 — Compromised object
Card credential
Customer account
Identity
Promo entitlement
Refund process
Marketplace account
Column 2 — Mechanism
Manual
Bot
Credential stuffing
Card testing
Column 3 — Actor
External attacker
Customer/cardholder
Buyer
Seller
Unknown/coordinated
Column 4 — Loss/process
Unauthorized purchase
Dispute
Refund
Promo loss
Payout loss
Fulfillment loss
Underneath, show two horizontal metadata bands:
Payment/business context
and
Lifecycle + evidence status
Image alt text
Payment fraud taxonomy showing fraud classified by compromised object, attack mechanism, actor, merchant loss mechanism, payment context, lifecycle stage and confirmation status.
Authoritative source recommendations
Merchant first-party risk data
Best source for:
incident labels;
payment/account relationships;
fraud confirmations;
manual-review outcomes.
Merchant dispute/refund/account data
Required to distinguish:
fraud;
chargeback;
refund abuse;
account takeover.
EBA/ECB payment-fraud reporting
Useful for current evidence on the importance of defining payment instrument, value/volume, geography, and timeframe in fraud statistics. The 2025 joint report covers EEA payment-fraud data through 2024.
EMVCo
Use for authoritative CNP authentication context rather than merchant fraud prevalence claims.
Card-network security material
Current Mastercard material is useful as first-party network evidence that card testing can be treated as a specific early-stage fraud/security activity rather than a synonym for all card fraud.
Useful for demonstrating current operational separation among:
chargeback;
card fraud;
other fraud;
refund/cancellation.
Useful for verified high-level descriptions of:
risk evaluation;
custom rules;
review;
transaction tracking/reporting.
Proposed author and reviewers
Proposed author:
Do not invent a name.
Recommended reviewers:
fraud/risk lead;
payments risk specialist;
data scientist/analyst;
chargeback operations lead.
Additional reviewer where appropriate:
account-security specialist;
marketplace/subscription specialist.
The brief requires named expertise and warns against inventing review completion.
Highest-value human contribution
An approved, anonymized fraud-label audit.
For example:
take a sample of incidents historically labeled simply “fraud”;
reclassify by object, mechanism, actor, lifecycle and loss;
show how often the single label obscured another operationally useful dimension.
Do not reveal exploitable fraud rules or sensitive thresholds.
Fraud-definition fact-check items
For every named category verify:
what dimension the term represents;
whether it is fraud, abuse, context, mechanism, actor, or outcome;
whether merchant intent/customer intent is known;
confirmation methodology;
relationship to adjacent categories.
Particular checks:
CNP is not synonymous with stolen card.
Bot is not synonymous with card testing.
Account takeover is not synonymous with stolen payment credentials.
Synthetic identity is not synonymous with any fake account.
Refund abuse is not synonymous with friendly fraud.
Chargeback is not synonymous with fraud.
Attack-mechanism fact-check items
Verify that descriptions remain defensive and high level.
Do not publish:
credential-validation instructions;
bypass methods;
velocity-evasion techniques;
bot evasion;
authentication bypass;
account takeover procedures.
The brief makes the safety boundary explicit.
Signal/data fact-check
For every proposed signal ask:
Is it actually observable by the merchant?
Which provider/system supplies it?
Is it a raw signal or model output?
Could legitimate customer behavior produce it?
Is the article accidentally treating it as proof?
Examples requiring caution:
new device;
IP/location mismatch;
identity mismatch;
unusual velocity;
refund frequency;
issuer decline.
The brief explicitly prohibits treating issuer decline as confirmed fraud.
Fraud-statistics fact-check
For every statistic state:
fraud definition;
count or value;
payment method;
market;
merchant segment;
channel;
period;
denominator;
source.
Do not compare incompatible fraud rates.
The EBA/ECB 2025 report is current and useful for contextual evidence, but its EEA aggregate figures should not be presented as a universal ecommerce-merchant benchmark.
Industry/market fact-check
Avoid statements such as:
“Gaming has more fraud.”
unless supported by a current, comparable source.
Safer framing:
“Instant digital fulfillment can change the loss/recovery economics of fraud.”
That follows causally from the merchant process rather than asserting an unsupported prevalence ranking.
Similarly, do not label a country or region “high fraud.”
Regulatory/privacy flags
Fraud analysis can use:
identity information;
account data;
device/network information;
behavioral information;
automated decisions;
authentication.
Applicable requirements vary by jurisdiction.
Information notice: This article provides general information and does not constitute legal, regulatory, privacy, security, or compliance advice. Merchants should verify applicable requirements with qualified advisers, payment providers, fraud specialists, and relevant authorities.
Safety/abuse-enablement check
The article is safe when it explains:
what card testing is;
why velocity can be a signal;
how bots change scale;
where account takeover enters;
which merchant data helps identify patterns.
It should not explain:
how to test cards successfully;
which transaction values evade detection;
how to distribute bot attempts;
how to defeat velocity rules;
how to bypass authentication;
how to exploit promo/refund workflows.
Keep mechanics merchant-defensive.
Amber-flag claims
“These are the 10/13 definitive types of payment fraud.”
Do not publish.
The article's thesis is that classification is multi-dimensional.
“CNP fraud means stolen-card fraud.”
Wrong.
CNP is a transaction context.
“Card testing is bot fraud.”
Incomplete.
Automation can be a mechanism for testing; testing describes the action.
“Every bot payment is fraudulent.”
Unsupported.
“A new device means account takeover.”
Wrong.
It is a signal.
“A chargeback confirms fraud.”
Wrong.
“High refunds indicate refund abuse.”
Unsupported without context.
“Friendly fraud means the customer intentionally lied.”
Too strong unless intent is established.
“Fake accounts are synthetic identities.”
Not necessarily.
“All subscription payment failures are fraud.”
Wrong.
Do not publish.
Do not publish without approved evidence.
risk evaluation;
custom payment rules;
alert/decline functionality;
human review;
transaction tracking/reporting.
Current Pingback documentation distinguishes several negative-payment event reasons, including chargeback, credit-card fraud, other fraud, and canceled/refunded activity.
Before publication, internally verify:
current meanings of “credit card fraud” vs “other fraud” in operational data;
whether merchants can retrieve those classifications consistently in reporting;
which risk-review states are exposed;
which account/device signals are merchant-visible;
which velocity indicators are available;
which authentication results can be consumed;
how Passport Risk describes rules vs ML decisions internally;
current human-review scope;
fraud-confirmation methodology;
whether chargeback reason and fraud labels are stored separately;
refund-abuse support;
account-takeover detection capabilities;
bot/automation capabilities;
promo-abuse capabilities;
any approved merchant first-party fraud taxonomy or case study;
any approved performance claims;
terminology that should remain internal/security-sensitive.
Do not publish proprietary rules, thresholds, model logic, or attack-specific defensive gaps.
Cluster sameness audit
Field
Types of Payment Fraud
Opening device
Fraud vocabulary as a coordinate system
Fraud actor
Multiple; actor itself is one taxonomy axis
Targeted asset
Multiple; object itself is an axis
Entry point
Lifecycle is metadata, not one fixed stage
Attack mechanism
Mechanism separated from fraud objective
Merchant loss
Loss mechanism separated from fraud label
Primary signals
Signals explicitly kept outside confirmation labels
False-positive risk
Treating anomalies/categories as proof
Primary format
Fraud taxonomy map
Unique evidence anchor
One incident can validly carry multiple fraud labels
Editorial position
Use multi-dimensional classification
Merchant decision
Design incident taxonomy/schema
Original framework
Payment Fraud Taxonomy
Primary metric
Category-specific, not one universal fraud KPI
Conclusion
Classification test
Closing device
Six-question incident record
This keeps Article 2 uniquely responsible for taxonomy, while the following articles own deep mechanics.
Final classification test
Before a merchant adds a new “fraud type” to its dashboard, ask six questions.
What does the label classify?
Does it describe:
payment context?
compromised object?
mechanism?
actor?
merchant process?
loss?
If the team cannot answer, the label is probably ambiguous.
Can one transaction legitimately carry this label and another fraud label?
If yes, the fields should probably coexist rather than compete.
“Bot” and “card testing” are the obvious example.
Are we recording evidence or claiming an outcome?
Unusual IP
is evidence.
Confirmed account takeover
is an outcome classification.
Do not store them at the same semantic level.
Does the category identify the merchant loss?
A promo-abuse incident and a stolen-card purchase can both cost money.
They lose it through different mechanisms.
That distinction determines which team and metric should own the problem.
Are we accidentally describing the payment lifecycle rather than the fraud?
CNP, subscription, and marketplace can provide important context.
They should not erase the underlying fraud mechanism.
How certain are we?
The fraud record should preserve whether the classification is:
suspected;
confirmed;
policy abuse;
disputed;
unresolved.
A strong fraud taxonomy therefore does not answer:
“Which single type of fraud happened?”
It answers:
“What was targeted, how did the activity occur, who appears to have acted, where did it enter the payment or account lifecycle, how did the merchant lose value, and how strong is the evidence?”
Once those questions are separated, the apparent overlap between CNP fraud, stolen cards, account takeover, card testing, bots, customer abuse, refunds and disputes stops being a terminology problem.
It becomes useful merchant data.
Google/search publication checklist
Primary query answered early.
Taxonomy is original and genuinely useful.
CNP, stolen card, bot and testing are not used interchangeably.
Fraud vs abuse is explicit.
Fraud vs chargeback/refund is explicit.
Suspicion vs confirmation is explicit.
Signals are not described as proof.
Each detailed fraud family links to its dedicated article.
No unsafe operational attack instructions.
Current external evidence is dated/contextualized.
Named expert author/reviewer before publication.
Supporting visual has descriptive alt text.
Article structured data reflects visible author, headline, image and publication/update dates.
Google's current people-first guidance emphasizes original, substantive content, clear sourcing and visible expertise—making the original multi-axis taxonomy and a named fraud practitioner materially more useful than an undifferentiated list of fraud definitions.
Google's current Article structured-data documentation supports properties such as headline, author, imagery, datePublished, and dateModified; those values should match the visible article.
Publication status
Research refreshed: August 17, 2026.
Editorially ready: Yes.
SEO architecture ready: Yes.
Payment Fraud Taxonomy ready: Yes.
Safe for merchant-facing publication: Yes, subject to normal editorial/security review.
Before publication
confirm public Passport claims remain current;
verify pingback/event-reason meanings with product/risk owners;
ensure no internal security rules or thresholds appear;
have a fraud/risk practitioner validate the taxonomy;
have data/operations validate the incident-schema fields;
preserve suspected vs confirmed classifications;
remove any unsupported prevalence rankings;
define denominator for every fraud statistic;
keep fraud, chargeback, refund and abuse labels separate;
ensure every dedicated fraud family links to its own article;
do not let this taxonomy page expand into the detailed prevention cluster.
Publication principle
The article should change the reader's starting question.
Not:
“Which fraud type is this?”
But:
“Which dimension am I describing?”
That one correction makes the rest of the Payment Fraud Fundamentals cluster substantially easier to understand—and substantially more useful to operate.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗