They moved to Stripe for payments years ago, and it's helped them out a lot with simpler integration and more data. Sigma looks great for them.
They're not a big outfit, they don't have a dedicated engineering3 dept or developers on staff. Their main business is making chocolate after all.
With Sigma they can more easily query their transaction data and get all sorts of insight. My friend has degrees in Chemical Engineering and Nutrition, she's a smart woman and can do a lot more with excel that I can muster. Although she learned some coding in engineering school, using the APIs directly is a lot to ask. SQL is much more accessible, and was originally developed for business professionals just like her. So I expect something like this will help her go from periodic data imports and excel-based analysis to much more frequent, maybe daily, reports and analysis.
This is a great-looking product.
Note: I'm specifically excluding Redshift which requires active management
A lot of customers don't in fact do that. I've been working a bunch on dj-stripe (https://github.com/kavdev/dj-stripe) and trying to make it work exactly like that, but before that at the very least it's pretty safe to assume that most Django apps using Stripe only had a fraction of the data you can pull from Stripe.
It's also only a model you really need for subscriptions. For one-off charges, all you need is a copy of whatever data you care about in the charge and invoice models.
The act of reconciling the list of transactions you have stored in your database with what the source of truth has is an important process for finance teams.
Err... we push seven figures a year through Stripe, and we don't do this.
Though the point about data sets is important: even if we have the metadata here, ultimately it's only a partial view into money we're receiving.
But if Stripe is your only payment process, this is definitely interesting.
We are a fairly long-running Stripe customer, and we mirror all transaction data, with the exception of actual card info, into our internal dbms. I am presuming nearly all Stripe customers do this as well, considering how easy API integration is. So what is the utility of this service versus querying internal data - particularly when one can join on data sets that Stripe has no access to?