Added support for Paddle Billing

[deanpcmad]

This PR adds support for Paddle Billing, the new service/APIs available from Paddle. More Info

• Old Paddle code has been renamed to Paddle Classic
• Existing subscriptions will need to have their processor changed from paddle to paddle_classic

Paddle Billing now supports multiple subscriptions for a customer, similar to Stripe, so I've copied some code from Stripe and modified as required.

This uses my Paddle Gem which supports both the new Billing but also the Classic APIs. The existing Paddle Classic code is untouched, but could be changed to use my library.

Fixes #837

[excid3]

Dang! I will try and find some time this week to review.

The existing Paddle Classic code is untouched, but could be changed to use my library.

Let's do this in a second PR (before release). Consolidating dependencies would be nice and I'm sure that users on Paddle Classic will likely want to upgrade so they would only need the single dependency in the new version.

[deanpcmad]

It's not complete yet, just thought I'd create a PR of what I've done so far 😅

Let's do this in a second PR (before release). Consolidating dependencies would be nice and I'm sure that users on Paddle Classic will likely want to upgrade so they would only need the single dependency in the new version.

Sounds good 👍

[strzibny]

@deanpcmad It's great that you already started a PR.

I too looked into Paddle Billing recently. For one, I already documented the new webhook verification so you can reuse it for the PR: https://nts.strzibny.name/verify-paddle-billing-webhooks-rails/

I have one question. Should we design the pause & cancellations changes as they are in Paddle Billing?

In Paddle, subscriptions are active even on a grace period which looks like Pay now follows as well. Hovewer it seems to me that Pay still marks subscriptions as "paused" or "cancelled" even if the change is only scheduled.

What would be the right way for this PR to work?

I would maybe prefer to have this same as Paddle since it's less mental overhead. On the other hand I understand the value of doing it similarly as for other providers.

@excid3 can you provide any insight on the design here? (I might just misunderstand it.)

[deanpcmad]

@strzibny thanks for the link!

I'm not sure how the paused and cancelled subscriptions would work tbh. I see that they created a "scheduled change" with the effective_at field, which I'm currently using.

[strzibny]

Yep, exactly as you said, they should be modeled with scheduled changes I believe. But previously Pay would immediately marked a scheduled subscription to be paused or cancelled. I would like to avoid that and match the status in Paddle, whatever it is.

[deanpcmad]

Maybe setting the pause_starts_at field when a pause event happens and then when the webhook fires when the pause actually happens, then update the status to paused?

Also, when upgrading a subscription, Paddle creates a Credit, so when creating transactions that will need to be taken into account

[deanpcmad]

Not sure why the tests are failing at the mo

[deanpcmad]

I received an email about a comment on this but I can't see it now 🧐
But no, Classic and Billing use different ways of verifying the signature.
I've not had much chance to work on this, but I can give you access to my repo?

[excid3]

Whoopsie. I did not mean to merge that lol. 🙃

[excid3]

I did get tests passing again though. What other features are unfinished?

[deanpcmad]

haha, I did wonder that. I'm pretty sure all the subscription stuff is working.

Need to work out how Pay will show paused/cancelled subscriptions as Paddle use "scheduled changes". e.g. If I set a subscription to cancel, the status will still be active but there will be a scheduled_change option showing the action and the effective_at.
On Paddle Classic, Pay was set to change the status straight away but @strzibny said it might be best to change this for Paddle?

The documentation also need updating.

You may notice that I've removed the passthrough code for Paddle too as it's like Stripe, so a Customer will be created on Paddle and then a subscription will be linked to that customer

[deanpcmad]

Also need to work on tests for Paddle

[excid3]

I see that PaddlePay is still referenced in the new Paddle code, so we should update all those references as well.

All we need for the scheduled changes is to use those in the sync method to determine the date, just like we do with Stripe. Should be easy enough.

[excid3]

@deanpcmad I see the custom_data.passthrough is still referenced in Subscription#sync. That can be removed too?

[deanpcmad]

Sounds good, so still set the status and date fields as required? I believe I already have that set when running pause or cancel on the subscription, so that can be added so the sync method too.

And yes, that can be removed as I found that it's much easier and cleaner to set the Customer ID when setting up the Paddle subscription button.

I can help work through the docs, as there's a few changes on their new Paddle.js

[excid3]

Yeah, status should always be set to what Paddle has defined.

I'll go ahead and remove that. 👍

Docs + tests are going to be the biggest things to complete I think.

[excid3]

I think that charge needs either an update as it requires a Price ID now and does not use amounts.

[excid3]

After upgrading Jumpstart Pro... I'm starting to think it's better if we use Pay::PaddleBilling and Pay::PaddleClassic. Much easier to differentiate and less confusing for existing users. They're likely to keep that naming in their site / docs for a long time.

I will probably rename it today or tomorrow unless you beat me to it @deanpcmad.

[deanpcmad]

Yeah that makes sense tbh. Some tests need to be written for it too

[excid3]

I'll start a PR for it today.