What are the known limitations of the Paddle integration?
When sending Paddle data to ChartMogul, we strongly recommend setting your churn recognition setting in ChartMogul to When the subscription ends in your billing system (default). This allows us to properly set the churn date that the billing system provides. This is a global setting and will affect all data sources.
Further, we do not recommend use of the ChartMogul auto churn feature as the cancellation dates provided by Paddle should be adequate in most instances.
Because of a number of limitations in the Paddle API, the following features are either not support or are only partially supported:
- Paddle Classic - This integration is dependent upon webhooks being sent via Paddle. If you do not have webhooks sent historically, it will not be possible to reconstruct history. We suggest making sure that all webhooks are enabled.
- Paddle Classic - Partial Refunds are not supported
- Paddle Classic - Historical Refunds are not supported
- A historical full refund doesn't have the necessary information to treat it properly, so we remove it and the associated order which results in the correct MRR and net cash.
- Paddle Classic - Customer country uses the first order which will always take precedence.
- Paddle has heavily rate limited endpoints that restrict us from updating it on a last in basis (should the customer location change).
- Paddle Classic - Long sync times
- The Paddle API has restrictive rate limits in some cases that are global limits (across all of our customers). So, at times the initial sync make take several days to complete depending upon how much history you have in Paddle.