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 [email protected]? 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.

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.

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-...

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.

(counter-intuitively)

=max(whatTheJudgeThinks, max(10mEUR, 0.02*turnover))

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"

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.

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).

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!

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.

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.

https://www.profitwell.com/privacy-policy

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.

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.

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. :)

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.

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.

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.

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.

"[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: 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.

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.

They do have an opt-in "Recover" product, just like Baremetrics, which is priced exactly the same way as Baremetrics.

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...

"Plus, we're able to show our customers they have a problem that we can then sell an add-on for." - I really like that part.

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.

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.

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.

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. :)

[1]: https://stripe.com/us/sigma

Wait, what? What do you mean? I'm not seeing this at all.