[HN Gopher] Stripe migrates Stripe Subscriptions users to Stripe...
___________________________________________________________________
Stripe migrates Stripe Subscriptions users to Stripe Billing
Author : corentin88
Score : 260 points
Date : 2020-11-12 18:13 UTC (4 hours ago)
(HTM) web link (stripe.com)
(TXT) w3m dump (stripe.com)
| reilly3000 wrote:
| Recurring billing is hard stuff. If you haven't touched it and
| don't know what Dunning means, or how to handle upcoming card
| expirations, or proation, or mixing one-time and recurring
| purchases, then you probably won't appreciate what kind of value
| is provided by a 3rd party service. Its a wonderful thing to
| outsource for many SaaS companies. If you have a totally novel
| business model with unique billing requirements it may make sense
| to build, otherwise its almost universally cheaper and more
| maintainable to buy.
| hugoromano wrote:
| 5C/ made sense, 0.5% is a parasitic approach, the tech stack and
| engineering costs them 0.1C/ per recurring transaction.
| adrr wrote:
| There's a fixed cost to put a transaction onto the card brand
| networks. Recurring includes dunning management which retries
| failed auths. If you rolled your own, you'd be paying for the
| declines.
| hugoromano wrote:
| Stripe is charging extra 0.5% for the billing feature, so a
| billing charge goes in the US with stripe 3.4% + 30C/. It
| could be done for 2.9% + 30C/ + 5C/, stripe will still get
| the its cut, but not the extra 0.5%.
| donor20 wrote:
| Sounds like you could clean up in this space at $00.001 per
| transaction!
| hugoromano wrote:
| C/5/transactions for billing services we could do it, might
| need some small seed funding to set up a small dev team. Do
| you think we could get interest customers?
| mrnobody_67 wrote:
| This is the PayPal model.
|
| Starts slowly, then add in dark patterns for FX currency
| conversion, withdrawals, etc. etc.
| breck wrote:
| I hope they can also innovate more on behalf of the customer with
| regards to recurring charges.
|
| PayPal has this management console where a customer can see __all
| __recurring charges and __instantly __cancel any of them with one
| click:https://imgur.com/a/lLE3iAt
|
| IMO, this should be standard across all payment cards. I detest
| businesses that make it hard to cancel recurring charges and I
| think payment card providers need to stop that from happening (I
| get Stripe is not quite a consumer card provider...yet).
| candiddevmike wrote:
| In my opinion, no one should be using recurring billing for any
| provider. If you do, you've basically tied yourselves to them--if
| you ever decide to move, you need to somehow get the subscription
| details for every customer migrated into your app!
|
| Instead, view your payment processor as just another
| PaymentProcessor enum. Own the recurring subscriptions yourself,
| or be willing to pay for someone to do it for you.
| nickjj wrote:
| I think this is good advice or at least seriously worth
| considering it.
|
| I remember DHH from Basecamp mentioning this once a few years
| ago. I forgot if I asked him on Twitter or if someone else did,
| but it came down to asking why Basecamp doesn't use Stripe's
| subscription API.
|
| He said it didn't exist at the time but he also said it wasn't
| a ton of work to get it all working using the basic single
| charge API. Details are spotty since it was a random tweet from
| a while ago but the overall feeling of it was it's very doable.
|
| I feel like the topic came up in one of those YouTube videos
| where DHH walked through real life code in Basecamp.
|
| Even today it might be worth it. I mean if you try to integrate
| an abstraction on top let's say Stripe and Braintree, there's
| quite a lot of differences between the 2 for subscriptions. How
| much more work would it be to write your own subscription logic
| once and use it anywhere vs writing a really good abstraction.
| paxys wrote:
| That is easier said than done. Managing recurring billing is a
| significant engineering problem, and getting tied in with a
| provider and paying a surcharge is still worth it over
| maintaining an entire in-house dev team to do it.
| raiyu wrote:
| I guess now it's as simple as checking whether cost of a dev
| team to do recurring billing is < 0.5%
| mytailorisrich wrote:
| > _Managing recurring billing is a significant engineering
| problem_
|
| It's not. Sure it's a problem and it requires thought and
| engineering skills. But overall it is not one of the
| complicated problems and quite standard work for an engineer.
|
| Sometimes I feel that people have become so used to have a
| third party API for everything so that they are scared of
| doing actual engineering work... ;)
|
| That said, of course weighing the cost of dev and maintenance
| in-house versus paying a surcharge is a very valid
| consideration. At the same time one should not underestimate
| the risk/cost of getting tied to a provider for anything
| critical (and payments are obviously critical).
| porker wrote:
| > It's not. Sure it's a problem and it requires thought and
| engineering skills. But overall it is not one of the
| complicated problems and quite standard work for an
| engineer.
|
| If you reduce it to "Charge them again after X period" then
| sure. If you want to comply with worldwide payment laws and
| tax requirements, then I'd disagree it's "not one of the
| complicated problems".
|
| Edit: And dunning. And pro-rata'd subscription changes. And
| pro-rata'd refunds.
|
| We pay Paddle 5% of every subscription transaction for a
| reason.
| Silhouette wrote:
| _If you want to comply with worldwide payment laws and
| tax requirements, then I 'd disagree it's "not one of the
| complicated problems"._
|
| It's also not something that a service like Stripe will
| handle for you to a useful degree.
|
| _Edit: And dunning._
|
| Which, AFAIK, you still can't actually test properly with
| Stripe's system before making it live. I'm not even sure
| it's fully documented yet, and if it is, that's a
| relatively recent development.
|
| _And pro-rata 'd subscription changes. And pro-rata'd
| refunds._
|
| You can literally write the code to do things like this
| in a few minutes, including all conceivable edge cases.
| Many of us have. It's basic arithmetic combined with some
| almost-but-not-quite-trivial logic around dates.
|
| _We pay Paddle 5% of every subscription transaction for
| a reason._
|
| But Paddle's model is a merchant-of-record, which also
| takes care of things like the tax reporting and
| remittance headaches that a service with Stripe's model
| doesn't. It's not a fair comparison.
| mytailorisrich wrote:
| I'm not reducing, this is what _recurring_ billing is.
| The relevant issues include cancellations, pro-rata
| refunds, card expiry, calendar calculations (always fun),
| etc. These are not rocket science.
|
| Handling of tax has to happen on any payment and is not
| an issue specific to _recurring_ billing /payments. It
| obviously brings in its own set of issues, the biggest of
| which is the multiplication of requirements if you want
| to comply with the rules of many countries, as you point
| out.
| candiddevmike wrote:
| In my experience, it should be no more difficult than sending
| recurring emails. You should have all the data
| (PaymentProcessorCustomerID, LastBillingDate, etc), run it
| like you would a email with a retry queue.
| abfan1127 wrote:
| its more than that. The "What ifs" get out of control
| pretty quickly. Prorating, canceling, expired/canceled
| cards, tend to create a ton of end cases.
|
| For instance, a person pays for Feb 15 to Mar 14, the card
| expires March 1, then the person requests a cancellation
| Mar 7 and wants a refund.
|
| Its not impossible, it just takes a lot of time and effort
| to weasel out all of these end cases.
| candiddevmike wrote:
| In the example you gave, how would stripe billing solve
| that? This seems like you'd need some kind of manual
| interaction regardless?
|
| For all the end cases, you manually handle them until
| they happen with enough frequency to require automation.
| A simple recurring billing system is absolutely fine for
| most businesses, and as you scale you can add more bells
| and whistles to it.
| abfan1127 wrote:
| I think you're right in this case. I haven't looked at
| the problem in about 10-15 years (before Stripe had
| recurring). I remember there being a ton of end cases I
| had to deal with. We ended up going with Recurly due to
| it.
| abfan1127 wrote:
| > Managing recurring billing is a significant engineering
| problem
|
| This is a huge understatement! Its very painful. It sounds
| easy, but there are so many end cases with the calendar
| alone! Let along discounts, prorating, cancelations, etc.
|
| It sucks to become dependent on providers for this service,
| but it also sucks to have crappy recurring billing.
| lwhi wrote:
| I guess this is a good example of why we should be building a
| very flexible abstraction layer between our payment services and
| the payment processor we use.
|
| We don't need to be held hostage - but probably will if we're not
| careful.
| alooPotato wrote:
| We (Streak yc s11) signed up for Stripe way back in the day and
| have just been paying their standard payment processing fees for
| years. We haven't upgraded our API version or used any of their
| new billing features or anything like that. Basically we get the
| same value from Stripe we did from the day we integrated. I
| thought our pricing was going to be grandfathered but this change
| will cost us tens of thousands of dollars. Unfortunately, we're
| kind of hostage to it.
|
| Anyone else at scale and have an old integration? How are you
| handling the fee increase?
| l8rpeace wrote:
| https://www.swipesum.com/ these folks can negotiate you a
| better deal on that
| klinskyc wrote:
| If you're doing significant volume, which I assume Streak does,
| you can negotiate significant volume discounts. You have been
| leaving a ton of money on the table if you have not done that.
| danpalmer wrote:
| Huge +1 to this. Everything about Stripe pricing is
| negotiable. I'd recommend going in to the discussion with a
| quote from another provider.
| Alupis wrote:
| Maybe - they seemed really not interested in negotiating much
| at all and I got the impression they feel that their
| customers should be lucky enough to be allowed to use Stripe
| as a processor.
|
| My company went through negotiations with Stripe earlier this
| year. We were more than 1.5% + $0.10 away from our current
| processor, and they wouldn't budge to even match our existing
| rates. They kept saying they are a better value, and offer
| more things for the price - except most of the "value-adds"
| we didn't care about (their only interesting things was the
| Stripe Checkout with Fraud detection - which requires you to
| use their hosted checkout page... which is a complete non-
| starter for a serious eCommerce operation).
|
| Perhaps not a good fit - but paying a ton more per year in CC
| processing fees just because Stripe uses "AI!!!!" wasn't
| something we could swallow.
| onepointsixC wrote:
| Did you end up staying with your current processor or
| swiping to Stripe?
| Alupis wrote:
| We stayed put actually. At the end of the day, you need a
| processor that charges low fees, provides easy tools to
| handle chargebacks and refunds, provides tools to
| automate sweeping balances nightly, and doesn't go down
| often.
|
| People don't switch processors often, so building out an
| integration once every 10 years isn't a big deal if you
| design your integration correctly.
|
| That, and I assure you, your customers don't give a darn
| about which processor you use.
| klinskyc wrote:
| How much volume are you doing? That's been the biggest
| lever I've seen when it comes to Stripe reducing rates
| tomsi wrote:
| Would you mind sharing which processor you are using?
| Seriously considering moving away from Stripe after todays
| news and since we have to implement basic subscription
| handling ourselves anyways or pay more ransom to stripe.
| Would be much appreciated.
| larrik wrote:
| > Stripe Checkout with Fraud detection - which requires you
| to use their hosted checkout page
|
| Does it? In my experience you can just use their Hosted
| Fields which are actually really great.
| Alupis wrote:
| That's not how they pitched it to us - and I asked for
| clarification multiple times because of how absurd the
| proposal was for a well established eCommerce site.
| Sending customers off-domain for a payment is not
| something we were willing to do for a normal credit card
| checkout flow.
|
| Even "hosted fields" is absurd (and by that I assume you
| mean an iFrame you embed), and would require redesigning
| significant portions of the checkout process.
|
| That, coupled with their refusal to even match our
| existing rates, was really off-putting. The sales people
| made little effort to understand our business and pain
| points - they just wanted to talk about how great Stripe
| is and all the AI stuff they do.
| edwinwee wrote:
| You don't have to use Checkout for Stripe's fraud
| detection, which supports several types of integrations:
| https://stripe.com/docs/radar/checklist.
| Alupis wrote:
| I guess the point was, that "feature" was the only value-
| add we cared about, but not enough to pay thousands more
| per year for effectively the same service - accepting
| credit card payments.
|
| Your sales team walked away from the negotiations after a
| while because we weren't willing to pay significantly
| more just to have the brand "Stripe" be part of our
| business. It really was a "but, but, we're Stripe! AI!
| Why don't you just agree to the terms? AI!!! Did we tell
| you about the AI!?!?!".
|
| I suppose it was Stripe's loss in the end... and I
| imagine we're not the only company that had this
| experience.
|
| I have the impression Stripe's "bread and butter" are
| small-time shops (partnered with Shopify where 99% of
| sites generate < $1MM annual), hobbyists, and similar
| smaller operations that either can't negotiate better
| rates due to low volume, or don't know they can negotiate
| better rates due to high volume. Nothing is wrong with
| that - it just means Stripe isn't a good fit for
| companies with significant volume.
| edwinwee wrote:
| Hm, no bueno. And sorry about that. I'd love to see that
| thread if you could forward it to me at edwin@stripe.com.
| merb wrote:
| haha we had a similar story with a company (not payment
| tough) all they said was AI, we are better, so we charge
| more. but who cares if you charge 10x more than your
| competitor, with 10x more you need to be at least 100x
| better.
| enahs-sf wrote:
| Could you define "significant volume" a bit more
| specifically? Wondering if I too, have been leaving a ton of
| money on the table. What is the approximate scale that this
| makes sense at?
| klinskyc wrote:
| This link says 80k/month, which matches our experience ->
| https://www.fool.com/the-blueprint/stripe-payments-review/
| sigwinch28 wrote:
| An extra 0.5% is going to cost you "tens of thousands of
| dollars"?
|
| You're literally moving millions of dollars a year through your
| billing platform. That's not a little bit of money. That's a
| lot. Own it.
|
| You're not a hostage. You're deeply integrated through nobody's
| fault but your own.
| whimsicalism wrote:
| > You're literally moving millions of dollars a year through
| your billing platform. That's not a little bit of money.
| That's a lot. Own it.
|
| Nobody said it was a little bit of money? Where is this
| comment coming from?
| Loughla wrote:
| I think OP's point was, if you're moving that much money,
| you shouldn't be relying on a third party vendor; doing so
| shifts the blame from them, to you, for not controlling
| your own payments. That's what I read in that post.
|
| I have no idea if it's a good point or not.
| jm20 wrote:
| There's a big difference between "millions of dollars"
| and "relying on a third party vendor for payments." I
| don't know of many sub-$1B companies that implement their
| own payments infrastructure...
| kempbellt wrote:
| Without knowing their business model, it really doesn't
| matter how much money is moving through their system. It
| could very well be that they have a lot of buyers because of
| a very low profit margin and this actually has a notable
| impact on the company's finances.
|
| Saying you are "held hostage" might be a bit of a dramatic
| way to phrase it, but for some companies a change like this
| actually makes a difference. Such is the life of relying on
| any third-party services though.
|
| Also, pointing out "faults" is not helpful. It's unproductive
| conversation. Many companies are built upon third-party
| services that they are (probably falsely) under the
| impression will not change. It's not your "fault" if you
| decide to use AWS services and become deeply integrated and
| they increase their prices by 10% and you can no longer
| afford their services... It's no one's fault. It's just
| unfortunate and all you can do is try to work around it, or
| close the company.
| PragmaticPulp wrote:
| > It could very well be that they have a lot of buyers
| because of a very low profit margin and this actually has a
| notable impact on the company's finances.
|
| This is the real problem.
|
| From the sidelines, it's easy to dismiss an additional 0.5%
| overhead as trivial. After all, that's less than 1%, right?
|
| But it's not so simple. That 0.5% comes out of the profit
| margin. If a company has 50% profit margins, losing that
| extra 0.5% isn't a big deal. However, if a company is
| operating on 10% margins, that 0.5% suddenly becomes an
| extra 5% overhead.
| lwigo wrote:
| Move to another solution? I have no idea on pricing but maybe
| NMI, Braintree, etc. Also play hardball with the account
| manager if you're comfortable with that.
| polote wrote:
| > Unfortunately, we're kind of hostage to it.
|
| The day you decided to go with Stripe you started being hostage
| of them, but this is not a bad thing, this is business, you
| choose a partner, they are allowed to change the terms if the
| contract permit it.
|
| People on HN always think they deserve to be treated better
| than others
| wakatime wrote:
| That's why we integrated with 4 payment providers. We use a
| common Quote object that knows how to "apply" itself to
| subscriptions on all 3 (GitHub is inverse) providers.
|
| 1. Stripe
|
| 2. Braintree
|
| 3. Coinbase Commerce
|
| 4. GitHub Marketplace
| jerrod wrote:
| This is smart, Alan. I like it.
| Loughla wrote:
| >People on HN always think they deserve to be treated better
| than others
|
| I have noticed a significant attitude of, "I originally
| signed up for this product with 'x' cost and 'x' features,
| and you have zero right to change anything about that."
|
| It seems like a basic contract negotiation process would
| ferret that out - I thought that was a business thing to do.
| I work in higher ed, and we absolutely have to have contracts
| for all third-party vendors; any changes are negotiated with
| the start of new contracts. If we can figure it out, surely
| startups can - we're not really all that good at efficiency.
| troughway wrote:
| >People on HN always think they deserve to be treated better
| than others
|
| Y..you mean we won't all be millionaires when we grow up?
| arghwhat wrote:
| No no, _we_ will all be millionaires. Just not you
| specifically. Sorry.
| grumple wrote:
| Why are you hostage to it? How much dev time would switching to
| a different transaction processor take? This seems like it
| should be a very competitive space.
| lukevdp wrote:
| It's not just dev time, that would be easy. It's getting
| every customer to re-enter their credit card details which
| won't happen without a significant uptick in arrears, and
| depending on the type of customer, churn.
| iamacyborg wrote:
| I'm constantly surprised that Direct Debit isn't a thing in
| the US.
| loceng wrote:
| Indeed, there needs to be laws for data portability to
| allow a true free market mechanism so then if a company
| isn't providing reasonable value for their fees, people
| will be mobile and can shift away without friction;
| Facebook has survived because lack of adequate data and
| network portability.
| sigwinch28 wrote:
| Not anticipating this scenario is a collective failing of
| everyone in the business who deals with third party
| integrations.
| byteofbits wrote:
| Stripe supports exporting PCI data like credit card details
| to other PCI Level 1[1] providers such as Recurly and
| Braintree.
|
| Data portability is a solved problem in this space - so
| there isn't a material risk of churn due to a migration
| like this.
|
| We recently went through the process and it was very easy.
|
| [1] - https://stripe.com/docs/security/data-
| migrations/exports
| jlokier wrote:
| > Data portability is a solved problem in this space - so
| there isn't a material risk of churn due to a migration
| like this.
|
| Here's my anecdote of a different situation but with some
| similarities, where we couldn't get the data portability
| we wanted.
|
| A few years ago I asked our Direct Debit provider if we
| could migrate customer subscriptions from our old
| business entity to our newly incorporated company version
| of the exact same business.
|
| The old business entity was to be wound up as a complete
| transfer to the new one, the trading name was identical
| (transferred along with trademarks), and we were happy to
| keep the same DD provider.
|
| The answer we got was no, each customer would have to
| enter their bank details and agree to the same terms
| again. From the customer's point of view, they probably
| wouldn't even notice it was a different business, because
| in a real sense it wasn't.
|
| We decided this would lead to significant churn in
| customer subscriptions, and we couldn't afford it. It
| would be cheaper to maintain and administer the old
| business entity, for no business purpose whatsoever, just
| the _sole purpose_ of continuing to receive the DD
| subscriptions, and pay them immediately in full to the
| new business entity.
| epa wrote:
| Email your rep and tell them you want to move to interchange
| plus pricing.
| globile wrote:
| Make sure you run the numbers first. If you have a lot of
| international traffic, you may end up paying more.
| merlinbeard wrote:
| we're exactly in the same situation.
| TAForObvReasons wrote:
| Earlier this year, they made other changes for long-term
| customers:
|
| - increased fees for non-US payments (3.9% + 30 cents)
|
| - did not refund fees when you refund customers
|
| If there was a compelling alternative that isn't PayPal we'd
| jump in a heartbeat
| loceng wrote:
| I have to believe this is Stripe leadership pumping up the
| revenues/profits to look peachy for their IPO, so they can
| all get a considerable exit while raising a war chest -
| meanwhile competitors will come along and try to take market
| share while Stripe can spend more on acquisitions and feature
| development for the same price. I think this play as part of
| the VC industrial complex leaves them more vulnerable than is
| obvious - but leadership won't ultimately care because
| they're set for generations.
| jm20 wrote:
| If the Stripe leadership wanted to exit and be set for
| generations they could've done it years ago. I agree it
| could be a revenue boost to prepare for IPO but this isn't
| some personal greed thing
| cambalache wrote:
| Agree, it's collective greed
| marcinzm wrote:
| Personal greed doesn't magically end just because you
| want $5 billion instead of $1 billion. Greed is greed
| even if the only point of it is having a larger number in
| your bank account or higher social standing from it.
| globile wrote:
| Same thing has happened for Radar for example. We set up our
| whole infrastructure with their beta 3DS and Radar products,
| and then one day (a few months back), it is $ 0.07 per txn in
| Radar as well as no returned fees on refunds.
|
| Stuck with nowhere to go.
|
| Not against improving margins, but customers that have walked
| hand in hand with Stripe for so long and seen them thru their
| early growing pains should definitely be grandfathered.
|
| Grandfathering would be the cool thing to do.
| sigwinch28 wrote:
| Why should they be grandfathered?
| markdown wrote:
| Because it
|
| > would be the cool thing to do.
| NeutronStar wrote:
| Did you even read the comment?
| globile wrote:
| Oh yes! To Grandfather or not to Grandfather! That dilemma!
|
| I understand they are still using the same functionality
| they had at signup time, and are still on the same API
| version, so not taking advantage of new direct
| functionality.
|
| Yes, of course there is a bunch of indirect functionality
| or magic behind the scenes, but from a company lifetime
| perspective, when you enter into an agreement with a
| service provider, you would expect a relatively constant
| delivery of services, at the agreed prices, especially if
| your needs have not changed.
|
| There are many companies that upon adding new functionality
| or services, decide to grandfather. New direct
| functionality comes at new prices, even if you are
| inherently benefitting from the new stuff.
|
| Three I can think of, Zendesk, Customer.io and Geckoboard
| grandfathered our plans.
|
| When it is easy to switch providers, grandfathering is not
| that important, but if you're tightly integrated, which
| pretty much everyone doing volume on stripe is, then you're
| screwed. You can't leave.
|
| Even if you negotiate custom pricing, there is a knock on
| the door one day saying, "new pricing in place. Take it or
| leave"
| marcinzm wrote:
| Because it creates a reputation that choosing Stripe is a
| safe move for a business. Like how AWS never increases
| prices. It allows businesses to lock themselves into the
| platform with little worry which makes the platform owner
| profit in the long run. Businesses don't want sudden costs
| one day that they couldn't budget or plan for.
| e_commerce wrote:
| Stripe needs to lower fees. Fees have stayed high for the entire
| history of the company.
| dang wrote:
| I've changed the title from "Stripe is now charging 0.5% more for
| recurring charges", which apparently is misleading, to one that
| is, though clunky, apparently accurate.
|
| If anyone can suggest a better title--that is, accurate and
| neutral, and preferably with less clunk--we can change it again.
| merlinbeard wrote:
| The original title was way more accurate. That is the essence
| of the change, and the reason why people are so unhappy.
| dang wrote:
| I know nothing about the intricacies of Stripe product
| offerings, so need to rely on others to come up with an
| accurate title, which is (as always) our intention.
|
| The submitted title implied that Stripe is raising its prices
| on all recurring charges. As I understand it, that's not
| true; therefore that title was misleading and needed to be
| changed. (Site guideline on this: " _Please use the original
| title, unless it is misleading or linkbait; don 't
| editorialize._" -
| https://news.ycombinator.com/newsguidelines.html)
|
| If there's another title that is even less misleading, we can
| change it again. Btw, as a rule, the best way to complain
| about a bad title is to propose a better one. We can't come
| up with all of them and often adopt community suggestions (a
| few examples: https://hn.algolia.com/?dateRange=all&page=0&pr
| efix=true&que...).
| [deleted]
| dang wrote:
| That contradicts what's said elsewhere in the thread. My
| understanding is that prices are going up for the earlier
| users of an older product who are now being moved to a
| newer product. It's understandable why they and others
| wouldn't be happy about that, but it's a different
| situation from what you're describing here. If that's
| wrong, I'm happy to be corrected. Like I said, I have no
| firsthand knowledge, so have to rely on people who do.
| harrisonjackson wrote:
| For those of you that have negotiated better rates with Stripe or
| other vendors - are they committed to those rates for some amount
| of time or total volume?
|
| Stripe billing competes with Recurly and Chargebee. Anyone using
| those products that has had similar price increases? How were
| they handled?
| elevenoh wrote:
| How much more can stripe wring out of merchants while signalling
| virtue?
|
| e.g. 2.6%+ per transaction? Jesus christ.
|
| I worked for a payment processing co. It was all about financial
| institution connections (uncompetitive). And the costs my company
| incurred to process payments were negligible.
| jb775 wrote:
| I love how a Ycombinator company can quickly get a HN story title
| changed to censor the whole "price increase" aspect being debated
| here.
| floatingatoll wrote:
| I was in the process of writing an email to the mods requesting
| that they change it to be more accurate when I found they'd
| already changed it. Apparently I'm not the only user to do so,
| since someone beat me to it. I have no associations with YC,
| HN, or Stripe.
| dang wrote:
| Literally anyone can quickly get a HN story title changed if
| they let us know how an existing title is inaccurate. This is
| bog-standard moderation which we do all day every day, and it
| is certainly not limited to YC cos.
|
| The intention is to have a front page with accurate and neutral
| titles. Call that censorship if you want to (as far as I can
| tell, that word is just a pejorative for editing that someone
| doesn't like) but it seems a bit weird to speak of "censoring"
| titles for being misleading.
|
| As I said elsewhere in the thread
| (https://news.ycombinator.com/item?id=25074261), if anyone can
| suggest a better title (i.e. more accurate and neutral) we'd be
| happy to change it again.
| tschellenbach wrote:
| This is particularly annoying since Stripe Billing was initially
| free, you start using it and now it suddenly costs 0.5% *
| revenue. Which can be quite substantial. The more frustrating
| part is that it's currently at best a beta quality product.
| Reporting and interface for the finance side of the company
| leaves a lot to be desired. Anyone know any solid alternatives?
| tschellenbach wrote:
| ChargeBee, Recurly, what else is out there?
| tallytarik wrote:
| Stripe still doesn't support settling USD payments into a USD
| bank account on an Australian Stripe account, instead forcing
| their 2% currency conversion fee on top.
|
| So my fee for every subscription charge is increasing to a an
| even more ridiculous A0.30 + 5.4%.
|
| Our users have been asking for PayPal for years, and I had always
| put off integrating because of how frustrating their API was. But
| it feels like the Stripe developer dream is over. Fine, I'm
| adding PayPal support. :(
| unreal37 wrote:
| This is for their product called "Stripe Billing".
|
| I have no idea if my subscriptions are on Stripe Billing. So
| confusing.
| aeden wrote:
| Thank you, I feel exactly the same. I assume at this point
| _any_ use of subscriptions in Stripe means we are using Stripe
| Billing, but the messaging is very unclear.
| merlinbeard wrote:
| They are.
| lubos wrote:
| 0.5% is immaterial for subscription-based businesses where profit
| margins are typically the highest.
|
| But... it adds up.
|
| For example, just looking at the last $39 USD transaction in my
| Stripe dashboard which gets converted to $53.72 AUD (I charge in
| USD but receive AUD)
|
| Stripe currency conversion fee: $0.88 Stripe processing fees:
| $1.69 Total: $2.57
|
| That's 4.78% fee. Now add this new 0.5% and we are over 5% fee on
| transaction processing.
|
| Is this expensive enough for me to consider alternatives? No.
| unethical_ban wrote:
| The idea that the ongoing cost of moving money between parties
| varies on the amount of money moving is very "sus" as they say.
| Whether they move $10,000 in a transaction or $3, roughly the
| same number of bits move, the same number of algorithms kick off,
| and so on.
|
| Is there a cost-based rationale for doing a percentage-based
| pricing model, or is it really "because they can"?
|
| I could brainstorm and say "fraud" or "defense against lawsuits
| involving large transactions" but those both feel weak.
| JumpCrisscross wrote:
| > _Is there a cost-based rationale for doing a percentage-based
| pricing model_
|
| Liability scales with transaction size.
| lukevdp wrote:
| > Is there a cost-based rationale for doing a percentage-based
| pricing model, or is it really "because they can"?
|
| It's definitely because they can.
|
| There is no rule that pricing must be cost based.
| tengbretson wrote:
| I think its a form of value-based pricing.
| PaybackTony wrote:
| Much of the interchange rate is charged directly by Visa /
| Mastercard. The merchant bank will then add basis points to
| that, and often you get another mark-up by the individual ISO
| (independent sales organization) in a typical set up. So, then,
| why do card processors charge percentage? Well, when you see
| those Capital One commercials where you get 1% cashback on this
| type of purchase or 2% cashback on this, that's where the money
| is coming from.
|
| Companies like Stripe shield you from the intricacies of
| interchange pricing but if you operate on interchange +
| (meaning, the merchant account provider is charging you
| interchange + X %), you see that processing corporate rewards
| cards are the biggest killers, because you are essentially
| covering their 2% cashback programs. Additionally, some of that
| cost is insurance. If you have a fraudulent charge on your card
| processors work with your banks to cover some of that money,
| which they make from the overall % of total volume.
|
| Not saying any of that is right, or an ideal situation, that's
| just the why.
| GeneralTspoon wrote:
| Just to note, interchange in the EU is capped at 0.2-0.3%.
| Stripe charge 1.4% + EUR0.25, so that's not the full story
| (there are scheme fees too, but I assume Stripe is still
| making some margin on the % fee - but open to correction on
| that)
| thesimon wrote:
| Though only for consumer 4-party scheme cards.
|
| If you have mostly EU customers, then it would make sense
| to switch the acquirer and probalby get an Interchange++
| rate.
|
| If you have customers from all over the world, using mostly
| business cards or cards from Amex, then the Stripe rate
| might be okay.
| dmlittle wrote:
| Isn't that rate part of the 2.9% + 30c fee? Not the
| additional 0.5% for Stripe Billing.
| PaybackTony wrote:
| Absolutely. I took the question as to why a percentage is
| charged for card transactions at all. The additional 0.5%
| is most definitely a "because they can" type of pricing and
| that's more an economics theory discussion. The market has
| shown a willingness to put up with that pricing and
| therefore a value proposition is set so until something
| changes no reason to price differently if the market is
| willing to pay a model with a much higher margin. I don't
| necessarily agree but that's a sound short-term business
| decision. I know from experience that sometimes going into
| a market with an established pricing model, however unfair,
| with a better pricing model for the customer can be bad for
| business and result not only in less profit per sale, but
| fewer customers making the buy decision because of the
| pricing model expectations that have already been set by
| the market. It baffles me, but I'm no economics major.
| lotsofpulp wrote:
| The pricing everything, in general, is "because they can".
| the-dude wrote:
| Would this thread have become #1 with this title?
|
| The title used to read something like 'Stripe charges 0.5% more
| for subscriptions'.
|
| edit: I would understand if this was actually the title of the
| page. But it isn't either.
| corentin88 wrote:
| Post author here. Original title was "Stripe is now charging
| 0.5% more for recurring charges". Which I agree is a bit
| clickbait. But the current title is definitely a well-made
| boring PR title.
| pc wrote:
| (Stripe cofounder.)
|
| Hi folks -- as Edwin points out elsewhere in the thread, the
| article title isn't accurate. (I'll update or delete my comment
| if it's fixed.)
|
| [Update: it was changed. It used to read "Stripe is now charging
| 0.5% more for recurring charges."]
|
| You can happily make recurring charges _yourself_ and no
| additional fees are incurred. Lots of Stripe customers do this
| and we don 't charge anything extra for it.
|
| If you decide to use Stripe Billing, which is a separate product,
| we charge for that. Stripe Billing's pricing hasn't changed in a
| few years. What's changing is that we're ending the several-year
| grace period where we didn't charge anything for Stripe Billing
| for businesses who started to use this functionality before 2018.
|
| Charging for Billing helps us fund a lot more investment in it --
| we've gone from very basic cron-like functionality to a pretty
| full-featured subscriptions management tool. (You can read more
| at https://stripe.com/billing.) Billing is now sophisticated
| enough that companies like Slack and Atlassian are using and
| paying for it. We've built things like "Smart Dunning" (which
| improves revenue recovery for failed charges by about 14%),
| better analytics, international payment method and invoicing
| support, and a whole host of other features. There are now more
| than 30 people working on improving Billing.
|
| Importantly, Stripe Billing is (and will remain) significantly
| cheaper than most of the other competitors in the space.
| alooPotato wrote:
| Kind of agree with cabolos here. When we signed up for Stripe,
| the fees included access to Strip Subscriptions. We chose
| Stripe in part because of that. Now we either have to pay more
| for the same functionality or migrate of.
|
| We'd be totally happy keeping the old functionality of Stripe
| subscriptions and not getting any of the new hotness. I think
| Stripe has done a great job supporting old versions of the API,
| seems like we should just be able to stay on our old pricing /
| subscriptions functionality as well.
|
| Saying that we can build the infra ourselves to do reoccurring
| kind of goes against what we purchased Stripe for initially. I
| know technically you can change your pricing/billing however
| you want but this is more of "let's capture more revenue from
| old customers" than it is "we launched a bunch of stuff thats
| new so pay for the new stuff".
| pc wrote:
| We've been testing this change for a few months to make sure
| that, broadly speaking, the vast majority of current
| customers _are_ willing to pay for the new functionality. We
| don 't want to even try to charge for things that customers
| don't feel they're getting good value from.
|
| There's obviously heterogeneity, though, and we'll be as
| reasonable as possible. If this would be really disruptive
| for your business, or if you need more time to plan a
| migration (if you don't think Billing makes sense for you),
| or something like that, I'd be happy to connect you with the
| team -- we could extend your current pricing through the end
| of 2021.
| alooPotato wrote:
| Extending the pricing through 2021 seems reasonable and
| would give us a chance to do the cost/benefit on upgrading
| to Stripe Billing (including integration work) or moving
| off. Thanks for giving us the time to make the right
| decision for our business.
|
| There have been comments elsewhere in the discussion that
| for folks with higher volume, we should be negotiating our
| fees. At what volume would you recommend companies reach
| out to your team to do so?
| pc wrote:
| Great -- if you reach out to support@stripe.com with
| "billing pricing extension" in the subject, it'll go to
| the right folks.
| gizmo wrote:
| Does this billing price extension only apply to people
| who read HN, or will there be a newsletter informing all
| your customers of this new policy?
| mritchie712 wrote:
| I'm in the same boat, is this offer open to anyone?
| pc wrote:
| Yep. See https://news.ycombinator.com/item?id=25076068
| for how to get in touch.
| onassar wrote:
| Can you clarify on the term "migrates" in the new title? If we
| use Stripe Subscriptions, do we need to migrate our system to
| the new Billing product?
| pc wrote:
| No, you don't need to do any work.
| merlinbeard wrote:
| You don't need to do any work, but you just need to pay
| more ;)
| pc wrote:
| You don't _need_ to! The pricing doesn 't kick in 'till
| next year. We want to give people time to migrate away or
| to implement a billing system manually. (And if anyone
| wants more time to do that, we're happy to grant it.)
| rexreed wrote:
| Yes - we need more time. This is a bit of a surprise. How
| do we get an extension, and how long will this extension
| last?
| tomsi wrote:
| This is just great! :)
| onassar wrote:
| If I reach out to support, will they be able to chat w/ me
| about what's actually happening? I'm pretty confused atm,
| and don't want to drown this thread with questions about
| what's actually taking place.
| nfm wrote:
| Long term Stripe customer across multiple companies here.
|
| I'm ok with paying for services like this that provide loads of
| value. I expect there's increasing diversity in terms of
| Stripe's customer base and how they use the product, and trying
| to pick a single percentage price point that works across all
| of them is no longer feasible.
|
| That said, I'm quite unhappy with Stripe's pricing as an AU
| customer. We're paying exorbitant rates to convert USD to AUD
| (think retail bank rates despite transacting multiple millions
| a year, ~3x what we'd pay Transferwise). There's no option to
| settle in USD, and a lot of our expenses are in USD, so we then
| pay another currency conversion fee when we spend.
|
| It's problematic to the extent that we're considering whether
| the ongoing costs and hassle of setting up a US entity, dealing
| with international tax, compliance, parent companies etc. would
| be worthwhile.
| pc wrote:
| Yep, heard loud and clear. We've been investing a lot in USD
| (and other currency settlement) in various markets (and
| actually just released it in Singapore). We're working on it
| in Australia too.
| nfm wrote:
| Thanks for replying, I'm very excited to hear it's in the
| works!
| _kyran wrote:
| This is infuriating. I've been told so many times that it's
| 'coming'. 5% of top line revenue is pretty significant and
| now an added 0.5% feels like a slap in the face.
|
| Braintree have offered it for years so this might be the
| final motivation to switch over.
|
| It's been around 7 or 8 years with Stripe now and it just
| seems like they are prioritising heavily increasing their
| average revenue per user at all costs.
| TedDoesntTalk wrote:
| Do you really need to set up a US entity just to open a US
| bank account?
|
| If not, I would set up a US checking account and settle some
| portion stripe transactions there. Take that revenue and pay
| your US vendors. No currency conversions.
| _kyran wrote:
| You can have a USD bank account, but Stripe won't pay out
| to it, they'll only pay out to an AUD account and take the
| 2% along the way.
| [deleted]
| stvhanna wrote:
| is the Subscription API
| (https://stripe.com/docs/api/subscriptions) part of Stripe
| Billing and thus subject to the additional fee?
| merlinbeard wrote:
| yes, as we found out through the email. Even if you send
| invoices, they will also take a 0.5% of those!
| corentin88 wrote:
| AFAICT - Yes
|
| [1] In Stripe's API, the subscriptions section is nested
| under "Billing"
|
| [2] https://www.stripe.com/billing is all about handling
| subscriptions through Stripe
| merlinbeard wrote:
| We process a significant amount of charges through Stripe and
| this is hitting us hard. We're basically being told that you'd
| like to keep some of our money for yourself. We were never told
| that we should expect such a fee increase. This smells a lot
| like bait and switch.
| pc wrote:
| I'm sorry that it feels that way. Stripe Billing's pricing
| has been public since 2018. (We didn't charge any of our
| existing users from the outset precisely because we wanted to
| avoid any sense that there's a bait-and-switch. We wanted to
| wait until we really were confident that we had a good
| product that businesses are willing to pay for.)
| Silhouette wrote:
| _I 'm sorry that it feels that way. Stripe Billing's
| pricing has been public since 2018._
|
| But lots of us have been using Stripe for a lot longer than
| that, and don't necessarily want or need all the extra
| things you're now putting under the "Billing" brand.
|
| We haven't received any notification of a change from
| Stripe, but from the HN discussion, it looks like the
| option to just have a simple, automated recurring charge --
| the key feature that attracted businesses like mine to
| Stripe in the first place -- is being removed. If that is
| the case then we'll naturally view the change as a 0.5%
| increase in Stripe's fees, pure and simple.
| TedDoesntTalk wrote:
| We use recurly.com for subscription management and have
| been very pleased with them for years.
| Silhouette wrote:
| FWIW, we're in the UK, where a combination of the
| European PSD2/SCA changes, ever more complicated tax
| rules, and uncertainty over Brexit is making the model
| used by services like Stripe unattractive now. We've been
| looking into merchant-of-record alternatives, where it
| can be someone else's problem to keep up with all the tax
| and regulatory changes and to implement all the awkward
| UI edge cases. We haven't yet made a final decision on
| how to proceed, but apparently the difference in fees
| relative to the existing services we use is going to be
| smaller in the new year, so that's one barrier to
| switching getting lower.
| tomsi wrote:
| Second that! We are exactly in the same shoes. We are not
| using or planning to use any of those extra features and
| are pretty disappointed by that move. Costs us a couple
| of grand more every year in stripe fees or we now have to
| go hire a developer.
| merlinbeard wrote:
| Unfortunately no, It was never communicated to us. we were
| told stripe billing would be free to use. The very least
| that Stripe needs to do is to grandfather the existing
| revenue for old customers, and put in the charge for only
| newly created subscriptions.
| gizmo wrote:
| We were told we were grandfathered in, actually. We
| specifically asked before we started our migration process
| to Stripe Billing.
| _kyran wrote:
| This was what was sent to us:
|
| Your account has been upgraded to Stripe Billing for free.
| No matter how much revenue you process on Stripe, you'll
| get unlimited use of Billing's Starter plan included in the
| price you currently pay for payments. All new features are
| available in your account now, no API version upgrade
| necessary.
|
| If Stripe pushed ahead forcing an additional 0.5% with no
| new features adopted, that's pretty predatory and the kind
| of rent seeking that will leave a bad taste in a lot of
| people's mouth which then when starting new projects won't
| be looking to adopt Stripe with the same passion they did
| years ago.
| JonoBB wrote:
| I've been a Stripe user for many users - essentially since the
| beta in the UK. I've implemented a number of solutions for
| clients in the US and UK over the years, some of which do tens
| of millions in recurring subscriptions per month.
|
| However, since the change to subscriptions about a year ago, I
| no longer recommend Stripe, and I have already moved some
| clients to other solutions. It used to be a super easy
| integration, but its become hugely convoluted and complicated
| now. The docs were terrible for a long time - many
| contradictions on how to do things, links that pointed to the
| wrong page, etc. Its somewhat better now.
|
| The two things that made Stripe so popular in the early days
| (super simple integration plus payments hosted on your site
| with no PCI requirements) are no longer.
|
| Pushing everything to hosted payment pages? No thanks! If I
| wanted that, I would have stayed with Worldpay from 15 years
| ago.
| joseakle wrote:
| Cool!
|
| btw there's a small bug on the storage part of the pricing plan
| calculation. It shows 5,525 GB units but then the calculation
| is for 10,100 units.
| radihuq wrote:
| Thanks pc! OT: You're very active, and usually one of the first
| to get involved, in Stripe-related discussions on HN. I'm
| curious how you manage this. Do you lurk HN all day like me and
| spot the new Stripe-related threads, or do others at Stripe let
| you know when they see a Stripe-related thread?
| pc wrote:
| Thanks! Mostly a slightly excessive affinity for HN. But
| sometimes people point me to stories too.
| radihuq wrote:
| Interesting!
| jdreaver wrote:
| I've always wondered if there is a business opportunity here:
| a company that monitors social media for all mentions of your
| business and pings you about it. Maybe this already exists?
| radihuq wrote:
| I do think there are existing applications that provide
| this service (ex: Hootsuite[0]). I think a layman could
| probably setup Google Alerts[1] to achieve the desired
| results for topics they're interested in (like your
| company)
|
| I'm curious how Patrick does it though as his attention
| isn't exactly cheap
|
| [0](https://hootsuite.com/platform/monitor)
|
| [1](https://www.google.ca/alerts)
| metal13 wrote:
| There are tons of companies that do that, with varying
| levels of automation and responses.
| JoshTriplett wrote:
| https://f5bot.com/
| cabalos wrote:
| I feel that spinning this as a several-year grace period is a
| bit disingenuous. I'm a huge Stripe fan, but this is leaving a
| bad taste in my mouth. Here's the exact notification that went
| out on April 6, 2018 in the dashboard:
|
| "As a user of Stripe Subscriptions, you will get all the
| functionality of Stripe Billing's starter plan with no change
| in price. You can continue using it free of charge on your
| existing Stripe pricing, even beyond the $1M free threshold.
| This will be automatically applied to your account. Contact
| support@stripe.come with any pricing questions"
|
| As far as I can see, the Billing Starter plan has not changed
| and still applies. Not only that, it claims we get "all the
| functionality of Stripe Billing.." when this hasn't been the
| case for a few months. New features have been gated recently,
| ie. the new customer portal.
|
| You have every right to change your pricing how you see fit.
| However, if this message was worded as it being a grace period,
| we would have taken steps two years ago to consider other tools
| or building something in-house.
| pc wrote:
| You're right. It would have been a lot better if we'd made
| explicit that we weren't intending to make a permanent
| commitment. This is good feedback for the next time we do
| something like this.
|
| (Our actual thinking was that we'd iterate on the product for
| a few years until we were confident it was good and worth
| paying for -- with both large and small companies using and
| paying for it -- and then revisit.)
| porker wrote:
| > You're right. It would have been a lot better if we'd
| made explicit that we weren't intending to make a permanent
| commitment.
|
| And the original message, when I read it for the first time
| today, implies that it is for life because it's "beyond
| $1M" and there's no qualifier.
|
| I'm not using Subscriptions so I have nothing invested. But
| that's what your message says.
| cabalos wrote:
| You're welcome; appreciate the response. For what its
| worth, I have yet to get an email about the increase and HN
| is the first I've heard of it.
|
| I should have known something was up when Stripe sent out
| the email survey two days ago about subscription pricing.
| Very strange that you only sat on those results for a day
| before pulling the trigger on this. Interestingly, some of
| the survey answers included concepts of a free tier.
|
| To me, the percentage makes little sense. You could be
| running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and
| the cost is the same. This pricing model hits high value
| subscription companies significantly harder, even though
| Stripe's costs are lower.
| pc wrote:
| > _To me, the percentage makes little sense. You could be
| running 1,000,000 $10 /mo subs, or 1,000 $1,000/mo subs
| and the cost is the same. This pricing model hits high
| value subscription companies significantly harder, even
| though Stripe's costs are lower._
|
| While this is true on some level, the challenge is that
| we'd have to set pricing at an inefficient point (i.e.
| we'd end up charging more than some businesses can afford
| to pay and less than others are willing to pay). If we
| charged $1/sub/mo (say), $5/mo subscriptions would be
| prohibitively expensive. At the other extreme, if we
| charged $0.02/sub/mo per month, it just wouldn't make
| sense to invest as much in improving the product, which
| would indirectly hurt businesses by depriving them of a
| counterfactual product that they'd like to be able to
| buy. Pricing is obviously always an exercise in trying to
| find a reasonable trade-off between simplicity /
| optimality and this is our best effort.
| JoshTriplett wrote:
| Would you be willing to consider capping the per-
| subscription cost? For instance, "0.5% of your
| subscription price, at most $x/month/subscription"? That
| would keep it reasonable for low-cost subscriptions, and
| have high-cost subscriptions pay more, but the cap would
| make it feel much more reasonable to use Stripe Billing
| even for very large subscription costs.
|
| With a structure like that, I'd want to use Stripe
| Billing for _every_ customer, rather than considering any
| kind of special arrangements for high-value customers.
| cabalos wrote:
| You're right; regardless of which model you pick, one
| side is going to be affected more. I'm sure you ran the
| math on it and saw Stripe customers skewed closer to the
| $10/mo sub than the $1,000/mo sub.
|
| In the survey, there were a lot of options for dual
| pricing models. It must have been something you were
| considering. I'd be curious to hear why this was decided
| against?
|
| To be honest, none of the new Billing features are
| relevant to us. We'd much rather have new features gated,
| like customer portal is, than paying 0.5% for features we
| never intend to use.
| pc wrote:
| > _In the survey, there were a lot of options for dual
| pricing models. It must have been something you were
| considering. I 'd be curious to hear why this was decided
| against?_
|
| I'm actually not sure. I'll check with the team. (The
| timing of the survey was coincidental, though -- we've
| been working on making our Billing pricing consistent
| since the start of the year.)
|
| > _To be honest, none of the new Billing features are
| relevant to us. We 'd much rather have new features
| gated, like customer portal is, than paying 0.5% for
| features we never intend to use._
|
| We seriously considered that. It gets pretty complicated
| (and error prone), though, with the number of different
| code paths that have to be maintained. The fact that such
| a large fraction of customers we reached out to directly
| _were_ willing to pay for a more full-featured Billing
| (mostly on the basis of competitors being significantly
| more expensive) made us eventually conclude that it wasn
| 't worth the complexity of having two adjacent versions
| of the product.
| conductr wrote:
| I may be out of date but thought the 2.9% price was
| already a premium price vs getting a merchant
| account/gateway and the Stripe API was the value for
| which you paid the premium. In which case I'd expect the
| product features to grow over time without increased
| pricing. Acting like new revenue is required to grow
| feature set is a half baked excuse when simple
| explanation that they intend to further monetize existing
| features seems more truthful.
| iffycan wrote:
| When I first signed up with Stripe years ago, it was a breath
| of fresh air. Stripe did one thing exceedingly well, at an
| understandable price and took minutes to integrate with.
|
| I could sell Stripe to my developer friends (and did, a lot!)
| in a single sentence: "You can add credit card charging to your
| site in about 15 minutes for 2.9% + 30C/ per transaction." I
| can't do that anymore. Stripe is no longer a single-sentence
| sell.
|
| Stripe still does good work. But the air is getting murkier.
| I'll point to some objective changes, but mostly Stripe is just
| starting to _feel_ different.
|
| - Several years ago, when I saw announcements that Stripe
| started supporting ACH payments (and later international
| payments), I thought, "Great! This is Stripe! I'll just be able
| to flick a switch and turn those on." Not so. I understand that
| it's complicated from their end. It's just not the same "Stripe
| is so easy" experience. "Stripe is supposed to abstract away
| the complexity, not expose it to me."
|
| - The pricing page is a big sign of the added complexity. There
| used to just be one or two numbers on that page [1]. Compare
| that with the current pricing page [2]
|
| My suggestion to you, pc: Start a little company within Stripe
| to disrupt Stripe (i.e. re-simplify) in the same way Stripe
| disrupted the industry 10 years ago. Or keep getting bigger and
| become just as complex as the things Stripe replaced.
|
| [1]
| https://web.archive.org/web/20111216054911/https://stripe.co...
|
| [2] https://stripe.com/pricing#pricing-details
| xyst wrote:
| We really need a way to facilitate money transfer between one or
| more parties. There are way too many middlemen (credit card
| processor, credit card network, bank fees, merchant fees,
| exchange network fees, ...) that artificially inflate the cost of
| products and services.
|
| This is likely worsened when you consider transactions between
| parties in different countries.
| jnwatson wrote:
| That was one of the hopes of cryptocurrency. Unfortunately, it
| hasn't panned out (yet).
| parhamn wrote:
| Yikes! This thread. First time I've seen negative comments on
| Stripe like this on HN. I guess this is what happens when you
| grow! You eventually become one of 'them', start squeezing for
| the same reasons the folks in the last cycle did, and the cycle
| repeats.
| kgog wrote:
| Stripe apologists coming to this thread in 3..2..
| byteofbits wrote:
| We recently finished moving our "Recurring Billing" stack from
| Stripe to Recurly after we found a tonne of problems with the
| Stripe billing setup. We still use Stripe as a Payment Gateway
| but we migrated off of their "Billing" product.
|
| I think a lot of those problems related to us being a European
| business and Stripe not quite being there yet in regards to Tax
| and Invoicing but now we have switched it's really shocking to me
| how steep of a price Stripe is placing on a somewhat lacking
| billing system here. I always assumed their Billing product was
| there to lock people in to the payment gateway and make it harder
| to have Interchange++ pricing negotiations.
|
| What's particularly sad is that I have fond memories of the early
| days of Stripe when I was genuinely excited to use their
| recurring charge product because the developer experience was so
| nice.
|
| Today with VAT MOSS, SCA and a larger team the Billing product is
| neither easy nor powerful for us.
|
| One saving grace for anyone else who finds themselves with an
| expensive / insufficient Stripe integration is that they make
| migration out very easy. We were able to get the whole process
| done with no downtime or missed billing - so it's definitely
| possible even when dealing with complex billing arrangements.
| edwinwee wrote:
| Stay tuned on the European tax stuff--we're working on that
| now. (And if you want to talk more about it, feel free to email
| kmoriarty@stripe.com and me at edwin@stripe.com.)
| KingOfCoders wrote:
| Because they can.
| sokoloff wrote:
| If it adds more value than the cost when compared to other
| alternatives, why _shouldn 't_ they charge something for it?
| It's not like stripe has anything close to a monopoly in the
| payments space.
| vkou wrote:
| Yes, and they can because being a payment processor is not
| easy. If it were, nobody would need middle-men like them.
| PaulDavisThe1st wrote:
| But of course, it ought to be, and there should be no need
| for the middle-men, certainly not ones that take 2-4% of the
| transaction.
| tudelo wrote:
| Yeah but isn't that just the way of the world? Processes
| can become simpler but at a certain point the complexity of
| the process is inherent and it would benefit you to employ
| an expert (individual or entity). You can build a house
| yourself, with your own hands, but why? I'm not an expert
| on the whole domain of payment processing but it seems to
| me there is a lot of non trivial problems inherent with
| taking payments. I guess if you are hedging on a different
| system of holding and transferring money there may be a way
| to get rid of the middleman. What do you propose?
| PaulDavisThe1st wrote:
| I propose the governments require the infrastructure for
| zero-cost, instant transfers be made available to anyone,
| with open APIs. I don't care who runs the infrastructure.
|
| If you want subscriptions/recurring payments, stored
| payment methods and all the "fancy" stuff contemporary
| payment processors offer, you pay for it. If you just
| want to move money from A to B, it should be easy and it
| should be free.
|
| The only way for that to happen is for it to be socially
| provided service.
| vkou wrote:
| > I propose the governments require the infrastructure
| for zero-cost, instant transfers be made available to
| anyone, with open APIs. I don't care who runs the
| infrastructure.
|
| Will this infrastructure handle chargebacks? Fraud?
| Stolen credit cards? Forex?
|
| If yes, it can't be zero-cost.
|
| If no, it won't be usable until the middle-men build all
| of these systems on top of it.
| PaulDavisThe1st wrote:
| Check out the EU (and UK). Open the app on your phone.
| Tap in a bank ID (routing number) and an account number
| and an amount. In less than 1 second, the money is
| transferred to the specified account.
|
| Neither you (the sender) nor the recipient pay anything
| for this service.
|
| You may have noticed that banks/financial services
| companies make bucketloads of cash. Why should the cost
| of running the system always be pushed back to consumers?
| The EU/UK example points to a different direction
| entirely.
| soulofmischief wrote:
| Middle men save you the pain of surviving an audit over
| mishandling PII.
| mtmail wrote:
| Afaik that's the pricing since June at least
| https://twitter.com/GrahamJCampbell/status/12780024901858426...
| https://twitter.com/steveofmcleod/status/1277771707537780736
| ceejayoz wrote:
| Quite a few of us were grandfathered in, though.
|
| > As an early user of Stripe, you have had free access to
| Stripe's machine learning based fraud protection tools, Stripe
| Radar and Radar for Fraud Teams.
| ddevault wrote:
| As a Stripe user, it has never been smart to use recurring
| charges, or most of Stripe's other advanced, hands-off features.
| It's much, much better to just store payment source IDs and run
| charges in a cronjob. This gives you the flexibility to leave
| Stripe more easily when they make changes you don't like. Keep
| your integrations lean, dependencies are a liability.
| leoplct wrote:
| So, in the end the full pricing for a no-EU card paid with a
| subscription is 0.5% + 2.9% + 0.25$ ?
| jakemcgraw wrote:
| The expectation that Subscriptions/Billing would be free forever
| is silly. The product offering is significantly more complex than
| the base Stripe offering. Additionally, the proposed rate of 0.5%
| is 1/10th what other repeatable billing providers are charging.
|
| This is a win-win and I'll be moving my startup over to Stripe
| Billing in the near future.
| heipei wrote:
| Nobody is a fan of extra charges, but I am quite happy with
| Stripe since it's simple enough to use, by now powerful enough to
| be used even with bigger customers and for us it was the biggest
| road to being able to send out invoices to customers abroad which
| can be paid via Credit Card quickly.
|
| Look at it this way: If you're serving big customers on annual
| plans you can always include text on your invoice about how they
| can pay via SWIFT / SEPA wire transfer. Of course you're still
| eating the currency conversion and bank handling fees for
| accepting those payments.
|
| For us the pain of the 2.9% + 0.5% percent is not big enough to
| warrant even researching cheaper alternatives. If someone has hot
| tips for something that allows me to charge via Credit Card,
| accept payments in various currencies, and has an invoicing and
| subscription product built in I'm all ears!
| [deleted]
| clark_ruby wrote:
| On the other hand, this opens up space for competitors to beat
| them on price.
| adrr wrote:
| Paying for payment retries.
| ceejayoz wrote:
| Well, and hosted invoice pages, dunning emails, etc. There's
| quite a bit more to it than retrying the charge a few times.
| dabeeeenster wrote:
| We're very happy ChargeBee customers - I guess this doesn't
| affect us as we only use Stripe to store the card details -
| ChargeBee is the actual recurring billing engine.
|
| Not affiliated to CB - just a happy customer!
| merlinbeard wrote:
| Do you pay CB the listed prices, or there is significant volume
| discount?
| GordonS wrote:
| I just had a look at the pricing, and I'm a bit confused. Take
| the base plan for example, PS199/month - it doesn't mention any
| other charges, and is apparently all-inclusive; or do you have
| to pay card processing fees on top?
| corentin88 wrote:
| This is going to impact all SaaS using Stripe. Managing your
| subscriptions (recurring charges) via Stripe cost 0.5% - on top
| of the payment fees.
| legitster wrote:
| This is funny timing for us - we are currently looking at
| implementing a subscription service and were already looking at
| this price. Even so, 0.5% fee is miles away the cheapest option.
| (Most others want a fixed fee per month plus .8%).
|
| Is there reason for us to be scoffing at the new price? This is
| still a fraction even of processing the credit card.
| tschellenbach wrote:
| yes the billing product doesn't work well. ask your finance
| team what they think about it
| merlinbeard wrote:
| If you use stripe to send monthly invoices to your customers
| (even if they don't pay by card) this fees is going to apply. If
| I'm wrong someone please correct me. I'm pulling my hair over
| this change as a 5+ years old customer.
|
| (edited) typo
| gargron wrote:
| Confused because I thought Stripe Billing referred to the
| Customer Portal functionality and some advanced Stripe Checkout
| features like customer-facing promotional codes. I thought
| subscriptions were part of the core Stripe functionality. Can
| anyone clarify?
| clintonb wrote:
| https://stripe.com/billing
| hartator wrote:
| It's what I thought as well. If we knew it's gonna to cost us
| an extra .5% of revenue, we would have built our own billing
| system instead of hacking one around Stripe one.
| nathcd wrote:
| Is there any downside (other than a little more work for the
| implementer) to just using their main payment processing API, and
| to implement subscription billing with a cronjob? This is what
| sr.ht does [1], at least as of a year ago. If doing it manually
| now means saving a bunch of money, seems like a no-brainer.
|
| [1] https://cmpwn.com/@sir/103074952842876982
| driverdan wrote:
| The downside is that you have to write and maintain the code
| and infrastructure to do it. You have to do the math for your
| business to decide if those costs are lower than the 0.5% fee.
| drchiu wrote:
| We did that for a couple of SAAS. In fact, we even extracted
| this out to an internal library with a web UI. If anyone is
| interested, let me know and I'd be happy to open source it.
| It'll have to be run in its own server and process.
|
| But for full disclosure, my latest project just bit the bullet
| and accepted the extra 0.5%. Wanted to see how it goes. Could
| always switch if I found the need.
| tomsi wrote:
| We'd definitely be interested since we are currently
| evaluating our options
| wishinghand wrote:
| Isn't this backwards? Shouldn't a steady cash flow be rewarded?
| cbhl wrote:
| I would expect subscriptions to get a higher chargeback rate
| since people aren't always expecting that second or third
| charge to come through.
| ppod wrote:
| I'm mostly joking but.. didn't they hire the guy who wrote the
| really famous "charge more" post?
| smnrchrds wrote:
| patio11. They sure did hire him.
| markdown wrote:
| I bet he's behind this. Grab a pitchfork!
| MR4D wrote:
| This link doesn't match the title....at all
| edwinwee wrote:
| Edwin from Stripe here. It's worth distinguishing between
| charging money on Stripe (for which you incur payments pricing)
| and using Stripe Billing (which is a separately-paid product).
|
| Stripe Billing has had this pricing for a few years. For some
| longtime users of Subscriptions, we originally didn't change
| their pricing but are doing so now. We think charging a separate
| fee for our Billing product is fair, given comparable products in
| the market (say, Recurly or Chargebee) charge something similar.
| (Generally more!)
|
| We've been investing a ton in making Stripe Billing better. For
| example, from talking to users we learned people needed it be
| _significantly_ easier to get up and running with subscriptions.
| So in the last year we built the Customer Portal[0]. (We've also
| listened to you and improved the analytics[1].) Payments is a
| low-margin business and our customers are (quite reasonably) very
| price sensitive. So to be able to make Billing a great product,
| we realized it was going to have to charge a fee commensurate
| with the product scope.
|
| [0] https://stripe.com/docs/billing/subscriptions/customer-
| porta...
|
| [1] https://support.stripe.com/questions/billing-analytics-
| dashb...
| onassar wrote:
| Thanks for jumping in here so quick. I'm sure it'll be a tough
| thread, but something about this response rubs me the wrong
| way. It doesn't seem like it's really addressing the change
| (eg. why is it worth _existing_ customers to be paying an extra
| 0.5%? The fact that Stripe added features for new customers
| doesn't really impact those of us who have been with you for
| 5-10 years). Additionally, I don't recall getting an email
| about the price increase.
|
| I genuinely don't even know: am I going to be seeing this price
| increase? Would have liked getting an email about something
| like this, rather than finding out on HN, and now having to dig
| into things to figure out if I'm actually affected (which I
| presume I am).
|
| To give you a comparison: if my bank or credit card company
| increased their rate, I'd expect to be (and am) notified of
| that.
|
| My two cents :)
| john_minsk wrote:
| Careful. They might want to develop one more dashboard -
| showing you structure of the fees and their changes. Brace
| yourself for another 0.5% fee to pay for it
| [deleted]
| edwinwee wrote:
| Yes, you'll be emailed--if you were on the old Subscriptions
| pricing and are using Billing now, the emails are going out
| now (most have already been sent). Email me at
| edwin@stripe.com and we can also check.
| onassar wrote:
| Cool thanks
| tebbers wrote:
| I don't think this is a pricing increase? It's just their
| pricing for Stripe Billing. It's been 0.5% since at least
| 2018 which is when I started using it. I'm not sure why this
| has suddenly exploded on HN.
| onassar wrote:
| I think it's because Stripe has for a long time branded
| themselves as being priced simply. Reading that there is a
| price increase, I think, warrants a noticeable reaction,
| since it could mean a new 0.5% cost for every business
| relying on them.
|
| That can be a lot of money for some people, and in general,
| I'm a bit disappointed that I found out about the Billing
| product increase through HN. I would have expected to get
| an email from Stripe, maybe a month ago, saying "Hey: our
| rates are going up on 12 November"
| edwinwee wrote:
| The changes would absolutley not go into effect today--
| they would start next year, January 15, 2021.
| onassar wrote:
| Thanks for the clarification on the date of prices going
| up
| ihsw wrote:
| What do you say to users that have zero interest in the
| Stripe Billing product and do not want to pay for a
| product that they do not use?
| [deleted]
| Gaelan wrote:
| IIRC, Stripe used to have a "subscriptions" API at no extra
| cost. A few years ago, when they launched Billing (with the
| 0.5% fee), they moved everyone over to that but
| grandfathered in the old pricing. Now they're making
| everyone pay for it.
| TAForObvReasons wrote:
| They've been chipping away at the grandfathered accounts
| this year.
|
| What bothered me the most was earlier this year when they
| stopped refunding fees when issuing refunds. They rolled
| out a feature during the early days of the pandemic, and
| in the same week they started charging older accounts for
| refunds https://news.ycombinator.com/item?id=22371330
| dawnerd wrote:
| Is there anyone left that refunds fees? Paypal stopped
| last year and AFAIK all of the other processors also keep
| the fee.
| TAForObvReasons wrote:
| Amazon payments apparently does:
| https://pay.amazon.com/help/201212280
|
| > If a refund takes place, you will also be refunded the
| following transaction fees:
|
| > - The domestic processing fee (for example, the 2.9%
| fee)
|
| > - The cross-border processing fee (for example, the
| 3.9% fee)
|
| > Note that the Authorization fee and Disputed chargeback
| fee are non-refundable.
|
| So it looks like Amazon Payments holds onto the 30 cents
| but refunds the variable part. It's obviously not zero,
| but for a $100 domestic charge Amazon's 30 cents is much
| less than the $29.30 that Stripe pockets.
| Cieplak wrote:
| > _but for a $100 domestic charge Amazon 's 30 cents is
| much less than the $29.30 that Stripe pockets_
|
| Is this true?
| ceejayoz wrote:
| No, it'd be $3.20. 2.9% + $0.30/transaction.
| ddispaltro wrote:
| $2.90 + $0.30, you mean?
| thebean11 wrote:
| > $29.30
|
| God I hope the decimal is just in the wrong place there
| fphhotchips wrote:
| It is, but as they also added the extra 0, it indicates
| they were actually out by a factor of 10 in their math,
| it wasn't just a typo.
| _kyran wrote:
| Braintree only takes the $0.30 and refunds the
| percentage.
| loceng wrote:
| The economies of scale that Stripe is now benefitting from
| doesn't make your reasoning sit with me very well.
| texasbigdata wrote:
| Yeah I mean, maybe being larger as a financial institution
| has some costs also. Primarily that it sucks. I interviewed
| at a hedge fund that had to submit (something) to (some
| regulatory body, don't remember) because it was too
| systemically important. But they required dedicated staff to
| handle the regulatory burden. Given how tightly staffed that
| place was it was actually a meaningful portion of headcount
| measured as a percentage.
|
| Maybe some of those economies of scale are only 80% realized
| if you're a financial institution. And rightfully so.
|
| Don't have a horse in the game here re: Stripe, just hoping
| the damn kids will go on someone else's lawn.
| smabie wrote:
| How about: they're increasing the price to X because that's
| what they want to charge. They think price X will help
| maximize the long-term value of the company.
| loceng wrote:
| Sure, they can say that and be honest instead of trying to
| marinate us with these gymnastics; it's insulting too that
| they believe we can be manipulated like this.
| thatguy0900 wrote:
| I think the war on nonsensical marketing speak has long
| since been lost
| Cederfjard wrote:
| What's the manipulation? I'm not being a wiseass, I
| genuinely can't see it.
| vmception wrote:
| > Payments is a low-margin business and our customers are
| (quite reasonably) very price sensitive.
|
| Thanks for tackling a low margin business!
|
| I always look at people like they have two heads when they
| pitch something like that.
| amadeuspagel wrote:
| AWS doesn't charge anything for elastic beanstalk beyond the
| standard price for resources, even though of course competing
| products like heroku charge a lot more. I'm not arguing about
| fairness, I'm sure that's not a concern for AWS either, but if
| you have a basic product with solid margins, doesn't it make
| sense to account something you build on top of that product as
| marketing or documentation, rather then as a distinct product
| that has to pay for itself?
| pixiemaster wrote:
| Well, if you start comparing yourselves to chargebee, they have
| a far more complex product - and really impressive traction in
| terms of new features being released regularly - combined with
| a really super support. I have not even seen a single company
| that deliver on the same level as chargebee does.
| jb775 wrote:
| At the end of the day, you're using electricity to send around
| a bunch of 1's and 0's. The amount of electricity used doesn't
| change much whether it represents $10 or $100,000...so why do
| you need a _percentage_ of the total?
|
| I understand existing banking structures already work on the
| _percentage_ model (so there 's probably downstream percentage-
| based charges Stripe must pay), but why can't this entire
| banking structure be disrupted to transfer that value back to
| society?
| fastball wrote:
| Recurly and Chargebee both provide helpful things like multi-
| currency support, which AFAIK Stripe Billing does not.
|
| At least this was true last time I looked into this.
| weego wrote:
| _We think charging a separate fee for our Billing product is
| fair, given comparable products in the market (say, Recurly or
| Chargebee) charge something similar._
|
| Copying what other people in the market are doing is the
| antithesis of what made Stripe so important when it first
| launched.
| toomuchtodo wrote:
| Processing margins are thin and they have a valuation ($36B)
| to justify, so they have to grow product margins where they
| can ("going upmarket"). Market realities/constraints.
| Silhouette wrote:
| That only works if you have a number greater than zero to
| multiply your margin by, though. Stripe is already
| relatively expensive among the payment processing options
| we have available. In the early years, that premium was
| justified for us because Stripe was also much easier to set
| up than anyone else at the time. But that was nearly a
| decade ago. Today, there is far more competition from other
| payment processors, while the experience of using Stripe as
| a merchant is far worse. I'm assuming that they've simply
| decided to focus their business on the larger merchants who
| are obviously worth much more to them individually, but
| those merchants surely have negotiated rates below headline
| and won't be paying an extra 0.5% for this either, so it's
| a puzzling move.
| floatingatoll wrote:
| To clarify, is "Stripe Subscriptions" a subset-of/component-
| of/deprecated-into "Stripe Billing"?
| edwinwee wrote:
| Correct -- Subscriptions was the really old one. Two years
| ago Billing was rolled out as Stripe's separate product for
| recurring charges and invoice management
| (https://stripe.com/billing).
| floatingatoll wrote:
| Thanks, appreciated. I notice that the post title has been
| updated to clarify that as well (wasn't me, but glad
| someone did!).
|
| Mod thread on title change here:
| https://news.ycombinator.com/item?id=25073970
| mentos wrote:
| Awesome, I setup subscriptions using Stripe for a website a few
| months ago for the first time and was so turned off by how
| convoluted the process was I was actually thinking about
| emailing Stripe to suggest they take a hard look at the process
| and how to make it easier. Glad to see that was already
| underway, great work!
| eigthbits wrote:
| I've had to run a number of price changes (mostly increases)
| over the years. In case the folks with pitchforks are unclear,
| your mistake was not clearly communicating to your customers.
| Every impacted customer should have received an email that
| explained the change, how much their bill would increase, and a
| timeline for the increase that would give them a few months of
| runway make other plans.
| jb775 wrote:
| However you sugarcoat this, it's essentially shifting long term
| wealth away from your customers and into your pocket. People
| aren't stupid.
|
| Hopefully this triggers more competition.
| tomsi wrote:
| I'm pretty disappointed by that move from Stripe as well to be
| honest. When we signed up long time ago we were not aware that
| the basic functionality of subscriptions was offered for free
| only temporarily. We use the stripe backend only to create and
| cancel subscriptions, that's it. Now we have to pay a couple of
| grand a year to do this or hire a developer.
|
| I think a much better move would have been to add a new billing
| plan for the few new features that have been added, but leave
| people with the basic functionality that they grew used to.
|
| And c'mon, narrow margins my ass. We are not talking about a
| small startup here, we are talking about Stripe, a billion dollar
| company! They should be able to afford having a developer or two
| working on those long neglected features and not compare
| themselves with chargebee. It's just sad.
___________________________________________________________________
(page generated 2020-11-12 23:02 UTC)