Recurring payments
The integration of this solution allows the merchant to tokenize the customer's 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.
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
Below, it will be explained how to perform first tokenization payments and subsequent payments in the integration modes:
- Hosted Payment Page
- Pay-by-Link
- XPay Build
- Server to Server:
- 2 Steps payment
- 3 Steps payment
First payment
A first transaction must be generated, assigning a unique contract for each customer, an identifier that allows XPay to save the combination between the customer and the payment card used.
Hosted Payment Page
The payment flow remains the same as the Hosted Payment Page solution, as it is necessary to call the same API::
Valuing the "recurrence" object with the parameters:
| action | CONTRACT_CREATION |
| contractId | Unique string |
| contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
Pay-by-Link
The payment flow remains the same as the Pay-by-Link solution, as it is necessary to call the same API:
Valuing the "recurrence" object with the parameters:
| action | CONTRACT_CREATION |
| contractId | Unique string |
| contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
XPay Build
The payment flow remains the same as the XPay Build solution, as it is necessary to call the same API:
Valuing the "recurrence" object with the parameters:
| action | CONTRACT_CREATION |
| contractId | Unique string |
| contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
2 Steps payment
The payment flow remains the same as the 2 Steps payment solution, as it is necessary to call the same API::
Valuing the "recurrence" object with the parameters:
| action | CONTRACT_CREATION |
| contractId | Unique string |
| contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
3 Steps payment
The payment flow remains the same as the 3 Steps payment solution, as it is necessary to call the same API:
Valuing the "recurrence" object with the parameters:
| action | CONTRACT_CREATION |
| contractId | Unique string |
| contractType | MIT_UNSCHEDULED or MIT_SCHEDULED |
Management of 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:
The following APIs are made available to be able to intervene on existing contracts: