Hacker News new | past | comments | ask | show | jobs | submit login
Stripe Sigma (stripe.com)
398 points by darwhy on June 1, 2017 | hide | past | web | favorite | 118 comments



A couple of people have mentioned that Baremetrics should feel threatened, and that's where my mind went immediately too. I asked Josh Pigford for his reaction, and this is what he said:

> We've had beta access to it for a while and have known it was coming. Generally not worried about it at all nor do we view it as any sort of competition in any sense of the word.

> It doesn't give access to any new data...it's an SQL wrapper on top of their API (albeit a very pretty one).

> What we've found over the years is that you really need more data sources to make real decisions. So, yes, Stripe has a lot of data, but it only tells you part of the story. And that’s the thing here…Stripe’s not trying to “tell stories” with the data in Sigma. They’re just giving you a specific tool to access the data points.

> Baremetrics, however, is focused on telling the story. We want to help businesses know what to do with the data, not just slice and dice it in to spreadsheets.

> So, in summary, I think it’s neat but it won’t be anything for us to worry about from a competitive standpoint as we’re solving different problems.

That was all on-the-record, obviously, or I wouldn't share it.


I'd have to agree with Josh. Sigma looks pretty cool because it would save me from having to write some custom query scripts that I have to do now. However it doesn't appear to be competition for the Baremetrics dashboard as far as I can tell. I'm a happy user of theirs and don't feel lured away by Sigma at all.

Edit: Additionally, the pricing seems a bit much considering that Stripe is already making a good deal of money off of their users transactions and it isn't so much trouble to write your own queries via their api.


Stripes ultimate mission is to increase the total GDP of the internet. The more transactions that are happening on the internet, the better it is for them. So, from a company standpoint whatever they can possibly do to ensure that companies have the best tools available from stripe is what they are going to do. How hard would it be to expand into Baremetrics product from what they already have? They say that they are not competing, but I think they are. They are both in the business of giving their customers the best possible metric tools, period.


I don't see them as competing products or services at all. In fact, it might only increase visibility.

If we used subscriptions in Stripe, we'd use Baremetrics. But we manage subscriptions using third party software, so their metrics/products are unfortunately not a great fit.


> Baremetrics, however, is focused on telling the story

What's preventing Stripe from having a story-like dashboard?

For the record, here are some screenshots I found on Google Images of Stripe and Baremetrics's dashboards: http://imgur.com/a/s4V8u


For established customers maybe not as there's a cost to switching but I'd be very surprised if this didn't have a hit on their signups going forward (once it's GA).


I think you're probably overestimating what Sigma does and underestimating what Baremetrics does. If anything we've just got a bit more work coming for us to explain the differences and intricacies of it all. But, I'm not losing sleep. :)


I've only glanced at this, but I love the idea of making your API be SQL. I did this recently for a company whose customers have a lot of "power users" who are not professional programmers but use tools like R, Excel, Tableau, or even Python. The customers are very happy with it! We saved a ton of time not building a JSON API, which our customers wouldn't be able to use anyway.

Basically we create a customer-specific database whose contents are all derived from our real OLTP database, and give them read-only access to it. In our case they also have to be on a VPN, but we've talked about adding a web-based SQL console like I see here.

It's funny that at first this approach sounds crazy, but really it is what companies have been doing since the 90s: creating flattened read-only reporting databases. If you want to do this, you should read Ralph Kimball's _Data Warehouse Toolkit_ for some inspiration and guidance.

Of course you don't want to give customers access to your OLTP database. Besides the security and performance problems there, if your core database becomes a public API, it is frozen and you can never add another feature again. But a separate reporting database still gives you plenty of flexibility to grow.


My first reaction to seeing an SQL-based API is 'ugh'. SQL is complex and a little cumbersome, and easy to get wrong.

My second reaction is 'oh, thank god'. I'm so tired of having APIs where I have to go through the 'get the list of users', 'iterate over the list to create a map', 'get the list of messages', 'iterate over the list of messages and add the username to the data structure', 'oh wait I have to get the channel list separately too, seriously?', 'get the list of channels', 'iterate over the list to create a map', etc.

I love Slack's API, for example, but having to fetch a list of users, along with the entirety of their profile data and everything about them, then do the same for channels, then do the same for messages, then tie everything together, it's very cumbersome compared to

SELECT m.message, m.when, u.username, u.name, c.name FROM messages m LEFT JOIN users u ON (m.uid == u.uid) LEFT JOIN (m.cid == c.cid) where c.name == "#general" LIMIT 50;

(or whatever it should be, I haven't done SQL in ages)

And I also get a lot fewer records, especially when I'm trying to get the last 50 messages from #general on a Slack instance that has 400 users and 200 channels.


That's one of the problems that GraphQL is intended to solve, specifically you don't want to write your API queries directly in SQL but you also want the flexibility to chain queries together and specify the exact types of data you require.


Wonder what you'd think of a pull + datalog mix, which is what Datomic / Datascript do: https://github.com/Datomic/day-of-datomic/blob/master/tutori... The neat thing about the syntax there is that it's a datastructure which if you write a generic visual editor like https://developers.google.com/blockly/ over that only fits puzzle pieces when they satisfy https://clojure.org/about/spec you could...


For an internal hackathon we basically tried to do this but ran out of time. We built our own query driven API layer that is basically a shim over datomics query and pull apis.


A question I'm asking myself is the security one. Obviously the accessed databases only contain the customer's own information with read-only access. But how do you prevent resource exhaustion / DoS attacks trough overly complicated queries? This is the obvious vector that comes to my mind but I wouldn't be surprised if there were a few other ones similar to it.


I'm sorry, but I don't grok the utility of this. Can someone "explain this like I am five"?

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?


A friend of mine is director of business for https://www.franschocolates.com/ , which is a great local Seattle family business that has grown up to be big thanks to a great product (Seriously good chocolate!).

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.


Running a data warehouse is a full-time commitment. Tons of real businesses have no software engineers.

This is a great-looking product.


With modern data warehouses like BigQuery & Snowflake, this is no longer true. We at Fivetran get people setup with a BI tool, warehouse and data pipelines in a day. From there, its all SQL with little to no management of the underlying system.

Note: I'm specifically excluding Redshift which requires active management


> I am presuming nearly all Stripe customers do this as well

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.


Thanks for being one of the people working on dj-stripe! I've been following its dev for months, and slowly building it in to a site I'm building, so I'm thankful to the people working on improving it!


Your internal data might not be consistent with what is stored in Stripe. Since Stripe is the one processing the payments, it is ultimately the source of truth for all data regarding whether or not transactions went through, failure reasons, disputes... etc.

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.


edit: Downvoted for asking a legitimate question about Stripe's data handling protocols. I'll ask Stripe directly. Sorry.


There's plenty of stuff that changes out-of-band, such as subscriptions/invoices, retried charges, etc. You're supposed to use the Webhook system for this, but not everyone bothers.


> I am presuming nearly all Stripe customers do this as well

Err... we push seven figures a year through Stripe, and we don't do this.


Well if you had this, you could probably get along with this just this more often. Kinda like you can "just" use the dashboard for most businesses rather than doing a bunch of API stuff.

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.


> I am presuming nearly all Stripe customers do this

I think you answered your own question!


Is the data freshness a joke? 2 DAYS to get data into the data warehouse? Stitch, Fivetran, Segment, and more can do way better than that without any internal hooks.... :/

> Additional processing time–up to 48 hours–is required to make your account’s transactional data available in Sigma. This means that it does not reflect your account’s most recent data and should be considered a couple days behind. The Sigma interface displays the date and time of the last update to your data.


I've seen plenty of reporting pipelines that are that slow over the years. If this was built on the cheap, so it just uses existing pipelines, and instead of working through streaming, it regenerates the world every night, a 48 max failure with some is not out of the question once you add some CYA magic. That would make this pretty cheap to make: Some website work, boxes for queries, and some security work to make sure data from other customers doesn't leak.

Given how Stripe seems to build products in a lean way, it'd not surprise me if they are just launching like this and measure customer reaction. If the main reason it doesn't get the traction they want is the 48 lag, they'll just rewrite their reporting pipeline to use streaming, and the product gets faster for free.


For decision making, hopefully you're looking at more than the past two days.


Does that have anything to do with transaction settlement or just pure lag?

I can understand an async mode of updates being partially behind but two days seems excessively laggy without a business reason for it.


It's payments. Miss a single row and customers will balk and scream at the missing $.45 that they think they are owed. Better to buffer with a longer SLA until you feel very confident that your pipeline is bulletproof before you try to approach 24 hours or less.


Really cool! Signed up for the beta, excited to try it.

Although at first glance, it looks quite expensive. Having to pay $10 monthly outright even with no charges feels kinda bad. I'm a huge fan of Amazon's free tiers to experiment with; Stripe's test mode is very nice for the same reason. And on top of this, the pricing being per-charge makes it far more expensive for businesses selling cheaper products ($5 subscriptions vs. $100 subscriptions).

Compare to Baremetrics' pricing plans which scales based on MRR: https://baremetrics.com/pricing -- At $50k MRR with $5 charge avg, Baremetrics costs $100/mo, Sigma costs 2.5x that. For $2.5 avg charge, Sigma costs double, Baremetrics remain the same.

They still sound like very reasonable prices though (and Stripe's fees are unfriendly to lower price points anyway).


Yeah I think this just means you aren't their target customer. I'm sure there are people out there who will see this and happily pay hundreds or thousands a month because this solves a burning problem for them.

Stripe sells to businesses, they aren't gonna drive their bottom line off $10/mo.


Oh no, I'm their target customer. Like I said, I signed up for the beta and I'll happily be paying what it costs. But if you think about this as the "metrics" extension of Stripe (which, as mentioned in a separate thread, was a bit of a missing piece to their offering), the way it's priced is very surprising.


$10/month is two coffees. Not even worth thinking about if you find the service at all useful.


In any business, there is a cost incurred in researching and justifying a purchase in the first place. This is a big reason why free tiers and free trials help onboarding.


> $10/month is two coffees.

What?! Where does a single cup of coffee cost five dollars?

For ten dollars, you can brew at least fifty cups of coffee.


I see you are not familiar with Bay Area artisanal pour-overs featuring hand picked organic berries harvested under a blue moon by Fair Trade certified farmers (TM).

The (TM) alone adds $0.50 to the price of a cup.


Large late at Startbuck in London is £3.4 - which is close to 5 bucks I suppose. If you live in SF, London, NY, 5 bucks for a coffee does not seem outrageous.


Starbucks anywhere in the US, any coffee shop in a large metropolitan US city (NYC, SF, Seattle, Philadelphia).


I was surprised as this as well. I wouldn't think running these queries on small datasets would take much computing resources and would provide a nice competitive advantage over other alternatives.


Being able to query your data in SQL is great. But to be really useful, you need to be able to join many different data sources. For example, if you want to estimate [cost of sales] / [lifetime value], you need to join your Stripe data with your Salesforce data. Thats why companies like mine (Fivetran) exist: to mirror all your data sources in a single SQL warehouse. If you use a ETL-as-a-service provider and a fully-managed warehouse like BigQuery, it's really not that hard to set up your own data warehouse that has all your data in it.


Interesting offering. I wonder who they're targeting with this and the problem they're trying to solve.

* Is the expectation that everyone can write SQL?

* If the customer can write SQL and they're sufficiently large, won't they export the data into their own in-house data architectures to use the tools and processes they already have?

* Is data exporting that hard from stripe that they decided to offer a query tool instead?

I'm thinking they're going after the lower end of the customer base, the customers that may have medium to small transaction volumes. Plus those customers might not yet have any data warehousing to speak of.

If I was BareMetrics, I would be especially concerned because it will be a matter of time before Stripe has their own compelling offer that does almost everything it does and more. There have been other examples of building businesses around other companies APIs (granted theres always exceptions to the rule but I want to point out its a huge risk):

https://news.ycombinator.com/item?id=9512441

https://techcrunch.com/2012/10/14/why-you-shouldnt-build-a-b...


SQL is quickly turning into the new Excel. Most excel power users at our company have picked up SQL easily. Our product, merchandising, marketing, finance, and operations have all managed to teach people SQL for everyday use. This tool is for them.


I get excited whenever Stripe releases a new product because their demo pages are bar-none the best ever made. The attention to design is very, very nice.


I found out they have a Dribbble account recently! https://dribbble.com/stripe


> I get excited whenever Stripe releases a new product because their demo pages are bar-none the best ever made.

So, what does this software actually do? My company uses Stripe and it is not immediately clear.


It looks like a hybrid of Big Query / Looker for your financial data that lives in Stripe, with a lot of help to make it easier for users.

Imagine if you were a small and/or non-technical shop who used Stripe for your payments. This offers a window to produce good looking reports about the business without needing to keep track of that information in parallel outside of Stripe.

They have all sort of pre-run queries for MRR, Payment Methods, etc. which offers _huge_ benefit to those people who can get some great insights for no added work.


Me too, but I'm disappointed this time... http://imgur.com/a/msL4T


That doesn't look right. Could you share with me your browser and OS versions? edwin@stripe.com


It's fixed now, I was on chrome 58.0.3029.113 on iOS.


literally the only reason I clicked the link was to see what they would do with that viewport. A little darker and less colorful than their usual work, but as a standalone piece it looks great.

except for this one major bug... http://imgur.com/a/UWrcC


Agreed, although Mapbox comes close imho.


> We’ve already written the queries for the most useful reports for different types of businesses: From computing MRR to ARPU to analyzing the payment methods your customers prefer...

This would have to be worrying for companies like Baremetrics, ChartMogul etc.

Obviously it is not 100% the same - but the ability to quickly get MRR, ARR etc would solve many peoples main pain.


No one ever learns about the perils of building on someone else's platform.

See: twitter 3rd party devs, Buffer, Facebook app devs, etc

Stripe isn't a payment processor; they are your financial back office as a platform.


> Stripe isn't a payment processor; they are your financial back office as a platform.

Well, they're getting there; Metrics were the #1 missing piece from Stripe, so it's good to see this. Dealing with EU VAT is still a massive pain though.


Anyone at Stripe know if they have at least some plan to handle EU VAT at some point? Currently for that you'll have to use 3rd parties like Octobat or Quaderno. Despite these products are nice, it really feels like something that should be built-in.


Time to pivot haha! The competitors could give away their service for free and then setup an ad platform to target Stripe users. That lead gen might even make them more money.

And since they have the financial data, they could proactively recommend the most cost-effective service to switch to. Kind of like a Credit Karma model.


Buffer is a $10+ million business that has made their founders well off. If you wait and wait until you see a business opportunity with little risk, you could wait forever.


As usual, another beautiful Stripe product page. Fantastic job! The product looks pretty awesome too.

In case any Stripe-people are lurking here, the scrolling on the example query modals (the ones you get from clicking on e.g. "How many active customers do we have?") is painfully slow -- as though it had only been tested for Mac touchpads, where scrolling quickly is easy.

I'm on Firefox/Ubuntu, using a shitty USB mouse with a scrollwheel.

P.S.: What demonym does Stripe use? "Striper" is a letter away from an embarrassing typo.


Answering my own question: a person who works at Stripe is a "Stripe", not a "Striper".


I'm not that familiar with Stripe, but my first impression is: why spend time on creating an inferior Metabase / Periscope / Power BI / Looker / mariusandra/insights clone? Just allow data export and if you really want to give a ready-to-use product to your customers, Metabase seems awesome for this kind of thing?

Stripe could have particular constraints that I'm not aware of, but it seems to an example of not-invented-here syndrome.


maybe in order to help with sales and retention? can't see how it can hurt.

I was making some edits in iMovie last week when I started talking to this video production professional. He started asking me why I wasn't using something more powerful like Final Cut and judging me for it. Mind you I was using final cut at least a decade ago and knew all about its capabilities. But he failed to realize that for what I needed to do (cut clips and speed up / slow down segments and add an audio track), iMovie was simple to use and did everything I needed it to do. Lagom.

I'm willing to bet there are enough people who don't wish to complicate something simple and add another service to their workflow... and manage yet another user account... or build out custom dashboards... When all they want is to answer a simple yet important question like "which customers have not payed their invoices?"


I get what you're saying. Metabase is quite simple, by the way. I think you're assuming that all BI tools are heavy. You can get Metabase running in 5 minutes and you wouldn't know it from it's very intuitive GUI, which has it's limit. It's the iMovie in your iMovie vs. Final Cut analogy.


Without any doubts, Stripe is killing it. Great engineering, great design and great customer support. Shut up and take my money ;)


Perhaps a dumb question, but it's not completely obvious from the demo - is there an API for this?


Not a dumb question at all! We do not currently have an API for Sigma. Although, its a great idea and good feedback for the Sigma team. Hope you find good use of its current incarnation. Thanks!


+1 for this. It would be cool to be able to save the queries and get them from an API request to feed into some other BI tool... it would almost act as a saved rdbms "views"


That's.. disappointing to hear, and actually getting me less excited about Sigma than I was. Please do make the API available.


This is the reporting interface I wish our product had. I tried out Sigma during the beta and was very impressed with it, especially the front-end. SQL is a bold choice but I think the right interface given the structure of Stripe data.


Is this going to finally allow us to get the same stats that are shown in the Stripe dashboard (like "gross volume" for the month)? Stripe has had no way to get an aggregate of transactions in a timespan - if you wanted to get the "gross volume" or any other sum or count, you'd have to iterate through every payment. Not very convenient when you have tens of thousands of transactions and want to show an up-to-date revenue number on your company dashboard.


Technically, how would something like this architecturally be structured? Curious how they would sandbox the user data and still provide a SQL like interface.

I wrote something for Doctrine last year where I let my users query their own data using DQL. I had to write a TONNE of AST walkers to ensure that they weren't accessing entities they didn't have permissions to. Was a huge issue that I wish I didn't start :D (But one of those cool things when it was finished)


My guess: they implement a SQL parser and executor on top of whatever infrastructure they have already.

The SQL layer could probably just be an API client to the data they have already.


Is here anything out there which

  * connects to a database

  * allows a database admin to write a query once (maybe for $50 a query) against your database

  * allows the query to have variables and hints in the code

  * visualizes the result set as various types of graphs

  * for each variable, lets you set values and ranges and steps etc.

  * runs the queries and generates reports
I think this could be a good business. If you want to do it together, contact me: https://qbix.com/about


I have been pondering something like this for ages, as most solutions seem to be insanely expensive. Found this though recently fwiw http://activereports.grapecity.com/server/


https://modeanalytics.com could work for you


Pardon my ignorance! Coming from background of building data pipelines. It seems to me like SQL on backend data. The UI is uber cool. What makes it different from any rdbms system with UI? am I missing something ?


Great question. Sigma is more than an rdbms, relational database. Sigma is an application where you can save and share reports with your team without the need to setup a dedicated ETL pipeline and engineering teams. We curate the quality of the data for you so you don't have to yourself. Hope that helps!


> We curate the quality of the data for you so you don't have to yourself.

If this is done well, that's a huge value. Data cleaning often takes more work than actually figuring out what queries you want to run against your data or running them.


> We curate the quality of the data for you so you don't have to yourself

Can you be more specific?


This is a SQL interface on top of the transactional data Stripe maintains for their users (based on the orders they process).


It seems that the difference is that you won't need to set up a DB server, maintain it, and keep feeding transaction data from Stripe into it.

While this may not be terribly complex, it opens up the chance to run SQL on your business data without building or maintaining the pipeline itself for SMBs which may have limited resources.


Odd slab pricing model that jumps; are there other SaaS products that do that?


Somewhat unrelated but anyone know what Stripe used to create that video run through - it looks really slick and would love to discover some tools to make recording and annotating these kind of videos easy.


I am consistently impressed by the features Stripe puts out. They always seem well thought-out and implemented. Usually makes me wish I was still running an ecommerce site so I could actually use them!


This looks great if you're using subscriptions, and put all data you can into Stripe. For most customers though who a) probably don't use subscriptions, and b) probably just make simple charges and don't put all the data they can into Stripe, I can't see much value here.

