For anyone wondering about pricing, here's our approach.
- For new Stripe customers, this is free up to the first (lifetime) $1M of payments.
- For existing customers, there's no pricing change. You just get more functionality than before for free. This is what we generally try to do: we want Stripe to continually become better value for you over time, as you get more functionality for the same price.
- What we've seen over Stripe's history is that customers handling large amounts of revenue have been forced to pay substantial amounts for expensive third-party systems. So, we've decided to build something that we think will be better and cheaper -- and that will, over time, increase the net revenue of businesses built on Stripe.
I'm sorry about any confusion in our communication around this!
Its not just a communication problem, it's a pattern. You guys did the same thing last year when you stopped returning fees on refunds.
I couldn't believe my eyes when I read that you weren't returning fees anymore. I get not returning the flat 0.30 transaction fee, but not returning the % fees smacks of being more worried about the corporate bottom line than customers. Many processors refund the % fees, and there's no way you couldn't negotiate special dispensation with "the various payment partners we work with" to at least be able to return the % fee.
I used to unabashedly recommend Stripe as the best payment processor -- a little expensive on the rate, but easy to set up and no monthly or hidden fees to worry about.
That changed as soon as I had my first new customer screaming about getting whacked with fees on a refund. Didn't affect my account, and your messaging was horrible on that change as well, so I blissfully recommended unaware of the change until a new customer to whom I'd sung the praises of Stripe got hit and had to yank all of the Stripe code and go to a direct processor.
Just because you grandfather existing customers doesn't mean you get off scot-free on unfavorable policies.
My recommendation immediately changed to only use Stripe if access to special niche features like Stripe Connect or non card payments were required, and otherwise use a direct card processor with defined fees (and much lower rates, like 0.5% lower at least).
Clearly your focus has changed from doing right by the little guy to "customers handling large amounts of revenue" and policies tilted toward the bottom line vs "rightness". That's fine, and a natural part of many corporations during growth... Just telling you how it's affected my perceptions of Stripe and my recommendations to customers.
Stripe has become masters at patronizing customers. We all know it is about the bottom line and the act is getting old at this point. The company was built on developer referrals and now that they are at critical mass - all of the "little guys" get drown out.
Depends on volume and risk profile. There are many very sharp Authorize.Net resellers out there that will work with you to get a great rate for your situation. I've seen 2.2% rates on 50k/mo of processing for low risk customers. Of course, with that you get some additional fees to factor in -- monthly statement fee, international, Amex, etc... but it pencils out to way lower than 3% at a decent volume.
And many of these processors will give you gross deposit which is the only way to make things easy for an accountant. The net fees model Stripe uses is a nightmare for reconciliation at any sort of scale.
This isn't to say I've abandoned Stripe entirely -- there are some cases where it makes sense, when you're actually using some of the advanced features and API, not just a straightforward card charge.
I just completed a Stripe Connect integration that handles millions a month for several clients... but even there you run into half baked/stapled on feelings when you try to produce a full featured process that works at scale. For example, there's no straightforward way to provide a batch report for a Stripe Connect client -- the charge ID's don't match up with the platform account, and the only way to fully map which charges/refunds/chargebacks are in a given deposit for the client account is to link them up by amount and date/time....
Research around. Many of the same processors will work with you even at low volume, although the rate wouldn't be as good. Of course, with little or no volume, the rate doesn't matter as much.
Any information on support for Europe? And if support for Europe were to be in the pipeline, would it be for the whole of Europe or only specific countries? We'd love to use Stripe for billing as well, but because Stripe is an American company, we feel like as Europeans we're constantly an afterthought and would therefore prefer a European provider. What's your opinion on this?
Btw, I was at the Stripe offices 2 years ago and it was an amazing experience. I really like what Stripe has done over the years. Keep it going and thanks!
> we feel like as Europeans we're constantly an afterthought
Agreed.
Ahem, Stripe team. May I have your attention?
Could you please, please, please do something about helping your customers with calculating, charging, and tracking VAT to EU countries? It is currently a glaring omission from your services.
Or, adding support for SEPA/EU Bank payments to Stripe Checkout?
I know it's in the main Stripe API, but if I'm going to have to roll my own integration, I'm just going to go use PayPal.
PayPal has much cleaner API for non-card payments.
With Stripe I need two different codepaths for bank payments and cards....
while you are talking about SEPA, i know that there is a support for SEPA Direct Debit, but are you thinking about implementing Swiss Direct Debit, right now there are two sub implementation one from Postfinance and one from the Banks, there are talks about combining it in one system in 2 years or so but right now its kinda shitty + i would rather work with stipe api then with camt and pain files.
I am very happily using Paddle. They treat me very well, but what makes their product really sticky is the (global, not just EU) VAT handling. I basically do nothing, and it just happens for me.
EU support is coming! The market is quite different, as you obviously know, and we want to take the time to test Billing properly with European users. But enabling support for Europe is a high priority for us.
Hi, we're working on adding support for Poland, but don't have a fixed ETA at this point. Mind sending me a note so we can talk more once we're ready? I'm pglootz@stripe.com.
Against all my instincts, even though this post is unconstructive and snarky and flame bait, and even though I am European (or perhaps because of it), I have to upvote this. European people, those voting for representatives voting for representatives (!) making the laws, need to start feeling the negative feedback of the regulations. I’m not saying there are no benefits to consumer protection; there are, I am a massive GDPR fan, but we are too unaware of the opportunity price we pay for this.
Be aware, fellow Europeans: there is a cost to all regulation. If you feel like a constant afterthought, maybe it’s because you are.
(I know these are not necessarily specifically related to this Stripe product. It’s more of a cultural undertone. What I’m trying to say is: the parent comment has a point.)
As a fellow European living in the US I feel divided about this: while the opportunity cost is high and the business environment is definitely stifled by regulation, the quality of life and health consequences of the lack of regulation in the USA are massive and there's very little recourse for the little people against the criminal misbehavior of corporations.
There must be a happy medium between the two positions, I don't know that a country has gotten it right yet but the US is no paradise.
There is no lack of regulation in the USA, it's just the USA has some wrong regulations that creates horrible results you see sometimes. Most of it is from a lack of single payer healthcare and a public culture of infrastructure neglect with high amounts of waste compared to pretty much everywhere else in the world.
I really think it comes down to legislation philosophy. In the english speaking countries, cost of compliance is something that is thought about for small businesses, so many regulations are small business exempt until you get to certain employee counts or revenue numbers.
In the EU, that concept doesn't seem to exist and businesses of 1 are assumed to be $100M revenue businesses that can afford to do things like GDPR properly.
If you are a 1 man show, how about not collecting data you most likely don't need anyway? And the 4% global revenue fine the GDPR is famous for does exactly what you want -- scales with the means of the business.
Last I saw there was a minimum fine of x million Euros.
Edit: had to verify. It seems a bit more reasonable: """Article 83 of the General Data Protection Regulation provides details of the administrative fines. There are two tiers of fines. The first is up to €10 million or 2% of annual global turnover of the previous year, whichever is higher. The second is up to €20 million or 4% of annual turnover of the previous year, whichever is higher.""" - https://www.gdpr.associates/what-is-gdpr/understanding-gdpr-...
Yes, because a minimum fine of $10 million for a 1 person business is totally reasonable, unless by the grace of the bureaucracy, they decide to give you a warning instead. /s
Also the GP post, there is more than 'avoiding collecting data'. If you have text field comments form and a 3rd party puts 'personal data' in that, then that is GDPR liable! You also need audit logs and and list of other requirements that needs multi engineer teams to implement properly.
As a result, most small businesses with email are probably not going to be properly compliant on some level and you can prosecute anyone. Just like the new-ish VAT laws, large stores are going to be compliant because they can afford it, while some petty bureaucrat will prosecute the small online shops instead.
I don’t see your logic. Of course new features of a US company are going to be focussed on their home market first.
And claiming that regulation in EU is stifling business is a bit naive. Regulation is everywhere. Have you ever tried to sell an app that uses encryption (like TLS or SSH) on the app store? The stuff you need to do in the US for „export compliance“ is ridiculous (even if it‘s an app that wasn‘t written in the US in the first place)
I doubt that EU regulations are more onerous than their US counterparts. And, obviously, the EU is mostly just replacing country-specific regulations, making it about 16x easier to enter the European market.
I'd also like people to name specific regulations they disagree with, yet any time I challenge s/o they slink away.
In this case, a stripe rep in this thread posted a list of their todos for the EU. Note that literally "putting VAT ID numbers on invoices" makes their top 5! Can't be that bad after all:
"localize the invoices, add EU specific payment methods to invoices, improve tax support, make default invoice templates EU compliant with VAT ID"
US requirements around what we put on invoices: 0
EU requirements around what we put on invoices: Still figuring it out
The technical implementation is not difficult. It's dealing with all the lawyers and accountants who have to understand regulations of 27 different countries.
There is a significant difference between "not regulated" and "regulated at all". The burden of understanding the regulation itself is a cost, even if the actual compliance turns out to be simple.
His opinion "I wonder why the EU is an afterthought when you need to spend millions on compliance for every new feature" is not backed up by any facts.
If he had said that meeting the legal requirements in 28 different independent and sovereign countries adds too much cost then he would be correct.
Remember the EU Single Market and Custom Union does not cover every aspect of commerce and industry across all 28 member states.
Having said that, the Payment Services Directive 2 (PSD2) which applies to Stripe, will remove any remaining barriers and costs that still exist between member states when applied to the provision of electronic payments. If one was to add in the eIDAS directive then meeting compliance for identity, fraud, etc will soon be irrelevant.
The EU has been moving towards more standardization for quite a while now. The most prominent example is the euro coin. And although the GDPR may seem to many like another regulation to comply to, it's actually a unifying regulation because now you don't have to deal with separate privacy laws for each member state.
From a tax point of view, EU is a lot easier to deal with than the US if you have to collect sales tax in the US.
There are two big differences.
Let's say I'm selling some digital good online. Consider three purchasers, one in the US in the state of Washington, one in Germany, and one in France.
First, how much tax do I have to collect from each?
For the German customer, that is easy. It is 19% VAT. I don't have to care where in Germany they live.
For the French customer, that is easy. It is 20$ VAT. I don't have to care where in France they live.
For the US customer in Washington...it is not easy. There is a state wide 6.5% sales tax, but there are also county, city, and other sales taxes that I have to collect. For example, if the customer is in the city of Seattle, I'm supposed to collect the 6.5% state tax, plus a 2.7% city tax, plus a 0.4% for something called the "Regional Transit Authority"...that's 9.6%. If that person is over in Bellevue instead of in Seattle, it would have been 10% (6.5% state, 3.5% Bellevue).
For the US customer, I have to care where in their state they live. Also, tax boundaries are not guaranteed to line up with postal code boundaries, so to do that tax accurately I really would need to collect their full postal address (which since I'm selling a digital good I have no use for except for calculating taxes).
Second, what do I do with the tax I collect?
For the EU, I sign up for the VAT MOSS system in a single EU country. Then each quarter I have to file a simple form with the tax authorities in that single EU country that simply lists each EU country, what my total taxable sales were in that country, the VAT rate I used, and the amount of VAT collected. I turn the collected VAT over to that single country's tax authorities. Then they deal with distributing it to all the other countries.
For the US...I have to deal with each state I collect tax for separately. Each has its own forms. Each has its own place to file them. Each has its own place to pay.
If you have to deal with more than just your own state and maybe a handful of others in the US, you pretty much have to use a third party service that specialized in handling all of this. For companies in lines of business that are only barely profitable, this could be prohibitively expensive.
If Congress ever decides to require online companies to collect tax for all states, instead of just those that they have a presence in, and they do not require that the states use something like the VAT MOSS system, and they do not require that each state has a single rate for out-of-state non-present sellers, it's going to be nightmare for small companies, and possibly drive many out of business.
The situation wouldn’t be nearly as bad if the federal government offered some sort of API or search service to which all states would have to report, but this is currently only being addressed by the private sector. And at kind of a prohibitive price for very small businesses, in some cases.
Fortunately, there’s almost no enforcement at all with respect to small- to medium-sized businesses collecting and reporting interstate sales tax. Do the best you can with it.
The core Stripe Billing features actually work in the EU: flexible billing, our recovery tools, and invoicing. You can use subscriptions with all of the payment methods on Stripe, including SEPA DD, ideal, and more. But as Patrick mentioned, there's a lot we can do to make the experience great for European companies and that's what we're focusing on right now. We're thinking about ways to localize the invoices, add EU specific payment methods to invoices, improve tax support, make default invoice templates EU compliant with VAT ID, and more. If you'd like to try early betas, let me know!
We're about to re-evaluate our billing system for StyleCI and as we're based in the EU, we'd love to give this a go. My email is james [at] alt-three.com
We are in France and we already use Stripe subscriptions. We'd like to try early betas of Stripe Billing for EU. My email is nicolas at vocationcity dot com.
FWIW, since Stripe has been completely ignoring Central Europe (I'm in Poland), I've been using Braintree (https://www.braintreepayments.com), which does want my money.
It's not as hip and fashionable as Stripe, but does work fairly well. They do subscriptions, but I had to take care of invoicing myself.
> For existing customers, there's no pricing change. You just get more functionality than before for free. This is what we generally try to do: we want Stripe to continually become better value for you over time, as you get more functionality for the same price.
The email that existing customers received was ambiguous on this point. It said this: "Since you used Stripe Subscriptions in the past year, the Stripe Billing Starter plan is included in your current pricing."
Many existing customers that rely on basic subscriptions probably think their rates are about to go up. Maybe you guys need a follow-up email to explain that they're not?
Very sorry about the lack of clarity in the email! You will get all of the functionality that you have now, plus anything additional that we add to Stripe Starter, at the price you currently pay to Stripe. No additional fees here, even beyond $1M lifetime cap.
We signed up for Stripe account on February 9, but are yet to start processing paymens, will our account be grandfathered in as well? I sent you email yesterday asking about it too. We did not receive Stripe email about changes. Could you please clarify it? Thank you!
Would love to hear what "more featureful" means for you and your business! What are the big features they have but we don't? (I honestly don't pay attention to them so not sure what features they offer...genuinely curious how we could be serving businesses like yours better.)
Josh to be honest we used you guys for almost a year and repeatedly gave large amounts of feedback, none of it which was really acted upon. To the point it felt that Baremetrics had essentially stalled. In fact, the only change I remember from the time we used Baremetrics is that the colors of the dashboard changed to be more pastel.
Baremetrics is a great "early release" product, but we don't see development on it, nor even a hint at a roadmap. Profitwell has a lot more features (Paypal support, customer tracing, a powerful UI, etc) and we constantly see new features being added.
I could tell you the same stuff I said when we unsubscribed: Paypal support, a better API, "cancel at period end" support (which Profitwell does have), etc... Wish you well with it, and I hope for your success as I really like how transparently you run Baremetrics, but the product just doesn't cut it for us. And I think you should definitely pay attention to what Profitwell is doing (or any competitors really).
Fair enough! 2017 was a tough year for us (especially May to December). You're correct that we launched very few improvements in that time. On the backend we were doing a complete rewrite, which ultimately set the stage for us to roll out really powerful new features like Segmentation (https://baremetrics.com/features/segmentation) which launched a couple of months ago.
Since January we've been on a roll, releasing a slew of new features and updates and have a ton more on the way.
Certainly wish we'd handled that big rewrite differently since it did leave a bad taste for some folks, but it is what it is. ¯\_(ツ)_/¯
The features that are crucial to one business are inconsequential to others, so I appreciate your perspective on what you guys really need.
Would love for you to give us a try again down the road and thanks again for taking the time to give feedback!
I know you wrote this to Josh, but just jumping in here to address the ProfitWell side. :)
1. You're 100% right. We don't have a live demo. We're working on a solution for you here, but it's been delayed for some other cool features. Happy to share when we launch something for you. I know a call can be annoying, but it wouldn't be a sales person. Most metrics demos are from our product/engineering team. :)
2. As for pricing - we don't typically hear it's confusing, but it's 100% free forever. We make money through our add-ons. There's definitely something here to get better at though, so I'll take this back to the team to make it rock.
The short answer to your question is, “Yes.” The long answer is:
> INFORMATION SHARING
1. With Third Parties:
We may share your information with third-party business partners...
...
2. With Service Providers:
We may share your information with third parties who provide services on our behalf...to which these services may include:
Payment processing
Providing customer service
Sending marketing communications
Conducting research and analysis
Providing cloud computing infrastructure
...which also means, “Yes.” In particular, “research and analysis” is not clarified (nor would a clarification outside the formal ToS be legally binding). As long as there is a defensible interpretation of these clauses, they can freely sell all of your information. This also might be of interest to you:
> We will respond to your request within a reasonable timeframe. In certain circumstances we may be required by law to retain your personal information, or may need to retain your personal information in order to continue providing a service.
There is a legitimate reading of this clause which allows ProfitWell to retain your data indefinitely because they’re providing a service to someone.
Let's back up a second. The silence isn't because I/we don't want to talk about this, it's because it was 2am here in Boston and I was sleeping at that point (coincidentally after leaving the office around 1130pm pouring over our new GDPR paperwork).
The short answer is 100%, absolutely no - we do not, have not, and will not ever sell your data. We say this pretty clearly at the top in our terms and services, which you didn't link to (found here: https://www.profitwell.com/terms-security). For context, there's a difference between a privacy policy and a terms of service. I'm not a lawyer, but from my understanding the reason here we structured things this way (as a lot of BI/analytics providers do) is because one handles the actual handling of data, especially pursuant to EU/International/US law, and the other handles the actual service of that data. For instance, we will share your email address with our email service or with our payment processor. The terms are inclusive of the privacy policy.
From a terms perspective, we don't access someone's account unless given permission for QA, analysis, and the like. We do aggregate data for research purposes, but there needs to be a minimum of 30 companies in that data set and if you'd like to opt out of that we're more than happy to sign/put together custom Ts&Cs, which we do with almost every company that requests one.
Additionally, with GDPR the nature of our privacy policy is going one step further beyond EU/Swiss Privacy Shield compliance to offering up DPAs and a whole host of new functionality to make sure we go beyond the requirements.
Apologies if I'm coming off any bit passive aggressive/defensive. Just trying to explain and sometimes the legalease can be tough to sift through. I started my career working in network security/intelligence, so I personally take this really seriously and we put a lot of work into all of this fun stuff (pen tests, training, our policies, etc.), so I take it too personally when hearing someone misinterpret how we work. We can always make this clearer, as we tried to do with the pre-amble to our terms, but happy to do what some other companies have done and really refine the plain speak of our terms and privacy policy (especially since they're shifting a bit with GDPR). Assume you meant the best here with your comments though, so hope this clears this up at least a bit.
From a monetization perspective, we do offer a service to _someone_ - our customers. We sell Price Intelligently, ProfitWell Retain, ProfitWell Recognized, and ProfitWell Premium. All of these products are feature and performance based - and more than paying the bills for us to continue to invest in building the company without a drop of funding (which is intentional to keep us independent).
The reason we set up our monetization this way is that frankly we don't think there's a whole lot of value in taking your data and putting it into a bunch of graphs. I know that's trivializing BI/analytics, but that's the crux of the industry right now. Plus, doing willingness to pay and pricing analysis supports this - hence why most BI companies have to go upmarket to survive/grow. Instead, metrics are the gateway.
The world we're building is one where ProfitWell can show you the one graph (or few) that you need to look at - not the 60 you need to sift through to truly understand if there's a problem or not. Then we're going to help you see exactly the metric you should worry about (and the ones you shouldn't worry about) before offering up resources to help you fix it or a product that takes care of that metric for you with 0 work on your part through what we call an anti-active usage product (like ProfitWell Retain). This just feels like the right move to best serve our customers and the greater community.
You should resolve the discrepancy between this comment and your Privacy Policy. A message board comment is not legally binding, and what I linked to has substantial wiggle room in interpretation.
Yup - a HN comment is definitely not legally binding. Given some of the flame wars on some of the threads over the years, that would definitely be a scary world.
Based on a number of lawyers (we've gone deep on this over the past several years), I'm confident this is resolved through the combination of our terms and privacy policy - the EU/Swiss privacy shield stipulations, which drove the privacy policy encompasses the specific data there that's shared (check out the section entitled "Collection", which is then what's referenced in the shared section). These are common information to engage in internet commerce like email, billing info, etc. This is actually specifically why we had language in our Terms to encompass the actual financial data. The ironic part of all this is we repeatedly told our legal folks we needed to simplify, simplify, simplify.
All that being said - you clearly came to the page and thought the worst based on the language, so I guess it doesn't really matter if we're legally doing the right thing, we need to make sure you (and other folks who reach us) are interpreting and seeing what we're doing as intended.
Give me/us a little bit of time to figure out how to make this instantly obvious. As I mentioned, we're in the midst of clearing up our house based on GDPR requirements, so it's a good time to revisit. Really appreciate the feedback - only way we get better. :)
For greater context, the reason why I’m saying your Privacy Policy needs to be revised for precision is because:
1. I have experience acquiring data for the financial industry, and your privacy policy looks like the kind used to discreetly allow data brokering for free apps that have a lot of user data, and
2. I’ve seen executives who do sell data deny that they sell data by being overly literal and obtuse about what users mean when they ask if their data is sold. When users ask if their data is sold they’re usually including “data sharing with affiliates”, even if they aren’t savvy enough to use that terminology. The concern there is that user data collected by third parties is allowed to be reshared by their affiliates and under opaque terms that do not preclude monetization.
In EU, you need to write something like "...share data with third-party service providers..." already if you use AWS, because customer data will not only be held at your premises, but also held by another company (Amazon).
It seems to be difficult to phrase the Privacy Policy in a way that will satisfy this condition, and at the same time remove the 'wiggle room' you see.
That has the big disadvantage that if you switch from AWS to Google Cloud, you need to notify all of your customers about the changed policy and ask them for consent again. I have not seen any Privacy Policy yet which lists the service providers.
You don't need to ask for consent, because it's typical that a clause will simply state, "Continued use of this service indicates acceptance of these terms", etc. That seems like a non-problem as far as these things go.
The reason you don't see privacy policies which list that information is not because it has an exorbitant inconvenience cost, it's because they benefit directly from that information asymmetry.
You actually do, because now you want to send data to Google Inc., for which you don't have the consent of your customers yet. They only agreed to sending it to Amazon. You can't make them agree to any future changes of your Privacy Policy.
edit: yes, you can send out a notification on every change and tell your customers that it is an implicit consent if they don't object. But I still wouldn't want to do that for every change of service provider, and there can be quite a few such providers in an SaaS.
If I understand correctly, finishing the last citation with:
"[in order to continue proving a service] to you."
would at least resolve the problem of retaining user data indefinitely, but I also totally agree with the free interpretation of "Conducting research and analysis".
Also, because Profitwell is available to customers in Europe, it will soon have to align with GDPR requirements (which also includes the right to being forgotten), even if it's not a European company or otherwise face fine risks.
Re: privacy/terms - hope the other comment I just made clears some things up. Happy to answer any questions if not, of course.
Re: GDRP - you're absolutely right. We'll be required to align with GDPR in just over a month. We're all set from an engineering perspective and rolling through all the fun documentation, agreements, compliance records, and trainings from a legal perspective now.
Hey Joewee - wanted to answer this directly here in case the other longer, more in-depth comment gets a bit buried - short and long answer is no. We have never and will never sell user data. We monetize through a bunch of products that help optimize different pieces of your business - pricing through Price Intelligently, churn through ProfitWell Retain, revenue recognition through ProfitWell Recognized, etc.
I explained this in depth in response to one of the comments here, but the crux of this is that metrics are the gateway, which allow you to see the problems in your business. We then offer resources or products to help with those problems.
FWIW I love that Baremetrics has a live demo as well and it's what turned me towards them in the first place. But I don't understand what you mean by "simpler pricing". Profitwell is literally free, I don't get how that's not simpler pricing.
They do have an opt-in "Recover" product, just like Baremetrics, which is priced exactly the same way as Baremetrics.
We don't want to be perceived as cheap, but super expensive isn't our plan either. We're free for companies below $10K MRR, then charge on subscriber volumes. We can offer custom pricing to high-volume/low-margin businesses, feel free to reach out if you'd like to discuss nick [at] chartmogul.com
Hey Dictum - we're free for non-basic usage, basic usage, and everything in-between. I explained a lot of why this is the case in the blog post link below (when we went all in for free), but it really comes down to the following:
PHILOSOPHICAL
1. In software (and the subscription economy) we're moving away from function based pricing to outcome based pricing. Putting this simply in the context of analytics/reporting means that if I just take your data and put it into a bunch of graphs, it's helpful, but not valuable, even if they are the right graphs (and most of the time they aren't the right graphs, at least in most BI/analytics products).
2. Based on this, we believe in outcome based pricing. We make money by selling products like Retain, Price Intelligently, etc. that all have a specific number we can point to (in your free ProfitWell account :)) that we helped move in the right direction. For some of these products we then only perfectly charge based on our performance. Others where we can't measure this precisely, we still price on a value metric axis.
ANALYTICAL
1. Metrics/analytics are a terrible business from a willingness to pay and unit economics perspective. People don't really appreciate how much work goes into 100% accuracy (that's our thing compared to our competitors fwiw). It took years to be perfect and even now we're still finding edge cases of edge cases. Multiply this by the number of billing systems and it takes a lot of work to support this free product.
Here's the thing though - back to that lack of appreciation - when measuring the willingness to pay for analytics/metrics, people just aren't willing to pay that much. We measured this well ahead of going all in on free and found that our unit economics, especially in a market that's weak in number of logos (subscription market is much smaller than people think). As a result, most BI/analytics companies go up market. We're upmarket and do have an enterprise plan for all the fun enterprise fixings people need, but we don't want to waste massive amounts of CAC fighting for $50/month or even $150/month. Creating a phenomenal user experience (we're not there yet) is so much valuable. Plus, we're able to show our customers they have a problem that we can then sell an add-on for.
Long story short, this business and space requires a scalpel, not a sledgehammer for growth. Hope that's helpful. Always up for answering questions.
We don't plan on stopping. Admittedly this gets us in some trouble being a growing company, because we need to make sure our free product is the best for our customers AND we offer up stellar paid products. A whole lot of surface area, especially for a bootstrapped company (although we're past the Ramen stage - $10M+ ARR and 45 folks :)).
There's a lot of work we did to make sure we're learning as quickly as possible that really helps advance the mission on all fronts.
This comment needs to be stuck to the top of this thread—the thread has already got out of hand wrt/ the confusion on how this affects current customers.
Thanks for clearing up the communication on this! I've been a happy Stripe user for years, now!
we use stripe subscriptions now quite a lot, and I'm a bit worried about the whole invoice pricing - could you please clarify that a bit?
the web site says invoices are free for up to first 2K, then $1 per invoice. our recurring charges to customers now are around $2.99 per month, I hope you're not planning to take $1 more away from that. does the invoice price apply for each recurring payment cycle, or am I reading something wrong here?
For existing customers, there's no pricing change. You just get more functionality than before for free.
Will anything change for those of us who might not need that new functionality? The wording in the email is that Stripe Billing "replaces" Stripe Subscriptions, but historically Stripe has been good at not breaking its API. We're concerned about another situation like GoCardless last year, where existing integrations would get broken.
The one thing we'd love to see improved is fixing failed charges. We've never been able to find much documentation on the previous settings for Dunning management, and support emails on the subject went unanswered. However, our stats for churn caused by mysterious Stripe payment failures are consistently quite a bit worse than the ones you mention in your publicity today, and relatively few of our customers resubscribe after their subscription is cancelled like that even if they were previously happy and active users so this does significantly hurt growth. This has been our #1 problem with Stripe for a long time. If this new system leads to better Dunning management and better documentation about how it works, that would be positive.
On your integration -- you won't have to change anything if you're currently using Stripe Subscriptions. You can continue as you are.
On high decline rates -- Of course, we're hoping Smart Retries and automatic card updater help you here without any additional work on your side. That said, drop us a line! There's actually quite a few things you can do on your end to minimize declines (pass us the right information at the time of charge, segment your decline reason codes in Sigma, experiment with trials, etc.) that can help reduce passive churn. (Docs on declines here: https://stripe.com/docs/declines)
Thanks for the reassurance on the current subscriptions integration. A first look at the API suggested that updating to the latest Stripe API was now going to involve some breaking changes, e.g., introducing products and requiring one to set up a plan.
On the decline rates, we actually have dropped you (Stripe) a line -- many times, in fact, and via multiple channels. In some cases, we never received a reply at all. In the others, the reply was essentially that you didn't know why the failure rates were so high and there was nothing actionable you could suggest to improve them.
I appreciate the link to the declines page, but I think that information has been available for quite a while now. What we have really needed is the detail about exactly what would happen if we configured the existing Dunning management to retry things, for example which objects get created in your system and/or get reused on retried payments, and which webhooks get sent at which points in the try/retry/give-up process and which objects they refer to. As far as I'm aware, none of this has ever been included in your usual documentation areas.
With today's announcement, it would now also be helpful to know the differences between the previous Dunning controls and the new Billing system, and how to migrate between them if necessary. The controls for the new smart retries feature seem to be in the same area on the dashboard, but as with the older controls, if there's any documentation anywhere about what any of these settings actually do under the hood, or how to simulate the relevant scenarios for integration and testing purposes, I can't find it.
It would also help to fix some limitations of the current tools, and again maybe the new Billing system helps with this but we haven't spotted it yet. For example, one problem we've run into a few times now is that address verifications are all-or-nothing. Either we don't use them (presumably worse for fraud detection) or we do (but then if a customer moves house and doesn't tell us, their next charge on a subscription will fail). In terms of risk, it would seem to make sense to check the details that don't appear on the card itself for the first payment(s), but after a while to trust that the card really does belong to the customer claiming it and downgrade/ignore those signals in later fraud checks, but this doesn't currently seem to be possible.
I appreciate that you're probably all very busy today with the roll-out of the new system, but I'm sure we're not the only ones who would be grateful if these kinds of documentation gaps and any actual limitations in the functionality could be addressed when time allows.
Thank you for the invitation, but as this happened several times over a period of years, there's not really any specific communication worth following up at this stage.
If you'd like to help, I'd suggest that the online documentation pages would be the most effective area you could look into. As Stripe has grown, gaps have appeared from time to time, where dashboard features or API calls weren't fully described. In this case, the entire feature set seem to be missing at the moment, so if there's anything you can do to fill in that gap and provide the kinds of specific details I mentioned in my previous comment, that could help others in a similar position to us as well.
In the rare cases where an existing customer is forced to migrate accounts (due to incorporation/moving elsewhere) is that considered an existing customer?
Can you share some details on when Stripe will be available for Israeli start-ups? There's quite a big ecosystem here dying to use Stripe but we just can't.
Also wondering how the new invoice and receipt emails are sent out?
> Under invoices there are two new documents "Invoice PDF" and "Receipt PDF" which are different from the standard e-mail receipts. Are these documents emailed to the customer automatically? Is there a way to control this?
(Pm on Stripe billing) There's a param in the API that indicates whether you want an invoice to be sent out or charged automatically -- you want `billing` to be `send_invoice`: https://stripe.com/docs/api#invoice_object-billing
For receipts, you can turn them on in your account settings: dashboard.stripe.com/account
Does "existing customers" mean someone (like me) who has a Stripe account set up, but who hasn't (yet) started accepting payments? Am I grandfathered in?
The email sent by Stripe says "Since you used Stripe Subscriptions in the past year, the Stripe Billing Starter plan is included in your current pricing."
So... based on that, it seems that "existing customers" means "customers that have actually used the product we're replacing".
I think we'd all appreciate a confirmation or clarification, though. :)
We'll make sure you're taken care of here. (If you're just running test subscription charges right now, you're still grandfathered. You can ping me any time if you have questions.)
I wish Stripe interface was more friendly. Looking at Freshbooks and Stripe, Freshbooks makes it look so simple and nice. Any plans to make your user interface more friendly to casual users who are not devs? Thanks.
This looks great, but I also see a lot of functionality being restricted to USA. That would be quite limiting for us as we are based in Europe and have the vast majority of our customers there. :(
Can you clarify what "Advanced reporting with Sigma" refers to in the Scale tier? Which fraud features are included in the base tier and which are a paid upgrade? Thanks in advance?
I assume Sigma refers to their SQL-based analytics product [1]. I think (and might be wrong) that most fraud-prevention features are included by default in all Stripe products, including Radar?
Sorry to hijack this thread but I wanted to ask if there's any news about supporting payments in Brazil. I've requested an invite 2 years ago and never heard a word.
we are a current enterprise subscription customer with more then 200k subscription transactions per year - we also have more then 40k a la carte transactions (non subscription w/no invoice) per year. If we move the a la carte transactions to the new invoice model will we be charged per invoice?
So as a customer of yours who still has to use PayPal because so many Europeans have "bank cards..." What do you recommend? Using both PayPal & Stripe? PayPal is a work around because, for example, a US Stripe account can't take EU "bank cards" (which account for about 1/3 of payments coming from the EU, as I see in Stripe's error logs) or non-US ACH.
Yes, like StavrosK said, for anyone who has significant customers outside of the US - there are lots of countries that use various types of "bank cards." Netherlands iDEAL is fairly well-known, but I get lots of customers with Visa & Mastercard "bank cards" in Italy, Germany, etc - all whose payments fail on Stripe (but they try anyway, not realizing theirs is not a typical "credit/debit" card).
I see a new 0.4% to 0.7% fee, that is enough to make me start shopping competitors on Monday. The stripe processing fee is already high. It seems that all I get is some hosted invoice stuff.. which I could build in a weekend and not have to pay a fee on?
Thinking about it, a medium sized SaaS company billing 15 million a year. 14,000,000 *.004 = 56k a year? For the same product they already had?
Obviously it is cool if you want metering and the advanced features, but I wonder if there is a way to opt out and use the old simple stripe without the new fee - or if this is to push those users into braintree / etc?
(PM for Stripe Billing here) It’s a good question, and one that we thought a lot about before launching the product. At Stripe, we are particularly interested in making startups (especially recurring billing startups, in the case of this product) successful on Stripe. It’s one of our most important goals.
For all businesses -- not just startups -- we waive Stripe Billing fees for your first $1M in recurring billing volume so that you’re not worried about fees when you’re in the early days of growing your business. We also hope there’s much more additional value from the full set of Stripe Billing features that are included in this price -- the increase in revenue you get from our recovery product, the savings in manual operations that you get from automatic invoice reconciliation, and the flexibility in building new business models that you get from improvements we made to the core billing engine (better upgrades, prorations, metered billing & more.) And, we’ll continue to invest in building more features and creating the best end-to-end billing system for fast-growing businesses.
If you’re an existing Stripe Subscriptions user, there’s no change to your pricing or your integration: you can continue as you were. We’ve sent an email to existing users on how this affects you -- please let me know if you still have questions! (tl;dr there’s no changes to your existing pricing.)
If you ever have a question on pricing or the product, I’m happy to talk about it any time. I’m tara@stripe.com.
We also hope there’s much more additional value from the full set of Stripe Billing features that are included in this price -- the increase in revenue you get from our recovery product
Just as a friendly warning, I think your (Stripe's) position on this is maybe not coming across the way you would like.
Mysterious failing payments is an area where Stripe has been historically awful compared to other payment processing services, at least in the experience of my professional network, with very obvious negative effects on KPIs. We're in "you had one job" territory here.
Now it looks like Stripe finally has a way to improve that situation. However, instead of trying to roll out those improvements as quickly and widely as possible, they're being bundled into a new service with as-yet unclear implications for integration and somewhat confusing messaging on pricing.
You might like to consider whether that comes across as having a great new feature or as being the sales guy who sells you $100 broken software but then offers you a gold support contract for only $500/year so you can report the bugs.
I just examined the changes to the Stripe dashboard, and, coupled with the email I received from Stripe and the web page about the new "Stripe Billing", I'm utterly confused about several things.
I suspect I'm going to have to unexpectedly spend some time updating my Stripe integration to the latest API, without much gain for my current business.
Stripe doesn't normally drop the ball but I feel like they did on this one.
BTW, Stripe team: the feature people here in the EU really want from you is help with calculating and tracking EU VAT. But you know that, right?
Also I don’t know if this is on purpose but you’re not answering the question people are actually asking: what if you’re an existing user and you hit $1M... then what?
(PM from Stripe) If you're an existing user, there's no extra fees, even if you are past the $1M threshold. For existing Stripe Subscriptions users, Stripe Billing is included in your current price. (You should have received an email about this earlier today)
Hi, another Stripe customer here who hasn't received an email from Stripe about this, and has found all of this highly confusing! I'm in the UK, if it makes any difference.
I'm working in my spare time on a series of articles about the curious psychology of the software development world. This one is near the top of my list!
If your needs are basic, why is that surprising? Anyone who uses multiple payment processing services, for example in different countries or to support different payment methods, is probably already doing their own thing at that level anyway. Big, complicated APIs and invoicing systems and so on are not your friend in that sort of environment.
Looks like Stripe Payments (the minimum you need to process credit card payments) is still 2.9% + 30¢ per transaction, for existing Stripe recurring billing users. For any new projects I'll be using Braintree for recurring billing.
Edit: the fee increase is only after $1M in revenue so still makes sense to use Stripe in a project's early stages.
I think they're hoping that the reduced churn rate will make up for the added fees. A "whoops please update your card" email gives people the opportunity to decide whether a sub is valuable, while a quiet background payment tends to be less noticed.
Or you can continue to improve your actual product while Stripe takes care of the rote billing issues. That's essentially Stripe's whole pitch, you could do everything they do on your own, but it's expensive and not central to your business.
Shameless plug here! We also created something we called our Smart Router engine at https://processout.com, which helps you connect to dozens of payment providers and optimize your transactions.
I also am confused. I've made sure that Stripe will not send any emails directly to my customers (disabling emails for successful payments, refunds) since I integrated with Stripe's webhooks for my own custom emails. Is there now some other option that I have to turn off for CC update emails?
(PM on Stripe Billing here) All emails from Stripe to customers (like credit card update emails to your customer, etc.) are off by default. This behavior is the same as all of our other emails to your customers: if you prefer to listen to webhooks & send your own, that's great!
so all the invoices I now see automatically created for all my pre-existing subscriptions, with their own Stripe-generated Invoice ID are NOT being sent out, are they?
How can I make sure of that? They have nothing to do with the actual invoices we already generate, send our customers, pass to our accountants and so forth and should any of these "Stripe-generated invoices" be made visibile to our customers it would create a HUGE accounting issue.
It's all about the fraud control and the reduction in chargebacks. Yes, you can hack up a credit card payment gateway in a long night (been there, done that), but on the modern web you'll get killed by fraud. That's the hard part and if it is your own merchant account you're always going to be a few chargebacks away from losing that merchant account and by extension getting into really hot water with your business.
Yeah the development of existing functionality is a sunk cost that should be optimized and depreciate in cost over time with additional volume, not incur additional charges after you're already invested the integration effort to lock yourself in to their gateway. Here they've auto-enrolled us into a new pricing scheme we didn't want or asked for.
I think this is a big step in the right direction for Stripe (unclear pricing aside). We’ve been thinking about usage based billing for a long time now. We built a bunch of apps using Stripe and found there was a lot missing if you wanted to track activity and bill for it, as well as with reporting and revenue optimization. Having not dug into the platform too far, this definitely looks like it could fill some gaps.
I will say I’m not a fan of taking a percentage for billing on top of taking a percentage on payments, though. There is risk involved for payments (chargebacks, fraud, etc), but billing is transactional. A percent there feels like a money grab to me.
The only other problem I see with this is that it all seems a bit convoluted. I get that it has to be tacked on to their existing platform. But we’ve found that the secret to an awesome usage based billing system was to track activity in real time, then apply automated billing to that tracked activity. It’s a different approach and we’re working on polishing that up and bringing it to market over the next few months.
Would love to hear more about how folks are thinking about consumption and usage based billing and pricing. I think it’s the next big wave in Internet monetization, so it’s important to get right.
Appreciate the kind words! To the point on pricing: believe in revenue-based business models because it's the clearest way to align our incentives with those of our customers. We want to be forced to find ways to generate more revenue, via smart recovery, better invoice payment methods, more payment method support, etc. Our fees are actually significantly less expensive than those of our competitors, and we only make money when our users make money here (instead of charging a flat fee, which can penalize companies that are bootstrapping.)
Billing (recurring or one time) is a transactional activity and should be monetized as such. There should be a per invoice or per customer type of rate. This whole % of revenue seems crazy to me. There is no inherent risk involved like payment processing. You can get paid no matter what in a tx model...
Based on what I see in the market with other billing/subscription providers, they all do the same thing (rev share). Since these businesses are not the payment gateway they try to do a revenue grab with the % share.
I hoped Stripe would be able to disrupt this by already being positioned as a payment gateway and offer this on top in a transactional model....
Hope they rethink this strategy. And no first $1MM isnt going to cut it. Any serious business will see this as a growth challenge. Backend billing flows are challenging to build and once you are committed to this you are locked in for quite sometime from the roadmap perspective.
Thanks for the feedback. To your risk point -- there is often risk involved, as businesses that have worked with large ACH payments know.
More broadly, we believe in revenue-based business models because it's the clearest way to align our incentives with those of our customers. We want to be forced to find ways to generate more revenue, via smart recovery, better invoice payment methods, more payment method support, etc.
Maybe you can provide clarity on ACH risk. Seems like businesses have most of the risk there.. and not the billing system (keeping the gateway out of this).
Secondly, transaction/user based models are also aligned with customer incentives. With growth, customers will execute more transactions on the system.
Frankly, Smart recovery is an area where I can see you can ask for % share. Other features like payment methods etc sound transactional again.
Finally, Stripe has a payment gateway business already. This will ensure growth on that side of the business. Optically this seems like a revenue grab. You have the opportunity to disrupt the ecosystem.
Thanks for responding to my comment. Appreciate the interaction.
Lowering revenues doesn't really align with IPO'ing, though. The issue is the VC model that will keep us trapped in this, until there are less greedy given the resources to disrupt these systems. Capitalism works well, it shouldn't necessarily have a stake in foundational systems - which is why we need governance to manage.
Yikes, I've been using Stripe subscriptions happily for a few years and now I'm upset to see they're going to be charging a fee. It's unclear if the fee starts at $1MM total revenue or $1MM/year. $1MM/total would hurt a lot of the small lifestyle businesses for no gain in service--we already had subscriptions built in to the cost and we don't need invoicing or any of the other new-fangled stuff :(
Paypal has free recurring billing. Sure it's a pain to set up but once you've built it in it works pretty damn well with little to no maintenance. If you do even a smallish amount of business through them you can set up daily sweeps into your bank account to stave off the famous Paypal "random freezing of funds" nonsense.
Did they email the announcement to you? If you already used Stripe subscriptions in the past, you'll be grandfathered in for free. This is the relevant line:
"Since you used Stripe Subscriptions in the past year, the Stripe Billing Starter plan is included in your current pricing."
Yeah, but the Starter Plan starts charging an additional fee after $1MM (yearly? total?) revenue. So it's not grandfathering in at all, we just get shunted to the temporarily-free plan that everyone else has to start on.
Edit: Since my posting this Stripe has clarified that existing customers get the Starter package at no further cost, we we are grandfathered in.
(PM from Stripe) If you're an existing user of Stripe Subscriptions, you get Stripe Billing features included in your current price. (To be clear, there's no extra fees for existing users.)
(PM from Stripe) If you're an existing user, there's no extra fees, even if you are past the $1M threshold. For existing Stripe Subscriptions users, Stripe Billing is included in your current price. (You should have received an email about this earlier today)
The initial communication left some room for clarity, which really had me confused in the same way as others in this thread. Really outside of the norm for Stripe, who's communication is usually very clear.
(PM at stripe here) This is $1 per one time invoice (an emailed invoice you send to users via the Stripe dashboard) rather than recurring invoices. If you're sending thousands of subscriptions invoices, you will not get charged this fee.
Stripe has always been one of those products so well presented and with guidelines so simple. But this presentation today is a total failure. Makes the billing complicated and everyone doesn’t understand what the service does with detail. You’ll need to update the page to explain a lot.
When communicating important and potentially difficult to understand information: have some non-insiders read the text and ask them what they think it means.
Free for the first $1 million of recurring charges.
After that, 0.4% on recurring charges
Does this mean recurring charges don't carry Stripe's standard 2.9% + $0.30 charge? Or is the free at first/then 0.4% _on top of_ the 2.9% + $0.30 charge?
It seems to me that Stripe has gone from easy to cheer for underdog, to payment processor that wants to eat the world (ala Facebook).
I love that they are constantly innovating, but every time they do, I have to refactor my product, and then decide how much of my current product's custom functionality can be replaced by Stripe. Then I have to decide if I want to double down on Stripe (at the peril of other integrations), or create a wacky payflow that acknowledges dozens of additional gateways.
I don't want a single product that does everything. I want a great product that does a few things really well. This is starting to kill my love affair with Stripe.
>This is starting to kill my love affair with Stripe.
More and more I feel Stripe catering to the non-engineers who just want a simple workflow at the expense of customization.
I still dislike v3 for the fact it tries to push me to use their own interface.
I was happy hooking your library up to my form. I know I can "customize" it (change the css classes... wooo) but it completely replaced v2 with no way to get that functionality back.
I wish Stripe would have "full tricycle wheels, we charge a bunch" or "barebones, we get out of the way and charge you very little".
payment processors such as Stripe use this strategy to make even harder for you to switch for a different provider, if you ever feel like it. (payments industry expert here)
I just signed up a few weeks ago with the intent of using the subscriptions feature, but since I haven't actually processed any yet, I guess I don't get the feature as advertised when I signed up. Great.
> Does this mean recurring charges don't carry Stripe's standard 2.9% + $0.30 charge? Or is the free at first/then 0.4% _on top of_ the 2.9% + $0.30 charge?
Charges do carry the standard fee.
There are two different products, each with different pricing models.
Billing - tools to manage reoccuring subscriptions.
Payments - tools to accept/charge a credit card.
Payments pricing: 2.9%+ $0.30 per-charge.
Billing pricing: 0.4% after the first $1M in reoccurring subscription charges.
"Free for the first $1 million of recurring charges." would actually be a better deal for early startups than their standard pricing of "2.9% + $0.30 charge".
Also, since they've migrated old subscriptions into this new "Billing" product, does that mean I'll start NOT paying fees on existing recurring subscriptions?
Yeah, but now Stripe is adding in features like email invoices, presumably the ability to for customers to update payment info, etc. I don't know how much exactly has been added incrementally and how much is available in this release, but I'm optimistic that soon I will be able to phase Recurly out of our stack...If someone from Stripe wants to build a Recurly -> Stripe migration toolset, I'd love that!
Last time I looked, which was several years ago, recurly was shockingly expensive. Over the top outrageous that it was an automatic no go for my business. PayPal, which I personally hate was a better option
Looks buggy to me. I created a test invoice and specified that it should be payable at a later date and only via ACH.
I checked the preview link and the only option to pay was by credit card. I sent the invoice anyway and the test user's credit card was immediately charged.
(Engineering Manager at Stripe Billing) Ah - sorry about that, a last minute fix caused a bug. This is now fixed in production. Thank you so much for reporting!
Two nits... 1) on Safari 11.0.3 on MacOS 10.13.3, clicking on the Documentation link in the upper right leads to an HTML file download, not a valid link; 2) couldn't find where you can customize the invoice design within the UI or the docs?
Hope to move away from Wave Accounting to Stripe invoice, once I can match the design... thanks!
How is this any different than the subscriptions they previously offered? And what do services like Recurly do that Stripe subscriptions don't? And when is Stripe going to automatically handle sales tax?
I still have not found a single subscription solution that seamlessly handles adding sales tax and properly reporting it. Stripe does not. Recurly does not. TaxJar does not work with subscriptions. Avalara does not work with subscriptions...
With my UK small business hat on: Sometimes, it is just easier and cheaper to build it yourself than to rely on an outsourced service that doesn't do exactly what you need.
We have a database table of VAT rates per country with starting dates when they come into effect. All customer accounts are tied to a specific country, so all payments or subscriptions for an account can look up the current rate from the database and apply tax as necessary.
All successful payments (one-off or recurring) are recorded in our DB, triggered by webhooks from the various payment services we use. The DB records include all the tax information that applied at the time of the payment, including things like country and proof-of-location as required under EU VAT rules, and also including generating a sequential ID for each payment to comply with the rules there. This is also the point at which we do any necessary currency conversion calculations, and we then generate and send customers an email automatically with all the same details.
A little scripting looks up the necessary sales and tax figures from the database for the various VAT returns we are required to file for UK and for other EU customers.
The significant limitations are mostly around keeping that VAT rates table up-to-date (I know of no acceptable automated method for doing this, so we just have to review the information manually at frequent intervals) and around handling money repaid (refunds, or if we do ever get a chargeback or similar). As far as I'm aware, none of the automated services is even close to getting these things right either, so we're still no worse off having to do a few things by hand in these relatively rare situations.
Setting that lot up was a decent chunk of work, particularly all the hassle around EU VAT, which we had to retrofit in at least one case I can recall. However, it's certainly achievable for an average developer within a few days.
That's what businesses like Avalara are trying to do, but the EU VAT rules are such a mess that even the specialist businesses trying to do it still haven't nailed it several years later.
Same problem here. We use Avalara and just manage the subscription piece ourselves, i.e submit the transaction once we receive the webhook from Stripe.
Previously they only offered tiered billing (e.g.: gold, silver, bronze plans), further, the API for that was structured so you're billing for the next month.
This announcement suggests "usage-based", which is how AWS and Google Cloud bill you: for how much you used during the previous billing period.
I think most difficult problem is still proper accounting. I'm with a client right now, based in Europe and we had >really good time< integrating Recurly with Stripe and use it as their payment provider, but we got stuck when we figured out that there was a need to hire an accountant to handle the cancelations for us.
Having a service like Cleverbridge [1] / Avangate [2], where they end-up having someone to manage this for them for a bigger % of the sale, was the better deal.
Not sure how the startup-scene will solve this, but it's actually still really hard to do this properly.
My best solution would be to have Stripe doing whole-sale solution, where they invoice customers and you simply invoice them each month.
It just takes too much efforts to do this >legally< in Europe if you are on your own.
(Stripe PM here) We're actually working on exactly this problem right now. :) More to come in the next couple months, if you're interested in beta testing let me know! (tara@stripe.com)
And that's before you get into VAT-MOSS and all that jazz. That's the real issue if your payment gateway doesn't do a perfect job of it, even better if you have to issue refunds.
>We're also introducing a new feature: smart retry logic. It’s powered by the same machine learning infrastructure behind Stripe Radar. Our algorithms train on data across the billions of payments in the Stripe network to predict the right way to retry failed payments.
As someone who is completely oblivious to how payments work behind the scenes (for the most part) could someone please explain how this became necessary?
I used to work on billing and a bit of payments stuff for a large SaaS company, so I have some experience with this.
When you charge a credit or debit card, send a bunch of messages that end up going to an organization called a payment processor. Payment processors do stuff like make sure your account has enough money/remaining credit and also have fraud checks and other security features. Sometimes, the payment processor rejects a payment because of insufficient funds, suspected fraud, their system being down or a malformed request. Unfortunately, a lot of this stuff is pretty archaic and there are a few layers between your servers and the processor, so it's very hard to debug. On your end, you could simply retry payments if they get rejected, but that might lead to a set of ping pong failures that might even trip fraud alerts to the customer. You can also have retry logic that uses an exponential backoff, just like any other request. That's a reasonable strategy, but you can probably do better.If you're a big company, involuntary credit card churn is actually a pretty sizeable source of churn for you. 99% transaction completion rate sounds pretty good until you realize it means a guaranteed 1% churn rate (assuming people don't sign up again), which is not insignificant. You really want to get this as low as possible.
Enter Stripe: Stripe has handled a very very large number of payments, and they probably have really comprehensive data about failure rates. This allows them to identify patterns and come up with some rules around retries. A simple (fully hypothetical) example is: If a transaction is declined for insufficient funds, retry again on the 15th and the last day of the month (usually when people get paid). These rules can get really complicated. We had some rules that were as complex as "If the cardholder is in Spain, and the card is Amex, retry in three days before 5pm if it's a weekday, otherwise wait until Tuesday."
Overall, this is a pretty nice feature for large customers with high transaction volumes. We did the data analysis/rule generation ourselves and hand rolled the retry logic in our system, but offering it as a built-in service is a convenient (albiet probably expensive) perk.
That's a good question. AFAIK Stripe already had their magical Dunning rules for retries, which were supposedly already optimized via machine learning. I'm curious if this is substantially different from that.
People are focusing a lot on invoicing but the real power here is that you can create multi-part and tiered billing schemes now. Imagine something like "$100 a month and $10 per user" -- that was not possible using Stripe subscriptions without your customer getting two invoices. Honestly, it was laughably bad.
Yeah, people seem to have missed the forest for the trees here.
Being able to iterate on billing easily seems the killer feature here, to me. I would like to see exactly how it works.
If anyone from Stripe is here, question: We currently use Chargebee for all our subscription and Stripe to actually process the payments. With Chargebee V3 [1] we've just dropped in their js and then we get an overlay/pop-up for both subscription and then subscription management, like editing subscription, invoicing etc. Is this a replacement for Chargebee on the integration and coding side that we get without work? [2] We'd like to reduce the number of services we integrate with and if Stripe Billing provides this, then we would like to directly use it.
As far as I can tell this is just dashboard and api only. But I guess they're moving towards that. Ironic as the connect partners that helped them grow are now having their toes be stepped on. Not a nice way to play. Burn the community who helped you get there in the first place.
You can't expect that Stripe doesn't expand their feature set. Seeing that there are hundreds of services built around stripe (https://stripe.com/works-with/types/stripe-extensions) it's really expected that some of them will be cannibalized eventually.
Subscription billing has been in Stripe for many years... it's just been very weak until now. Totally makes sense for them to work on this and if you built a subscription billing company on top of Stripe you should have known it was only a matter of time before theirs got better.
They’re also shooting themselves in the foot. They’re without a doubt less competitively positioned from a developer POV now. In my opinion. Even from a startup who isn’t technical. More percentages just get scary when you have people like Braintree keeping it simple...
Also Stripe still rely on their partners to drive business to them at the end of the day. No denying that it’s a big part of their funnel. A startup looking at their offering cold now will just be confused as well. What even is it? Some people think it’s a checkout when it’s not. It’s just s slightly more advanced subscription api with a price tag.
Also by cannibalising their partners will dry up their eco system. Chances are the partners do a better job as they’re focused on it. Can’t be perfect at everything.
I’ll see what they have to say on the call I have with them tomorrow.
To be clear there is no doubt it’s a sensible direction and a great product but charging for it is not IMO. Superior product will drive more business to them regardless. The market of payment gateways is competitive already.
But congrats and good job Stripe. Just reconsider the pricing.
Of course, I’m just saying to charge for it when they built their success on this is leaving a bitter taste... the community that made them are being pushed aside in favour of short term profit
It seems on par with many platforms in the past. Twitter, FB, Paypal etc. See what was built on top, see what is succeeding and they add that to the offering.
Just received an Email saying this "replaces Stripe Subscriptions", what does that mean exactly? e.g. what happens with our existing Customers and their active subscriptions?
IMO this is a poor communication and confusing announcement with lots of open/unanswered questions for existing Customers, which is unlike what I've come to expect from Stripe.
(PM for Stripe Billing here!) If you’re an existing user of Stripe Subscriptions, you can continue as you were! Your existing integration will still work as before and your customers won’t be impacted.
That said, you’ll also get access to all of the new tools as well -- would love for you to try them (and see if it improves your experience!) If you go to the Dashboard, we walk you through what changed in detail -- let me know if that helps, or feel free to send me an email at any point: tara@stripe.com
Apologies for any confusion! No extra fees for existing Stripe Subscriptions users, even after the $1M mark. Stripe Billing is free forever at your current price.
It's basically an automated recurring billing service that you can use whether you run a static monthly subscription service ($9/mo per user), or if you are using a metered approach, such as $0.02 cents per SMS, and then do that on a recurring basis.
So if you think about the 3 or so standard business models for SaaS, per user, per usage, or per tier (standard, pro, advanced) - this provides for all of that in an automated fashion.
Right, Subscriptions only has, IIRC, per-tier type of pricing. I need per-usage for my product, and was doing manual Stripe payments. But that meant if I wanted to change the pricing I would need to keep track of what customer was at what price point on my end. I'm interested to see if Billing is flexible enough to handle my use-case.
What companies does this hurt? Recurly? Zuora (which recently had an IPO)? Chargify?
The truly interesting feature to me is the credit card recapture part which updates automatically cards that are re-issued.
Zuora customers are likely at the "enterprise" level and wouldn't consider switching, at least in the short term. Chargebee, Chargify, and Recurly might have some issues ahead of them on the other hand...
This is extremely disappointing. For my business this means an additional 0.4%-0.7% fee added onto a service I currently use for free justified by features that I cannot use for compliance purposes. This new invoicing process does not qualify as an exempt financial service for a covered entity. (see subsection 1179 of HIPAA)
So unless they are now willing to sign a business associates agreement I just got a price hike for a feature that would cause fines so large they would close my business. This is going to be a PR nightmare for stripe. They have destroyed all of their goodwill, and now I will have to start considering competitors. If anyone from Stripe is here in the comments I would love to chat (email is in profile)
(PM from Stripe) If you're an existing user, there's no extra fees, even if you are past the $1M lifetime threshold. For existing Stripe Subscriptions users, Stripe Billing is included in your current price. (You should have received an email about this earlier today, but you can always ping me (tara@stripe.com))
Tara as a forewarning gmail marked your message as spam in my inbox. I would expect a lot of people to have the same experience. Second the messaging is not clear if you are indeed offering a grandfather clause for existing customers you need to state that clearly. Using the term "included" is ambiguous and I interpreted it in the same manner as a tip being included on a check. (meaning we've already added it, not that we didn't charge you)
Appreciate the heads up, we definitely should have improved the email wording here. In case the email went to spam, there's also two notifications on this in the Dashboard -- check in your notifications section.
I don't do $1MM in business but I'll definitely shop around once I get close. Prior to this announcement I wouldn't think twice about staying with Stripe forever. This is the first time I've ever thought, hmm, who else can I use?
So... "Subscriptions" is now 3.3% + 30c for new clients, for a bunch of features that used to be 2.9% + 30c, along with different billing models, "smart recovery," and automatic card updater (which I swear was already a feature they'd implemented.)
This feels like a very backdoor way to raise their rates for their subscription service because they felt like they were undercharging and they need more margin, and masking it with a couple of features that they're claiming can help make it worth it. (And sure, first $1M free, but still.)
I kind of wish there was a "standard" tier that kept it at the normal rate and maintained parity with the features we had yesterday for 2.9%...
As a connect platform partner this is a bit of a blow as this impacts our customer acquisition funnel, we drive customers to Stripe and then they use us.
I have been talking with Tara who has been very helpful on this matter but wanted to pitch in here.
I think from a connect platform partner stand point it comes across as a bit inconsiderate almost.
I have already seen some people immediately put off considering using Stripe now due to the additional fees and complexity. It just doesn't seem to sit well.
The Subscriptions API was the main reason for Stripe's success and now it's being charged for, why not charge for the dashboard usage and leave the api users alone?
First $1 million for the lifetime of the account I assume, not per year?
Seems odd that they announce a fee increase without any notice to existing customers.
Also I found their wording very confusing - I had a few seconds that I was very worried I'd have to migrate something or other. Poor communication wording on Stripe's part. C'mon, guys.
Having used Chargebee for a long time I would say that this problem space is much larger than it first appears. There are a lot of boxes to tick before a solution like this does all the stuff you’ll need it to (but have no idea about).
Nothing is a good replacement for Chargebee - stay the course there!
Don't get me wrong. I love Stripe, and we use it for handling all the payments. Over time I'm sure this billing offering will grow in functionality but it's unlikely to even get close to feature parity with Chargebee.
Many days from now you're going to have this internal monologue while in Chargebee; "Noooo, I have to do this really weird thing with promotional credits and coupons and pro-rating and adjusting subscriptions all at the same time and there's no way... oh, wait, that all works. And it showed me everything that was going to happen on screen before hand so I could double check. Just. Amazing."
Can anyone explain me why Stripe is so hyped on HN ? It's the most expensive card processing service I know. I am using one where I pay 1.9% for all my clients and another for EU clients where I pay only 1.7%.
I don't see anything in their offer that is worth paying additional 1.2% of my business to card payment processor.
This website, Hacker News, is essentially the community site for companies emerging from Y Combinator. (Hence the Y icon in the upper left corner of the page.)
Can anyone explain me why Stripe is so hyped on HN ?
When Stripe launched, the alternatives for a new or small business that wanted to charge cards online were basically traditional merchant account and payment gateway integration (terrible developer experience, excruciating long process, often borderline abusive conditions for merchants) or PayPal (terrible developer experience, faster experience for as long as it lasted, countless nightmare stories of frozen funds etc.).
Stripe came along and let you add that functionality within a few hours, and it did so while also providing excellent and highly developer-friendly documentation and support, which obviously plays very well to the typical HN reader. It wasn't about slightly higher fees vs. slightly lower fees, it was about whether it was possible and worth doing at all.
Stripe today is not as good as Stripe in the early days for many reasons, but it's still better than almost anyone else I've used on all of those scores. Presumably I'm not the only one on HN who has had that experience. It's reassuring that there are several more businesses now starting up in this area, but I haven't yet seen anyone significantly better that didn't also seem to have at least one significant drawback for any business I'm involved with that uses Stripe today.
(Stripe here) Stripe's pricing varies depending on the country you're doing business from. If useful, you can see our pricing for businesses in the UK here, which starts at 1.4% + 20p for European cards: https://stripe.com/gb/pricing
I work at Accumulus which has a recurring billing platform that de-couples payment processors from recurring billing, i.e. invoicing, price plans, customer management and notifications, etc. The thing is that you don't want to be locked into a particular payment processor long term. Convenience sells, but be mindful of lock-in. As companies grow, they get better rates with different merchant account providers. As a company, you want maximum flexibility and negotiation ability to take your business to those who give you the best value, globally.
We are putting together an offer specifically for Stripe users who want to avoid lock-in and save money long term. If you are interested, you can get on the list here https://accumulus.com/it-is-your-revenue
"Behind the scenes, Stripe now generates a unique virtual bank account number for each of your customers, which keeps your company’s banking details private. Any payments received appear in your Stripe balance and invoices are automatically reconciled and marked as closed."
Everyone here is complaining about price, so let me offer a counterpoint.
My understanding is that 2.9% + 30 cents is barely above what you would expect the credit card networks themselves to be charging Stripe. The margins are razor thin. If you have beef with this percentage of your revenue being taken, it's with the credit cards.
Adding a .4% fee on top is likely cheaper than using a separate service on top, like Chargify/Recurly/Chargebee. (Sure, if you had already built your own stuff on top of Stripe, you don't see this tradeoff as real. But all of those are legitimate businesses, suggesting there's a huge market out there of people who don't prioritize eng time like you.)
.4% isn't nothing, but put it in context of a functioning SaaS business with product priorities, especially when you think about expensive it is to hire software engineering talent. It's going to be a fraction of a fully loaded engineer's time that is probably best dedicated to other parts of the business. (Fully loaded = take a salary, add 30% for taxes and benefits, plus ammortized recruiting fees.) A one-time or occasional integration project frees up engineering to focus on other stuff and enables other teams to work on their own.
Somewhat off-topic question, but how do others handle the need to create an invoice that corresponds to a Stripe charge? We've been using Stripe Subscriptions (I guess, now Stripe Billing) to auto-charge customers, and we separately define recurring invoices in QuickBooks Online. It's a clumsy process, but I'm assuming all Stripes Billing users have to solve it. Is there a better way to handle?
This is awesome, congrats! I'd love to be able to send invoice emails, and/or retrieve links for invoice PDFs and list those in your application for download (or re-sending of email). Seems a bit bizarre as the infrastructure for emails, and generation of the PDFs are clearly in place, just missing the bits to tie those two together.
Awesome job on making it easy to add usage based plans. I've found Stripe's customer service to be a notch above the rest.
Request to folks at Stripe ( @pc / @tarstarr ) : Please do something to protect small business owners against fraudulent payments (i.e. with stolen cards). Even if they follow all recommended practices by Stripe, it's very likely that there are a handful of stolen cards that will fly under the radar and hit them negatively.
I'd say if the merchant is not at fault due to a stolen card being used on their site, they should not get penalized for it. The chargeback fee is one thing, the worse part is the dispute rate going up. This threatens the existence of any business if their account is suspended by Stripe.
I understand how handy are solutions like stripe, but at least in Europe you can have a payment gateway from your bank just like they can give you a handheld device, and the rates are way cheaper, I just looked one which is 0.50%, six time less than stripe.
I'm so excited about this. We were looking into Recurly, but the migration from Stripe to them seemed like a huge hassle. Not sure yet, but it looks like this will allow us to unify all billing in 1 place, without a large dev or monthly cost. #awesome
If I may take advantage of the numerous highly knowledgeable people in the industry here — has anyone recommendations for accepting payments from the UAE?
We use Stripe to receive card payments there in AED and then need to pay this money out again in AED. As Stripe don’t settle in AED the funds get converted to USD and then we have to convert them to AED again to pay out.
Stripe charge 2% conversion fee over market rates to convert the funds. What’s most annoying is AED is pegged to USD and there’s no conversion risk, yet Stripe charge the conversion fee anyway. So we pay 2.9% or 3.4% (can’t remember which it is off the top of my head) international card fee, 2% Fx to USD and another few % back to AED :-€
Well, this is all a bit cheeky. Backed Stripe for so long now, kinda lost touch with the options. What are some other decent recurring payment processors that support Asia Pacific, specifically Australia/New Zealand?
A really cool touch is that those animated examples of pricing and other elements are actually animated html elements, not GIFs or video files. Again really slick touch from designers at Stripe.
Looks like a nice improvement. There's some very bizzare design decisions with Subscriptions, so hopefully this will start making things more flexible.
I'd love something like this that handled in-app purchased subscriptions. There's a bunch of annoying parts of dealing with the app store SDK's & verifying transactions, handling refunds etc. We have a combination of online credit card purchases and in-app ones, it seems like there's an opening for some tool to handle the in-app part as well.
I've been waiting for the invoicing piece for a long time. We currently use PayPal invoices (and will probably continue to do so), but for those customers who can't use PayPal, this is fantastic!
We've been using Plasso's payment form service, but they just changed how that works, so this came along at exactly the right time.
How does this work in the case where the majority of your customers currently pay by direct-debit/cheque? This is certainly the case for us, but we have long been looking for a affordable solution to have them managed with some sort of managed subscription engine
Does this support international wire transfers as an invoice payment method?
If so, that's a killer feature for us, as US-based customers have other options including simply mailing a check; it is our international customers exclusively who are interested in wire transfer...
(PM of Billing from Stripe here) Tools like Stunning, and the many other extensions that work with Stripe, are very complementary to Stripe Billing. As you’d expect from Stripe, we’ve taken an API-first approach, so that our partners can actually take advantage of our recovery tools when building their solutions. We expect that particular businesses will want to use both!
Hey! Yes you can email invoices to your users (finally!) We heard that feature request so many times. :)
Re: multicurrency subs -- we thought about this quite a bit. At the moment you'd need to create a plan per currency, with our reasoning being that you'd want to control the FX rates on your own (and setting a price internationally is a very intentional decision.) That said, how can we make this easier? This launch is a start of our investment in this space, really interested in feature requests.
Would be great if the "Pay in Full" button on the invoices used the same color that is set under Business Settings > Customer Emails > Customize Design.
Under invoices there are two new documents "Invoice PDF" and "Receipt PDF" which are different from the standard e-mail receipts. Are these documents emailed to the customer automatically? Is there a way to control this?
This seems like an excellent move for Stripe. Lowering the barrier to entry for anyone trying to get into the SaaS (or really Anything-aaS) field by making recurring billing easier strikes me a great move for their bottom line.
I see interest here in the new invoicing feature. My question is, if your accounting system can send electronic invoices (Quickbooks does), why do you need Stripe? Especially if it's more expensive?
Woaah there! 2.9% + $0.30?! I just changed my provider because their 1.45% (+ $0!) was way too expensive compared to the competition. Do Stripe provide a bag of gold at every Christmas?!
Sweet another service I can't use because I'm Canadian, but wont get access to their Atlas program because I don't qualify. I'll have to take another approach.
(I work at Stripe and am also Canadian!) It looks like you might have applied for Stripe Atlas when we were in a small private beta and we’ve greatly expanded the businesses we can support. Please feel free to apply to Atlas again, or you can email me us at atlas@stripe.com.
I wish this had existed a year ago when we shifted from primarily doing everything through Stripe to Chargify for metered billing, invoicing and dunning.
can anyone comment on support for purchase orders which a lot of companies use to recognise or initiate a purchase?
it seems to still be the only thing that needs to be manual in that process....
Skeptical a bit about "usage-based" billing and interested to hear others' thoughts. Isn't a major profit-driver for many subscription-based businesses the breakage?
For anyone wondering about pricing, here's our approach.
- For new Stripe customers, this is free up to the first (lifetime) $1M of payments.
- For existing customers, there's no pricing change. You just get more functionality than before for free. This is what we generally try to do: we want Stripe to continually become better value for you over time, as you get more functionality for the same price.
- What we've seen over Stripe's history is that customers handling large amounts of revenue have been forced to pay substantial amounts for expensive third-party systems. So, we've decided to build something that we think will be better and cheaper -- and that will, over time, increase the net revenue of businesses built on Stripe.
I'm sorry about any confusion in our communication around this!