Skip to main content

Recurring payments

The Managed Recurring Payments service provides you with the following features to support you with a seamless and easy journey on your recurring payments management: 

  • Recurring payment processing automation
  • Automatic billing calculation
  • Automatic credit calculation
  • Failed payment retries and rollover
  • Manage recurring payments
    • Retrieve billing cycle details
    • Manual payments on failed billing cycles
    • Refunds on billing cycles

Recurring payments processing automation

On the billing date in every billing cycle, Managed Recurring Payments service will attempt the payment using the consumer profile payment method designated for the recurring program.

Automatic billing calculations

Managed Recurring Payments service will automatically calculate the billing amount to be collected in every billing cycle for every recurring program.

The following are a few different scenarios and how automatic billing is done for them.

Scenarios for automatic billing calculation
Scenario Billing calculation details
For a recurring program where the recurringPlanDefault is set to true
  • If the recurringProgramQuantity = 1, billing cycle amount = plan amount.
  • If the recurringProgramQuantity > 1, total billing cycle amount = plan amount multiplied by the program quantity.
  • The billing frequency of the program is inherited from the BillingFrequencyCount and BillingFrequencyUnit of the recurring plan.
For a recurring program where the recurringPlanDefault is set to false 

(recurringprogramAmountprogramBillingFrequencyCount, and programBillingFrequencyUnit are required when creating such a recurring program)
  • If the recurringProgramQuantity = 1, billing cycle amount = program amount.
  • If the recurringProgramQuantity > 1, total billing cycle amount = program amount multiplied by the program quantity.
  • The billing frequency of the program is inherited from the recurring plan.
If the billing frequency is monthly and the start date of the recurring program is the 1st of the month The billing cycle will follow the calendar month.

For example: If the program start date of a monthly program is 1st of Jan, then billing will occur on 1st Jan, 1st Feb, 1st March, etc.
If the billing frequency is monthly and the start date of the recurring program is any other date than the 1st

The billing cycle will start on the same date the next month.

For example: If the program start date of a monthly program is 14th of March, then billing will occur on 14th April, 14th May, 14th Jun and so on, but the total number of days in a billing cycle won't be the same since April has 30 days and May has 31 days.

If the billing frequency is monthly and the start date of the recurring program is the 30th or 31st of the month

The billing cycle will consider the last date of the month as the start date.

For example: if the program start date of a monthly program is 30th April, the start date of the next billing cycle will be 31st May.

If the billing frequency is yearly and the start date of the recurring program is the 1st of the month

The billing cycle will follow the calendar year (including leap years).

For example: If the program starts on 1 Jan 2023 , then billing will occur on 1st Jan 2023, 1st Jan 2024, 1st Jan 2025, etc.

Full amount billing When the service is consumed for the entire duration of a billing cycle, Managed Recurring Payments will determine the full billing amount based on either the plan amount or the program amount.
Note

The total number of days for each billing cycle can vary from 28-31 according to the calendar month (monthly frequency).

Billing proration

When the end date of the recurring program falls in the middle of the last billing cycle, Managed Recurring Payments service will automatically prorate the amount to be charged on that cycle based on the number of days your consumer will use the services/product on the period.

The following formula is used for calculating prorated billing:

  • The total number of days in the final cycle for which the service was used = A
  • The plan amount or program amount = B
  • Total number of billing days per cycle as per the billing frequency = C
  • The prorated billing amount = (A/C) * B * recurringProgramQuantity

For example, let's say a monthly $100 recurring program starts from Jan 1st and ends on July 15th . The billing calculation for the month of July will be as follows:

  • The total number of active days in final the cycle for which the service was used = 15
  • The plan amount or program amount = $100
  • Total number of billing days per cycle as per the billing frequency = 30
  • The prorated billing amount = (15/30) * 100 * 1 = $50

Automatic credit calculation

In the event of a cancelation of the recurring program before the agreed upon end date in your terms with your consumers, a credit amount is automatically calculated based on the usage of the services/products on the last cycle collected. This is done to allow you to easily refund your consumer if needed as per your terms and conditions. Managed Recurring Payments service will not perform an automatic refund on that amount, but the credit amount computed will be available on the recurring program for your reference.

The following are the types of automatic credit calculations and the scenarios in which they can occur.

Automatic credit calculation types and scenarios
Automatic credit calculation type Scenario
Full amount credit
  • If the cancellation came on the same day after the billing cycle payment was processed, then it is a case of full amount credit.
  • This also applies if the end date of the recurring program is updated to the same billing day after the billing cycle payment was processed.

