5 ms·

Not OP but I've used the Stripe API extensively (I know it nearly end to end due to implementing one of the framework client libraries) and to me the parts that

Not OP but I've used the Stripe API extensively (I know it nearly end to end due to implementing one of the framework client libraries) and to me the parts that come to mind if I think "bloat"/"unintuitive" are SKUs, Coupons, and most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements. By far Stripe has the cleanest experience of all. I wish you'd treat your APIs more like amazon treats theirs though, that is to say: no private internal-only APIs; I should be able to reimplement the Stripe Dashboard in my own app if I so wanted (just like how the AWS console only uses public APIs). That'd also make for some cool potential projects like a Terraform plugin for Stripe. Feel free to reach out if you like, email on my profile.

nickjj 7y ago
> ... most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements. Yes, definitely this. Payment intents is so much more complicated and convoluted than the previous "Charges" API. Stripe went from one of the easiest bits of my app to develop to one of the most difficult, to the point where I'll admit it even temporarily killed my motivation to work on my app solely due to Stripe's API. I stopped working on the checkout process just to take a break and work on other parts of the app and it pains me to think about even touching the checkout flow again even though I know I have to in order to release my app. For any real app that's beyond the most trivial case you're likely going to be stuck using the "manual" payment intents workflow. Just figuring out which method to use was a huge ramp up of difficulty vs the old Charges API. I went as far as even emailing their support for advice and even they weren't able to give me a straight answer. Their primary advice was to recommend not using it and instead use their new Stripe-hosted checkout system (which will not work for most people since it's so limited) or continue using the old Charges API and lose out on payments due to authorization issues that will come with not being able to deal with the new user verification strategies that are required by some banks and cards. Like you I have no idea how to implement it any better, it's just the reality of the situation of the world we live in today but the bar has certainly been raised to consider accepting payments with Stripe now.
- zbuf 7y ago
  Yes, I feel Stripe has lost its edge with the new APIs. Interesting to hear 'demotivating' used as that's how I felt for a while. I needed many requests with Stripe support and could see the docs changing each time I returned to the task. The interesting one for me is the way the client triggers the transaction, and the server has to asynchronously process that. I'm pretty sure I'm still having dreams at night about all the edge cases and whether I've truly covered them. Others are probably a more "that seems to work" style of development. I was really happy with my idempotent IDs before....
  - edwinwee 7y ago
    >needed many requests with Stripe support Could you forward one or two of those to me? edwin@stripe.com
- Chris_Newton 7y ago
  Upvotes don’t show on HN, so let me first say this is very much like our recent experience. If those from Stripe who are reading this would like a hopefully constructive suggestion, may I suggest here the same thing I suggested to your support team? Right on the front page of your documentation site (https://stripe.com/docs https://stripe.com/docs) you have a step-by-step walkthrough for setting up a basic subscription the old way. If you follow through that process using one of the test cards for the new SCA behaviour (4000002500003155, say) you will see that the API effectively fails at a couple of points along the way. Presumably either integrations need to do something extra at those points to take into account what needs to happen for SCA, or integrations need to follow different steps in the first place so they don’t run into those problems. Either way, an equivalent step-by-step walkthrough showing how to use Stripe.js, the API and webhooks to set up a simple subscription in an SCA-compatible way would have been very helpful.
  - edwinwee 7y ago
    Thanks for the suggestion—you are right! We're working on a walkthrough that'll help with this now. Stay tuned.
benologist 7y ago
Second that for having all of the API be public. Being able to purge test data via API in a single call is long overdue too and would be a delight compared to the process now - sign in and navigate to the delete page and wait however many hours it takes to finish deleting records individually or silently crash. During this time the API credentials are blocked too. It would be really nice if there was a freeze on breaking API changes that amount to tweaking grammar too.
- scrollaway 7y ago
  Yeah I wonder why the purge-test-data job is blocking and long-running. I suspect it's just low priority to fix it, but I imagine it would be doable to "unlink" the user's entire "test database", provision a new one, and wipe the old one in the background whenever convenient (and not even necessarily the same day).
edwinwee 7y ago
Email sent! I'm pretty nostalgic, so I do miss the old Charges API sometimes. But Charges assumed payments were binary—and we all know they're most definitley not. This also doesn't help with the new SCA regulations that started rolling out last Saturday (https://stripe.com/sca https://stripe.com/sca). We've built Payment Intents to be future-proof. It tracks your customer's checkout flow, actually provides logic for retrying payments (subscriptions!), and also triggers authentication when necessary—so you'll meet SCA requirements. Many have told us this has been pretty easy (and improved conversion too), so I'm really sorry that you got unhelpful advice earlier. (Would be great if you could forward that to me: edwin@stripe.com.)
- marek0zinoviev 7y ago
  I agree that Payment Intents is a lot more complicated than Charges - it's like a snowball effect where a small amount of extra complexity in an underlying API (SCA) gets exaggerated into ever more complexity with each API that added on top of it. By the time it gets to our implementation it's horrible and occasionally (2% of the time?) we get a payment attempt that the client has handled and submitted to our server but isn't in succeeded state. We temporarily fix this by redirecting them back to the payment page but this time in 'Charges' mode. Which seems to work about 50% of the time I wonder how much of this complexity is necessary - inevitable given SCA - and how much is because of Stripe's desire to support DD / bank-based payment methods in one integration. I guess we will see if, once SCA becomes widespread, other payment processors have simpler integrations... Speaking of SCA, I really don't understand the motivation - it's not like higher fraud rates were hurting consumers, since those costs were borne by the merchants. My suspicion is that it is in the interest of card-alternatives like Sofort to add some friction to card payments, after all if every customer has to visit their bank for authentication anyway, why bother with a card payment at all? That said, it is infuriating that after wasting all that time re-developing, SCA doesn't seem to have gone live at all. It reminds me of GDPR - the law abiding god-fearing types spend weeks worrying about compliance, disrupting their business; whereas the cowboys just take no notice - and get away with it. It seems to be how the EU rolls: sweeping changes with terrifying penalties and sudden deadlines followed by minimal or selective enforcement.

nickjj 7y ago

> ... most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements. Yes, definitely this. Payment intents is so much more complicated and convoluted than the previous "Charges" API. Stripe went from one of the easiest bits of my app to develop to one of the most difficult, to the point where I'll admit it even temporarily killed my motivation to work on my app solely due to Stripe's API. I stopped working on the checkout process just to take a break and work on other parts of the app and it pains me to think about even touching the checkout flow again even though I know I have to in order to release my app. For any real app that's beyond the most trivial case you're likely going to be stuck using the "manual" payment intents workflow. Just figuring out which method to use was a huge ramp up of difficulty vs the old Charges API. I went as far as even emailing their support for advice and even they weren't able to give me a straight answer. Their primary advice was to recommend not using it and instead use their new Stripe-hosted checkout system (which will not work for most people since it's so limited) or continue using the old Charges API and lose out on payments due to authorization issues that will come with not being able to deal with the new user verification strategies that are required by some banks and cards. Like you I have no idea how to implement it any better, it's just the reality of the situation of the world we live in today but the bar has certainly been raised to consider accepting payments with Stripe now.

