7 ms·

Stripe has made transactions for my SaaS business so painless. I recently learned that I have customers with different currencies and it's not even something I

by warent 7y ago

Stripe has made transactions for my SaaS business so painless. I recently learned that I have customers with different currencies and it's not even something I had to consider or account for. Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases, but their superb documentation, clean dashboard UX, and relatively low fees really make the value offering huge. Overall I'm really not surprised at the valuation. Stripe is one of the best products/services out there.

Despegar 7y ago
Why is it better than Adyen?
- warent 7y ago
  For starters I've never heard of Adyen until just now. So, perhaps better marketing?
  - joshmn 7y ago
    It's pretty popular in the Europe and is a Dutch company.
    - scient 7y ago
      Its only "popular" because for a long time it was the only choice in Europe pretty much. In several countries it still is. It also was total garbage developer friendliness wise ~5 years ago.
      - mtgx 7y ago
        Well, Stripe still isn't available in like one quarter of the European countries.
- odiroot 7y ago
  I had the unfortunate opportunity to integrate with Adyen around 2016-2017 and it was super painful. The API didn't make much sense to me and the documentation was hard to navigate and understand. It all looked very rough and rushed to the market. Granted it was "a long time ago" but I can still remember the pain.
  - nspady 7y ago
    Had a very similar experience around that same time. However, Adyen provided much nicer built in reporting features than Stripe at the time which made Finance happy.
edwinwee 7y ago
We do want to optimize for those simple needs. Which parts do you think are bloated? Would love to hear how we can de-bloat. (Feel free to email me at edwin@stripe.com too.)
- enraged_camel 7y ago
  It would be great if the UI allowed you to mass-delete entries, at least in test mode.
  - djmashko2 7y ago
    Hi! I work at Stripe on the Dashboard. You can delete all of your test data by clicking a button in Settings > Data (/account/data). We also recently launched a feature that lets you delete multiple customers at a time, and hope to expand that to more different types of objects soon! Thanks for the feedback, keep it coming :)
    - Kye 7y ago
      >> "I work at Stripe on the Dashboard." I thought I saw someone running around in there.
- scrollaway 7y ago
  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.
munk-a 7y ago
Yea, I'm pretty cool with this IPO as the company has built into filling quite a good niche while also putting pressure on MasterCard/Visa to clean up their monopoly softened act. I hope they find good success in the long term! Edit: Oh please ignore my blindness, I didn't realize this was just a pure valuation announcement.
- mylons 7y ago
  where does it say this is an ipo? from the article: "Founded in 2010, Stripe is middle-aged by Silicon Valley standards, but Mr. Gaybrick and Stripe president John Collison said it had no plans to go public. "
bluedevilzn 7y ago
>their API is a little bit... bloated for simple needs I used Stripe about 7 years ago. I used it because their APIs were simple and PayPal etc. was complex and bloated. It seems that this cycle repeats throughout b2b startups. Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases?
- erikpukinskis 7y ago
  Always, in every part of the stack. The world of software APIs breathes in and out in waves of complexity.
- Chris_Newton 7y ago
  Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases? I think so. One of my businesses has used Stripe since they launched in the UK, around the same time we were launching ourselves. Like many others, we appreciated the straightforward API, excellent documentation and easy integration. I’ve been happy to recommend Stripe personally on many occasions since then. Recently, we were trying to update that original integration to take into account the new SCA rules that came in across the EU last weekend. Unfortunately, after reviewing Stripe’s current documentation site in its entirety and other SCA-related material, followed by a lot of discussion with Stripe’s support team, we were still struggling to understand the model of how SCA fits in with Stripe’s current API. That left us unclear about the structure that our integration needed in terms of Stripe.js, the API and webhooks. Essentially, after a lot of effort, we still didn’t really know where to start, and inevitably there came a point where it wasn’t viable to continue and we had to look at other options. Of course Stripe has grown a lot more than we have in those intervening years and it’s understandable that their data models and APIs will have become a lot more complicated to meet the needs of their wider target audience. But sadly, the simple API, clear documentation and top-notch support that made them so attractive originally do seem to have been casualties along the way. Given that SCA seems to be causing a lot of bother across the whole industry in Europe, to the point that several EU member states seem to be deferring its implementation because so many people aren’t ready for it despite years of advance notice, it does feel like there’s an opportunity for someone to disrupt the online card payments market in Europe now with a back-to-basics approach that is enough to meet the new regulatory requirements. One interesting question is whether it will actually be another card payment service that does so, given that a lot of other payment methods are popular in various European countries and some of them do have significant advantages including fewer complications due to SCA. We live in interesting times, as they say.
thaumasiotes 7y ago
> I recently learned that I have customers with different currencies and it's not even something I had to consider or account for. If your customers are at all price-sensitive, you might want to give this a little more consideration. Banks and payment processors always offer "We handle currency conversion for you! How convenient!", and they pretty much always do it by charging several times the normal conversion fee (in the form of converting at an extraordinarily unfavorable exchange rate). I hate merchants who use those services; I have a credit card that will pay you in any currency and only charge me a 1% conversion fee. Please charge me in your currency, not my currency.
- Chris_Newton 7y ago
  Please charge me in your currency, not my currency. We did that initially, but you do discover a few downsides fairly quickly. One is that if you also price in your (the vendor’s) currency, for any sort of recurring subscription or repeat purchase, exchange rates can cause noticeable and possibly surprisingly large changes in what your customers pay from one time to another. Naturally this is viewed favourably by your customer if the rate has moved one way but less so if it went the other. Another is that not everyone’s cards charge as little as a 1% conversion fee. If you’re charging a typical consumer subscription of say £10 per month from here in the UK, some customers could easily wind up paying several pounds more by the time you add in the percentage and flat fees that some card providers seem to be charging for foreign currency transactions. And finally, some people have never travelled much abroad and don’t really understand how things like currencies, exchange rates and conversion fees work at all. You’ll get someone who has signed up at £10/month, with the amount and currency clearly displayed at every step of the process, who will then email you to ask why they were charged $14.63 instead of the $10 they agreed to. Sometimes there isn’t much you can do at this point, no matter how much you try to explain that $10 and £10 are not the same, and that their card company has added a hefty surcharge for the conversion, and that this would have been explained in the credit card terms (which they probably never read) and isn’t something you have any control over as the merchant. It’s a tricky area, because there’s usually nothing in it for a merchant to push a customer who does know what they’re doing and does have good terms into paying via the less favourable currency. On the other hand, if you start to provide explicit options for this sort of thing so each customer can choose for themselves, you risk making your payment process more complicated and losing conversions due to analysis paralysis. As ever, there’s not really a single “right answer” when you’re dealing with customers with very different arrangements on their side that you can’t even detect.
pc 7y ago
> Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases You're right. We're fixing this. Stay tuned.
- huhtenberg 7y ago
  Please also make using Elements with Stripe.js v3 fully optional. We finished migrating to SCA-enabled payment flow not few days ago. Apparently, you can't create a PaymentMethod instance without using Elements and we don't have the time (nor do we see any practical need) to redo the frontend with them. So the end result is a Frankestein-style frontend that uses the v3, but with a fair share of v2 methods, because it's the only way to retain all the functionality we had prior to the migration (e.g. saving the card info for future use). This was a bit of nasty surprise to be honest. Migrating to the v3 basically breaks existing systems in a non-trivial and expensive to fix way... and the migration is mandatory because of SCA. * SCA = strong customer authentication
  - lx 7y ago
    Elements is not a requirement to create a PaymentMethod. The recommended path factors in PCI stuff etc. Feel free to email me to lx@stripe.com
    - huhtenberg 7y ago
      Uhm... got a link? According to [1] it is required and there's no other (documented) way to do it. Ditto for stripe.createToken() [2]. In fact, there's no word in the docs on how to feed raw card data into the v3 at all. So we had no choice but to use Stripe.card.createToken() from the v2, but then also use stripe.handleCardAction() from the v3 for confirmation... it's a mess. What did we miss? [1] https://stripe.com/docs/stripe-js/reference#stripe-create-payment-method https://stripe.com/docs/stripe-js/reference#stripe-create-pa... [2] https://stripe.com/docs/stripe-js/reference#stripe-create-token https://stripe.com/docs/stripe-js/reference#stripe-create-to...
      - 7y ago
jwr 7y ago
I am considering migrating from Braintree to Stripe. It does look better, but I find some of the praise a bit too rosy. For example, the whole invoicing setup makes US-specific assumptions which are largely invalid where I operate (EU, specifically Poland), and I wonder if their recurring billing can be used without invoices. Also, there is no SAF-T (JPK FA in Poland) reporting for invoices, which means I can't even legally use their invoicing. Their E-mail templates are not customizable, which in my case makes all of their E-mail functionality useless. Then the PSD2 SCA (3d-Secure) flows seem to be hastily added and there is no good overview in the documentation (Braintree suffers from the same problem). It still looks like the best option I have, though.

