Hacker News Reader

Comment by kwindla | Hacker News Reader

I'm a Stripe fan, so my perspective on this is that Stripe has done an incredible job making "easy things easy," and a pretty good job making "hard things possible."

There are things I'd love to see added to the Stripe Billing APIs (some of which I mentioned in the article), but I have a really healthy respect for the amount of good work that's gone into the design of an API that, as you say, touches just about every part of a potential customer/payments workflow.

Stripe's API has consistent naming, a clean design of the core data objects, consistent data formatting and request patterns, good dashboard tools for seeing what's happened in requests and webhooks, and great documentation. All of which are non-trivial, and basically none of which any of the other "name brand" APIs I've used in the last year or so do. :-)

View on HN

Yes and no. Some parts of the documentation can be clarified in my opinion.

For example: if you change the default payment method of a Customer, the default payment method of all this customer's Subscriptions is not changed. The documentation is not clear about that.

Also, if you remove a payment method from a customer, the subscriptions seems unaffected. If you're not careful you might still end up charging this customers card when the subscription auto-renews.

I'm still a fan of Stripe though. I have my fair share of experience implementing other PSP's and they were an unbelievable PITA. As far is my experience goes, Stripe is miles ahead of their (european) competitors.

You're right, their documentation is great and the API is nice to work with, but you are forced to do things their way. I was recently working with Billing and ran into a pretty big issue: A customer on a recurring plan upgrades to a more expensive plan. As long as the customer has a valid source on file, the upgrade is processed. Stripe's default is to adjust the payment to be collected and charge it on the next invoice, which comes at the end of the billing period. If you want to charge the difference immediately, you can by manually forcing an invoice. The problem is that the invoice doesn't close for 24 hours and you can't force it to close any faster. If the customer's payment source is declined when the invoice closes, you just gave them 24 hours access to your premium upgrade which you now have to detect and rescind after being alerted via a webhook. There's nothing in the documentation that warns about this or offers a solution, and worse yet, rolling the user back to their previous plan is not an option. For some use cases, it might not be a big deal, but for most businesses that is a nightmare. The easy stuff is indeed easy, but once you start to wander off of The Path, things can get very difficult.

Our experience is that manual invoices are charged right away. I wonder what's different about our setups? The only thing I can think of off the top of my head is webhooks that aren't responding, which would delay the invoice closing. But I think that would make the delay 72 hours, rather than 24.

I misspoke, it's 1 hour, not 24. Can be found here [0]. Regardless, the upgrade happens _before_ the customer is charged, so unless you put a hold on your system and wait for that invoice to close, you're still giving them access before they've paid (Stripe's system will shown them as having the new upgraded plan before the invoice closes). And with the charge re-tries and back-off they use, if your webhooks aren't listening and reacting, you've still opened up your product to a user who hasn't paid for up to days at a time. I would be very interested to know how you got yours to close instantly, if it is doing that.

[0] https://stripe.com/docs/billing/invoices/subscription#genera...

If you want to skip the 1 hour delay, you can manually finalize the invoice:

https://stripe.com/docs/api/invoices/finalize

You're right, it's not synchronous! I looked back at our development notes and it seems like we were seeing about 15 minutes, generally, between creation of the manual invoice and finalization/payment. But that was using our test, not production Stripe API keys, and was a fairly small set of anecdata. I don't have better data because we ended up not rolling out any features that required manual invoice generation.

Why can't you just charge the card directly?

That defeats the entire purpose of using the Billing product. Best I could come up with is to auth the source for the amount and see if it is accepted, then let it die by not capturing. But then you have customers who complain about being double charged.

Stripe's generally consistent, except for three different ways to enter a name:

     name
     account_holder_name
     first_name + last_name

And four different structures for addresses:

     address_line1
     address.line1
     legal_entity.line1 (a personal address, old as of new version)
     legal_entity.personal_address.line1 (personal address when the prior is a business, old as of new version)

Reply on news.ycombinator.com