In these cases, Managed Recurring Payments will store the credit amount and you can use the refund API to manually refund the amount to the consumers. 

For example: If the current billing cycle is from 1st May to 31st May, the billing amount is $100. If a cancellation request comes on 1st May after the billing amount is collected, then the computed credit amount is $100.

Prorated credit
  • If the cancellation comes anytime during the billing cycle but after the billing cycle payment was processed, then it is a case of prorated credit or partial credit.
  • This also applies if the end date of the program is updated to the middle of the billing cycle after the cycle payment was processed.

In these cases, Managed Recurring Payments will store the credit amount and you can use the refund API to refund the amount to the consumers.

Formula for credit calculations 

  • Total number of active days of the final cycle for which the service was used = A
  • Plan Amount or Program Amount = B
  • Total number of billing days per cycle as per the billing frequency = C
  • Prorated credit amount = B – [(A/C) * B] * recurringProgramQuantity

For example: If the current billing cycle is from 1st May to 31st May, the billing amount is $30. If a cancellation request comes on 14th May, then the computed credit amount is $16.

Payment retries

Let's say a payment fails with a specific soft decline code such as Not Sufficient Funds (NSF), Refer to Issuer, or Do Not Honor. There is a possibility of payment approval when tried at a later time. Managed Recurring Payments service offers automatic payment retries on soft decline codes from billing failures.

You can define the payment retry rules by setting up the following configurations:

  • Interval in between the retries (in Days) – 1, 2, 3, 4 days
  • Max retry count – 1, 2, 3, 4
  • Card brand soft decline codes – INSUFFICIENT_FUNDS, DO_NOT_HONOR, DECLINED_REFER_TO_ISSUER
  • Max retry exhaust action – Keep Program active, Cancel program

The following statuses indicate the current state of a payment retry.

Payment retry statuses
Status Description
IN_RETRY The payment is currently being retried.
RETRY_EXHAUSTED The maximum number of automatic payment retries were attempted and they failed.
Note
  • You can enable this feature by turning it on from the Recurring Payment Settings section of  Commerce Center.
  • You must ensure your terms and conditions with your consumers support the charge of past due amounts automatically on the next payment cycle to avoid disputes on rolled over amounts.

Past due amount roll over

The roll over feature helps you recover failed payments by consolidating your past due amount on the next billing cycle. Past due amounts can be rolled over for a maximum of 1, 2, or 3 immediate billing cycles based on your configuration. If the max roll-over count is reached and payment is still outstanding, then the recurring program is cancelled.

You may wonder what happens if the payment retries and roll over settings are both enabled. In such cases:

  • If the payment retry exhaust action is to keep the recurring program active, then first the payment retry will be attempted. Once the max retry count is reached and the payment is still outstanding, the roll over will begin.
  • If the payment retry exhaust action is to cancel the recurring program, then the payment retry will be attempted. Once the max retry count is reached, the program will be cancelled without rolling over.
Note
  • You can enable this feature by turning it on from the Recurring Payment Settings section of  Commerce Center.
  • You must ensure your terms and conditions with your consumers support the charge of past due amounts automatically on the next payment cycle to avoid disputes on rolled over amounts.

Scenarios for CIT and MIT transactions

Managed Recurring Payments indicates consumer-initiated transactions (CIT) to the card brands and obtains reference IDs, which will be used to link subsequent merchant-initiated transactions (MIT). The following are a few scenarios in which a transaction is considered as CIT or MIT.

Scenarios for CIT and MIT transactions
Transaction type Scenario
CIT transaction
  • On creating a recurring program that starts immediately, the payment processed for the first billing cycle is considered the CIT transaction.
  • On creating a recurring program that starts in future, the account verification request processed during program setup is considered the CIT transaction.
MIT transaction
  • On creating a recurring program that starts immediately, all the subsequent billing cycles processed automatically by Managed Recurring Payments will be MIT transactions.
  • On creating a recurring program that starts in future, the first billing cycle along with all the subsequent billing cycles processed automatically by Managed Recurring Payments will be MIT transactions.

The transaction ID (TXID) received on the CIT transaction is stored against the recurring program and used for the MIT transaction.

Tip

You might ask: When does the transaction ID (TXID) stored against a recurring program change?

This happens when the payment method linked to the recurring program is updated. Upon update, the account verification that is run on the new card is considered as the CIT transaction and a new TXID is obtained and stored.

Manage recurring payments

You can manage the recurring payments on your billing cycles by using the following features:

Recurring programs

Retrieve billing cycles

Make a manual payment

Refund a billing cycle