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
typeinfo

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:

  • The confirmation of the stored card number (PCI compliant, e.g., as a masked card number indicating the last four digits of the card number)
  • The purpose for which the card data is used and the duration of the agreement
  • Confirmation from the merchant that the cardholder will be notified of any changes in an agreed way

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.

Preview

UI Text Box
typenote

The current documentation is a preview. It's not ready for processing yet - mode live and test.

Subscription / contract / abo (recurring) - PAYONE contract module

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.

StepUse caseServer-API requestParams to setComments
How it should be done
1a

a) Get customer agreement for CoF - only get agreement, no amount is sent

preauthorization
  • amount=0
  • recurrence=recurring or recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure
1b

b) OR get customer agreement for CoF -with amount is sent

preauthorization
  • amount=<amount>
  • recurrence=recurring or recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure

Amount has to be captured by request "capture".

2a

Initial create access - customer is present

createaccess
  • recurrence=recurring
  • customer_is_present=no
  • As the customer already agreed for initial payment the access can simply be started
  • Parameter "customer_is_present=no" even if customer is present because customer agreement is already processed.
2b

Initial create access - customer is not present

createaccess
  • recurrence=recurring
  • customer_is_present=no
  • As the customer already agreed for initial payment the access can simply be started
3

Subsequent payments

handled automatically
  • Subsequential payment will be handled with CoF if customer agreed to the initial create access
How it's done now

Initial create access, no extra params given

3dscheck &
createaccess

  • The default value
    • for "recurrence" is "recurring" and
    • for "customer_is_present" is "yes". 
  • So by default these payment transactions may be enforced to be challanged by 3-D Secure

Subsequent payments

handled automatically
  • Subsequential payments may be declined by the issuer as they can not be authenticated by the customer

Subscription / contract / abo (recurring) - external service provider for contract

Description: This use case applies if you want to use your own contract system and simply send the transactions that should be marked with flag "recurring".

StepUse caseServer-API requestParams to setComments
How it should be done
1a

a) Get customer agreement for CoF - only get agreement, no amount is sent

preauthorization
  • amount=0
  • recurrence=recurring or recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure
1b

b) OR get customer agreement for CoF - with amount is sent

preauthorization
  • amount=<amount>
  • recurrence=recurring or recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure

Amount has to be captured by request "capture".

2

Subsequent payments

preauthorization
  • amount=<amount>
  • recurrence=recurring
  • customer_is_present=no
  • Subsequential payment will be handled with CoF if customer agreed to the initial payment process

Amount has to be captured by request "capture".

How it's done now

Payment transaction trail period

authorization
  • So by default these payment transactions may be enforced to be challanged by 3-D Secure

Payment transaction subsequent period

authorization
  • Subsequential payments may be declined by the issuer as they can not be authenticated by the customer


Micropayment / Billing / vauthorization (recurring)

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.

StepUse caseServer-API requestParams to setComments

How it should be done


1a

a) Get customer agreement for CoF - only get agreement, no amount is sent

preauthorization
  • amount=0
  • recurrence=recurring or recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure
1b

b) OR get customer agreement for CoF - with amount is sent

preauthorization
  • amount=<amount>
  • recurrence=recurring or recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure

Amount has to be captured by request "capture".

2

Create micropayment transactions

vauthorization
  • recurrence=recurring
  • customer_is_present=no

3Settlement of micropayment transactionshandled automatically
  • Settlement of the open amount marked as CoF transactions

How it's done now



Create micropayment transactions

vauthorization


Settlement of micropayment transactionshandled automatically
  • Payments may be declined by the issuer


Reservation / Sale with "oneclick" using CoF (one-click)

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.

StepUse caseServer-API requestParams to setComments

How it should be done


1Initial transaction and get customer agreement for CoFpreauthorization
authorization
  • recurrence=oneclick
  • customer_is_present=yes
  • Merchant must obtain consent that data will be stored and be used for subsequent payments
  • Customer has to agree to CoF
  • Initial payment will be handled with 3-D secure

Amount has to be captured by request "capture" if only reserved with "preauthorization".

2Subsequent transaction, customer is present

preauthorization
authorization

  • recurrence=oneclick
  • customer_is_present=yes
  • Customer selects and confirms stored credit card data
  • 3-D Secure may not be required
  • Subsequential payment will be handled with CoF
  • Initial payment will be handled with 3-D secure

Amount has to be captured by request "capture" if only reserved with "preauthorization".

3Subsequent transaction, customer is not present

preauthorization
authorization

  • recurrence=oneclick
  • customer_is_present=no
  • subsequential payment will be handled with CoF

Amount has to be captured by request "capture" if only reserved with "preauthorization".


How it's done now



Initial transaction

preauthorization
authorization


  • Payment transactions may be enforced to be challanged by 3-D Secure

Subsequent transaction

preauthorization
authorization


  • Payment transactions may be enforced to be challanged by 3-D Secure



Table of Contents