# Card on File Payments: A Guide for SaaS and AI Apps

> Card on file explained for SaaS and AI apps: how stored credentials work, CIT vs MIT rules, consent, PCI scope, and how to charge saved cards with Dodo Payments.
- **Author**: Deepak Jangir
- **Published**: 2026-10-16
- **Category**: Payments, Checkout
- **URL**: https://dodopayments.com/blogs/en/card-on-file-payments

---

Card on file means a customer has authorized a business to save their payment card and charge it later, without re-entering the card details each time. The card is stored as a token by the payment provider, not as a raw card number, and every later charge must fall within what the customer agreed to at the moment they saved it. Subscriptions, usage top-ups, and one-click purchases all run on card on file payments.

Here is why it matters for SaaS and AI products. Your best customers renew, upgrade, add seats, or buy extra credits at 2 a.m. when an agent runs out of tokens. Send them back through a full card form each time and some will not finish. Charge a saved card without the right consent and flags, and you invite declines and disputes instead.

This guide covers the stored credential framework, CIT vs MIT, consent, PCI scope, and a step-by-step implementation with Dodo Payments.

## What Card on File Means (and What It Does Not)

A credential on file is any payment credential a merchant or its provider stores to use for future transactions. For cards, that credential is a reference to the card number, expiry date, and related data, held in a secure vault. Your application only ever sees an identifier such as a payment method ID.

Card on file is not the same as a subscription. A subscription is a billing schedule; card on file is the stored token and permission that lets any future charge happen, from a monthly renewal to a variable usage bill.

| Term | What it is | Who triggers the charge | Example |
| --- | --- | --- | --- |
| Card on file (credential on file) | A stored, tokenized card plus the customer's permission to reuse it | Either party, depending on the agreement | Saved card in a customer's billing settings |
| Customer-initiated transaction (CIT) | A charge the cardholder actively starts | The customer | Clicking "Pay" with a saved card at checkout |
| Merchant-initiated transaction (MIT) | A charge the merchant starts under a prior agreement | The merchant | Monthly renewal, overage bill, auto top-up |
| Subscription | A billing schedule that usually uses MITs | The merchant, on a schedule | $49 per month Pro plan |
| One-click purchase | A CIT that uses a stored card with no form | The customer | Post-purchase upsell button |

