COF framework

To reuse your customers' card data for subsequent payments, you need to ensure their fair use:

• Get your customers' consent to store/reuse their car data on our platform.
• Define the scope of reusing their card data by linking them in a traceable manner.

To honour this, the card schemes have established the "Card On File" framework (COF). It makes distinctions on various levels that play a role for storing/using card data:

CITs vs MITs

The COF framework distinguishes between two types of transactions:

Customer-initiated transactions (CIT)

Transactions that your customers actively initiate in your webshop.

They either provide card data to be stored as a token on our platform (for the first transaction of a series of payments) or reuse card data already stored as a token (for subsequent transactions of a series of payments).

Each series of payments needs to be initiated by a CIT. This transaction is the first chain link of a series of payments, authorising you to reuse card data for subsequent payment.

Mind if your business is located in Europe, a first CIT needs to processed with SCA.

Merchant-initiated transactions (MIT)

Transactions that you process on the behalf of your customers.

MITs are logically linked by a legitimate business reason. This can be a standing instruction or an established industry practice.

Instead of using a token, you link the individual payments by referring to the payment.id of the initial CIT you started the series with.

Each series of MITs needs to be initiated by a CIT. This transaction is the first chain link of a series of payments, authorising you to reuse card data for subsequent payments – either because of a standing instruction or an established industry practice.

You can only process MITs without SCA, as you instead of your customers initiate the payments.

Standing instructions vs industry practice

There are two types of MITs:

Standing instructions

These are transactions that you need to process on a scheduled, recurring basis with fixed amount/intervals (i.e. for subscriptions). Alternatively, some payments for certain service happen on an unscheduled basis, with variable amounts/intervals (i.e. instalment plans or pay-per-use models).

Standing instructions require your customers' explicit consent to process subsequent payments.

Industry practices

Certain services might require you to collect additional fees to a previous order, such as

• No show penalties: Apply penalty fees for goods/services reserved by your customers but not picked up (i.e. hotel rooms). Also applicable for scenarios in which your customers agreed to a purchase but did not meet the terms of agreement
• Delayed charges: Apply a supplemental charge after delivering the original goods/services.
• Partial shipment: Collect the funds for a partially paid order. Also applicable for hospitality and car rentals for extended stays/rentals).
• Resubmission: You have already provided the goods/services to your customer, but you were unable to collect the funds at the time of the order.

These transactions do not require your customers' explicit consent to process subsequent payments.

token vs payment.id

The COF framework offers two ways of processing subsequent payments following a successful CIT: Via a token or a payment.id. Each option comes with different opportunities, requirements and limitations:

token

You can use a token only for subsequent CITs (use case C) but not for MITs. The token will remain the same throughout the whole series.

A token is a card profile stored safely on our platform. A UUID-formated string, it is returned in property creationOutput.token (for CreatePayment request) or redirectPaymentMethodSpecificOutput.token/cardPaymentMethodSpecificOutput.token (in GetHostedCheckoutStatus for CreateHostedCheckout requests). Find a JSON to create a token via a CIT in our JSON collection.

You can request subsequent CITs with token via API endpoints CreateHostedCheckout or CreatePayment in combination with CreateHostedTokenziation, by prefilling the payment form. Find a JSON to use a token for a CIT in our JSON collection.

Creating a token has no impact on your PCI level.

payment.id

You can use a payment.id only for subsequent MITs (use cases D through J) but not for CITs. Whenever you process a subsequent MIT, you need to take the payment.id from initial CIT you started the series with.

A payment.id is unique identifier of a transaction on our platform. It is returned in property id (for CreatePayment request) or payment.id (in GetHostedCheckoutStatus for CreateHostedCheckout requests).

The payment.id is linked to a scheme reference data. This a reference for the card schemes' and your customers' issuer, pointing to a transaction for which a specific card was used. Hence, this pointer links all transactions belonging to a payment series. This enables you to process subsequent payments for this very card.

You can request subsequent MITs with a payment.id via our dedicated API endpoint SubsequentPayment. Find a JSON for each MIT scenario in our collection.

This graph shows the differences between using a token or a payment.id throughout a COF payment series:

So how can you this framework when processing transactions? Have a look at our use cases, covering all possible scenarios.