The fact that it took the writer three months (!) to spot this problem sets up a situation (IMO) in which swearing for effect in a chat session is out of the question. It's partly on him.
Anything to do with money and tax internationally is complex, and it should be monitored at least until you know it works, e.g. put dates in your diary to check your first international customers paid the right tax?
I must say, the Stripe chat session support people are heroes when you consider the breadth of the topic area they are covering, and some of the random chat abuse they must get from confused end user customers, and I don't think they deserved the fake-swear or some of that tone.
Especially when the writer concedes he could have been productive in the meantime. Some of this stuff just goes with the territory, and they are a business, not magicians.
There's also a sandbox -- is the writer saying there was no way to find this out through testing in the sandbox?
I have had one experience like this where I got a result I did not expect on live compared with the sandbox, which came down to quirks of my sandbox testing.
Specifically to do with trying to speed up testing [0]. I was getting payment collection tested within the day, but that meant a setting that affected something that happened at the end of the billing day never showed an impact in testing; on live it always would. That outcome, I think, could have been covered in a footnote like the one that was added after the writer's experience.
The reality is that Stripe's documentation is heroically excellent (a counterpoint to the Hugo story yesterday) but their system is vast and has all sorts of complex real-world interactions. They have shown they are responsive by correcting the documentation going forward.
[0] About the only thing I wish you could do that you cannot, is accelerate time in the sandbox, to make stuff like this easier to test. I understand why you can't but this is my fantasy. A stateful Stripe Connect mock would be useful though; I had to add one to my app.
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.
I 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.
OK wow, I have never seen that, though I haven't done anything with subscriptions myself yet.
Thanks so much for pointing this out.
Looks like is is only for Billing/Subscriptions, rather than for the inter-account events in Stripe Connect that I am referring to in my case. At least so far. Oh I would _love_ time acceleration for Connect.
But it could have helped the writer of the original post test stuff out.
Anything to do with money and tax internationally is complex, and it should be monitored at least until you know it works, e.g. put dates in your diary to check your first international customers paid the right tax?
I must say, the Stripe chat session support people are heroes when you consider the breadth of the topic area they are covering, and some of the random chat abuse they must get from confused end user customers, and I don't think they deserved the fake-swear or some of that tone.
Especially when the writer concedes he could have been productive in the meantime. Some of this stuff just goes with the territory, and they are a business, not magicians.
There's also a sandbox -- is the writer saying there was no way to find this out through testing in the sandbox?
I have had one experience like this where I got a result I did not expect on live compared with the sandbox, which came down to quirks of my sandbox testing.
Specifically to do with trying to speed up testing [0]. I was getting payment collection tested within the day, but that meant a setting that affected something that happened at the end of the billing day never showed an impact in testing; on live it always would. That outcome, I think, could have been covered in a footnote like the one that was added after the writer's experience.
The reality is that Stripe's documentation is heroically excellent (a counterpoint to the Hugo story yesterday) but their system is vast and has all sorts of complex real-world interactions. They have shown they are responsive by correcting the documentation going forward.
[0] About the only thing I wish you could do that you cannot, is accelerate time in the sandbox, to make stuff like this easier to test. I understand why you can't but this is my fantasy. A stateful Stripe Connect mock would be useful though; I had to add one to my app.