We’ve migrated our documentation to a new site, which means some URLs have changed.
Subscriptions

Passive Churn Prevention (PCP): Implementation and Piano Subscriptions Checklist

1. Introduction

Passive Churn Prevention (PCP) reduces involuntary churn by managing payment-failure retry attempts and sending payment-failure notifications during a subscription grace period. PCP is not enabled by default and must be activated for each application.

This guide explains how to activate PCP, what changes immediately when PCP is turned on, how to test in sandbox, and how to prepare for production rollout.

2. What Changes When PCP Is Enabled

Enabling PCP is not just a UI change, it updates how renewals, grace periods, and certain email templates work. Review the following subsections carefully before requesting enablement.

2.1 Grace Periods Reset to 15 Days

When PCP is enabled, all term-level custom grace periods revert to a 15-day grace period under the PCP system-wide logic.

  • Why this matters: If you previously relied on longer grace periods (for example, 30–60 days), enabling PCP without creating custom PCP logic can cause subscriptions to expire sooner than expected after failed retries.

  • If you need different grace periods: Create additional PCP "logics" (custom churn prevention rules) with the desired grace periods and assign them at the Term level in the dashboard.

2.2 Renewal Retry Behavior Changes

Enabling PCP changes how renewal retries are handled. The table below summarizes the differences:

Behavior

Before PCP

After PCP (Default)

Number of retries

Effectively unlimited

Up to 5 retries

Retry interval

Every 5 days (minimum 5 days between attempts)

Every 3 days

Grace period

Custom per-term configuration

15 days (system default)

2.3 Payment-Failure Email Templates Are Replaced

When PCP is enabled, the existing templates for payment-failure communications are hidden in the dashboard and replaced with new PCP templates with default copy.

Impacted templates include:

  • Subscription renewal failure / payment failure messaging

  • 3DS 2.0 Authentication messaging


  1. Before activation, export or copy your existing template HTML/content.

  2. After activation, reapply your saved copy to the new PCP templates to avoid unexpected changes in subscriber communications.

PCP templates are distinct from non-PCP Email Manager templates, even if they appear similar. Plan for a post-activation validation of the templates used during PCP retries.

3. Piano Subscriptions Requirements and How to Request PCP Enablement

3.1 Prerequisites

  • Account Manager / Customer Success Manager approval is required before Support can enable PCP.

  • You must provide the Application ID(s) (AIDs) and specify the environment:

    • Sandbox and/or Production

  1. Enable PCP in sandbox first (to review UI and configure logic/templates).

  2. Validate configuration and operational expectations.

  3. Schedule production activation during business hours.

  4. After production enablement, immediately confirm:

    • Term-to-logic assignments

    • Email template content and enabled status

    • Retry/grace behavior matches your intended design

4. Sandbox Testing

PCP can be enabled in sandbox so you can configure churn logic and review template behavior, but sandbox has important limitations.

4.1 Sandbox Limitations

  • Churn Prevention reports are not generated in sandbox.

  • Scheduled jobs (like automatic renewals and consumer-facing email delivery) may not run automatically.

  • Emails may be prepared/queued but not delivered; you can typically inspect them in the dashboard (for example, under user email history).

  • Sandbox timestamps may use a fixed timezone (commonly in EST), which can cause apparent date offsets.

4.2 Provider-Specific Testing Considerations

  • PCP behavior can vary by payment provider integration and the decline reason data returned.

  • Not all payment providers support the same level of decline-reason segmentation ("advanced" vs "basic" implementations). With basic implementations, many declines may appear under an "Everything else" category, limiting scenario-specific testing.

5. Configuring PCP After Enablement

After PCP is enabled, you can create multiple PCP logics and assign them to different subscription terms.

5.1 Key Concepts

  • You can have multiple logics active at the same time.

  • Each Term can be assigned only one logic at a time.

  • This is how you apply different grace periods (for example, monthly vs annual) and different email schedules.

5.2 "Initial Renew" vs Retries

In PCP, the first attempt is often referred to as initial renew (day 0). Subsequent attempts are retries (1, 2, 3, etc.), mapped to the days you configure within the grace period.

Example: If your logic sends messages on day 0, 3, 6, 9, 12:

Day

Action

Day 0

Initial renew attempt (and optional email)

Day 3

Retry #1

Day 6

Retry #2

Day 9

Retry #3

Day 12

Retry #4

5.3 Email Cadence and Templates

  • PCP supports sending emails at specific points in the retry schedule.

  • You can use the same template across attempts or configure multiple templates/messages depending on your setup.

  • A common best practice is to send an email on day 0 (initial renew) so subscribers are informed immediately of a payment issue.

6. 3DS Emails and PCP

In some configurations, enabling PCP turns on 3DS-related email handling as part of the default system-wide logic. If you need to control 3DS-specific messaging, create a custom PCP logic so you can adjust the email logic section rather than relying on the system default.

7. Production Rollout Checklist

Before enabling PCP in production, complete the following steps:

  1. Back up email templates

    • Copy/export the current HTML and subject lines for payment failure and 3DS templates.

  2. Review grace period impact

    • Identify any terms relying on non-15-day grace periods.

    • Prepare PCP custom logics to match required grace periods.

  3. Plan for in-flight subscriptions

    • Consider auditing subscriptions currently in grace to ensure the transition won't unintentionally shorten their effective grace window.

  4. Schedule activation

    • Provide a target date/time and timezone if timing is important.

  5. Post-activation validation

    • Confirm term-to-logic assignments.

    • Confirm emails are enabled and contain your intended copy.

    • Confirm retry cadence is correct.

8. Disabling PCP

If PCP is disabled, the following changes take effect:

  • PCP-specific email templates are hidden again (save/export any custom PCP templates first).

  • Retry behavior reverts to the standard cadence (typically every 5 days until grace expires, based on your non-PCP configuration).

  • PCP custom churn logic stops running.

  • Disabling PCP does not retroactively restore subscriptions that already expired during PCP.

To request deactivation from Piano Support, provide:

  • Desired deactivation date/time (with timezone)

  • Confirmation you've saved any PCP email template content you want to keep.

  • Confirmation you understand retry/grace behavior will revert to your standard configuration.

Last updated: