The problem with Spreedly is that I still have to do a lot of stuff on my side. Spreadly would just give me some hooks, but then I have to handle these hooks my

The problem with Spreedly is that I still have to do a lot of stuff on my side. Spreadly would just give me some hooks, but then I have to handle these hooks myself. For example, I need to put on hold premium benefits of temporary non-paying users. Spreedly (or Stripe for that matter) cannot do it for me. I don't know if Spreedly can send notification email to my users (Stripe cannot at that moment), but even if such notification can be sent, there could be issues with email deliverability or with mismatch between my website name and spreedly "from" email field. User expresses the intent to upgrade or downgrade on my web site. In order to communicate that intent to Spreedly/Stripe/PayPal I have to make a call that reflects that intent. If the change is as simple as switch to another plan - then it may make sense. But if it's an edge case (e.g. discount), then I have to use more complex version of API. If I go through all that complexity anyway - why not just communicate with my own database and drop third-party dependency whenever possible? Fortunately with Stripe it's quite possible: I just charge credit card whatever the right amount is at whatever the right time is. That's it. No researching Stripe/Spreedly/PayPal subscription model. No dealing with arbitrary restrictions of these models. Another problem with Spreedly is that it does not support Google Checkout (most of my existing customers are from Google Checkout - my first payment processor). So I need to maintain all my Google Checkout customers myself anyway without any Spreedly help. Bottom line: if you want to polish subscriptions UX for your customers - handling subscriptions in-house is the only viable long-term option. (Keep only subscriptions in-house. Payments processing should be outsourced). Yes, it takes time. That's the cost of doing subscription business.