Robots Atlas>ROBOTS ATLAS
Infrastructure

Chargeback fraud

ActivePublished: 30 July 2026Updated: 30 July 2026Published
Key innovation
Abuse of the chargeback mechanism: the payer disputes a transaction with the issuing bank to recover funds despite having received the goods/service - the merchant loses the funds plus a chargeback fee.
Category
Infrastructure
Abstraction level
Pattern
Operation level
ApplicationDeployment
Use cases
Threat modeling for online paymentsDesigning (ML) fraud detection systemsProtecting sales of API credits/tokensAnalyzing abuse that feeds the relay gray marketRisk scoring and KYC/limit policies

How it works

1) A purchase occurs - the payer uses their own card (friendly fraud) or stolen data (criminal fraud); in card testing these are mass small transactions. 2) The goods/service are delivered or the resource (credits/tokens, compute) is consumed. 3) The payer or the legitimate cardholder files a dispute with the issuing bank, contesting the transaction. 4) The bank reverses the funds to the payer; the merchant loses the transaction amount, the delivered resource and a chargeback fee. A high chargeback ratio risks penalties from payment processors.

Problem solved

From the merchant's perspective this is a threat, not a solution: it causes financial losses, fees and loss of goods/services. It is modeled in order to design defenses (fraud detection, 3-D Secure, KYC).

Components

Payment instrumentTransaction source

The payer's own card (friendly fraud) or stolen card data (criminal fraud).

Official

Transaction / resource deliveryValue extraction

Purchase and delivery of goods/service or consumption of credits/tokens (compute).

Official

Dispute with the issuing bankPayment reversal

Contesting the transaction with the issuing bank to reverse the payment.

Reversal and feeFinancial outcome

Funds reversed to the payer plus a handling fee charged to the merchant.

Implementation

Implementation pitfalls
High false-positive rateHigh

Overly aggressive blocking rejects honest customers and reduces revenue.

Fix:Calibrate risk models, add a manual-review layer, use 3-D Secure for risky transactions.
Hard to prove friendly fraudHigh

With first-party fraud it is hard for the merchant to prove the customer actually received the goods/service.

Fix:Collect delivery/usage evidence, logs, confirmations; contest via representment.
Card testing and mass abuseHigh

Automated small transactions validate stolen cards and generate costs and penalty risk.

Fix:Velocity checks, CAPTCHA, limits, anomaly detection, blocking suspicious BINs.
Irreversible compute consumptionMedium

In AI services, consumed compute is a cost that cannot be recovered after a chargeback.

Fix:Prepayment/initial limits, KYC, card verification before granting large limits.

Evolution

1974
Chargeback right (Fair Credit Billing Act)
Inflection point

The U.S. Fair Credit Billing Act establishes the cardholder's right to dispute charges - the basis of the chargeback mechanism.

2010
E-commerce and the rise of friendly fraud

The growth of online (card-not-present) commerce makes friendly fraud a dominant share of disputes at many merchants.

2023
Abuse of AI/API credits

Selling AI-model credits/tokens becomes a target of card fraud that feeds access-reselling (relay) markets.

Hyperparameters (configurable axes)

Fraud typeCritical

Criminal (stolen card), friendly (first-party) or card testing.

Transaction channelHigh

Most often card-not-present (online); affects available protections (e.g. 3-D Secure).

Volume/scaleMedium

Single disputes vs mass, automated card testing.

Computational complexity

Time complexity: Nie dotyczy (zjawisko ekonomiczne, nie algorytm). Space complexity: Nie dotyczy.

Compute bottleneck

Detection at a low false-positive rate

The key defense constraint is distinguishing fraud (especially friendly fraud) from legitimate disputes without blocking honest customers; card testing also generates a high volume of events to analyze in real time.

Depends on
Jakosc sygnalow ryzykaKoszt weryfikacji manualnej

Execution paradigm

Primary mode
Conditional

This describes the defense layer (fraud detection); the fraud itself is not a compute paradigm.

Activation pattern
Input dependent
Routing mechanism

Anti-fraud systems conditionally route transactions to approval, manual review or rejection based on risk signals.

Parallelism

Parallelism level
Partially parallel

Attacks (especially card testing) are highly automated and parallel; detection also runs in parallel in real time.

Scope
Inference
Constraints
!Card testing relies on many parallel small transactions; defenses apply velocity checks.

Hardware requirements

Primary

The phenomenon itself is hardware-independent; the defense (ML fraud detection) may use accelerators but does not require them.