Recurring Payments
Introduction
The integration of this solution allows you to tokenize the customer card data, so that they can make recurrences for services such as subscriptions.
If, on the other hand, you are interested in a solution that allows the end customer to save their card data, and use them later to make purchases faster, refer to the solution OneClick Payments.
Recurring payments are also identified with the term MIT (Merchant Initiated Transaction). MIT transactions are divided into:
- Scheduled: charges with a defined frequency (eg. first of each month).
- Unscheduled: Charges with an undefined frequency.
The management of this solution is divided into 2 phases:
- First payment
- Subsequent payments
Here is how to make first tokenization payments and subsequent payments in the integration modes:
- Hosted Payment Page
- Pay-by-Link
- Server to Server: - 2 Steps payment - 3 Steps payment (1)
First Payment
Hosted Payment Page
The payment flow does not vary with respect to the Hosted Payment Page solution, in fact it is necessary to call the same API:
Valuing the "recurrence" object with the parameters:
Name | Description |
---|---|
action | CONTRACT_CREATION |
contractId | Unique string |
contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
Pay-by-Link
The payment flow does not vary with respect to the solution Pay-by-Link, it is in fact necessary to call the same API:
Valuing the "recurrence" object with the parameters:
Name | Description |
---|---|
action | CONTRACT_CREATION |
contractId | Unique string |
contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
2-Steps Payment
The payment flow does not vary with respect to the solution 2 Steps payment, it is in fact necessary to call the same API:
Valuing the "recurrence" object with the parameters:
Name | Description |
---|---|
action | CONTRACT_CREATION |
contractId | Unique string |
contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
3-Steps Payment
The payment flow does not vary with respect to the solution 2 Steps payment, it is in fact necessary to call the same API:
Valuing the "recurrence" object with the parameters:
Name | Description |
---|---|
action | CONTRACT_CREATION |
contractId | Unique string |
contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
Subsequent Payments
You can proceed with the next charge by sending a call to XPay with the contract registered during the first payment. The subsequent payment is not subjected to 3D Secure authentication.
For all integration modes, to make the next payment you need to execute the API call:
Additional APIs
The following APIs are made available to be able to intervene on existing contracts:
- List of contracts associated with a customer (GET /contracts/customers/{customerId})
- Deactivation of an existing contract (POST /contracts/{contractId}/deactivation) (1)