Introduction

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.

Scope

This feature concerns recurring card payments made with a registered card, similar to a Card Direct PayIn. Recurring payments with an unregistered card (similar to a Card Web PayIn) are not possible.

Recurring card payments are available in all currencies and with CB/Visa/Mastercard. The following cards are not supported: Amex, Maestro, and BCMC. Please note that acceptance rates may vary depending on the country due to the readiness of banks.

For Direct Debits, see the Mandate object.

Types of recurring payment

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.

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.

Basic flow

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:

1. Create the object Recurring PayIn Registration
2. 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.