Certainly for us, ChartIO backed by our own database is far more useful, particularly as we want to join on account data, preferences, registration details, NPS data, etc, which is all in our database.


As a current ChartMogul customer, 2 questions

1) Is it possible to easy display this data in graphs over time?

2) Can we record non-Stripe billing in it? (some customers will pay by check)


good to see. I just wrote a simple script literally yesterday to calculate MRR for my business using their API. It was smooth but I always wondered why Stripe doesn't improve its out of the box reporting/analytics capabilities.


I may be a bit dense, but does this include only the data stripe already has, or could it be enriched with, for example, cost data.

Because the payment process alone just doesn't include enough data to create relevant analysis for us.


@pc do I get a free t-shirt for suggesting the feature 1557 days ago?

https://news.ycombinator.com/item?id=5172637


I'm still waiting for the button that clears your test data but leaves your subscription test plans intact. Guess this feature wouldn't be able to help with that.


Alation is a more general solution to the data dictionary + shared workbook problem. Does anyone know if Stripe allows you to export the financial data?


Anybody else has problems reading the examples on that page? When I click on an example the source code for the example is rendered very blurry :-/


Do you have a screenshot? The examples I see aren't even images, they're text that I can select and copy.


Well, it was text here too, but the problem seems to be solved now. Thanks for looking after the problem :-)


