Recurring Payments
Recurring payments are automatically repeated for periods and at specified intervals, always charging the same amount from the same card or account.
It is widely used for magazine subscriptions, monthly fees, software licenses, among others.
Recurrence types
API E-commerce Cielo works with two types of Recurrences:
- Merchant Recurrence : when the merchant creates its own repeat purchase intelligence and stores the card data.
- Scheduled Recurrence: when Cielo is responsible for the repetition intelligence and storage of card data.
Merchant recurrence
In this format, the merchant is responsible for creating intelligence to:
Intelligence | Description |
---|---|
Save transaction data | The merchant will need to store the transaction and payment data. |
Create transactional repetition | The merchant must sent a new transaction whenever it needs an authorization. |
Procedure for declined transaction | If one of the transactions is declined, it will be up to the store to "retry" a new authorization. |
In order to define a recurrence as Merchant Recurrence, send the parameter Parameter:
Payment.Recurrent
= "True".
Merchant recurrence example
This is an example of how API E-commerce Cielo allows the use of external recurrence systems in your transactions.
Merchant recurrence is a configuration of the API E-commerce Cielo that allows a merchant to use an internal recurrence system specific to their business needs.
In this model, the merchant's system is responsible for defining the period, the transactional data, and, when necessary, sending us the recurrence transaction.
Merchant recurence + tokenized card
A gym called Cleverfit has a specific billing system, where the client is charged every fifteen days, but never on weekends.
As a highly customized model, CleverFit has its own recurrence system, using the API E-commerce Cielo via two mechanisms:
- Merchant recurrence - CleverFit sends the transaction data as a normal sale, but the API identifies it as a recurrence and applies differential authorization rules to the order.
- Tokenized card - CleverFit keeps cards stored in a tokenized form at Cielo, according to security rules, avoiding storing card data in their system.
CleverFit sends the transaction every fifteen days to the API E-commerce Cielo, using the tokens saved in the API itself and opting for Merchant Recurrence, which changes the authorization rules to suit its billing model.
Scheduled recurrence
In this model, Cielo is responsible for the intelligence necessary to perform a recurrence automatically.
The Scheduled recurrence allows the merchant to create a base transaction that, when sent to the API E-commerce Cielo, will be saved and executed following the rules defined by the merchant.
To learn more about configuring a scheduled recurrence, access Cielo portal.
In this model, the API performs and allows:
Advantages | Description |
---|---|
Saves transactional data | Save transaction data, thus creating a model of what the next recurrences will look like. |
Automates the recurrence | Without the need for merchant action, the API creates future transactions according to the store's definitions. |
Allows updating of data | If necessary, the API allows modifications in the transaction information (such as shopper data) or recurrence cycle (such as billing date). |
The Scheduled Recurrence has two request flows; the difference is in the AuthorizeNow
parameter.
When the first transaction must be authorized at the time of scheduling, please send AuthorizeNow
as "true".
*If Post Notification was enabled by the merchant.
When the first transaction must be authorized after scheduling, send AuthorizeNow
as "false"; in this case, also send the StartDate
parameter.
*To schedule the transaction needs the RecurrentPayment
node, the transaction date and the AuthorizeNow
field as "false".
**If Post Notification was enabled by the merchant.
See the example of the snippet with the RecurrentPayment
node, which must be inserted in a credit transaction.
"RecurrentPayment":
{
"AuthorizeNow":"False",
"StartDate":"2019-06-01"
"EndDate":"2019-12-01",
"Interval":"SemiAnnual"
}
Where can we define the data as:
Parameters | Description |
---|---|
AuthorizeNow | Defines the time a recurrence will be created. If it is sent as True , it is created at the time of authorization, if sent as false False , the recurrence will be suspended until the date chosen to be initiated. |
StartDate | Defines the date on which the Scheduled Recurrence transaction will be authorized. |
EndDate | Defines the date the Scheduled Recurrence will end. If it is not sent, the Recurrence will be executed until it is canceled by the merchant. |
Interval | Recurrence interval.
|
When a transaction is sent to the API E-commerce Cielo with the Scheduled Recurrence node (
RecurrentPayment
), the recurrence process becomes effective when the transaction is considered AUTHORIZED. From that point on, the transaction will occur within the interval defined by the merchant.
Important features of Scheduled Recurrence:
Information | Description |
---|---|
Creation | The first transaction is called "Scheduling Transaction", all subsequent transactions will be copies of the first transaction. It does not need to be captured for the recurrence to be created, it just needs to be AUTHORIZED |
Capture | Scheduled Recurrence transactions do not need to be captured. After the first transaction, all recurrence transactions are automatically captured by the API. |
Identification | Scheduled Recurrence transactions generate two types of identification:PaymentId : Identifies a transaction. It is the same identifier as the other transactions in the API RecurrentPaymentId : Identifies recurrence order. A RecurrentPaymentID has many PaymentId's linked to it. This is the variable used to Cancel a Scheduled Recurrence. |
Consulting | To consult, just use one of two types of identification:PaymentId : Used to consult A TRANSACTION WITHIN THE RECURRENCE RecurrentPaymentId : Used to consult THE RECURRENCE. |
Canceling | A Scheduled Recurrence can be canceled in two ways: Merchant: When the merchant requests the canceling of the recurrence. You can't cancel transactions already finalized before the recurrence cancelation order. By invalid card: If the API identifies that a saved card is invalid (e.g.: Expired) the recurrence will be canceled and will not be repeated until the merchant updates the payment method. NOTE: Canceling transactions within the recurrence does not end the scheduling of future transactions. Only the Cancellation using the RecurrentPaymentID ends future schedules. |
RecurrentPaymentID Structure
Scheduled Recurrence example
This is an example of how to use API E-commerce Cielo recurrences to increase your sales:
Recurrence is the process of saving a transaction and repeating it at a predefined time interval. Ideal for subscription model.
Cielo' Scheduled Recurrence has the following characteristics:
- Scheduled intervals: monthly, bimonthly, quarterly, semi-annual and annual;
- Expiry date: allows you to define whether the recurrence has an end date;
- Retentative: if a transaction is declined, we will retry the transaction up to 4 times;
- Update: allows you to change recurrence data, such as value, interval.
Monthly and annual recurrence
Musicfy offers an online subscription service where their customers pay to be able to access a music library and listen to them via streaming.
To capture as many customers as possible, they offer two payment methods:
- Monthly for R$19,90;
- Annual (with discount) for R$180,00.
How do they bill their customers monthly or yearly?
Musicfy uses API E-commerce Cielo's Scheduled Recurrence.
When creating a transaction, Musicfy informs the client that the order in question will be repeated monthly or annually and that there is no end date for the billing.
What are the advantages of using scheduled recurrence for MusicFy?
-
Practicality: The monthly charge is automatic, so MusicFy does not have to worry about building a billing system.
-
Usability: The subscription value can be updated without having to redo the transaction. A month can be canceled or the recurrence can have a delay (the 30-day free model) with only one setting.
-
Safety: MusicFy does not need to store sensitive card and shopper data.
-
Conversion: Cielo's Scheduled Recurrence has an automatic retry system. If one of the transactions is denied, it will be retried up to four times, seeking to achieve authorization.
Updated 2 months ago