3 ms·
If they do not have time acceleration I think it's clear that the fault lays with Stripe and their bad testing practices. I thought people paid Stripe to handle
by emj 5y ago
If they do not have time acceleration I think it's clear that the fault lays with Stripe and their bad testing practices. I thought people paid Stripe to handle the "get money from humans" problem, that is a pretty broad problem though so Ig guess not. Considering it took Stripe, and lets be generous, 7 months to figure this out they obviously have problems with testing.
- unfocussed_mike 5y agoI don't know how you can say any of this with the certainty you're conveying here. It seems wholly unwarranted. For the most part you test your app in development the way you test any app that uses a third-party API service: by carefully reading the documentation, faking/stubbing responses and triggering your own webhooks with example data (which you can do from their devtools). So beyond that, a sandbox that does everything the same way the live environment does except actually move money is actually the right kind of sandbox. There are some narrow situations in Stripe Connect testing where it would be really nice to be able to tell Stripe to count days as minutes, though it does seem to ignore initial delay_days delays which is the most important one. An official stateful Stripe mock with Connect support and webhook triggering would be useful (localstripe is excellent but lacks this). But you shouldn't dive into Stripe Connect without knowing that it gets complex if you're deploying it globally, and I dare say the same applies to automatic taxation across different jurisdictions. You're going to need to know how to test this.