by warent 7y ago

Despegar 7y ago

Why is it better than Adyen?

warent 7y ago
For starters I've never heard of Adyen until just now. So, perhaps better marketing?
- joshmn 7y ago
  It's pretty popular in the Europe and is a Dutch company.
  - scient 7y ago
    Its only "popular" because for a long time it was the only choice in Europe pretty much. In several countries it still is. It also was total garbage developer friendliness wise ~5 years ago.
    - mtgx 7y ago
      Well, Stripe still isn't available in like one quarter of the European countries.
odiroot 7y ago
I had the unfortunate opportunity to integrate with Adyen around 2016-2017 and it was super painful. The API didn't make much sense to me and the documentation was hard to navigate and understand. It all looked very rough and rushed to the market. Granted it was "a long time ago" but I can still remember the pain.
- nspady 7y ago
  Had a very similar experience around that same time. However, Adyen provided much nicer built in reporting features than Stripe at the time which made Finance happy.

edwinwee 7y ago

We do want to optimize for those simple needs. Which parts do you think are bloated? Would love to hear how we can de-bloat. (Feel free to email me at edwin@stripe.com too.)

enraged_camel 7y ago
It would be great if the UI allowed you to mass-delete entries, at least in test mode.
- djmashko2 7y ago
  Hi! I work at Stripe on the Dashboard. You can delete all of your test data by clicking a button in Settings > Data (/account/data). We also recently launched a feature that lets you delete multiple customers at a time, and hope to expand that to more different types of objects soon! Thanks for the feedback, keep it coming :)
  - Kye 7y ago
    >> "I work at Stripe on the Dashboard." I thought I saw someone running around in there.
scrollaway 7y ago
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.

munk-a 7y ago

Yea, I'm pretty cool with this IPO as the company has built into filling quite a good niche while also putting pressure on MasterCard/Visa to clean up their monopoly softened act. I hope they find good success in the long term! Edit: Oh please ignore my blindness, I didn't realize this was just a pure valuation announcement.

mylons 7y ago
where does it say this is an ipo? from the article: "Founded in 2010, Stripe is middle-aged by Silicon Valley standards, but Mr. Gaybrick and Stripe president John Collison said it had no plans to go public. "

bluedevilzn 7y ago

>their API is a little bit... bloated for simple needs I used Stripe about 7 years ago. I used it because their APIs were simple and PayPal etc. was complex and bloated. It seems that this cycle repeats throughout b2b startups. Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases?

erikpukinskis 7y ago
Always, in every part of the stack. The world of software APIs breathes in and out in waves of complexity.
Chris_Newton 7y ago
Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases? I think so. One of my businesses has used Stripe since they launched in the UK, around the same time we were launching ourselves. Like many others, we appreciated the straightforward API, excellent documentation and easy integration. I’ve been happy to recommend Stripe personally on many occasions since then. Recently, we were trying to update that original integration to take into account the new SCA rules that came in across the EU last weekend. Unfortunately, after reviewing Stripe’s current documentation site in its entirety and other SCA-related material, followed by a lot of discussion with Stripe’s support team, we were still struggling to understand the model of how SCA fits in with Stripe’s current API. That left us unclear about the structure that our integration needed in terms of Stripe.js, the API and webhooks. Essentially, after a lot of effort, we still didn’t really know where to start, and inevitably there came a point where it wasn’t viable to continue and we had to look at other options. Of course Stripe has grown a lot more than we have in those intervening years and it’s understandable that their data models and APIs will have become a lot more complicated to meet the needs of their wider target audience. But sadly, the simple API, clear documentation and top-notch support that made them so attractive originally do seem to have been casualties along the way. Given that SCA seems to be causing a lot of bother across the whole industry in Europe, to the point that several EU member states seem to be deferring its implementation because so many people aren’t ready for it despite years of advance notice, it does feel like there’s an opportunity for someone to disrupt the online card payments market in Europe now with a back-to-basics approach that is enough to meet the new regulatory requirements. One interesting question is whether it will actually be another card payment service that does so, given that a lot of other payment methods are popular in various European countries and some of them do have significant advantages including fewer complications due to SCA. We live in interesting times, as they say.

