Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I generally like Stripe's API, and this blog post gives me some hope, but the complexity of their system and documentation has definitely been growing a lot more than I'd like. These days, I end up attaching `expand` to most API requests, because they've become addicted to overly nested data structures. And for some reason you have to include array brackets within the parameter name, so really it's `expand[]`, which is awkward in many contexts. The length of property names has gone up significantly and now often use multiple words separated by underscores, e.g. `statement_descriptor_suffix`, which is also awkward, especially in JavaScript. The docs still mention Sources and Tokens in many cases, without a clear translation to Payment Methods and usually without even mentioning that those concepts are deprecated or outdated.

Tangential to that, while the post seems to hint at trying to make a unified and cohesive experience, I can only see that happening for simple one-time payments. Subscriptions and Connect still seem like an afterthought. For the longest time, you could do destination charges for one-time payments but not subscriptions. Additionally, when using subscriptions with Connect, you have to specify the application fee as a percentage, which is painful for us because we want to charge a flat rate, so we have to fudge it with some math using hardcoded values to properly take into account coupons and Stripe's fees and we end up having to round to the nearest penny. It's just an unnecessarily messy headache. One-time payments are pretty easy with Stripe, the rest seems bolted on.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: