Passive churn prevention UA testing

Preconditions

• Enablement of the passive churn prevention feature changes the default renewal cadence of 1 retry attempt every 5 days to 1 retry attempt evey 3 days. 

• Enablement of the passive churn prevention feature changes all existing grace periods configured on a term-level to a unified grace period of 15 days. 

• Enablement of the passive churn prevention feature replaces two existing email templates ‘Subscription renewal failure’ and ‘3DS 2.0 Authentication’ with two new templates with same names that can have multiple active versions (requirement for PSP feature to work). Contents of these templates will be copied upon the feature enablement by the support representative, but it is good to verify that the content is correct. 

Test cases

Creation of new custom logic 

Steps 

1. Create new custom logic as described in the

   documentation

   . 

Expected results

1. New logic is created. 

2. System-wide logic is still selected as the application default logic for all terms. 

3. No changes in renewal/retry behavior are made yet. 

Switching from system-wide to custom logic 

Steps

1. Click on ‘Make default’ near the ‘Custom annual logic’ to switch to it from a system-wide logic. 

2. Confirm your action in the confirmation screen. 

Expected results

1. ‘Application default’ badge is applied to the ‘Custom annual logic’. 

2. All terms moved from system-wide logic to the ‘Custom annual logic’.

   

3. ‘Custom annual logic’ is applied as a churn prevention logic for all terms.

4. Grace period for all subscriptions on all terms changed according to the ‘Custom annual logic’ 

Selecting churn prevention logic on a term level 

Steps

1. Create additional ‘Monthly custom logic’ logic as described in the

   documentation

   . 

2. Open any payment or dynamic term. 

3. Select ‘Monthly custom logic’ as a logic applied to this term.

   

4. Save changes. 

Expected results

1. New custom logic is applied to the term. 

2. Grace period for subscriptions on this term are changed according to the ‘Monthly custom logic’ configuration. 

3. Number of terms linked with the ‘Monthly custom logic’ changed in the churn prevention section. 

Applying a logic to multiple terms at once 

Steps

1. Create additional ‘Extended annual grace’ logic as described in the

   documentation

   . 

2. Open this logc and switch to the ‘Terms’ tab.

   

3. Click on ‘Add term’. 

4. Select whether the new logic should be applied to the whole term or to a specific period of the dynamic term.

   

5. Click the ‘Add’ button and confirm the action. 

Expected results

1. Logic was applied to terms and specific periods.

   

2. Number of terms linked with the logic changed.

3. You can see on the term level that logic is not applied to unselected periods and applied to selected ones. 

Payment failure testing

Payment failure testing is specific to a payment provider. Testing with payment providers that have a basic level of support doesn’t make a lot of sense, as all error codes will fall under the ‘Everything else’ decline reason and the system will not be able to differentiate them. Also, this test can’t be properly executed in the production environment, as payment providers typically don’t emulate error messages in the live environment. All tests should be executed in sandbox. 

During this type of test, we need to validate that the system is acting according to the configuration of the passive churn prevention logic based on the error message received from the payment provider. To emulate a specific error message from the payment provider we need to trigger an automatic renewal with a specific renewal price that will trigger an error response from the payment provider. 

Braintree

Here are the mapping error codes to transaction prices for Braintree 

Steps

1. Open the passive churn prevention section of the Subscription Management + Billing dashboard and

   configure

   a custom scenario for every decline reason that you would like to test. Make sure you create and assign a separate version of the payment failure template for each scenario because this is how you will be differentiating system behaviour. Copy of each version should be different to make identification easier.

   

2. Create a term

   with a trial period, where the trial price will be within the successful range (0.01 - 1999.99) and the base price of the term will be equal to an error code that you would like to trigger.

3. Make sure that the created passive churn prevention logic is assigned for this term.

   

4. Go to the apply term wizard and subscribe new or existing users to that term using the test card data provided by the payment provider. Initial purchase should go fine as the trial price is within the valid price range.

5. Open this new user details in the user management section and navigate to the subscriptions tab. Open the just created subscription and click on the green ‘Run scheduler renewal’ button to trigger an automatic renew.

6. Repeat from step 2 for every decline reason/error code you would like to test.  

Expected results

1. Subscription details modal will automatically close with the notification about successful renewal (the attempt was successful in this case, but the result was a payment failure). If you open the subscription details again, you should see that this subscription is now in a grace period. The length of the grace period should be equal to the value configured for a specific scenario in the PCP logic.

   

2. Navigate to the ‘Emails’ tab, you should see that there is an email scheduled to be sent to the end-user with the topic and body that was configured for a specific scenario in the logic. 

Last updated: June 25, 2026