thaumasiotes 7y ago

> I recently learned that I have customers with different currencies and it's not even something I had to consider or account for. If your customers are at all price-sensitive, you might want to give this a little more consideration. Banks and payment processors always offer "We handle currency conversion for you! How convenient!", and they pretty much always do it by charging several times the normal conversion fee (in the form of converting at an extraordinarily unfavorable exchange rate). I hate merchants who use those services; I have a credit card that will pay you in any currency and only charge me a 1% conversion fee. Please charge me in your currency, not my currency.

Chris_Newton 7y ago
Please charge me in your currency, not my currency. We did that initially, but you do discover a few downsides fairly quickly. One is that if you also price in your (the vendor’s) currency, for any sort of recurring subscription or repeat purchase, exchange rates can cause noticeable and possibly surprisingly large changes in what your customers pay from one time to another. Naturally this is viewed favourably by your customer if the rate has moved one way but less so if it went the other. Another is that not everyone’s cards charge as little as a 1% conversion fee. If you’re charging a typical consumer subscription of say £10 per month from here in the UK, some customers could easily wind up paying several pounds more by the time you add in the percentage and flat fees that some card providers seem to be charging for foreign currency transactions. And finally, some people have never travelled much abroad and don’t really understand how things like currencies, exchange rates and conversion fees work at all. You’ll get someone who has signed up at £10/month, with the amount and currency clearly displayed at every step of the process, who will then email you to ask why they were charged $14.63 instead of the $10 they agreed to. Sometimes there isn’t much you can do at this point, no matter how much you try to explain that $10 and £10 are not the same, and that their card company has added a hefty surcharge for the conversion, and that this would have been explained in the credit card terms (which they probably never read) and isn’t something you have any control over as the merchant. It’s a tricky area, because there’s usually nothing in it for a merchant to push a customer who does know what they’re doing and does have good terms into paying via the less favourable currency. On the other hand, if you start to provide explicit options for this sort of thing so each customer can choose for themselves, you risk making your payment process more complicated and losing conversions due to analysis paralysis. As ever, there’s not really a single “right answer” when you’re dealing with customers with very different arrangements on their side that you can’t even detect.

pc 7y ago

> Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases You're right. We're fixing this. Stay tuned.

huhtenberg 7y ago
Please also make using Elements with Stripe.js v3 fully optional. We finished migrating to SCA-enabled payment flow not few days ago. Apparently, you can't create a PaymentMethod instance without using Elements and we don't have the time (nor do we see any practical need) to redo the frontend with them. So the end result is a Frankestein-style frontend that uses the v3, but with a fair share of v2 methods, because it's the only way to retain all the functionality we had prior to the migration (e.g. saving the card info for future use). This was a bit of nasty surprise to be honest. Migrating to the v3 basically breaks existing systems in a non-trivial and expensive to fix way... and the migration is mandatory because of SCA. * SCA = strong customer authentication
- lx 7y ago
  Elements is not a requirement to create a PaymentMethod. The recommended path factors in PCI stuff etc. Feel free to email me to lx@stripe.com
  - huhtenberg 7y ago
    Uhm... got a link? According to [1] it is required and there's no other (documented) way to do it. Ditto for stripe.createToken() [2]. In fact, there's no word in the docs on how to feed raw card data into the v3 at all. So we had no choice but to use Stripe.card.createToken() from the v2, but then also use stripe.handleCardAction() from the v3 for confirmation... it's a mess. What did we miss? [1] https://stripe.com/docs/stripe-js/reference#stripe-create-payment-method https://stripe.com/docs/stripe-js/reference#stripe-create-pa... [2] https://stripe.com/docs/stripe-js/reference#stripe-create-token https://stripe.com/docs/stripe-js/reference#stripe-create-to...
    - 7y ago

jwr 7y ago

I am considering migrating from Braintree to Stripe. It does look better, but I find some of the praise a bit too rosy. For example, the whole invoicing setup makes US-specific assumptions which are largely invalid where I operate (EU, specifically Poland), and I wonder if their recurring billing can be used without invoices. Also, there is no SAF-T (JPK FA in Poland) reporting for invoices, which means I can't even legally use their invoicing. Their E-mail templates are not customizable, which in my case makes all of their E-mail functionality useless. Then the PSD2 SCA (3d-Secure) flows seem to be hastily added and there is no good overview in the documentation (Braintree suffers from the same problem). It still looks like the best option I have, though.