How do make deferred downgrades with paddle integration

Hi ​@sitatech,

Thanks for reaching out. I’m happy to help.

RevenueCat relies on both Paddle's subscription state and transaction history to manage entitlements. When we receive a subscription.updated webhook, we fetch the latest subscription object and transaction history from Paddle's API to determine the current product and entitlements for the customer.

For your specific scenario using full_next_billing_period proration, RevenueCat will immediately change the user's entitlements when the subscription.updated webhook is processed. This is because Paddle updates the subscription's items to reflect the new product/price right away, even though billing is deferred to the next period. RevenueCat detects this product change on the subscription and updates entitlements accordingly, it does not wait until the current billing period ends. This means the user would lose access to their higher-tier features immediately, despite having paid for the full current period.

Our handling of Paddle's scheduled_change field currently only covers cancellations, pauses, and resumes, not deferred product or price changes. So there's no built-in mechanism to defer the entitlement change to the end of the billing period for this type of update.

Hope this helps, let me know if you have any other questions!

Best,

Hussain

Hi ​@hussain,

Thanks for your answer,

Does RevenueCat send both the PRODUCT_CHANGE and RENEWAL/INITIAL_PURCHASE webhook events for paddle upgrade/downgrade? This is well documented for Android and iOS here, but I couldn’t find anything about Paddle.

Also, does the store_subscription_identifier from the customer subscriptions endpoint match Paddle’s subscription id or corresponding transaction id?

Hi ​@sitatech,

RevenueCat does send PRODUCT_CHANGE webhook events for Paddle upgrades/downgrades. The specific events you'll receive depend on the proration type:

• For non-prorated changes (like full_next_billing_period): you'll receive only a PRODUCT_CHANGE event. Since Paddle doesn't create a new transaction in this case, only the existing transaction is updated with the new product, so no RENEWAL event fires at that point. A RENEWAL event would fire later when the actual renewal transaction occurs at the next billing period.

• For prorated changes (where Paddle creates a new transaction, e.g. prorated_immediately): you'll receive a PRODUCT_CHANGE event, and you may also receive a RENEWAL event for the same transaction if it qualifies as a renewal (i.e., its billing period is different from the subscription's original start). Both events can fire for the same transaction.

• INITIAL_PURCHASE is only sent for the very first transaction of a subscription, so it would not be triggered by an upgrade or downgrade.

The store_subscription_identifier from the customer subscriptions endpoint corresponds to the Paddle transaction ID (txn_*), specifically, the transaction ID of the latest/current period's transaction. It changes with each renewal as the latest transaction updates. It does not correspond to the Paddle subscription ID (sub_*).

The Paddle subscription ID (sub_*) maps to the original_transaction_id in webhook event payloads.

Hope that clears things up! Let me know if you have any other questions.

Best,

Hussain