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?
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.
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.
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.
We do not make use of any automated billing/subscription features, so what works for us isn't necessarily what will work for you.
I believe they've changed the name now, but we're using what used to be call PayPal Payments Pro, which is just a processor (customers stay on your checkout page, you build the checkout form, no PayPal account necessary for the customer, etc). We were using CyberSource when PayPal approached us for negotiations - they ultimately made an offer we couldn't refuse (based on volume) and made the switch. This CC Processor product from PayPal has none of the baggage or horror stories you hear from people using PayPal Express Checkout - it's almost like you're dealing with a completely different company.
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.
"hosted fields" are really just a fancy CC # widget (with postal code and exp built-in, when appropriate). If you use them, the annual PCI attestation becomes a checkbox instead of a giant form.
actually hosted fields isn't an iframe but replacing the cc detail fields with stripe fields and adding some javascript which tokenizes the cc details so you never see them
You don't have to use "hosted fields", but it does mean you have significantly increased requirements regarding PCI compliance (SAQ D vs the much simpler SAQ A, for example).
Not necessarily true. It depends how your site is setup.
Users of eCommerce platforms generally will be SAQ-A since they are not the ones controlling the system which handles CHD. This covers platforms like Shopify, BigCommerce, 3dCart, Volusion, etc, where the platform itself must be PCI compliant on their own, separate from whatever PCI level you are compliant with.
If you self-host, such as Magento, XenCart or some custom implementation - then yes you will be SAQ-D.
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.
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.
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.
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?
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.
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.
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"
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
>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.
I think trust in your providers treating you well is required for low-touch SaaS sales for key infrastructure to work well. If you don't trust your counterparties, then you get long contract negotiations and minimum viable contract sizes balloon, as many potential buyers just won't be willing to be dependent on your company without assurances.
Exactly. Certain SAAS companies (cough Datadog cough) seem to have very old school sales processes in place. I don't love the larger cloud providers, but at least they lay out their standard prices, supply a price calculator, and I can figure out if I want to use them without hearing someone tell me they'll have to "clear it with their director".
I imagine anytime someone says the have to "clear it with their director", you're talking about discounted or private pricing not the list pricing they have on their website. Every SaaS company has that, including the cloud providers.
Well yes, one wouldn't be talking to them in the first place if it were on the website. For many companies though "Enterprise" plans are always non-website prices, so there's nothing special about negotiating them, and the salespeople pretty much always are just saying that stuff to have a chance to go away, recalculate their monthly commission chances and figure out the price to try with you rather than actually seeking permission.
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.
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.
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
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.
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.
> 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.
> 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.
It's your fault if you chose lockin. If you don't want to talk about fault, fine, but then don't go on to talk about fault :)
Most people don't choose lock-in. They choose a provider that works for them on the budget and timeline that they have, and they build on that. Expanding to multiple providers isn't always feasible depending on a company's business model and financial state - it takes time and development resources to do so, which can both be very sparse for company with tight profit margins.
You have to start somewhere. Unless you have been handed a substantial amount of starting money and baked "we need to be provider agnostic" into your company beliefs from the beginning, it's rarely an early priority. Becoming profitable is usually what comes first. Securing a stronger foundation for your platform comes over time.
> If you don't want to talk about fault, fine, but then don't go on to talk about fault :)
Yeah, I know. What I'm saying is taking the seemingly low-hanging fruit of locked in technologies is a conscious decision to be competitive. It has very obvious pros and cons. The cons potentially materialising is part of the choice.
> What is the point of saying this?
Whatever criteria you used to justify asking this question probably also apply to it.
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.
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...
> You're not a hostage. You're deeply integrated through nobody's fault but your own.
Exactly this. We started being Stripe customers after they bought some third party several years ago. While Stripe maintained the deal it was good for our business but recently they decided to end the deal we had (I don't blame them, it was a very sweet deal for us). Fortunately my startup always have had more than one provider and now we can calculate a "least cost routing" process, which will definitely move a lot of our volume outside of Stripe.
But it is just that, business. You should not trust any one provider with your business, not even AWS (i.e. not even at that level).
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.
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.
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.
> 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.
We wanted to move ~300 credit card details from SagePay to Stripe. SagePay had a minimum admin fee of 2000GBP in order to do this, and no amount of negotiation could shift it.
If anyone's had a better deal from SagePay - let me know.
This is fantastic thank you; I thought our customer card data was effectively held hostage in Stripe so the only way to move customers to a new system was to wait until their credit cards expired and were updated.
We're planning to migrate away from Stripe after this latest in a line of price increases.
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.
Wouldn't help with credit cards. Plus I'd guess the idea is that you want to have some friction between you and the thousand companies that you have a transaction with in a year.
Anyone else at scale and have an old integration? How are you handling the fee increase?