Card on File
Card on file transactions are transactions where the card details used for the transaction are retrieved from storage, rather than entered manually by the cardholder at checkout, i.e. where the details are kept “on file”.
Card on file transactions are transactions where the card details are stored, i.e. kept on file, rather than being entered by the cardholder directly. There are two ways these transaction can be initiated:
By the cardholder, where their payment details have been stored for reuse at checkout.
By the merchant, where the cardholder has given the merchant permission to initiate payments using the card, typically for recurring payments such as subscriptions.
Card on file is often abbreviated to COF. The COF abbreviation can also refer to “Credentials on File”, which has the same meaning - stored payment credentials are used rather than being entered by the cardholder at checkout.
Storing credit card details requires adhering to strict PCI DSS requirements. These requirements are mandated by the credit card schemes. There are various levels of certification that depend on the volume of transactions processed and whether credit card details are stored directly or by a third party.
The PCI DSS requirements are designed to ensure that sensitive card details are stored securely to protect them from malicious actors. As meeting these requirements is costly and requires annual audits, merchants typically outsource the storage of card details in a secure vault to a third party (e.g. IXOPAY). Most merchants opt for this option, as it significantly reduces their PCI DSS scope and associated costs, replacing the need for annual audits with a simple self assessment questionnaire (SAQ). However, if merchants meet all the requirements, have the necessary infrastructure in place and are willing to undergo annual audits, merchants can store credit card details in their own vault.
To ensure that merchants can process card on file transactions without storing the credit card details locally, a security mechanism called tokenization is used. When the customer enters their credit card details for the first time, the encrypted details are sent directly to the vault provider for storage in encrypted form. A so-called token is then generated by the vault provider. This token consists of a series of random characters that cannot be reverse engineered to reveal the underlying credit card details. Merchants can store this token without any risk of exposing sensitive data and use the token to reference the card details stored in the vault.
When processing a card on file transaction, the merchant simply includes the token as part of the transaction, along with other information such as the amount to be charged. The token is then used to look up the associated credit card details in the secure vault. These raw card details are then forwarded directly to the payment service provider for processing.
The best way for merchants to ensure that credit card details are protected and stored securely is to use a third party vault. This removes the burden from the merchant to ensure that their infrastructure is up to standard and avoids the need for costly annual PCI DSS recertification. It also shifts liability from the merchant to the vault provider.
When using a third party to store credit card details, merchants should ensure that the details are never accessed or processed directly by the merchant. Encrypted card details should be sent directly to the vault provider from the checkout form.
They streamline the checkout process for return customers, avoiding the need for cardholders to re-enter their information each time they make a purchase. Instead, customers can simply select from a previously used payment method they have stored. This speeds up the checkout process, eliminates the risk of entering incorrect information and typically leads to lower cart abandonment rates.
They allow for recurring billing where merchants charge the card at regular intervals, e.g. for subscriptions. The merchant simply charges the card whenever payment is due, with no involvement by the customer. However, merchants need to ensure that the credit card details are always up-to-date or face the risk of a payment failing if the card details have changed (e.g. if a new card is issued because the old one has expired).
Merchants can either use an account updater, such as IXOPAY’s Account Updater, or rely on network tokens issued by the card schemes.
When using an account updater, credit card details are sent to the schemes on a regular basis to check whether the card details have changed. If so, the information stored in the vault is updated accordingly to ensure that payments can continue to be processed using the card.
Network tokens are tokens that are issued directly by the card schemes. The card schemes ensure that the associated card information is kept up to date. The network token retains its validity even if the underlying card details change, ensuring that the card can continue to be charged.