Best practice for Subscriptions with multiple payment methods (e.g. Stripe, Paypal, Crypto, etc.)?

Hi, I’m just implementing subscription payments into my website and want to allow customers to pay either by card (stripe), paypal or even with crypto (further down the line). I just had a couple questions on best practices for this implementation.

Would it be best to use the dj-stripe app and the paypal app and yet another app for crypto, with all their respective separate models? Or does anyone know if there’s a cleaner version e.g. using django-plans or something similar to centralize the subscription data instead of having it separated into stripe, paypal, crypto models? Of course the flip side of this is, despite the bloat, using the dj-stripe, django-paypal and whatever crypto app is probably the best choice in terms of maintainability, but it just feels so clunky having each of those apps installed and only using them for certain subsets of subscribers.

Part of me is tempted just to use django-paddle as that allows for stripe and paypal payments integrated as one, plus with the tax already taken care of - but this feels like too much vendor lock in. Plus Stripe is now offering some pretty good tax reporting tools.

I guess my main question, if anyone can offer any advice, is what is your advice on integrating multiple payment channels for a subscription SaaS? Such that we’re balancing out maintainability (least custom code as possible - so leaning on apps more) with simplicity (ideally one or fewest models containing subscriber data).

Does it even matter that much if, for example, I installed dj-stripe, django-paypal and some other crypto app and use them all individually but on the same site? Maybe this wouldn’t be as messy and ugly as I’m tempted to think it would be. Would this cause performance concerns?

Anyway, thank you for taking the time to read this. Would love and appreciate any advice, thanks.

@tyler

Please share how you implement this in the end. I am thinking about the same thing :slight_smile:

Hey shawn, I ended up just going with django-paddle for now, as it gives customers option of card or paypal + taxes taken care of. I’m watching the django-payments library as it develops though and there’s some promising work there. Looks like they’re just starting to flesh out subscription support and once that’s in I’ll definitely migrate to it at a sensible moment for my needs. django-payments seems like a good library for making your billing models payment method agnostic.

I see, thanks!

I am incline to go with django-payments since it’s maintained by jazzband and has more stars. Still, I need to try 1st …

Hi Guys.

I wanted to chime in for more information.
I recently started working on integrating PayPal subscriptions into my Django project and wanted to use django-paypal, but can’t get it to accept the IPN on the URL path:

Not Found: /paypal/ipn/
HTTP POST /paypal/ipn/ 404 [0.01, 127.0.0.1:62227]

Because of the troubles I’m having, I looked into the two you guys mentioned, but can’t see anything about subscriptions. Have any of you integrated a monthly subscription service?

I would just recommend using a service like getlago that way your monthly subscription can be set up easily and in a vendor-agnostic way (so you’re not totally beholden to paypal, or stripe)