Test a membership addon offer before enabling it

An addon benefit should answer a specific question: which customer receives which price on which selected option? If that sentence is difficult to write, the rule is probably too broad to test confidently.

Start with a disabled rule and a small example.

Choose a clear boundary

Identify the qualifying product, the eligible hosting product and the addon value. For example, owning one active membership service might reduce a chosen backup addon on a selected game product.

Do not assume the same rule covers every resource option or changes the base hosting plan.

Compare two customer states

Use a qualifying account and a non-qualifying account with the same target product, billing period and addon selection. Check both the option display and the final checkout breakdown.

Then test a loss of eligibility in a controlled environment. A suspended or expired qualifying service should not behave like an active, unexpired one.

Verify the renewal boundary

A benefit can apply when a new renewal invoice is generated. An already-issued invoice should not be silently rewritten after a membership change.

Keep the stored service baseline separate from the earned reduction. Otherwise a temporary free addon can accidentally become permanently free after eligibility ends.

Review billing arrangements

Changing benefits can conflict with a fixed payment-provider subscription amount. Read the relevant integration requirements before applying a rule to existing subscriptions.

Once the test matches the intended offer, enable the rule deliberately and keep its name and expected behaviour in a private operational note. The first-rule checklist provides the sequence, while the eligibility guide explains the customer-facing result.