zbuf 7y ago
Yes, I feel Stripe has lost its edge with the new APIs. Interesting to hear 'demotivating' used as that's how I felt for a while. I needed many requests with Stripe support and could see the docs changing each time I returned to the task. The interesting one for me is the way the client triggers the transaction, and the server has to asynchronously process that. I'm pretty sure I'm still having dreams at night about all the edge cases and whether I've truly covered them. Others are probably a more "that seems to work" style of development. I was really happy with my idempotent IDs before....
- edwinwee 7y ago
  >needed many requests with Stripe support Could you forward one or two of those to me? edwin@stripe.com
Chris_Newton 7y ago
Upvotes don’t show on HN, so let me first say this is very much like our recent experience. If those from Stripe who are reading this would like a hopefully constructive suggestion, may I suggest here the same thing I suggested to your support team? Right on the front page of your documentation site (https://stripe.com/docs https://stripe.com/docs) you have a step-by-step walkthrough for setting up a basic subscription the old way. If you follow through that process using one of the test cards for the new SCA behaviour (4000002500003155, say) you will see that the API effectively fails at a couple of points along the way. Presumably either integrations need to do something extra at those points to take into account what needs to happen for SCA, or integrations need to follow different steps in the first place so they don’t run into those problems. Either way, an equivalent step-by-step walkthrough showing how to use Stripe.js, the API and webhooks to set up a simple subscription in an SCA-compatible way would have been very helpful.
- edwinwee 7y ago
  Thanks for the suggestion—you are right! We're working on a walkthrough that'll help with this now. Stay tuned.

benologist 7y ago

Second that for having all of the API be public. Being able to purge test data via API in a single call is long overdue too and would be a delight compared to the process now - sign in and navigate to the delete page and wait however many hours it takes to finish deleting records individually or silently crash. During this time the API credentials are blocked too. It would be really nice if there was a freeze on breaking API changes that amount to tweaking grammar too.

scrollaway 7y ago
Yeah I wonder why the purge-test-data job is blocking and long-running. I suspect it's just low priority to fix it, but I imagine it would be doable to "unlink" the user's entire "test database", provision a new one, and wipe the old one in the background whenever convenient (and not even necessarily the same day).

edwinwee 7y ago

Email sent! I'm pretty nostalgic, so I do miss the old Charges API sometimes. But Charges assumed payments were binary—and we all know they're most definitley not. This also doesn't help with the new SCA regulations that started rolling out last Saturday (https://stripe.com/sca https://stripe.com/sca). We've built Payment Intents to be future-proof. It tracks your customer's checkout flow, actually provides logic for retrying payments (subscriptions!), and also triggers authentication when necessary—so you'll meet SCA requirements. Many have told us this has been pretty easy (and improved conversion too), so I'm really sorry that you got unhelpful advice earlier. (Would be great if you could forward that to me: edwin@stripe.com.)

marek0zinoviev 7y ago
I agree that Payment Intents is a lot more complicated than Charges - it's like a snowball effect where a small amount of extra complexity in an underlying API (SCA) gets exaggerated into ever more complexity with each API that added on top of it. By the time it gets to our implementation it's horrible and occasionally (2% of the time?) we get a payment attempt that the client has handled and submitted to our server but isn't in succeeded state. We temporarily fix this by redirecting them back to the payment page but this time in 'Charges' mode. Which seems to work about 50% of the time I wonder how much of this complexity is necessary - inevitable given SCA - and how much is because of Stripe's desire to support DD / bank-based payment methods in one integration. I guess we will see if, once SCA becomes widespread, other payment processors have simpler integrations... Speaking of SCA, I really don't understand the motivation - it's not like higher fraud rates were hurting consumers, since those costs were borne by the merchants. My suspicion is that it is in the interest of card-alternatives like Sofort to add some friction to card payments, after all if every customer has to visit their bank for authentication anyway, why bother with a card payment at all? That said, it is infuriating that after wasting all that time re-developing, SCA doesn't seem to have gone live at all. It reminds me of GDPR - the law abiding god-fearing types spend weeks worrying about compliance, disrupting their business; whereas the cowboys just take no notice - and get away with it. It seems to be how the EU rolls: sweeping changes with terrifying penalties and sudden deadlines followed by minimal or selective enforcement.