Hacker News new | ask | show | jobs
by Alupis 2051 days ago
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.

4 comments

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.

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

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.

You don't have to use Checkout for Stripe's fraud detection, which supports several types of integrations: https://stripe.com/docs/radar/checklist.
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.

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.
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.
This often happens when companies make a good product and then let salespeople entirely take over the customer facing culture.
How much volume are you doing? That's been the biggest lever I've seen when it comes to Stripe reducing rates
Did you end up staying with your current processor or swiping to Stripe?
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.