Types of Payment Fraud

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 1. Editorial interpretation Article: Types of Payment Fraud Working title: Types of Payment Fraud: A Practical Taxonomy for Merchants Primary keyword: types of payment fraud 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: 1. what happened; 2. what was targeted; 3. how it happened; 4. who appears to have acted; 5. where it entered the lifecycle; 6. how the merchant lost value; 7. 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.

2. Proposed architecture 1. Fraud types are coordinates, not boxes 2. Why payment-fraud labels overlap 3. Axis 1: what was compromised? 4. Axis 2: how did the activity occur? 5. Axis 3: who performed it? 6. Axis 4: which merchant process or loss mechanism was abused? 7. Add lifecycle stage and payment context 8. The major payment-fraud families 9. Why CNP, stolen-card, bots, and card testing are not synonyms 10. Fraud vs abuse 11. Fraud vs chargeback and refund 12. Suspicion vs confirmed fraud 13. Signals do not belong in the taxonomy as outcomes 14. Payment Fraud Taxonomy 15. How to store fraud labels operationally 16. Which metric belongs to which fraud problem 17. Industry and business-model context 18. What taxonomy changes about controls

20. Final classification test

4. 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?

5. 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.

6. 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.

7. Classification decision aid When an analyst encounters an incident, ask in this order: 1. What object or process is compromised? Card? Account? Identity? Promotion? Refund? Payout? 2. What activity occurred? Purchase? Login? Validation? Refund claim? Dispute? Payout change? 3. How was it performed? Human? Automated? Credential stuffing? Repeated testing? 4. Who appears to be acting? External party? Actual customer? Buyer? Seller? Unknown? 5. Where is the merchant loss? Payment? Goods? Refund? Promotion? Chargeback? Payout? 6. What is the evidence state? Signal? Suspicion? Confirmed fraud? Confirmed policy abuse? Unresolved? Only then assign operational labels.

8. 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/ Primary keyword 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.

9. 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

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. Signal/data fact-check For every proposed signal ask: 1. Is it actually observable by the merchant? 2. Which provider/system supplies it? 3. Is it a raw signal or model output? 4. Could legitimate customer behavior produce it? 5. 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.

17. 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.

18. 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.”

19. 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.

20. 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.

21. 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:

2. current meanings of “credit card fraud” vs “other fraud” in operational data; 3. whether merchants can retrieve those classifications consistently in reporting; 4. which risk-review states are exposed; 5. which account/device signals are merchant-visible; 6. which velocity indicators are available; 7. which authentication results can be consumed; 8. how Passport Risk describes rules vs ML decisions internally; 9. current human-review scope; 10. fraud-confirmation methodology; 11. whether chargeback reason and fraud labels are stored separately; 12. refund-abuse support; 13. account-takeover detection capabilities; 14. bot/automation capabilities; 15. promo-abuse capabilities; 16. any approved merchant first-party fraud taxonomy or case study; 17. any approved performance claims; 18. terminology that should remain internal/security-sensitive. Do not publish proprietary rules, thresholds, model logic, or attack-specific defensive gaps.

23. 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.

24. Final classification test Before a merchant adds a new “fraud type” to its dashboard, ask six questions. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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.

25. 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.

26. 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

2. confirm public Passport claims remain current; 3. verify pingback/event-reason meanings with product/risk owners; 4. ensure no internal security rules or thresholds appear; 5. have a fraud/risk practitioner validate the taxonomy; 6. have data/operations validate the incident-schema fields; 7. preserve suspected vs confirmed classifications; 8. remove any unsupported prevalence rankings; 9. define denominator for every fraud statistic; 10. keep fraud, chargeback, refund and abuse labels separate; 11. ensure every dedicated fraud family links to its own article; 12. 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.