Dunning Action Settings

🚧

Important

If you use Cleeng Merchant, Dunning actions settings will be configured by Cleeng and they should remain default values, except otherwise agreed with your account manager.

If you operate for the web the Merchant of Record (hence, when you do NOT use Merchant), dunning actions settings are allowed to be adjusted the way you want.

Dunning is the process of retrying payment attempts and sending payment reminders to customers when a payment gets rejected. With Cleeng you can configure payment retries at intervals to ensure payment will be recovered and subscription can continue its cycles.

Dunning actions settings specify when Cleeng should emit the events mentioned in the Webhooks section. They must be set up for all your payment method Ids and all subscription cycle durations (weekly, monthly, 3-months, 6-months, annual, seasonal).

You can set them up by calling this endpoint.

Example:
Let’s imagine you have 2 payment methods 123 and 456. You offer your subscribers 2 types of subscriptionsmonthly and annual. In this case, you would have to create settings for the following method-cycle combinations:

  • payment method 123 and cycle monthly
  • payment method 123 and cycle annual
  • payment method 456 and cycle monthly
  • payment method 456 and cycle annual

🚧

Make sure you create dunning action settings for all the subscription cycle durations right at the beginning, as it is easy to forget to create this setting when a subscription with a previously unsupported cycle is added.

For example, you start selling only a monthly offer, and you set up dunning actions only for this offer and the respective payment methods, and after some time, you decide to start selling a 6-month offer. If you fail to set up dunning actions for the new, 6-month cycle, your customers who have subscribed to it, will not get their payment reminders, and payment retries will not be made. This will result in termination of subscriptions, and customer churn.

❗️

Important

Dunning actions settings for PayPal and Adyen payment methods require the authorizedFirst property to be set to true.

Recommended Dunning Settings

If you are not going for custom dunning actions settings, please use our recommended dunning actions settings for the respective billing cycles.

Dunning Action PeriodAuthorized FirstPayment Attempts (Hrs)GracePeriod (Hrs)
Monthly1[0, -24, -72, -168, -359]360
3 Months1[0, -24, -72, -168, -359]360
6 Months1[0, -24, -72, -168, -359]360
Annual1[0, -24, -72, -168, -359]360
Seasonal1[0, -24, -72, -168, -359]360

Please note that Payment Attempts values should be negative (below zero) if you want dunning actions to take place at certain intervals during the grace period.

🚧

Important

Grace period should be set to maximum 2 hours after the last payment attempt.

For example, if you set the last payment attempt to [0], then the grace period length should be set from 0 to 2 hours. If you set the last payment attempt to [-46], the maximum grace period is 48 hours.

Payment Attempts and Grace Period

You can set both payment attempts and a grace period for a subscription, however payment attempts settings have priority over a grace period. Please see below for different scenarios, depending on a possible setup.

🚧

Note

Dunning actions settings can be adjusted only if you do NOT use Merchant.

No Payment Attempts during Grace Period

If there are no payment attempts set during a defined grace period -> payment retries are made every hour during the grace period.

Payment Attempts = Grace Period

If payment attempts are set for the same length of time as the grace period -> payment retries are made as defined for payment attempts frequency.

For example, if payment attempts are defined as [0,-1,-3,-5] and the grace period is set to 5 hours, payment retries are made as per payment attempts settings (there will be 4 payment attempts).

Grace Period > Payment Attempts

If a grace period is longer than the period for which payment attempts are set -> payment attempts settings are followed for as long as they are set. After that time, the rules for grace period are followed and payment retries are made every hour until the end of the grace period.

For example, if payment attempts are defined as [0,-1,-3,-5] and the grace period is set to 7 hours, at first payment retries are made as defined for payment attempts frequency (there will be 4 payment attempts) and then for each hour that is later than the last defined payment attempt, an additional payment retry is made.

Grace Period ≤ Payment Attempts

If a grace period is shorter than the period for which payment attempts are set or it equals zero -> only payment attempts settings are followed.

For example, if payment attempts are defined as [0,-1,-3,-5] and the grace period is set to 1 hour, payment retries are made as defined for payment attempts frequency (there will be 4 payment attempts).

Example:

See this example to illustrate a case when an original next payment date for a subscription is: 4 Oct 2022, at 13:05.

Payment Attempts (Hours)Grace periodPayment attempts dates / timestamps:
[0]2 hours13:05; 14:05; 15:05
[0,-1,-3,-5]5 hours13:05; 14:05; 16:05; 18:05
[0,-1,-3,-5]7 hours13:05; 14:05; 16:05; 18:05; 19:05; 20:05
[0,-1,-3,-5]1 hour13:05; 14:05; 16:05; 18:05

📘

Good to know

Subscriptions are shown as active in the ChurnIQ dashboard when they are in a grace period.