Stripe Billing
stripe.com
stripe.com
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!
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.
Negatively.
Edit: See also https://news.ycombinator.com/item?id=16772655
For example, these guys: https://www.netcompaysystem.com
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....
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!
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.
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....
On the UI side, mind shooting me an email at eduardo@stripe.com? I can share some stuff we're working on!
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.)
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.
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'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"
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.
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.
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.
Is there anything like it in Germany?
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.
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?
I'm glad that I now know the answer, but I would've been asking Stripe support if I hadn't stumbled across this by chance.
Any thoughts on either acquiring https://baremetrics.com/ or creating similar functionality within Stripe?
Seems like a natural extension to Billing to also have Revenue Analytics.
Its a lot better, cleaner, more featureful and it's free.
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).
As an outsider, comparing BareMetrics vs Profitwell - all I have to say is thank you for 2 specific reasons.
1. BareMetrics has a live demo. Profitwell tried to make me schedule a call with a sales person just to view the product.
2. BareMetrics has simple pricing. With Profitwell, I literally couldn't figure out how much it'd cost if I were to use them.
For non-basic usage, that's a con, not a pro.
ChartMoguls is excellent if you want to be on a paid plan. It's also super expensive.
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.
Here's the blog post we wrote up with some of the data, too: https://www.profitwell.com/blog/why-we-released-a-better-pro...
Thanks for clearing up the communication on this! I've been a happy Stripe user for years, now!
Stuff like this is part of the reason I love Stripe so much.
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?
We were literally looking for a Billing solution that works with Stripe YESTERDAY. T
This is phenomenal timing for us. Thanks Stripe!
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 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)
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.
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.
Most of our clients have an accounts payable department that's different from the main contact email.
> 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?
For receipts, you can turn them on in your account settings: dashboard.stripe.com/account
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. :)
Wait, what? What do you mean? I'm not seeing this at all.
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?
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.
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?
Yesterday: 0% extra Today: 0.4% extra
Right?
> tarstarr 7 hours ago [-] (PM from Stripe) If you're an existing user, there's no extra fees, even if you are past the $1M threshold.
(Which is kind of the full circle of this thread)
Edit: the fee increase is only after $1M in revenue so still makes sense to use Stripe in a project's early stages.
It's literally a bunch of 'value add' features maybe you'll use for a 0.4% increase in fees you didn't ask for.
Let me opt in to the new stuff.
Except that's not how it works.
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.
Excited to check out Cheddar when it launches!
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.
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.
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.
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.
"Since you used Stripe Subscriptions in the past year, the Stripe Billing Starter plan is included in your current pricing."
Edit: Since my posting this Stripe has clarified that existing customers get the Starter package at no further cost, we we are grandfathered in.
When communicating important and potentially difficult to understand information: have some non-insiders read the text and ask them what they think it means.
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?
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.
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".
Edit: The answer is no.
This announcement has burnt through a lot of goodwill that’s accumulated over the years. Not cool!
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?
I'm game.
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.
1) Send a user an invoice
2) The user copies the auto-generated bank details and manually initiates a transfer from their bank?
Hope to move away from Wave Accounting to Stripe invoice, once I can match the design... thanks!
What are people doing?
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.
> I know of no acceptable automated method for doing this, so we just have to review the information manually at frequent intervals.
This announcement suggests "usage-based", which is how AWS and Google Cloud bill you: for how much you used during the previous billing period.
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.
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?
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.
[1] https://www.chargebee.com/docs/checkout-v3.html [2] https://www.chargebee.com/docs/assets/screenshots/images/cha...
Turn and burn it seems
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.
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.
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.
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
But what if I'm an existing user, and about to start a new business? Honestly, this sucks.
There's a note on pricing in the email to existing users (but let us know if you have any questions!)
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.
Not sure if Zuora is in the same camp or not, but probably at least partially? They actually have an IPO coming up: https://www.sec.gov/Archives/edgar/data/1423774/000119312518...
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)
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%...
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?
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.
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."
I don't see anything in their offer that is worth paying additional 1.2% of my business to card payment processor.
https://www.startupgrind.com/blog/the-collison-brothers-and-...
Also, payments is something that every real start-up will hit sooner or later.
http://www.ycombinator.com/ - second quote, at the bottom
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.)
https://news.ycombinator.com/newswelcome.html
if it helps, all YC graduates are hyped... on the YC 'news' site.
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.
"Once Stripe is supported in your country, you’ll be able to accept payments from customers anywhere in the world."
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
May I ask which payment processor you're using in the EU?
Comparison with Stripe here:
"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."
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.
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.
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 :-€
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.
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...
Also do you have multi currency subscriptions? Or do i need to create a pro_monthly_euro, expert_yearly_dollar subscription ?
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.
Thanks
Soon: 4 versions of APIs working simultaneously, with a different mix of missing features in each one of them, and no docs.
Whatever makes you say something so absurd?