Never mind PayPal, they're more expensive than the commodity players in the UK, like SagePay.
Stripe's strategy is all about developer-led adoption, and their approach to their tech belies this. Unfortunately, in reality, developers have as much say as to which PSP their client uses as the cabin boy does what course the captain should sail.
I run an eCommerce firm - we've mooted stripe to all of our customers, as we like the look of their approach - but none will adopt, purely on the basis of cost.
For stripe to be more expensive than Paypal I'd need to bill 15,000 a month.
That is a nice problem to have (and in fairness it's a .5% different or about about 75 quid).
On 15,000 billable I'll take a 300 a month hit to never have to deal with PayPal again.
Broken sandbox, flaky API, customer service reps from the Hannibal Lecter school of customer service, payment frozen, ridiculous demands on holding cash and proving you are who you say you are, high pressure sales.
Screw PayPal, I'll drive to my customer and take cash before I use them again.
I've actually had a different experience where clients are now requesting Stripe. My situation is unique in that across various sites clients got to experience PayPal, Braintree and Stripe. Due to a range of reasons with the flow of PayPal subscriptions to the phone nature and fee structure on Braintree (they might have simplified it now), Stripe is turning out to be the favorite even with the 7 day transfers.
There are also cases where developers do have some say, especially since many clients don't even care as long as they can accept payments--the fee is more or less on par. It's a favorite for me because when you look at Stripe.js + the API you can tell it was developed for use by other developers and not as an after thought.
Aye - our clients tend to be of the bigger, more established ilk, and as a result tend to either bring whatever odd solution they've selected along to the party. Regularly find ourselves integrating with Barclays and HSBC's Arcot-driven house of horrors, even though we'd never, ever, ever recommend either of them under any circumstances.
We have a few clients who are smaller, and therefore more willing to listen to recommendations and suggestions, but the big guys just steamroll on with whatever the advertorial in the trade journal told them to do this month. Very hard to convince a 40 year veteran FD that you know more about payment solutions than him.
Hmmm. Shameless self plug here but you sound like some Spreedly customers' we have. Your developers just work with our API's to avoid the arcane payment gateway API's but your customer doesn't have to change their processor/gateway relationship.
If you're doing typical e-commerce -- as opposed to, say, SaaS -- the cost of payment processing seems especially important, since it might eat into your (typically low) margins. Why would you recommend Stripe over an established, cheaper processor?
Reliability and redundancy. We always recommend that each client has at least two PSPs enabled, with PayPal typically as the fallback/secondary. SagePay have a long and sad history of "we broke it", which is only just made up for by their low costs. You lose way more margin being unable to transact than you do on processing fees.
For what it's worth, a lot of our bigger users (from MoMA to Walmart) ended up using Stripe because their developers successfully pushed it internally.
Could you drop me a line? patrick@stripe.com. I have an idea I'd be curious to hear your thoughts on.
Stripe's strategy is all about developer-led adoption, and their approach to their tech belies this. Unfortunately, in reality, developers have as much say as to which PSP their client uses as the cabin boy does what course the captain should sail.
I run an eCommerce firm - we've mooted stripe to all of our customers, as we like the look of their approach - but none will adopt, purely on the basis of cost.