This author understands that PayPal offers this service, but does not explain why, despite seemingly being positive about their past experiences with PayPal, they opted for Stripe instead; the factors they actually considered would have been very interesting: without it the article lacks.
I am also curious why their list of alternatives was so short... no Chase Paymentech? no Litle & Co? There are numerous players in this space that handle large clients, not just the three being compared here. The article only states that they did research, and ended up with that list. :(
Not to mention, once you have some monthly transaction volume going, both PayPal and a good merchant account are cheaper than Stripe. It's easy to get a bad merchant account where the fees are opaque and creep up on you monthly, but good ones (especially interchange-plus pricing where you always know you're paying a fixed amount over cost) are attainable for even the smallest business.
Stripe's API sure is spiffy (they're on my short list of backup payment services), but not that different than, say, Authorize.net which would be a cheap gateway option for most merchant accounts. Making a charge, refund or storing a credit card number in their secure vault offering are all a matter of a simple HTTP POST of a couple XML fields. That's not anything new, their API and others have been around for years and years.
hi - I decided not to post the entire list in that bulleted list because it would be too long but I can assure you I did look into a lot of providers including Chase - I plan to post about all of that in another post hopefully next week. Thanks for reading the post and giving me your feedback.
I think one of the big factors in going with Stripe over PP Payments Pro was the strong technical side that Stripe offers.
Interestingly, that is the reason I would go with PayPal over Stripe. Stripe's API is touted as "awesome", but I see no way to automatically reconcile chargebacks (the word "chargeback" isn't even present in their API documentation), and their "webhooks" feature is explicitly missing the critical functionality of "retry if the server failed the response" (making it totally useless to rely on: you are going to have to drop to polling to trust your data). I would thereby additionally be very curious to know what technical factors you found lacking with PayPal in relation to Stripe.
Is there a traditional merchant account provider that has an API for chargebacks? I've actually never come across that anywhere but PayPal; maybe it's more common with 3rd party providers since they already need to connect chargebacks with their online service just to attribute the fees to the right user.
The other service I have been looking a lot at recently is Litle & Co, which has even better chargeback support than PayPal: they offer the ability to not just reconcile but fully automatically respond to chargebacks, complete with APIs for uploading documentation such as shipping invoices.
I do not know if you (or anyone) would count them as a "traditional merchant account provider", however (or if they are really a "merchant account provider" at all; I will be honest and say I'm still behind on some of these terms).
(Also, for completeness: Amazon Flexible Payments, in a similar boat to PayPal and thereby falling under the same "already need" reason you list, also has good mechanisms for automatic chargeback reconciliation and reporting.)
The payments space gets confusing. There are gateway providers that serve merchants yet process payments through an underlying provider. At the end of the day there are multiple types of companies which can serve your needs.
I am bias since I work at Litle & Co. My team implemented the chargeback upload API years back, it's great to see it catching on.
Litle has some neat features including a JavaScript API for tokenization that we call Pay Page.
I won't go on self promoting, however I can answer questions if you have them. I follow hacker news because of my personal interest in software development.
Really quickly, this guy has clearly not researched the field. We (I do contract work for a large e-commerce business that does 8 figures USD a month and have a side recurring saas company that will do 5 figures a month in Jan). We looked at Litle, Braintree, Stripe, and Samurai. We quickly eliminated Stripe because it's expensive and then had an RFP for the other guys. For my contract job, Samurai ended up winning out over Litle and Braintree (Ended up being between Litle and Samurai in the end). I can't recommend the FeeFighters guys highly enough... I worked with them on my contract gig and ended up using them for my side project too. They have a fantastic API - http://samurai.feefighters.com/developers and were just great to work with. For my contract job (big bureaucratic company) we just tokenized ~a million credit cards with them and have shifted about half of our transactions that way.
Stripe is way better than paypal. It is also really expensive. Unless you are a hobby website, I wouldn't give it much thought, except for something to grow up out of. For real businesses, I think the flexibility afforded by a real merchant account plus gateway (Braintree, Litle, or Samurai) is worth a lot.
Did the Samurai API have much weight in the decision making process? I understand if you can't share details here publically. I work for Litle and we are always interested in feedback we can use to improve our offerings.
agree, I'm extremely skeptical to have two pro stripe articles.. and this one claiming that users don't understand paypal or google wallets. I mean who really cares if they switch to Braintree, Stripe, or some other service, what really matters if the conversions of users entering their credit card vs users using Google wallet and paypal. I feel like Stripe's marketing team is at work here.
I can assure you that my post has nothing to do with Stripe, their marketing team or anything else.
And frankly my post has a lot more to do with the order flow than Stripe because you could insert Braintree or a regular payment provider in the place of Stripe and the post still holds.
I just went to the CloudContacts order page and seeing that I type my credit card info straight on that page scared me. I'm pretty sure it's because I'm an engineer but even if it said "Powered by Stripe", I'd still be suspicious...
I was really hoping I wouldn't react that way because I like what Stripe is doing.
I agree, and that's where I start looking for the PayPal button.
It doesn't have to be one payment processor or the other -- many major ecommerce retailers, and you, too! can have a credit card form on site and a PayPal button on the page to skip it.
I offer it on all my sites and >50% choose PayPal, both for one-off payments and subscriptions.
The striking realization for me with regards to PayPal usage (and how both reasonable it is to provide the option, as well as how many people must actually prefer to use it) was the day I noticed that Apple, a company that often is described as having the valuable asset "millions of customer's credit card details on file, ready for one-click purchase of anything on their Mac or iPhone", actually supports PayPal as a payment option in their iTunes suite.
Note that for an international business, PayPal has the invaluable benefit of supporting a huge bunch of national payment methods - in many countries, these are more widespread than credit cards, so if you want to do business with normal people there (like Apple), you have to support these methods.
We tested exactly this. Our conversion rate was appreciably higher when keeping users on the page (using the Braintree Vault) when compared with Paypal or Google.
It seems to me that users have already decided to trust us at the point of putting in credit card information, and sending them off-site required them to rethink it.
I'd love more input here - the page is SSL - I purposely don't want to put "powered by stripe" on the page - so far the only one I have seen doing this (i did ask) is Kickstarter. If you have ideas on how to overcome your concern, I would totally love to hear it - thanks!
"Powered by Stripe" doesn't help; I mean, in the end, you are "powered by Visa", and if you are using a Visa card, you hopefully trust Visa. Instead, the question is whether we trust your website to handle the credit card data in a sane and safe manner before it is ever sent to these backend providers.
Specifically, we do not know whether the credit card ends up on your server (possibly stored poorly), and just knowing you use Stripe (which allows for that not to happen) doesn't guarantee that your server has the requisite security required to not have been modified to send the things we enter to a third party.
(That said, I will say that I am not actually the kind of person who fears using my credit card online, so I may be simulating this argument train incorrectly; these thoughts go through my head, but my reasons for often using PayPal when provided the option have more to do with liking the kinds of reporting I can easily do using their APIs.)
Aah - I need to add the line that we do not store your credit card info to the order form - thanks for that! It's on the thank you page but you are right - I could add it to the form.
One thing I absolutely wanted in our new system was that we were never going to store the cc# - that's one of the reasons I liked Paypal/GC because we never stored the cc number. I read something about a wine store being hacked and the hackers getting all of the credit card numbers recently.
One of my points, however, is that I have to take your word on that, and even if I know that you are using Stripe, I have to trust that your webserver wasn't compromised and is now running a few lines of "extra" JavaScript that also skim my credit card to a third party site.
(Honestly, and I realize this is a stupid bias on my part, I'd trust your site more if the labels on the text boxes lined up with text boxes. I think it is fair to say, however, that a lot of people have silly biases like that, as a lot of time you are just fighting with some gut feeling someone is getting about your site as they are about to convert, and not any appeal to rational argument.)
(Again, though: I am actually the kind of person who tends to just use their credit card willy nilly. I, personally, would have no serious problem signing up for your site as is. However, if you had PayPal as a payment option, I'd use it, and in the end it could actually save you money. If you had Amazon Flexible Payments as a payment option I'd definitely use it, and it would almost certainly save you money.)
Don't think it's a CloudContacts problem, but rather just any service that doesn't send you off to Google, PayPal or Amazon to fill out your credit card.
Obviously. That said, it is also a trust to specific site problem: I might trust Apple, but not trust Flowroute. Honestly, many people might trust a website that looks "corporate", and not one that looks "Web 2.0", or trust websites that use blue on white, but not ones that uses yellow on black. Having PayPal (or an alternative, such as Amazon Flexible Payments, which is epic in many ways, although lacking in international support) as a fallback option is great as anyone who doesn't trust your website has a fallback option.
I'm guessing that the numbers would improve if we weren't using PayPal, so next week I'm planning to try to use Stripe.
However, I am sad to say, for making payments I am still stuck with PayPal for awhile, as I can not see anything else that is so easy. On any given day my website gets something like $70 and pays out something like $50. Right now I've a cron job that runs once a night and which pays everyone who is owed money from my PayPal account. But the payments are usually small. On a normal night, at 3 AM EST, my PayPal account makes payments that might look like this:
$24
$14
$12
$9
$7
$7
$5
$4
$4
$3
$3
$3
$2
$2
$2
$2
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
$1
I use the PayPal MassPay API. I've looked into other services for sending payments, such as Payoneer, but none have such wide acceptance as PayPal.
Any suggestions for sending automated payments, other than PayPal?
I think when you are paying OUT, it's important to think about your payees. Are your payees wanting to use something else? For these small amounts, they may want paypal and that could be one of the reasons they use you.
I have an affiliate relationship setup with one company - and make about $50 a month or so - they pay via paypal and that is perfect. I am not sure I would want to bother with it if they required me to setup a new account with some other program.
"Check Out" is an old standard users will be familiar with, and "Place Order" or "Submit" is usually acceptable for the actual click that submits the order.
OK, I'm pretty sure this is an FAQ but not getting a sensible result from google: Does anyone have a pointer to a table of processing fees for the major providers?
If your competitor sells $1 eBooks using Stripe, there's an easy way to move him out of business: buy 10'000, then ask for a chargeback on each of them.
Chargebacks are expensive because it's an extremely manual process, especially representments - $15 is not outrageous. Many issuers will simply not charge back small amounts because it's not worth it. If you want to commit fraud, just buy small amounts at Starbucks on a prepaid card with no balance - they generally don't auth (to give that smooth consumer experience) and will not charge back when their forced post comes in because it's not worth it for them.
You may want to also consider SaaSy.com:
- All-inclusive – hardly any development work needed - More functionality - GUI-based for the most part - Global tax/VAT management - Works with vendors in most any country - 10 currencies - 20 languages - Best customer service experience of your life
