Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Introduction
With Payment Service Directive 2 (PSD2) it's required that all credit card payments have to be authenticated by the customer using strong customer authentication (SCA). See 3-D Secure.
Of course, this is only possible if the end customer is also present at the time of payment and can carry out an SCA (like 3-D Secure 1.0 or 3-D Secure 2.x).
This is precisely not the case with subscription models and micropayments (virtual account / billing), since these are carried out in the absence of the customer. For this purpose, the model "cards on file" or "credentials on file" (CoF for short) is offered, with which such payments are specially marked and then excluded from the SCA. Likewise, the first, initial payment must be authenticated using SCA to meet the PSD2 guidelines. Subsequent payment transactions can be initiated with reference to the initial payment transaction. The reference to the initial transaction will then be handled by the PAYONE platform.
CoF can also be used to speed checkout by first depositing a credit card for a customer and then referencing it for follow-up payments. This function has already been offered for a long time by the pseudo card number of the PAYONE Platform - but now CoF also makes it PSD2-compliant.
With CoF you may re-use a credit card number for recurring transactions where the customer can not proceed the SCA process. To do so the first initial payment process has to be authenticated via SCA and the customer has to be informed that his credit card number will be stored for subsequent payments, the purpose of payment and the amount that is expected.
UI Text Box | ||
---|---|---|
| ||
All online merchants who initiate recurring transactions in the form of CoF payments and have their customers' card data stored by themselves or their PSP storing the data must obtain the explicit consent of the cardholder / customer. This approval must include the following elements:
|
CoF and PAYONE Platform
The PAYONE Platform already supports parameters for:
These parameters will be used for credit card payments to indicate CoF payments.
Here an overview of different use cases with credit card payments and recurring transactions.
Subscription / contract / abo
Description: This use case applies if you want to use our Contract module to handle subscriptions where the amount for a trail period and subsequential periods are fixed and known when starting the contract.
Use case | Server-API request | Params to set | Comments |
---|---|---|---|
How it should be done | |||
Initial create access - customer is present | createaccess |
|
|
Initial create access - customer is not present | createaccess |
|
|
Subsequent payments | handled automatically |
| |
How it's done now | |||
Initial create access, no extra params given | createaccess |
| |
Subsequent payments | handled automatically |
|
Micropayment / Billing / vauthorization
Description: This use case applies if you want to use our Billing module for micro payments. The accumulated amount is then settled after a given period of time. Typically the amounts per settlement period are different.
Use case | Server-API request | Params to set | Comments |
---|---|---|---|
How it should be done | |||
Get customer agreement for CoF | preauthorizationauthorization |
|
|
Create micropayment transactions | vauthorization |
| |
Settlement of micropayment transactions | handled automatically |
| |
How it's done now | |||
Create micropayment transactions | vauthorization | ||
Settlement of micropayment transactions | handled automatically |
|
Reservation / Sale with "oneclick" using CoF
Description: This use case applies if you want to store a credit card and use it for the following transactions in order to process them without 3-D Secure.
Use case | Server-API request | Params to set | Comments |
---|---|---|---|
How it should be done | |||
Initial transaction and get customer agreement for CoF | preauthorization authorization |
|
|
Subsequent transaction, customer is present | preauthorization |
|
|
Subsequent transaction, customer is not present | preauthorization |
|
|
How it's done now | |||
Initial transaction | preauthorization |
| |
Subsequent transaction | preauthorization |
| |
Table of Contents |
---|