PSD2 applies strong customer authentication (SCA) to all customer-initiated transactions (CIT). For these transactions, the cardholder is on session on the website or app to authenticate the transaction via the 3DS2 protocol. This protocol is handled by the SecureMode parameter on the MANGOPAY API.
Merchant-initiated transactions (MIT) are out of scope of PSD2. For these transactions, the merchant makes the payment request in the absence of the cardholder (the user is off session). These MITs are not authenticated individually, but must be linked by MANGOPAY to a previously authorised CIT.
Therefore, a recurring card payment has two phases:
- An initial transaction in the presence of the cardholder (CIT), which will be subject to SCA. No exemption is possible on a CIT.
- Subsequent transactions made in the absence of the cardholder, initiated by you (MIT). These transactions are out of scope and not subject to SCA.
Recurring card payments are only available in EUR and with CB/Visa/Mastercard. The following cards are not supported: Amex, Maestro, and BCMC.
For Direct Debits, see the Mandate object.
The first version of this feature does not accept preauthorized card payments as the initial CIT, but this will be included in a future version.
A recurring card payment consists of an initial CIT followed by at least one subsequent MIT. There are three different types of recurring payment (the type is indicated by the
RecurringMode returned by the API):
- Subscription (CLASSIC_SUBSCRIPTION)
- Installment (FRACTIONED_PAYMENT)
- Custom (CUSTOM)
All three types must possess an active card which cannot change during the recurrence. A change of card necessarily entails SCA.
Subscriptions and installments must also possess the following information: start date, end date, frequency, and the amount of all payments. All of these data points must be entered at the creation of the recurring payment and cannot be modified during the recurrence. These types of recurrence are considered to be more reliable as they possess all information which could be requested. Therefore, they are more likely to be accepted by the issuing bank (the cardholder’s bank).
Custom payments are more flexible: the end date, frequency, and amounts can be modified during the recurrence. However, an issuing bank may be more likely to request SCA on a custom payment if the transaction is deemed unreliable. This analysis is carried out by each issuing bank individually based on its risk analysis tools.
EndDate is not specified, the issuing bank may define one by default and display it to the end-user. Since this date is not taken into account for the payment recurrence, you should consider reassuring your users to avoid confusion.
We recommend that you provide as much information as possible regarding the recurrence. All transactional data provided is taken into account by the issuing bank to determine whether or not to accept a payment request.
The Recurring PayIn Registration object allows you to transmit all information related to a recurring payment, such as the frequency, the registered card, the start date, the end date and the amounts.
Each Recurring PayIn Registration object corresponds to one recurring payment (which is composed of several recurring pay-ins).
Once created, the Recurring PayIn endpoint enables you to request pay-ins linked to this registration object.
To set up a recurring card payment:
- Create the object Recurring PayIn Registration
- Execute a Recurring PayIn in the presence of the cardholder, subject to SCA
Once the first CIT is authorised, the recurring payment is validated.
Thereafter, you can use the same endpoint Recurring PayIn to execute MIT payments in the absence of the cardholder, while respecting the information submitted in the Recurring PayIn Registration.