Support for subscription

[paulocoutinhox]

Hi,

Can you add support for subscription?

This is a nice project.

Thanks.

[mariofix]

Can you elaborate?

There are a few ways to handle recurring subscriptions (assuming that's what you are referring).

[paulocoutinhox]

Yes,

Im talking about recurring subscriptions.

This lib already have support for this?

I see some PRs to add support for this.

Things that help understand if the user is a subscriber will help.

[mariofix]

Perhaps this project would be helpful? https://github.com/PetrDlouhy/django-plans-payments

[paulocoutinhox]

Hi,

I want pay with this library a product with recurring subscription on checkout, it possible?

I don't know where i put the product-id in this library.

Thanks.

[mariofix]

Hi Paulo, the stripe endpoints available in this library are for Checkout Sessions.

I would suggest trying dj-stripe, I think they have support for other Stripe products.

[deeprave]

There are only a few differences between direct payment processing and subscriptions, but subscriptions/automatic payments will require a bit more backend work in periodic processing later. The initial part would be turning the capture off and saving the authorization ID, then processing the initial payment request as usual. A schedule - and some way of executing it - would be needed to initiate further payments using the same authorization/billing ID returned by the provider. The provider endpoints and content may differ slightly, but these are just provider variants. The infrastructure is already there for most of this.

I am looking for the same feature, so I will look into this further unless someone is already on it (in which case, I am more than willing to help in testing).

[mariofix]

hey @deeprave thanks for your message, I've been thinking about the subscription/recurring payments thing, and i'm not sure it'll be as straightforward, i was thinking something like:

• Add a payment_type with the options "one_time", "recurring"
• Add a recurring method in each provider that accepts subscriptions and processes the different reply structures
• Add a new url to process the webhook calls from each provider
• Add a new view/form to make the new payment

I'm worried about the payment_type, since it breaks backwards compatibility. I'm not sure how to store each payment made within the subscription, using extra_data seems a bit much since a single payment would take a lot of space.

It looks interesting, unfortunately i have a bit of a backlog with this project, but i'll be willing to assist if you'd like to contribute.

[deeprave]

You're right. I was working through an implementation and now better appreciate the complexity.

Breaking changes and restructuring the data in the db will be required to track individual payments against each provider authorization.

A suitable migration for payment_type could be done to backfill with the default value "one_time," but I think that, in reality, it requires more. There is a relationship between provider, available payment types, payment period and even amounts—which needs configuration. Sometimes, this can be fetched via provider-specific API.