---
url: >-
  https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/CardOnFile/index.md
description: >-
  CardOnFile (CoF) refers to a stored credential transaction model in which card
  details are saved with cardholder authorization and reused for later payments.
  In PingPong, `bizType=CardOnFile` represents a cardholder-initiated `CIT CoF`
  path and typically enables CVV-free one-click checkout.
---
## Definition

`CardOnFile (CoF)` refers to a transaction model in which a merchant stores card details with cardholder authorization and reuses those stored credentials in later payments.

In card network terminology, CoF is primarily about the stored credential classification and later reuse of those credentials, not just whether CVV is entered.

In PingPong documentation, `bizType=CardOnFile` represents a cardholder-initiated `CIT CoF` path. Its typical effect is:

- The first payment passes `bizType=CardOnFile` and completes card binding
- When the cardholder later selects a saved card, payment can typically be completed via token without re-entering CVV

In the PingPong platform, if the first payment did not pass `bizType=CardOnFile`, subsequent payments follow the regular saved-card path and cannot use the CardOnFile token-payment path directly.

## What It Is Not

- It is not the same as `saving card details`: saving a card improves UX by reducing repeated entry
- It is not the same as `Tokenization`: tokenization is a way to protect stored credentials and sensitive data
- It should not be reduced to `whether CVV is skipped`: CVV-free checkout is only one product outcome, not the full definition of CoF

## Use Cases

`CardOnFile` is suitable for cardholder-present one-click payment scenarios:

- The cardholder logs in to the merchant platform and selects a saved card to pay
- The cardholder can typically pay without re-entering CVV or the full card number

If the merchant needs to trigger charges while the cardholder is not present, use `bizType=Recurring`.

`Recurring` is closer to an MIT charging capability: the merchant decides when to trigger each subsequent charge and manages the authorization relationship, charge schedule, and retry policy.

## Cardholder Notice and Consent

Before using `CardOnFile` or `Recurring`, the merchant should complete cardholder notice and consent in its own flow, including:

- Authorization to save card details for future use
- An explanation of the scope of later use
- Merchant-side retention of the authorization or opt-in record

## Business Value

When the first saved-card transaction passes `bizType=CardOnFile`, card networks classify subsequent payments as stored credential follow-on transactions and apply dedicated CoF risk models.

For merchants, this means:

- Issuers can make authorization decisions using a previously authorized transaction context instead of treating the payment like a first-time card transaction
- Unnecessary declines caused by missing transaction context can be reduced
- The model is suitable for merchants focused on repeat-purchase conversion

## PingPong Split of CoF Scenarios

In card network standards such as Visa and Mastercard, both CIT (cardholder-initiated) and MIT (merchant-initiated) belong to the stored credential / Card-on-File family. PingPong splits them into separate `bizType` values:

| `bizType` | Transaction type | Cardholder present | Typical scenario |
|:----------|:-----------------|:------------------|:-----------------|
| `CardOnFile` | CIT CoF | Yes | One-click checkout |
| `Recurring` | MIT CoF | No | Merchant-initiated charges, auto-renewal, usage-based charging |

::: warning Note
Even when no CVV is required, subsequent payments may still be challenged or declined because of issuer risk controls, regulatory requirements, or transaction risk.
:::