12 ms·

Note: this is different than Braintree and Amazon payments, which either refund in full or simply charge only the $0.30 fee. Stripe is now at or near the most e

Note: this is different than Braintree and Amazon payments, which either refund in full or simply charge only the $0.30 fee. Stripe is now at or near the most expensive here relative to the competition. The idea that they have been doing customers a favor is not accurate. I have used stripe for years, but they are a company that has continued to make things worse with every update, versus AWS which has my trust they won't increase rates. If AWS ever offered a true competitor, we would switch. They invest in publishing books, but they still miss basic features like a way to test credit cards in the production system for QA purposes. It's an easily solved problem (let you generate one time fake card numbers programmatically that stripe "pretends" to charge). I have been trying to test checkout flows with them for years and their official stance is "don't test production checkout flows", which is insane. I hope stripe changes it's ways here, but they have been a large disappointment over the last 4 years or so after a solid start.

polemic 7y ago
> ..don't test production checkout flows.. That's good advice. Payment providers have test gateways and cards for you to test your code against. While it might be a minor convenience for you to have 'fake' cards in their production system, the only thing they have to gain is a potentially serious fraud loophole (at best), or an expensive footgun for you. Don't "test" checkout flows in production unless you're using real credit cards :D
- rblatz 7y ago
  Agreed, test environments exist for a reason, if you don’t trust your test environment to accurately replicate prod then you need to clean that up.
  - edwinwee 7y ago
    Yes, testing in production can be dangerous and Stripe purposefully designed as many testing scenarios we could think of to avoid that (https://stripe.com/docs/testing https://stripe.com/docs/testing).
    - rblatz 7y ago
      Yep, I oversaw the implementation of the stripe connect api into our product. You guys have been great to work with.
  - seanwilson 7y ago
    Do you mean this in general or for Stripe? For the former, you have to run some tests on production after initial setup and major changes surely? API keys could be wrong for a start and a lot of web services don't give you a programmatic way to sync settings between environments.
    - OJFord 7y ago
      If you want to do some sanity checking in prod to rule out any issue with the test environment setup... Why would you want to set up a special fake test card in prod? Either don't do it, or have everything about it real. e.g. a canary purchase test & then a refund flow test. Yes there's a fee, but there's a fee when you do it for real. Hopefully you have many more real transactions.
- octocode 7y ago
  I used to run a company card for testing Stripe on prod, and then just processed a refund afterward. It was mildly inconvenient, and eventually I just stopped because there was never actually a difference between their staging and prod behaviour.
- Silhouette 7y ago
  Payment providers have test gateways and cards for you to test your code against. And yet in 2020, you still can't write an automated test suite that spins up a virgin test environment, simulates all relevant scenarios, and allows you to quickly verify that your integration is responding properly as part of your normal CI process. Working with a single, persistent test environment that offers no facilities to manage events like simulated user actions, API requests and webhooks feels like programming in another, much less productive era. Sadly, this still seems to be the norm for online payment services. It's particularly ironic that online payment services are among the worst offenders for making API changes that require significant changes to integrations or even a whole new integration, and that by their nature they are also at high risk of Very Bad Things happening if an integration breaks. This is exactly the sort of situation where you really want a tight feedback loop and ongoing automated integration testing! Stripe used to be a welcome exception, but even they have dropped the ball badly in recent times.
  - polemic 7y ago
    I don't quite understand this comment. In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs. Unlike other API services you can write integration tests against their test gateways. What are part of our industries is that normal? Most API-first services don't provide test endpoints at all.
    - Silhouette 7y ago
      In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs. They are also somewhat unique in that they handle real money. You don't need a simulated API if you're sending an email or SMS message to a designated recipient or downloading the local weather forecast or traffic news, because there are no significant and irreversible consequences to these actions anyway.
  - verletx64 7y ago
    You can’t create an entirely new sandbox, no, but you can, quite easily test most scenarios. Including weird stuff like falling into delinquency - it takes a little bit more thought, but it’s fine.
- derrick_jensen 7y ago
  One feature I would like to see is the option to create multiple test environments. I have one dedicated for the CICD, and ideally each person testing locally would have their own API key they can use however they wish.
exhilaration 7y ago
We use Adyen (we deal with international customers) and they've got the same rule - no test cards in production. I've never heard of a payment provider allowing test cards in prod.
- wonderwonder 7y ago
  I integrated with Adyen and found Stripe far easier to use. The international aspect forced me to use Adyen though. What was your experience like with them?
  - exhilaration 7y ago
    I've only done one integration with Stripe and it was such a nice experience that I recommended it to everyone. But nobody can beat Adyen's international support so it really depends on who your customers are.
  - lucaswb 7y ago
    I work for Adyen and would love to talk over any feedback and suggestions you have to make the integration easier. My email is lucas@adyen.com
curious_1 7y ago
Not my experience. Working with Stripe hasn't been error free. I've had one or two nasty bugs. But the product is fluid, works, and most importantly, they have great customer support. I wouldn't mind paying a little extra for it. I'm a relatively small fish, but they replied within hours and fixed the issue. On a Saturday. As long this "Saturday test" remains true, I'm a happy user.
- derrick_jensen 7y ago
  Honestly, I don't find their support helpful with fixing any of my issues, and asking the same question multiple times gives completely different responses. I managed to completely break the Stripe Test API (nothing works, always "in the process of deleting"), and I've been in support limbo for at least a week now. Haven't looked into the alternatives, but I hope I can move most commerce over to Bitcoin since I can run that fairly cheap internally to the company (and bypass PCI compliance, etc) EDIT: Maybe I was being overly critical in the first half, but in general implementation has been a bumpy experience. Most transactions on this platform are microtransactions, so it isn't that Stripe is expensive as much as I'm using it in an unconventional way, and not having a $0.30 static fee drastically changes my profit margins
  - edwinwee 7y ago
    Hrm, not good. Could you add me to that email chain and I can help? (edwin@stripe.com)
    - derrick_jensen 7y ago
      Nah, I don't want to be that guy. In the meantime I've just locally stubbed all Stripe API calls, since internal integration tests are all I need for non-production uses. I've also reached the point where regular production deployments make sense (or at least the payments logic is stable enough).
  - wonderwonder 7y ago
    I've always had pretty good luck on their freenode channel
pc 7y ago
(I'm one of Stripe's cofounders.) Thanks for the candid feedback. A few quick thoughts -- - This is not a new policy change -- it's been our pricing for all new users since 2017. (The news is that we're now applying this pricing to Stripe's older users, in part as a response to some price increases that the card networks are making.) - Our policy on refunds is pretty much the same as Braintree's. - We've added a lot of new functionality to Stripe since we launched in 2011. (The Stripe that launched back then did not support any non-card payment methods, non-USD currencies, non-US users, etc.) The vast majority of new features come with no new fees -- the Stripe package just gets better. For improvements that don't represent discrete new features, the changes can be non-obvious. Our goal is to quietly optimize things so that Stripe integrations continually get better without your code having to change. For example, Radar is far more effective at preventing fraud and chargebacks than it's ever been. Or, last year, we built an ML engine to automatically optimize the bitfields of card network requests. This has already generated an incremental $1 billion of revenue for Stripe users (with no additional cost). - Testing production flows with fake numbers is tricky. (How should these charges show up for reporting purposes? If we exclude them, that introduces another discrepancy. If we include them, that means you have to then handle the downstream cash discrepancy.) It's not an intrinsically unsolvable problem but we have not yet seen a clean solution that we feel good about. As other commenters point out, making sure they're sufficiently secure is also a challenge. - While we're proud of our books, I can assure you that the ratio of people working on improving our payments stack to publishing is about 1000:1. All that said, it's helpful to hear how it seems from your standpoint. We're acutely aware of how much Stripe has yet to do/build. We'll continue to work hard, and I hope we can support your business for many years to come.
- ValentineC 7y ago
  > Our policy on refunds is pretty much the same as Braintree's. I'm seeing something different on (my local) Braintree site [1][2]: > All processing fees, except the per transaction fee, are returned for full refunds. For partial refunds, all processing fees are returned at a prorated amount, but the transaction fee is not returned. [1] https://www.braintreepayments.com/sg/braintree-pricing https://www.braintreepayments.com/sg/braintree-pricing [2] Looks like the US one has the same policy as Stripe: https://www.braintreepayments.com/braintree-pricing?locale=us https://www.braintreepayments.com/braintree-pricing?locale=u...
manigandham 7y ago
Why not use a small charge against a real card? A few $1 charges work fine and are cheap enough to ignore.
- billyhoffman 7y ago
  Until someone in QA who keeps running that test flow manually says “Wait a minute, my time is valuable!” and scripts the checkout flow in Selenium...
  - manigandham 7y ago
    That's what the dev/staging environments are for. Even if you run it 3x/day in production, it's less than $100/month. Use a company card and you get the money back too. I don't see enough of a problem that requires all the technical debt to support fake numbers in production.
  - notwedtm 7y ago
    This is the difference between unit and integration tests.
    - OJFord 7y ago
      Manual vs selenium? No it isn't...
- sk5t 7y ago
  I've always had a concern about getting a real card flagged for fraud / card-status-probing and thus locked.
  - manigandham 7y ago
    I've never had it happen and it shouldn't be a problem for occasional spot checks. Make sure everything in dev/staging environments is working first before doing a production run.
deleted 7y ago
[deleted]
on_and_off 7y ago
>I hope stripe changes it's ways here, but they have been a large disappointment over the last 4 years or so after a solid start. Sadly the same experience here. Getting them to fix the many many basic issues of their client libraries is hell, testing is no better and library updates often break your testing scenarios.
- nkohari 7y ago
  I work on developer experience at Stripe. If you'd like to email me at my HN handle @stripe.com, I'd love to hear more about the trouble you've run into.
lucasverra 7y ago
a real alternative (from EU) https://www.mollie.com/en/payments https://www.mollie.com/en/payments They are big and cool like stripe. PS: not related to them, just met them at vivatech paris
ykevinator 7y ago
We've been using stripe for years, this may be enough for us to switch. Is Amazon's service reliable, easy etc?
- knudt 7y ago
  Wondering the same. This is the first I am hearing about Amazon having a payment service too.

polemic 7y ago

> ..don't test production checkout flows.. That's good advice. Payment providers have test gateways and cards for you to test your code against. While it might be a minor convenience for you to have 'fake' cards in their production system, the only thing they have to gain is a potentially serious fraud loophole (at best), or an expensive footgun for you. Don't "test" checkout flows in production unless you're using real credit cards :D

rblatz 7y ago
Agreed, test environments exist for a reason, if you don’t trust your test environment to accurately replicate prod then you need to clean that up.
- edwinwee 7y ago
  Yes, testing in production can be dangerous and Stripe purposefully designed as many testing scenarios we could think of to avoid that (https://stripe.com/docs/testing https://stripe.com/docs/testing).
  - rblatz 7y ago
    Yep, I oversaw the implementation of the stripe connect api into our product. You guys have been great to work with.
- seanwilson 7y ago
  Do you mean this in general or for Stripe? For the former, you have to run some tests on production after initial setup and major changes surely? API keys could be wrong for a start and a lot of web services don't give you a programmatic way to sync settings between environments.
  - OJFord 7y ago
    If you want to do some sanity checking in prod to rule out any issue with the test environment setup... Why would you want to set up a special fake test card in prod? Either don't do it, or have everything about it real. e.g. a canary purchase test & then a refund flow test. Yes there's a fee, but there's a fee when you do it for real. Hopefully you have many more real transactions.
octocode 7y ago
I used to run a company card for testing Stripe on prod, and then just processed a refund afterward. It was mildly inconvenient, and eventually I just stopped because there was never actually a difference between their staging and prod behaviour.
Silhouette 7y ago
Payment providers have test gateways and cards for you to test your code against. And yet in 2020, you still can't write an automated test suite that spins up a virgin test environment, simulates all relevant scenarios, and allows you to quickly verify that your integration is responding properly as part of your normal CI process. Working with a single, persistent test environment that offers no facilities to manage events like simulated user actions, API requests and webhooks feels like programming in another, much less productive era. Sadly, this still seems to be the norm for online payment services. It's particularly ironic that online payment services are among the worst offenders for making API changes that require significant changes to integrations or even a whole new integration, and that by their nature they are also at high risk of Very Bad Things happening if an integration breaks. This is exactly the sort of situation where you really want a tight feedback loop and ongoing automated integration testing! Stripe used to be a welcome exception, but even they have dropped the ball badly in recent times.
- polemic 7y ago
  I don't quite understand this comment. In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs. Unlike other API services you can write integration tests against their test gateways. What are part of our industries is that normal? Most API-first services don't provide test endpoints at all.
  - Silhouette 7y ago
    In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs. They are also somewhat unique in that they handle real money. You don't need a simulated API if you're sending an email or SMS message to a designated recipient or downloading the local weather forecast or traffic news, because there are no significant and irreversible consequences to these actions anyway.
- verletx64 7y ago
  You can’t create an entirely new sandbox, no, but you can, quite easily test most scenarios. Including weird stuff like falling into delinquency - it takes a little bit more thought, but it’s fine.
derrick_jensen 7y ago
One feature I would like to see is the option to create multiple test environments. I have one dedicated for the CICD, and ideally each person testing locally would have their own API key they can use however they wish.

exhilaration 7y ago

We use Adyen (we deal with international customers) and they've got the same rule - no test cards in production. I've never heard of a payment provider allowing test cards in prod.

wonderwonder 7y ago
I integrated with Adyen and found Stripe far easier to use. The international aspect forced me to use Adyen though. What was your experience like with them?
- exhilaration 7y ago
  I've only done one integration with Stripe and it was such a nice experience that I recommended it to everyone. But nobody can beat Adyen's international support so it really depends on who your customers are.
- lucaswb 7y ago
  I work for Adyen and would love to talk over any feedback and suggestions you have to make the integration easier. My email is lucas@adyen.com

curious_1 7y ago

Not my experience. Working with Stripe hasn't been error free. I've had one or two nasty bugs. But the product is fluid, works, and most importantly, they have great customer support. I wouldn't mind paying a little extra for it. I'm a relatively small fish, but they replied within hours and fixed the issue. On a Saturday. As long this "Saturday test" remains true, I'm a happy user.

derrick_jensen 7y ago
Honestly, I don't find their support helpful with fixing any of my issues, and asking the same question multiple times gives completely different responses. I managed to completely break the Stripe Test API (nothing works, always "in the process of deleting"), and I've been in support limbo for at least a week now. Haven't looked into the alternatives, but I hope I can move most commerce over to Bitcoin since I can run that fairly cheap internally to the company (and bypass PCI compliance, etc) EDIT: Maybe I was being overly critical in the first half, but in general implementation has been a bumpy experience. Most transactions on this platform are microtransactions, so it isn't that Stripe is expensive as much as I'm using it in an unconventional way, and not having a $0.30 static fee drastically changes my profit margins
- edwinwee 7y ago
  Hrm, not good. Could you add me to that email chain and I can help? (edwin@stripe.com)
  - derrick_jensen 7y ago
    Nah, I don't want to be that guy. In the meantime I've just locally stubbed all Stripe API calls, since internal integration tests are all I need for non-production uses. I've also reached the point where regular production deployments make sense (or at least the payments logic is stable enough).
- wonderwonder 7y ago
  I've always had pretty good luck on their freenode channel

pc 7y ago

(I'm one of Stripe's cofounders.) Thanks for the candid feedback. A few quick thoughts -- - This is not a new policy change -- it's been our pricing for all new users since 2017. (The news is that we're now applying this pricing to Stripe's older users, in part as a response to some price increases that the card networks are making.) - Our policy on refunds is pretty much the same as Braintree's. - We've added a lot of new functionality to Stripe since we launched in 2011. (The Stripe that launched back then did not support any non-card payment methods, non-USD currencies, non-US users, etc.) The vast majority of new features come with no new fees -- the Stripe package just gets better. For improvements that don't represent discrete new features, the changes can be non-obvious. Our goal is to quietly optimize things so that Stripe integrations continually get better without your code having to change. For example, Radar is far more effective at preventing fraud and chargebacks than it's ever been. Or, last year, we built an ML engine to automatically optimize the bitfields of card network requests. This has already generated an incremental $1 billion of revenue for Stripe users (with no additional cost). - Testing production flows with fake numbers is tricky. (How should these charges show up for reporting purposes? If we exclude them, that introduces another discrepancy. If we include them, that means you have to then handle the downstream cash discrepancy.) It's not an intrinsically unsolvable problem but we have not yet seen a clean solution that we feel good about. As other commenters point out, making sure they're sufficiently secure is also a challenge. - While we're proud of our books, I can assure you that the ratio of people working on improving our payments stack to publishing is about 1000:1. All that said, it's helpful to hear how it seems from your standpoint. We're acutely aware of how much Stripe has yet to do/build. We'll continue to work hard, and I hope we can support your business for many years to come.

ValentineC 7y ago
> Our policy on refunds is pretty much the same as Braintree's. I'm seeing something different on (my local) Braintree site [1][2]: > All processing fees, except the per transaction fee, are returned for full refunds. For partial refunds, all processing fees are returned at a prorated amount, but the transaction fee is not returned. [1] https://www.braintreepayments.com/sg/braintree-pricing https://www.braintreepayments.com/sg/braintree-pricing [2] Looks like the US one has the same policy as Stripe: https://www.braintreepayments.com/braintree-pricing?locale=us https://www.braintreepayments.com/braintree-pricing?locale=u...

manigandham 7y ago

Why not use a small charge against a real card? A few $1 charges work fine and are cheap enough to ignore.

billyhoffman 7y ago
Until someone in QA who keeps running that test flow manually says “Wait a minute, my time is valuable!” and scripts the checkout flow in Selenium...
- manigandham 7y ago
  That's what the dev/staging environments are for. Even if you run it 3x/day in production, it's less than $100/month. Use a company card and you get the money back too. I don't see enough of a problem that requires all the technical debt to support fake numbers in production.
- notwedtm 7y ago
  This is the difference between unit and integration tests.
  - OJFord 7y ago
    Manual vs selenium? No it isn't...
sk5t 7y ago
I've always had a concern about getting a real card flagged for fraud / card-status-probing and thus locked.
- manigandham 7y ago
  I've never had it happen and it shouldn't be a problem for occasional spot checks. Make sure everything in dev/staging environments is working first before doing a production run.

deleted 7y ago

[deleted]

on_and_off 7y ago

>I hope stripe changes it's ways here, but they have been a large disappointment over the last 4 years or so after a solid start. Sadly the same experience here. Getting them to fix the many many basic issues of their client libraries is hell, testing is no better and library updates often break your testing scenarios.

nkohari 7y ago
I work on developer experience at Stripe. If you'd like to email me at my HN handle @stripe.com, I'd love to hear more about the trouble you've run into.

lucasverra 7y ago

a real alternative (from EU) https://www.mollie.com/en/payments https://www.mollie.com/en/payments They are big and cool like stripe. PS: not related to them, just met them at vivatech paris

ykevinator 7y ago

We've been using stripe for years, this may be enough for us to switch. Is Amazon's service reliable, easy etc?

knudt 7y ago
Wondering the same. This is the first I am hearing about Amazon having a payment service too.