All of these are [card-not-present transactions](https://dodopayments.com/blogs/card-not-present-transactions), which means the issuer cannot see the physical card. That is why the rules around how a stored card was saved, and why it is being charged, carry so much weight with issuers.

## How the Stored Credentials Framework Works: CIT vs MIT

Card networks such as Visa and Mastercard introduced stored credential rules several years ago to give issuers clearer signals about card on file transactions. The core idea is simple: the first transaction that saves the card is treated differently from the charges that reuse it, and every later charge is labeled with who started it and why.

### Step 1: The initial customer-initiated transaction

The first time a customer saves a card, the cardholder is present and taking an action. This initial CIT is where three things happen together:

- The customer enters card details and agrees to your terms for future use.
- The transaction is authenticated where required, for example with [3D Secure](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication) for cards in regions that mandate strong customer authentication.
- The issuer returns a transaction identifier that ties future charges back to this original, consented transaction.

The initial transaction can be a real charge (the first month of a plan) or a zero or small-amount verification when you only want to save the card for later.

### Step 2: Later merchant-initiated transactions

After that, charges the merchant starts are flagged as MITs and reference the original transaction. Networks recognize a few common MIT types:

- **Recurring**: fixed amount on a fixed schedule, such as a monthly subscription.
- **Installment**: a known total split into a set number of payments.
- **Unscheduled credential on file**: variable amount or timing, triggered by an event the customer agreed to, such as an auto top-up when a credit balance drops below a threshold.
- **Industry-specific MITs**: resubmissions after a decline, incremental or delayed charges, and similar cases.

In regions with strong customer authentication rules, such as the European Economic Area, properly flagged MITs are generally out of scope for re-authentication because the customer is not present. That only holds if the initial CIT was authenticated and the agreement covers the later charge.

### Step 3: Later customer-initiated transactions

When the customer comes back and actively chooses to pay with their saved card, that is a CIT again, just one that reuses a stored credential. A one-click upgrade or a "buy more credits" button in your app falls here.

```mermaid
flowchart LR
    A["Customer enters card and consents"] --> B["Initial CIT: charge or verify, 3DS if required"]
    B --> C["Provider stores card as token"]
    C --> D["MIT: monthly renewal"]
    C --> E["MIT: usage or overage charge"]
    C --> F["MIT: auto top-up below threshold"]
    C --> G["CIT: one-click purchase by customer"]
    D --> H["Webhook: payment succeeded or failed"]
    E --> H
    F --> H
    G --> H
```

The payoff is approval rates. Issuers see a known customer, an authenticated original transaction, and a later charge of an expected type. Missing or wrong flags are a quiet cause of recurring declines, covered in our guide to [reducing payment declines](https://dodopayments.com/blogs/reduce-payment-declines).

You rarely set these flags by hand. Your provider applies them based on which API you call; your job is to pick the right flow and capture consent.

## Consent and Disclosure Requirements for Credit Card on File

Card network rules and many consumer protection laws expect the same basics when you store a credit card on file. Exact requirements vary by network, country, and in the US by state, especially for automatic renewals, so treat the list below as the common baseline and check with counsel for your markets.

At the moment you save the card, clearly tell the customer:

- That the card will be stored for future payments.
- What the future charges are for, and how the amount is set (fixed price, per-unit usage, top-up amount).
- When or how often charges will happen, or what event triggers them.
- How to cancel or remove the saved card, and how that affects their service.
- For trials, when the paid period starts and what it will cost.

Then follow through after the fact:

- Send a receipt or confirmation that records the agreement.
- Notify customers before material changes, such as a price increase or a new top-up threshold.
- Make it easy to see and delete saved cards in account settings.
- Use a recognizable billing descriptor so customers do not mistake a valid charge for fraud.

Consent is not just a compliance checkbox. Unclear consent drives many "I did not authorize this" disputes on recurring and usage charges (see [chargeback vs refund](https://dodopayments.com/blogs/chargeback-vs-refund)). A customer who understood why they were charged is far more likely to email you than call their bank.

### PCI implications: tokenization means you never store card numbers

If your servers stored primary account numbers (PANs), your whole infrastructure would fall into heavy PCI DSS scope. With a modern provider, card data is captured in a hosted checkout or secure field, tokenized immediately, and stored in the provider's vault. Your database holds only identifiers such as a customer ID and a payment method ID.

That keeps your PCI scope small. You still secure your account and API keys, but you are not encrypting and auditing card storage yourself. For the details, see our explainer on [payment tokenization](https://dodopayments.com/blogs/payment-tokenization) and the [PCI compliance checklist for SaaS](https://dodopayments.com/blogs/pci-compliance-checklist-saas). On Dodo Payments, card numbers are tokenized on entry, and the platform is PCI DSS Level 1 certified. Some providers go a step further with card-network tokens that stay valid across reissues, which our guide to [network tokenization](https://dodopayments.com/blogs/network-tokenization) explains.

## Card on File Transactions for SaaS and AI Apps: Use Cases and Risks

Card on file transactions show up in almost every monetization model a software company uses. The table below maps common use cases to the transaction type and the main thing to get right.

| Use case | Transaction type | Amount | Key consideration |
| --- | --- | --- | --- |
| Monthly or annual subscription | MIT, recurring | Fixed | Clear renewal disclosure and reminders |
| Usage or overage billing | MIT, unscheduled | Variable | Explain pricing units and caps up front |
| Auto top-up of AI credits | MIT, unscheduled | Usually fixed per top-up | Disclose the trigger threshold and amount |
| Manual "buy more credits" | CIT with stored card | Customer chooses | Make the saved card the default option |
| One-click upsell after purchase | CIT with stored card | Fixed offer price | Show the exact price before the click |
| Seat or plan upgrade mid-cycle | CIT or MIT, depending on who acts | Prorated | Explain proration in the confirmation |

### Subscriptions

The classic case. The customer pays the first period with an authenticated CIT, and renewals follow as recurring MITs. Our [recurring payments guide](https://dodopayments.com/blogs/recurring-payments-guide) walks through billing schedules, proration, and renewal logic in more detail.

### Usage top-ups and on-demand AI credit charges

AI products often bill for consumption that is hard to predict: tokens, generations, minutes of compute, or agent runs. Card on file lets you charge as usage accrues or when a prepaid balance runs low, without stopping the user mid-task. If you sell credits, our guide to [adding credits billing to an AI app](https://dodopayments.com/blogs/add-credits-billing-ai-app) covers ledger design, and [on-demand subscriptions for hybrid pricing](https://dodopayments.com/blogs/on-demand-subscriptions-hybrid) shows how to mix a base fee with variable charges.

### One-click upsells

Right after a purchase, an add-on that charges the saved card in one click converts well because there is no second form to abandon. Our walkthrough of [one-click upsells after purchase](https://dodopayments.com/blogs/one-click-upsells-after-purchase) shows the full UX pattern.

### The risks you need to plan for

Stored cards are not set-and-forget. The main failure modes are:

- **Expired or replaced cards.** Cards expire, get reissued after fraud, or get cancelled. Some networks offer account updater services that refresh stored details, explained in our guide to the [account updater service](https://dodopayments.com/blogs/account-updater-service). Whether that applies depends on your provider, so do not assume it, and build your own card-update prompts regardless.
- **Declines.** Insufficient funds, issuer fraud rules, and do-not-honor responses hit MITs too. Learn the common responses in our list of [credit card decline codes](https://dodopayments.com/blogs/credit-card-decline-codes), and design sensible [payment retry logic](https://dodopayments.com/blogs/payment-retry-logic) for each category.
- **Disputes.** Charges a customer does not recognize or did not expect turn into chargebacks. Clear consent, descriptors, receipts, and pre-charge notifications are your main defenses.
- **Customer trust.** A surprise charge, even a valid one, can cost you the account. Usage alerts and spending caps help, and our piece on [involuntary churn from failed payments](https://dodopayments.com/blogs/involuntary-churn-failed-payments) shows how payment friction turns into lost customers.

## How to Implement Card on File Payments with Dodo Payments

Dodo Payments acts as your Merchant of Record, so it is the legal seller on each transaction and handles sales tax, VAT, and GST, along with compliance and chargebacks. For card on file, it gives you three building blocks: saved payment methods at checkout, one-click charges against a saved card, and on-demand subscriptions for variable merchant-initiated charges. The full reference lives in the [cards documentation](https://docs.dodopayments.com/features/payment-methods/cards).

### Step 1: Capture the card with a consented first payment

Send new customers through a Dodo checkout session for their first purchase or subscription. This is the initial CIT: card details are entered on the hosted checkout, tokenized on entry, and checked with fraud scoring, CVV validation, and 3D Secure where needed. Put your consent and disclosure copy on your pricing page and confirmation screens so the agreement is clear before the customer pays.

Store the Dodo `customer_id` against your user record. You will need it for every later step.

### Step 2: Show saved payment methods to returning customers

When a returning customer starts another checkout, pass `show_saved_payment_methods: true` together with their existing `customer_id`. The checkout then lists their saved cards, so they can pay without typing a card number again. The default is `false`, so you have to opt in.

### Step 3: Charge a saved card in one click

For in-app purchases where you do not want to show checkout at all, such as a "Buy 1,000 credits" button, retrieve the customer's saved payment methods and create a checkout session with `payment_method_id` and `confirm: true`. Per the [integration guide](https://docs.dodopayments.com/developer-resources/integration-guide), `payment_method_id` is only accepted with `confirm: true`, you must pass the existing `customer_id`, and you must include a complete `billing_address` (or only `country` and `zipcode` when `minimal_address` is `true`). The session charges the card directly and returns no `checkout_url`.

```ts
import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env['DODO_PAYMENTS_API_KEY'],
});

// Customer clicked "Buy 1,000 credits" inside the app
export async function buyCreditsWithSavedCard(customerId: string) {
  // 1. List the customer's saved cards
  const methods = await client.customers.retrievePaymentMethods(customerId);
  const savedCard = methods.items[0];
  if (!savedCard) return { needsCheckout: true }; // send to normal checkout

  // 2. Charge the saved card directly, no checkout page
  await client.checkoutSessions.create({
    product_cart: [{ product_id: 'pdt_credits_1000', quantity: 1 }],
    customer: { customer_id: customerId },
    payment_method_id: savedCard.payment_method_id,
    confirm: true,
    minimal_address: true,
    billing_address: { country: 'US', zipcode: '94102' },
  });

  // 3. Grant credits only when the payment.succeeded webhook arrives
  return { status: 'processing' };
}
```

In production, pull the billing country and postal code from the customer's profile. Because there is no redirect, treat [webhooks](https://docs.dodopayments.com/developer-resources/webhooks) as the source of truth and only add credits after the payment succeeds.

### Step 4: Use on-demand subscriptions for variable merchant-initiated charges

For charges you start without the customer clicking anything, such as usage bills or auto top-ups, use [on-demand subscriptions](https://docs.dodopayments.com/developer-resources/ondemand-subscriptions). The customer authorizes a payment method once through checkout (you can set `mandate_only: true` to save the mandate without an initial charge), and you then charge variable amounts with `client.subscriptions.charge(subscriptionId, { product_price })`, where the price is in the smallest currency unit.

One trade-off to plan for: Dodo does not automatically retry failed on-demand charges. You need your own logic to pause usage, notify the customer, ask them to update their card, and retry when it makes sense. The [handling payment failures guide](https://docs.dodopayments.com/developer-resources/handle-payment-failures) and our overview of [dunning management](https://dodopayments.com/blogs/dunning-management) are good starting points.

### Step 5: Know which methods support stored payments

Subscriptions on Dodo accept cards, Google Pay, Cash App Pay (USD), and UPI Intent (INR). BNPL, bank debits such as ACH and SEPA, and other local methods are one-time only. If a customer pays a one-off purchase by ACH, you cannot reuse that for recurring charges, so steer customers who need recurring billing toward a card or supported wallet.

On cost, Dodo has no monthly fees. Domestic US cards and wallets are 4% + 40c, international cards add 1.5%, and subscriptions, add-ons, and usage billing add 0.5%. Disputes are $30 each, which is one more reason to invest in clear consent. Recovery features for abandoned carts, dunning, and payment retries are free to enable and charge 5% only on recovered revenue.

## FAQ

### Is it legal to keep a customer's credit card on file?

Yes, as long as the customer agrees to it and you follow card network rules and local consumer protection laws. In practice that means clear disclosure of how the card will be used, a record of consent, and an easy way to cancel. Using a provider that tokenizes cards also means you never store the raw card number yourself.

### Do I need 3D Secure every time I charge a saved card?

Usually not. Strong authentication generally applies to the initial customer-initiated transaction, and properly flagged merchant-initiated transactions under that agreement are generally exempt. An issuer can still request authentication on a customer-initiated charge with a saved card, so your flow should handle that case.

### What happens to a stored card when it expires?

The stored token keeps pointing at the old card details, so charges will start to decline once the card expires or is replaced. Some networks run updater services that refresh stored details, but coverage varies by provider and issuer. Prompt customers to update their card before expiry and handle declines with a clear update flow.

### Can I charge a different amount than the first payment on a stored card?

Yes, if the customer agreed to variable charges, such as usage billing or top-ups, and you disclosed how the amount is calculated. Charging an amount outside what the customer reasonably expected is a common source of disputes. On Dodo, on-demand subscriptions are built for this kind of variable charge.

## Final Thoughts

Card on file is the quiet infrastructure behind most SaaS and AI revenue: renewals, top-ups, upgrades, and upsells all depend on a stored card that issuers trust and customers understand. Get the initial customer-initiated transaction right, capture clear consent, let your provider handle tokenization and transaction flags, and plan for expired cards, declines, and disputes from day one.

[Dodo Payments](https://dodopayments.com) gives you saved payment methods at checkout, one-click charges with `payment_method_id`, and on-demand subscriptions for variable charges, while acting as your Merchant of Record for tax and compliance. Review the [pricing](https://dodopayments.com/pricing) to model your costs, then follow the [cards documentation](https://docs.dodopayments.com/features/payment-methods/cards) to add card on file payments to your app.
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)