Use Cases
The following use cases are affected by the credential-on-file requirements.
One-Click
A cardholder can create an account with the merchant and place the card credentials for future shopping. With every shopping session the cardholder can select the preferred card from the merchant account and initiate a payment for a purchase without entering the card details again (apart from the CVV). Combined with the storage of preferred shipping and billing addresses in the merchant account the simplified checkout is often called one-click checkout.
One-Click payments are always cardholder initiated transactions (CIT) no matter if it is the initial or subsequent transaction with the shop.
Recurring Scheduled
This use case describes recurring payments with a fixed schedule and a fixed amount.
A typical example would be a subscription with a merchant for a specific service or product, e.g. a subscription for the usage of a mobile app, where the same amount is collected by the merchant on the first day of each month.
The initial transaction always has to be cardholder initiated (CIT) as this is typically the time the cardholder gives the consent for such scheduled recurring agreement.
All subsequent transactions will be merchant initiated (MIT).
Some card schemes (e.g. Visa, Mastercard) return a special identifier in the authorization response of an initial recurring transaction. This identifier has then to be provided with each subsequent transaction initiated by the merchant.
In conjunction with 3DS 2.0 even a zero amount card check combined with a 3DS authentication can be used as the initial recurring scheduled transaction, as long as the first subsequent transaction initiated by the mechant is referencing the initial card check.
Note that a 3DS 2.0 authentication for recurring transactions always requires a strong customer authentication (SCA) and therefore does not support the frictionless flow.
Recurring Unscheduled
This use case describes recurring payments without any fixed schedule and a fixed amount. The cardholder signs an agreement with the merchant that the merchant is allowed to charge the card whenever any usage of a service or product occurs. The exact amount and the time when the card will be charged is not known at this point.
A typical example would be video-on-demand agreement where the card will be charged whenever a new video will be booked.
The initial transaction always has to be cardholder initiated (CIT).
All subsequent transactions will be merchant initiated (MIT).
Some card schemes (e.g. Visa, Mastercard) return a special identifier in the authorization response of an initial recurring transaction. This identifier has then to be provided with each subsequent transaction initiated by the merchant.
In conjunction with 3DS 2.0 even a zero amount card check combined with a 3DS authentication can be used as the initial recurring unscheduled transaction, as long as the first subsequent transaction initiated by the mechant is referencing the initial card check.
Note that a 3DS 2.0 authentication for recurring transactions always requires a strong customer authentication (SCA) and therefore does not support the frictionless flow.
Installments
Installment payments are recurring payments following a pre-defined installment plan, where the customer choses to pay a purchase with a number of partial payments over a pre-defined period of time.
The customer might have to pay some additional fees for such model.
Installments are currently not supported by the Concardis Payengine!