# Card-Not-Present Transactions: Fees, Fraud, and Liability

> What a card not present transaction is, why CNP payments cost more, how CNP fraud and chargebacks work, and how 3DS liability shift protects merchants.
- **Author**: Deepak Jangir
- **Published**: 2026-10-11
- **Category**: Payments, Chargebacks
- **URL**: https://dodopayments.com/blogs/en/card-not-present-transactions

---

Every payment a SaaS company, digital product seller, or online store processes has one thing in common: the customer's card never touches a terminal. That single fact changes what you pay per transaction, who absorbs the loss when a stolen card gets through, and how many disputes land in your inbox. Most founders only notice it when the first batch of fraud chargebacks arrives and the processor explains that, as a card-not-present merchant, the loss is theirs.

This guide explains what a card not present transaction is, how it differs from a card-present sale, why it costs more, which fraud patterns target it, and how liability actually shifts. It closes with a practical defense pipeline and a webhook handler you can drop into your stack.

## What Is a Card Not Present Transaction?

A card not present (CNP) transaction is any card payment where the physical card is not presented to a payment terminal at the time of purchase. The merchant never sees the chip, never reads the magnetic stripe, and never captures a tap. Instead, the card details are typed, stored, or tokenized and sent to the processor over the internet or phone.

Common CNP scenarios include:

- Online checkout on a website or hosted payment page
- In-app purchases inside a mobile or desktop application
- Mail order and telephone order (MOTO) payments keyed in by staff
- Subscription renewals charged against a stored card
- Invoices paid through a payment link

If your business sells software, digital goods, or services online, effectively all of your card volume is CNP. It is the default operating mode for internet businesses.

## Card Present vs Card Not Present: The Key Differences

The difference between card present vs card not present comes down to how much the card network can trust that the real cardholder is involved. A chip or contactless tap produces a cryptogram that is extremely hard to forge. A CNP payment relies on data that can be copied, so networks price and allocate risk accordingly.

| Factor                  | Card present (CP)                                  | Card not present (CNP)                                                  |
| ----------------------- | -------------------------------------------------- | ----------------------------------------------------------------------- |
| Authentication method   | EMV chip cryptogram, contactless tap, PIN          | Card number, expiry, CVV, AVS, optional 3-D Secure                      |
| Typical interchange     | Generally lower                                    | Generally higher for the same card type                                 |
| Fraud exposure          | Lower, counterfeit cards are hard to use with chip | Higher, stolen card data can be used anywhere online                    |
| Default fraud liability | Often with the issuer when chip is used correctly  | Generally with the merchant unless authenticated with 3-D Secure        |
| Chargeback exposure     | Mostly service and quality disputes                | Fraud claims, "item not received", and friendly fraud are all common    |
| Proof of purchase       | Signed or PIN-verified receipt, terminal logs      | IP address, device data, delivery logs, login history, usage records    |

The exact interchange rates vary by network, region, card type, and merchant category, so treat the "higher" label as a direction rather than a number. The pattern is consistent though: when the card is not present, every party in the chain charges for the extra uncertainty.

## Why Card Not Present Fees Are Higher

Card not present fees are higher because the issuing bank carries more fraud risk and recovers part of that cost through interchange. Networks publish separate CNP or "e-commerce" interchange categories that sit above their card-present equivalents.

Three forces push CNP costs up:

- **Higher fraud rates.** Stolen card numbers are sold in bulk and tested against online checkouts. Issuers price that exposure into interchange.
- **More disputes.** CNP payments generate more chargebacks, and every dispute costs the issuer, the acquirer, and the merchant operational time.
- **Weaker default authentication.** Without a chip cryptogram, the issuer has less evidence that the cardholder was present, so the transaction is treated as riskier.

On top of interchange, processors add markup, fraud tooling fees, and dispute fees. Cross-border CNP payments usually carry extra assessment and FX costs, so a global seller's blended cost can drift well above the headline rate.

## Types of CNP Fraud Merchants Face

CNP fraud is any unauthorized or illegitimate payment made without the physical card, and it shows up in a few distinct patterns. Each one requires a slightly different control, so it pays to know which ones are hitting your checkout.

### Stolen card data

A fraudster buys card numbers harvested from breaches or phishing and uses them to buy goods or services. The real cardholder spots the charge and files a fraud dispute. Digital goods are attractive targets because delivery is instant.

### Card testing

Fraudsters run many small authorizations to find which stolen cards still work. Checkouts without rate limits are ideal targets, and even failed attempts can cost authorization fees. Our guide to [detecting and stopping card testing attacks](https://dodopayments.com/blogs/card-testing-fraud) covers the signals in detail.

### Account takeover

The attacker logs into a real customer's account with leaked credentials and buys with the stored card, so basic checks pass. Watch for login anomalies, new devices, and sudden email changes.

### Friendly fraud

The cardholder made the purchase but disputes it anyway, claiming they did not recognize it, did not receive it, or forgot to cancel. For subscription businesses this is often the largest category of CNP chargebacks. Clear billing communication and easy cancellation reduce it sharply, as explained in our breakdown of [friendly fraud prevention tactics](https://dodopayments.com/blogs/friendly-fraud-prevention).

For a broader view of how these patterns turn into disputes, see [how chargeback fraud works and how to prevent it](https://dodopayments.com/blogs/chargeback-fraud-prevention).

## CNP Chargebacks and the 3DS Liability Shift

For CNP payments, the merchant generally bears the liability for fraud chargebacks. If a stolen card is used on your checkout and the real cardholder disputes the charge, the issuer will usually win the dispute and the money comes back out of your balance, along with a dispute fee.

The main exception is 3-D Secure (3DS). When a payment is successfully authenticated with 3DS, the issuer has verified the cardholder through a one-time code, a banking app approval, or a risk-based frictionless check. In return, fraud-related chargebacks on that payment can shift to the issuer. This is the 3DS liability shift, and it is the single most important lever a CNP merchant has against stolen-card disputes.

General caveats:

- The liability shift typically covers fraud reason codes, not service disputes like "not as described" or "subscription cancelled".
- Exemptions and network rules vary by region and card scheme, so not every 3DS-flagged payment gets full protection.
- 3DS adds friction for some customers, so most merchants apply it based on risk rather than on every payment.

If you want the mechanics of challenge flows, frictionless authentication, and Strong Customer Authentication, read our explainer on [3D Secure payment authentication](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication). For a refresher on the full dispute lifecycle, start with [what a chargeback is and how it works](https://dodopayments.com/blogs/what-is-a-chargeback-explained).

## Controls That Reduce CNP Fraud and Disputes

No single control stops CNP fraud. Use a layered pipeline where each check removes a different class of bad payment, and post-purchase tools catch what slips through.

```mermaid
flowchart LR
  A["Checkout request"] --> B["Velocity and device checks"]
  B --> C["Blocklist lookup"]
  C --> D["AVS and CVV verification"]
  D --> E["Risk-based 3DS"]
  E --> F["Authorization"]
  F --> G["Clear descriptor and receipts"]
  G --> H["Dispute alerts: Ethoca and Visa RDR"]
```

### Pre-authorization controls

- **Velocity limits.** Cap attempts per card, per IP, per email, and per device within a time window. This is the cheapest defense against card testing.
- **Device signals.** Browser fingerprint and IP reputation help separate humans from scripts.
- **Customer blocklist.** Once a customer has committed fraud or filed a bad-faith dispute, block their email or card from buying again.
- **AVS and CVV checks.** The address verification service compares the billing address with the issuer's records, and the CVV confirms the buyer has card details beyond the number. Mismatches are a strong signal but not definitive, as covered in our guide to [handling AVS mismatch declines](https://dodopayments.com/blogs/avs-mismatch).
- **Risk-based 3DS.** Trigger authentication on higher-risk payments to gain the liability shift without adding friction to every checkout.

### Post-purchase controls

- **Clear statement descriptor.** A descriptor that matches your brand prevents "I don't recognize this charge" disputes. See [how to set a statement descriptor customers recognize](https://dodopayments.com/blogs/statement-descriptor).
- **Fast, easy refunds.** A refund costs less than a chargeback and does not count against your dispute ratio. Our comparison of [chargebacks vs refunds](https://dodopayments.com/blogs/chargeback-vs-refund) walks through the economics.
- **Pre-dispute alerts.** Ethoca alerts and Visa Rapid Dispute Resolution (RDR) notify you or auto-resolve a case before it becomes a formal chargeback, keeping it out of your dispute ratio.
- **Evidence collection.** Log IP addresses, login timestamps, product usage, and delivery confirmations at purchase time so you can respond quickly when a dispute opens.

For a subscription-specific playbook, read our guide to [chargeback prevention for SaaS](https://dodopayments.com/blogs/chargeback-prevention-saas), and for the response side, our [dispute management guide](https://dodopayments.com/blogs/dispute-management-guide).

## Merchant-Initiated vs Customer-Initiated Transactions

Subscriptions add a second dimension to CNP payments: who started the transaction. A customer-initiated transaction (CIT) is one where the cardholder is actively in session, entering card details or clicking "pay". A merchant-initiated transaction (MIT) is one where the merchant charges a stored card without the customer present, such as a monthly renewal or a usage-based overage.

Card networks have stored credential frameworks that govern this. In general terms:

- The first payment, where the customer agrees to future charges and the card is saved, is a CIT. It is the right moment to apply 3DS and capture clear consent.
- Later renewals are flagged as MITs that reference the original stored credential. They usually fall outside Strong Customer Authentication challenges because the customer is not present to complete one.
- Correct flagging helps approval rates, because issuers can see that the charge is part of an agreed series rather than a random card-on-file attempt.
- For usage-based or variable charges, how the amount is reserved and captured matters too, which our guide to [authorization holds and pre-authorization](https://dodopayments.com/blogs/authorization-hold) covers.

The dispute risk with MITs is mostly friendly fraud: a customer forgets a subscription and disputes the renewal. Renewal reminders, easy cancellation, and an accurate descriptor matter more here than any fraud score.

## How a Merchant of Record Changes CNP Risk

A Merchant of Record (MoR) changes the CNP picture because the MoR, not you, is the legal seller on every transaction. Dodo Payments acts as the merchant of record, so the card payment is processed under Dodo's merchant account, and Dodo carries the fraud screening, dispute handling, and compliance obligations that come with CNP volume.

In practice that means:

- **Fraud screening is built in.** Checkout risk checks run on every payment without you configuring a separate fraud tool. Details on supported cards and how card payments are handled are in the [card payments documentation](https://docs.dodopayments.com/features/payment-methods/cards).
- **Disputes are handled by the MoR.** Dodo receives the chargeback from the network, manages the response workflow, and notifies you. The [disputes documentation](https://docs.dodopayments.com/features/transactions/disputes) explains statuses and how to submit evidence.
- **Customer blocklist.** Since September 2026, you can block specific customers from purchasing again, which is the cleanest way to stop repeat abusers. See the [customer blocklist guide](https://docs.dodopayments.com/features/customer-blocklist).
- **Pre-dispute prevention.** Verifi/Visa RDR support has been available since early 2026, alongside Ethoca alerts and dispute deflection.
- **Security.** Card data never touches your servers. See the [Dodo security policy](https://docs.dodopayments.com/miscellaneous/security-policy).

The dispute-related costs are published on the [Dodo Payments pricing page](https://dodopayments.com/pricing):

| Dispute tool       | Fee                                    | When it applies                                      |
| ------------------ | -------------------------------------- | ---------------------------------------------------- |
| Dispute            | $30 per dispute                        | A formal chargeback is filed                         |
| Visa RDR           | $18 per dispute                        | A Visa dispute is resolved through RDR               |
| Ethoca alert       | $27 per alert                          | An Ethoca pre-dispute alert is received              |
| Dispute deflection | $15 per deflection                     | Only when a dispute is successfully deflected        |
| Refund             | $1 per refund                          | You refund a customer proactively                    |

A $1 refund is far cheaper than a $30 dispute. Card payments themselves start at 4% + 40c for domestic US cards and wallets, with +1.5% for international cards and +0.5% for subscriptions, and tax calculation and remittance are included. For the full MoR dispute picture, see [how a merchant of record handles chargebacks](https://dodopayments.com/blogs/merchant-of-record-chargebacks).

## Handling CNP Chargebacks with Dispute Webhooks

Even with an MoR handling the network side, your app should react when a dispute opens: pause a suspect account, preserve evidence, and update state on the outcome. Dodo sends `dispute.opened`, `dispute.won`, and `dispute.lost` events, documented in the [dispute webhook reference](https://docs.dodopayments.com/developer-resources/webhooks/intents/dispute).

Webhooks follow the Standard Webhooks spec, so you verify the `webhook-id`, `webhook-signature`, and `webhook-timestamp` headers against the raw request body before trusting anything in the payload.

```typescript
import express from 'express';
import { Webhook } from 'standardwebhooks';
import { db } from './db'; // your data layer

const app = express();
const webhook = new Webhook(process.env.DODO_WEBHOOK_SECRET!);

interface DisputePayload {
  type: 'dispute.opened' | 'dispute.won' | 'dispute.lost' | string;
  data: {
    dispute_id: string;
    payment_id: string;
  };
}

// Raw body is required: signatures are computed over the exact bytes sent.
app.post(
  '/webhooks/dodo',
  express.raw({ type: 'application/json' }),
  async (req, res) => {
    const rawBody = req.body.toString('utf8');
    const headers = {
      'webhook-id': req.header('webhook-id') ?? '',
      'webhook-signature': req.header('webhook-signature') ?? '',
      'webhook-timestamp': req.header('webhook-timestamp') ?? '',
    };

    let event: DisputePayload;
    try {
      webhook.verify(rawBody, headers);
      event = JSON.parse(rawBody) as DisputePayload;
    } catch {
      return res.status(401).send('Invalid signature');
    }

    // Idempotency: Standard Webhooks may retry, so skip duplicates.
    if (await db.webhookEvents.exists(headers['webhook-id'])) {
      return res.status(200).send('Already processed');
    }

    const { dispute_id, payment_id } = event.data;
    const account = await db.accounts.findByPaymentId(payment_id);

    switch (event.type) {
      case 'dispute.opened': {
        if (account) {
          // Pause access and block new purchases while the case is open.
          await db.accounts.update(account.id, {
            status: 'disputed',
            purchasesBlocked: true,
          });
          // Snapshot evidence now, before logs rotate.
          await db.disputeEvidence.insert({
            disputeId: dispute_id,
            paymentId: payment_id,
            accountId: account.id,
            lastLoginIp: account.lastLoginIp,
            lastLoginAt: account.lastLoginAt,
            usageEvents: await db.usage.recent(account.id, 90),
            capturedAt: new Date().toISOString(),
          });
        }
        break;
      }
      case 'dispute.won': {
        if (account) {
          await db.accounts.update(account.id, {
            status: 'active',
            purchasesBlocked: false,
          });
        }
        break;
      }
      case 'dispute.lost': {
        if (account) {
          // Keep the account flagged; consider adding it to the blocklist.
          await db.accounts.update(account.id, {
            status: 'suspended',
            fraudFlag: true,
          });
        }
        break;
      }
    }

    await db.webhookEvents.record(headers['webhook-id'], event.type);
    return res.status(200).send('ok');
  },
);

app.listen(3000);
```

A few implementation notes:

- Always verify against the raw body. Parsing JSON first and re-serializing it will break the signature.
- Return a 2xx quickly and push slow evidence capture onto a queue.
- Pausing access suits suspected stolen-card fraud, but for a long-standing customer who forgot a renewal, a support email may resolve it faster.
- Pair a `dispute.lost` outcome with the customer blocklist so the same buyer cannot return with a new card.

## FAQ

### What counts as a card not present transaction?

Any card payment where the physical card is not presented to a terminal counts as card not present. That includes online checkout, in-app purchases, phone and mail orders, payment links, and subscription renewals charged to a stored card.

### Why are card not present fees higher than card present fees?

Card networks generally assign higher interchange to CNP payments because they carry more fraud and dispute risk. Without a chip cryptogram, the issuer has less proof the real cardholder was involved, so the extra risk is priced into every transaction.

### Who is liable for CNP fraud chargebacks?

As a general rule, the merchant is liable for fraud chargebacks on CNP payments. If the payment was successfully authenticated with 3-D Secure, liability for fraud-related disputes can shift to the issuer, subject to network rules and exemptions.

### Does 3DS stop all CNP chargebacks?

No. The 3DS liability shift mainly covers fraud reason codes. Disputes about non-delivery, product quality, or forgotten subscriptions are not covered, so clear descriptors, refunds, and cancellation flows still matter.

### How does a Merchant of Record reduce CNP risk for my business?

A Merchant of Record is the legal seller on every transaction, so it runs fraud screening and manages the dispute process with card networks. With Dodo Payments you also get customer blocklisting, Visa RDR, and Ethoca alerts, while your app reacts to dispute webhooks to protect accounts.

## Final Take

Card-not-present payments are the default for internet businesses, and with them come higher interchange, more fraud attempts, and merchant-side liability for fraud chargebacks. The answer is a layered defense: velocity limits, AVS and CVV, risk-based 3DS for the liability shift, a recognizable descriptor, fast refunds, and pre-dispute alerts.

If you would rather not build and operate that stack yourself, [Dodo Payments](https://dodopayments.com) acts as your Merchant of Record and handles fraud screening, disputes, and global tax on [cross-border card payments](https://dodopayments.com/payments). Review the transparent dispute and processing fees on the [pricing page](https://dodopayments.com/pricing) to see what CNP risk costs when someone else carries it.
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)