Looks like they are re-building cloud ERP systems, just starting at the payment transaction and working outward.

Compare to Netsuite and other similar platforms.


I guess this is useful if you have e.g. a bunch of stripe buttons on a static website and don't want to set up a database to do analytics.


The demo is top-notch, impressed.


Completely irrelant to Sigma itself, but the landing page crashes FF on a Galazy S6 :(


The site freezes my android device and chrome on desktop for 1 minute. :/


I forgotten the name but i think an similar service exist for analytic data.


So is this what the old rethinkdb team have been working on at stripe?


Your business data at our fingertips ;-)


Stripe's products is done right.


Is this based on SQLite?


Oh shiny, but does it blend? I mean, Stripe has a great API, great design and this, but is Stripe a good payment solution? No, it is not, especially for sellers. Fraud and charge backs are worse than with PayPal. Despite its many shortcomings, PayPal has at least a much better fraud protection system. This is what matters or should matter when choosing a payment solution. Shiny stuff is great, but if the engine is made with rubber-bands, you won't get very far.


Hi -- I work on the fraud team at Stripe. Last October we introduced Stripe Radar ( https://stripe.com/radar ) a suite of integrated tools to help you beat fraud. While different businesses see different patterns of fraud, we believe that overall our fraud prevention is now as good or better than essentially every other product in the industry. This partly follows from Stripe’s scale: whenever a card is used, there’s now an 80+% chance that we’ve seen it before. We use this data from the global Stripe network to detect and prevent fraud with ML models that we’re constantly updating and refining.

We’d love to hear what would make us work better for you. My email is brahn at stripe.com.


Ah machine learning.. I've studying that the last few months. Cant say i got much more wiser on it, as 99% of the examples and explanation out there is regarding classifying images. And not so much about handling structured data. Is there are public information on how ML is implemented at stripe?

And you write that > 80% of the worlds issued cards are in the stripe db because they are once used via stripe? Are you sure about this number?

Can't say im much impressed by this sql interface 'feature'; It's more opening low level access then a feature, but that is just my humble opinion. And it is of course nice for techies having to work with, instead of specific 3rd party APIs.

Will there also be plain (not plaintext but simple) replication interfaces/APIs in the future that clients can run sql slave nodes (mysql/postgresql) with near realtime replication for local querying (privacy) and backup purposes? (and being able to continue to use the data even if stripe would be unaccessible/down)?


Stripe has higher chargeback rate compare to other gateway but they provide really good API.

You can use 3rd party fraud screening service such as FraudLabs Pro to compensate the Stripe weakness. It cut down our chargeback rate to less than 0.5% and we are happy.


Fwiw, you can roll your own fraud warning system independent of payment solution:

https://www.maxmind.com/en/minfraud-services


Stripe provides fraud protection? I thought they were just a (really awesome, developer-friendly) payment processor and you'd need to put something like Kount in front of them to do your own fraud protection.


Radar, smack there in the left-menu, is Stripe's Fraud "prevention" system. You can register and mark fraudulent purchases to improve the machine learning system behind Radar (sure). You can setup rules such as "Block if CVC verification fails" (really and can be disabled). At least, Stripe is trying to address the problem. Unfortunately, not with great success at the moment, but I'm sure/hope it will improve. We use both PayPal and Stripe and the difference is like a green meadow compared to a green toxic waste dump with regards to charge backs and fraud.


The fraud protection is a fairly recent offering.

https://stripe.com/radar

I've personally had good results with it, but admittedly at lowish volume.


References?


Stripe owns Hackernews. They consistently get their new product offerings to the front page with huge points. Yes they're loved by the Hackernews community (and rightly so) but I wonder if their ability to get their stuff to the front is less to do with it's relevance and more to do with their army of hackernews accounts with tons of karma. Just a thought.


50 comments / at 100 points probably indicates that there's plenty of interest in this product.

Always assume good faith... It makes everyone happier, including you.


It is a YC company. I don't think they're cheating, I just think stripe is especially interesting to the IN community.


You don't need an army of bots if you have a direct line to the people that run the site!


same with google. i think it is moreso just that a lot of people in the community respect the companies and want to work there. not as much employees themselves.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: