Prerequisites
- A
ClientId
and an API key – if you don’t have these, contact Sales to get access to the Mangopay Dashboard - A User object created for your end user, and their associated Wallet
- A registered card (CB, Visa, or Mastercard), which is
VALID
or registered less than 24 hours ago, to make the payments
- Customer-initiated transaction (CIT) - An initial transaction in the presence of the cardholder, for which is required.
- Merchant-initiated transactions (MIT) - Subsequent transactions made in the absence of the cardholder, initiated by the platform (and not subject to SCA unless required by the )
1. Create the Recurring PayIn Registration
The Recurring PayIn Registration object will define key information about the recurring payments such as:- The start and end date, as well as the frequency
- Whether the amount is the same for each payment
- Whether you want to offer zero-amount payments to your end user at the start of the recurrence (for example, during trial subscription offers)
POST /v2.01/{ClientId}/recurringpayinregistrations
Id
of the Recurring PayIn Registration for the next steps.
API response
API response
2. Process the first recurring payment (CIT)
Make the request
Request the first payment, linking it to the registration object by using theId
returned in the previous step as the RecurringPayinRegistrationId
.
In our example, the first transaction amounts have been defined at the registration level. Because of this, we don’t need to define the DebitedFunds
or Fees
at the pay-in level.
POST /v2.01/{ClientId}/payins/recurring/card/direct
API response
API response
Redirect the user to 3DS protocol
The CIT transaction always requires 3DS (theSecureModeNeeded
value is set to true), so you need to redirect the end user to the SecureModeRedirectURL
value to complete the authentication.
For more information on how to handle 3DS redirection, see Steps 6 and 7 of the How to process a card payment guide.
3. Process the subsequent recurring payments (MIT) at the defined intervals
Once the first pay-in has been successfully authorized, the platform can initiate payments without the end user being present to authenticate (but note that, at any time, the issuer may request SCA - see Step 5). Create the recurring pay-in at the set interval with the dedicated endpoint. Note that in our example, we didn’t define the next transaction amounts at the registration level. As a consequence, we need to pass theDebitedFunds
and Fees
parameters at the pay-in level.
POST /v2.01/{ClientId}/payins/recurring/card/direct
API response
API response
200
4. Update the registration (if required)
Some information regarding the recurring registration may be modified during the recurrence:CardId
- Changing this will require a new CIT for SCABilling
andShipping
5. Handle re-authentication (when required)
At any moment during the recurrence, the issuer may request that the end user authenticates again. This also occurs when changing theCardId
in the Recurring PayIn Registration (see Step 4).
The need for re-authentication is indicated by the registration object’s Status
changing to AUTHENTICATION_NEEDED
.
You can be notified of this by setting up webhook notifications for the following event type:
RECURRING_REGISTRATION_AUTH_NEEDED
6. Check the recurring payments’ current state
TheCurrentState
of the Recurring PayIn Registration provides key information about the recurring payments:
- Number of pay-ins made against the registration
- Cumulated amounts of debited funds and fees
- Last pay-in made against the registration
GET /v2.01/{ClientId}/recurringpayinregistrations/{RecurringPayinRegistrationId}
API response
API response
API response
7. End the recurring payments
Recurring payments may come to an end either automatically (when anEndDate
was defined) or because the end user requests it.
To end the recurring payments manually, use the Update a Recurring Registration endpoint to change the Status
to ENDED
.
PUT /v2.01/{ClientId}/recurringpayinregistrations/{RecurringPayinRegistrationId}
RECURRING_REGISTRATION_ENDED