Hacker News Reader

> For example, what if customer does not upgrade the plan, but downgrades? How would proration work in that case?

Stripe deals with the prorata and credits the customers account next billing cycle.

> what if Stripe cannot charge credit card for a day or two

Stripe re-trys at time intervals you specify

> What if user managed to resubscribe again using different credit card

Stripe handles the connection because a subscription and card is attached to a customer object. Stripe will intelligently tie all this up and only charge the customer once even if two cards are entered.

> What if the card is permanently unchargable

After a specified number of failed charges stripe will send you a separate webhook at which point you know this is a completely failed card. Simply send the user an email and ask them to re-enter card details. If the card authenticates stripe will tie things together and correctly charge for the subscription.

> Stripe handles the connection because a subscription and card is attached to a customer object.

That all sound good in top-level theory.

In practice that would mean that I have to reattach new credit card to the same customer object in Stripe.

I didn't even research if it's possible, but if it is - that's a different API call. Different than API call for signing up new customer.

Updating credit card on existing customer makes it harder to allow customer to return back to customer's previous credit card ("Use my previously entered Visa credit card ending by 1234").

How about the case when:

- Payment delayed.

- I removed premium membership from user.

- Stripe subscription finally charged old user's credit card, but my system did not receive IPN notification yet.

- User resubscribed again with new credit card.

- Then my system receives old credit card charge IPN notification.

What should my system do in that case?

What if my user decided switch to PayPal and still has Stripe subscription stuck in the limbo?

What do I do when I receive that we-were-able-to-charge-that-stubborn-credit-card IPN if user already paid by other means?

Do you see how these "Stripe-to-my-system subscription synchronization" issues are getting very ugly very quick?

Maybe you should ask the Stripe people these questions.

This post is exactly why I use Spreedly (for my subscription product), because writing code for all the edge cases would cost me a metric truckload more than the pittance I pay them every month.

Any chance you looked at Saasy or any of the others on the matrix? Tr http://saasy.com/matrix.php Trying to choose a vendor now. I've heard good things about Spreedly also.

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.

Agreed. Pricing is too important to let someone else set all the rules. I'm not saying that Stripe did a bad job with their subscription system, but I think it's a mistake to let someone else make all the decisions when it comes to such a critical aspect of your business.

For example, I personally don't like prorating costs. I want my customers to be able to make changes and play around with the new features before deciding to pay. I also don't like the idea of having a few plans and forcing every single customer into one of them. I want everyone to use the software how they want, and pay based on that usage. These are important business decisions that would be impossible (or at least very difficult) if I used a pre-made subscription system.

Luckily Stripe makes it incredibly easy to roll your own subscription system.

We certainly understand that for some specific billing situations, Stripe's subscriptions API may not be a good fit. That said, we've tried to accommodate as many use cases as possible, and I just wanted to make sure you knew we have a prorate => false flag that you can pass when switching subscriptions. We also have a concept of usage-based charges (invoice items). Your larger point of course still stands (that there are always going to be edge cases and custom billing logic).

I think the best approach for you would be to keep one or two simple subscription cases and suggest your other customers who ask for edge cases to implement their own subscription system.

I wish you gave me that "do it yourself" recommendation - that would save me a lot of time (trying to squeeze what I need into subscription model that Stripe has).

Now that I do subscriptions in-house only - I don't even need to know what Stripe web-hooks are, what are all these possible subscription models and what are their limitations. Just two simple calls: one to create stripe customer and another to charge it when I need.