You can search HN and find this question many times.
My 2 cents, I don't trust any company owned by Paypal as Paypal has a very strange, aggressive and non-transparent and inflexible process to holding funds from businesses, charities etc (even after providing all the extra "evidence" they ask for).
Stripe has a lot of advantages, API being a huge one. I have heard of a few people that complain about delays in responses from them, but at least for me I have never had that. In fairness too, 99% of the time the answers I have needed are in their documentation.
If I were you, no matter who you choose to integrate, I'd encapsulate it behind your own payment "service" so that even if you have to switch or you need to add more then one (highly recommended), then you can. Some will argue this is overkill, but I have done a lot of payment integrations, with specific banks, First Data and Stripe, Paypal etc. Having it encapsulated means a little more design but a lot less breakage and lets you minimize risk if a vendor decides to shut you down or freeze funds etc.
IMO if you are accepting payments you should already have encapsulated your payment vendor, as a real risk to business continuity exists if they decide to freeze your ability to charge or like Paypal freeze funds during charge back windows etc.
"If I were you, no matter who you choose to integrate, I'd encapsulate it behind your own payment "service" so that even if you have to switch or you need to add more then one (highly recommended), then you can."
This is the best advice in the comments. I've seen my own code and others become overly coupled to a specific provider's terminology, mechanisms, and expectations - leading it to be exceptionally painful when you inevitably have to migrate away to a new provider (or support more than one).
For those in the ruby/rails world, there's a gem which does this (make it easy to switch between payment vendors) for you: Active Merchant (http://activemerchant.org/).
Dumb question, wouldn't rolling a wrapper over existing payment service also require me to store credit cards myself somewhere so I can easily switch integration later? If so, isn't that risky.
It is not unacceptable to ask for updated payment details every so often, so users don't generally have issues with this and it saves you from having to store the actual card details. You just have to store the token as others pointed out.
Also, if you do integrate multiple providers early on, you can break users up over them so that again your risk is minimized. This does come with some accounting pain, but it mitigates some risk so it is worth it. So essentially if you had to move away from one vendor it isn't your entire customer base all at once.
gentle plug - spreedly is a service that handles this for you. one of the guys in our coworking space uses this for his service, and it allows his customers to be able to swap processors relatively easily, as spreedly acts as a middle-man secure vault to hold that info away from any one particular service.
there may be other services that do something similar, but if you're concerned about switching services, and don't want to have all your customers reinput billing info, spreedly (or similar) would probably be worth investigating.
Or... you need to support multiple, and they might change?
They support something like 90+ gateways around the world. Not everyone will necessarily need that flexibility.
But on the topic of switching....
How much is it worth to you to be able to switch without losing any recurring revenue? If you're OK with a potentially large portion of your recurring billing going away because you want or need to switch gateways, DIY is fine.
Again, not a direct user (though I've tested their API for a project), but I have colleagues using it, and for one in particular, the value it brings both in breadth of processors and potential for switching is extremely valuable to him (and his clients).
You can switch providers in a over time fashion by sending all new people to a new provider, and maybe sending out an "update your details" to existing people. If any existing users take action, move them over. If not keep billing on the old platform.
How often do you honestly need to switch gateways though? Most companies do it 0-1 times in the first 10 years of business I would expect.
No, not at all, as long as you aren't afraid to ask for someone's credit card again. You should also be able to transfer credit card information between services (which usually takes weeks and costs thousands, though).
As other said it's usually not a problem to ask again for the credit card, and when you switch payment services the users might actually see different details in their bank transactions, get billed with different delays or otherwise have billing problems.
Having a transition step where the users know something is changing can be helpful to cover the edge cases.
Generally, payment processors give you a token once a client gives them a credit card. You just need to abstract away the processor-specific code that uses that token.
If you do a capture for say recurring monthly charges, not sure you can (legally and easily) capture card numbers to easily switch down the road? For one off charges it is easy to switch, but not for recurring, which is where I think these platforms "get you" by being sticky.
I currently work at a medium sized startup which processes ~100 million dollars / year. We offer both Stripe and PayPal.
The vast majority of our users prefer PayPal (80%+). For one particular product we had to roll out using Stripe only, the number one customer service request we had was to provide PayPal as an option. Subscription numbers rose by over 50% overnight when including it as a choice (literally tens of thousands of people signed up after the change).
Internationally, PayPal seems like the de facto choice for making online purchases. In addition, outside of the Bay Area tech bubble, I believe people in the states are simply more comfortable with using PayPal over Stripe.
While PayPal gets a lot of hate, I'd think long and hard before deciding not to offer it as a payment processor. It's possible that you're leaving a significant amount of money on the table.
I am interested in this, I participated in some tests on a few ecommerce sites in the past and it seemed to not make much of a difference, except for very new b2c apparel type companies that had no name recognition with consumers. In those cases Paypal did help some, but honestly branding, messaging and other things mattered just as much if not more. The sample act of having a prominently placed phone number on the site we found would lift sales, having a real address not a PO Box etc, would lift sales etc. Consumers feel better if they can find you and talk to you other then via just email. This also changes demographically too as we found.
You mentioned subscriptions, so I am assuming this is some type of B2C app or B2C service? Can you say what industry and what it is? e.g. Service, App, or ? And what is the typical transaction amount? This all likely is a factor too.
Also, you mentioned users preferring Paypal over Stripe, in 90% of our cases it was Paypal or the "business", clients never knew the business was using Stripe or First Data etc. Never tested that part on consumers decision process though, e.g. Stripe checkout vs Paypal checkout.
Interesting observations, thanks. We've been wondering about a similar thing for a small business we run that uses Stripe and sometimes gets requests from potential customers about PayPal.
My biggest concern with the latter is that if you want a vault+token system to avoid the serious PCI DSS hassles, PayPal seems to keep changing its mind about what the different options are: every time I've looked for quite a few years now, it seems like there are always several different things that each do (a different) 50-75% of what we're looking for, without any way to get the degree of control you have with some of the other services.
It's not like we have weird, exotic requirements, but we do want the flexibility to do things like moving a customer from one plan to another if they upgrade/downgrade, or reducing their payments temporarily or permanently as a result of a promotional offer, without them having to effectively sign up again with the payment service every time. Do you have any related issues with your startup, and if so, would you mind saying a bit about how you handled them with the different payment services you use?
I think the best thing to do with PayPal if you're doing an ongoing subscription with different plan levels or addons, is to use Pre-Approved Payments. This basically allows you to get a PayPal token which you can use like a Stripe token -- that is, you can tell PayPal "here's this token, I need to charge it $4.99" and they will do so anytime you ask.
As you might expect, they watch companies using this type of API very closely so obviously don't use abuse it. But we've been using it from around a year now with Roll20 an d have had great success with it. It allows our customers to link their PayPal account to their Roll20 account one time, and then buy subscriptions or digital one-off content without needing to log into PayPal again or anything like that, just as if they had a stored credit card on file with our Stripe integration.
The benefit from the consumer side is that you can log into your PayPal account at any time, and see exactly when and how much you've been charged over the life of the relationship, plus end the relationship on the PayPal side with one click. So it's really a win-win I think.
Note that we also do offer using a regular PayPal checkout flow for one-off content if you're not a subscriber, but as soon as someone wants to get on a subscription plan we have them do the pre-approved payments agreement with us.
At face value Stripe's API is about a billion times better (at least it was a year ago when I looked into using both).
I ultimately went with Stripe because I couldn't stand Braintree's API. So even with getting $50,000 at 0% revenue sharing and having PayPal support I still went with Stripe.
My condition was a bit different than yours tho. Most of my market had credit cards and it was an expensive item ($200). Part of PayPal's value is it's great for impulse purchases, so for an e-commerce site I recommend you integrate with them just because it will provide you more revenue in the end.
Totally agree with this. Braintree will save you a little money but their documentation is horrible; some of the worst I've ever seen. Their email tech support can be responsive and somewhat good but I feel like I have to email them about every little thing cause I can't find the answer in their disconnected documentation.
Also Braintree's registration process was crazy when it came time to move past their sandbox and accept real payments.
They wanted so much personal information including my full social security # (not just the last 4), copy of my driver's license and a copy of a recent utility bill.
Then on top of that I got questioned because I don't have any credit (I purposely made a life choice not to use credit cards), so they demanded 3 months of my most recent bank statements.
It took days of this, combined with struggling with their documentation until I just gave up and went with Stripe. Never looked back since.
Stripe's registration process was painless and automated. They also requested the bare minimum to accept payments directly to my bank account. It was a flawless experience.
Then on top of that I got questioned because I don't have any credit (I purposely made a life choice not to use credit cards), so they demanded 3 months of my most recent bank statements.
That's not Braintree's fault. In fact, that's them being sensible. The problem is that having no credit records makes you harder to tell apart from a fraudulent user.
Yeah but Stripe just asked me for my bank account number and last 4 digits of my social.
There was no background check and having to send over copies of various bills, statements, license, etc..
I felt like Stripe requested the least amount of info to legally accept payments where as Braintree requested a million things to build up some type of profile that they'll benefit from later.
You know, it's like the guy who sends you to a form where you need to fill out 4 pages of crap when in reality all he needs is your name to perform the service you're requesting.
Ultimately they're both going to want the same information. If you had started processing more than, say, $10K per day, Stripe would freeze your account and demand the same information. The difference being that Braintree wanted that information upfront and without the stress of frozen funds at risk.
I can't speak from experience but I doubt Stripe would just freeze everything and demand my full social security number instead of the last 4 they requested.
If they ask for bank statements and other pieces of info, that's fine. The user experience is just better with Stripe because they know 99.999999% of people won't be doing 10k+/day.
Actually, they do run a form of background checks on you. It's a process called KYC. Both payment vendors have to get a certain amount of information before allowing you to process. Stripe has made it much easier however. I don't think either company is collecting your personal information for anything other that underwriting and would ask for less if they could.
The only thing I will add about braintree vs stripe is that they are both aggregators that aggressively underwrite using algorithms. This means they are taking the risks upfront without full due diligence and then when any unexpected activity occurs (high ticket or high volume), your funds can be potentially held for a long time.
Other credit card processing companies may not be able to get you signed up in 5 minutes, but they follow a more traditional process of validating your business and documentation that gives you a more robust foundation for running transactions without problems.
Both of the vendors above however have extremely user friendly documentation and platforms and fast onboarding times. I would recommend them for startups.
Disclosure, I work for Fattmerchant, a fintech startup / payment processor.
Do you need to be able to manually bill? (i.e. for Enterprise and contract managed sales rather than self-serve... the difference being: invoicing, purchase orders)
Is this all subscription stuff, or are you doing one-off?
Does your market care about PayPal or is it all credit card?
You could probably boil it down to: If you care about PayPal then go Braintree, otherwise go Stripe.
But it's not as easy as that, something one can only learn through experience is which gateway will bill more transactions for exactly the same users and subscriptions? And yes, there will be a difference as banks treat different requestors differently, having different fraud profiles, etc.
It's so incredibly complex a question, that it needs vastly more information to answer.
But if you're early days, and cannot answer the questions fully, then just decide whether you think you care about PayPal and if not go Stripe to simplify everything.
Oh, and whatever you do... abstract away the payments and subscription stuff. Everyone changes their payments provider at some point, just put it all in one neat place so you can reduce the footprint of it for the time being.
HN is very US centric, but if you have plans for wide EU coverage for instance they can both pose challenges. When I looked recently Stripe was moving at a far more aggressive pace to comprehensive coverage in the region.
Neither have very good Asian/South American coverage.
However, with Braintree's Paypal integration it makes the above point moot (to a certain extent anyway).
I've used Braintree for about a year in a mid-sized ecommerce situation. Not a single complaint to be had. I find the API very easy to work with, and the support to be very responsive. They have a nice drop-in payment form with built-in support for PayPal.
On the surface level, Stripe seems to offer more in the way of open source and integrations (POS, Analytics, etc..https://stripe.com/docs/integrations)
I tried both, starting with Braintree. Even signing the contract was an issue with Braintree. I eventually went with Stripe, immediately when they launched their beta in France. The onboarding process was straightforward. The API, the documentation and the dashboard are great. I would choose Stripe again without any hesitation.
As a business, we've used PayPal since it's inception and Braintree as of last year. Both have been amazing experiences for us (Except for PayPal.com usabliity....ugh). Braintree, in particular, doesn't feel like a PayPal company. Good API documentation, support and website usability.
We've never experienced any of the pains that I've read about PayPal. But, perhaps, it's due to our long-standing relationship.
I interpreted your last sentence as: "We've never had any problems with the Don, but that's because we've known him longer. Maybe you should make an effort to show him a little throat and he'll be nice to you."
I personally wouldn't trust PayPal for anything more than running a kids lemonade stand - there are far too many horror stories.
There are plenty, but PayPal is a huge business with many customers. It's difficult to know how often bad things really happen with PayPal compared to other services, because probably the vast majority of their customers in each case just get things done and never comment publicly on it.
It's also difficult to know how many of the horror stories really are horror stories, and how many are just someone upset that their terms were changed on reasonable grounds because of greater volumes or fraud risk or whatever. I've seen plenty of small merchants irate about a certain amount of their funds being held back as they started to trade more, but while some of the payment services do seem to be better at communicating these things and the reasons for them to their merchants, it seems likely that all of the payment services would have made similar decisions under similar circumstances.
This potentially distorted perception is a PR problem for all major payment services. Today Stripe still gets a warm reception on HN most of the time, but there's definitely an element of nostalgia and/or gratitude in that, and half a minute of searching will find you plenty of small merchants on other forums who describe their experience with Stripe in the same four-letter terms as others describe PayPal.
In Hong Kong Braintree made it so incredibly difficult to get an account started that we ended up abandoning it. When Stripe finally opened up their HK beta I tried again and the process to get approved took all of 3 minutes.
We use pin.net.au for https://meanpath.com as the hosted payment pages they offer allow us to capture payment without needing to do any advanced programming. Their fraud protection is impressive and blocks 90% of the payment attempts we get from people dipping stolen cards.
For https://www.betterteam.com we chose Stripe as our developers are more familiar with the API. Braintree do have some features Stripe does not but the documentation of their API is not as straightforward as Stripe.
Stripe's documentation and API design are both the gold standards in my mind. Braintree is good as well, but they fall just a little short of Stripe in almost all categories.
The most notable shortcoming for me has been Braintree's testing/sandbox environment. They require different dollar values in order to trigger certain payment processor errors, and a payment won't fail in their sandbox environment if you use a bogus nonce. This behavior alone caused me to mistakenly ship a placeholder nonce to production, and it took us a while to figure out what was going wrong in production since all purchases worked perfectly in the sandbox.
tl;dr Braintree has burned me, and Stripe has not.
I just started using stripe and could not imagine an easier payment platform. I've used paypal and amazon in the past, and this was an eye-opening experience from ease of implementation alone. Customer support people are quick and knowledgable.
The biggest issue with Stripe is that it does not handle 3D-secure requests [1] which protects you against various frauds. Hopefully, they are starting to implement it for UE, US and also there are many FinTech SaaSes whose uses machine learning to help you improve protection.
Hey there, I work at Stripe. We're working to roll out 3D Secure, and it's in private beta right now for European, U.S., Canadian and Australian accounts. If you're interested, send me an email at edwin.wee@stripe.com!
The thing to realize here is that most of these payment processors have the same functionality. The key difference most of the time is the Documentation/Spec and the support provided by the processor.
I have been working on a Braintree solution for my place of employment and going from Authorize.net/First Data to Braintree was a pleasure! All support queries I've made to them have been answered in couple of hours. This to me makes the biggest difference.
Stripe vs Braintree feature comparison:
Braintree allows payments through Paypal
(This can increase conversion if you believe your customer base feels more comfortable when using Paypal, a name they will likely recognize, as their card details are not revealed.)
Stripe accepts American Express while Braintree does not
Braintree allows you to bring your own merchant account
The stripe ecosystem is (arguably) more developed (i.e. Atlas)
2. Cost Related Takeaways:
If you are going to be bringing in under $200k revenue, then Braintree will likely be the better option in terms of cost considering their first $50k fee-less revenue.
However, if you are to be earning more than $200k, then Stripe will likely be the better option in terms of cost considering their lower % fee on transactions.
Additionally, the number should be re-calculated based on your international/domestic split, your estimated no. of charge backs and your average transaction size.
There's more to the payment world than Stripe vs Braintree :) Actually, there's more to payments than cards! In many countries, local alternative payment methods account for more than 50% of e-commerce transactions. Do Stripe/Braintree support them? No.
Even more, you'll most likely have to integrate with each payment method's specific API/workflow!
2) Integrating with our API is the best way to remove the pain of supporting current and future payment methods! With one single integration you'll be able to support not only cards, but also dozens of Alternative Payment Methods from countries all over the world.
I don't own a SaaS or eCommerce company, but I would be wary of a company owned by PayPal. It might be that the increased availability and PayPal integration is worth the risk, but it's something I would weigh pretty heavily against Braintree.
For those selling to the EU from the UK - what subscription payment/accounts package combination can you recommend for pain free handling of VATMOSS type complexity?
I wrote about that last year (https://blog.wearewizards.io/looking-at-payments-solution-fo...) and I need to actually implement it this week. Haven't decided yet but quaderno + stripe is the best choice I've seen so far. Definitely interested in more feedback too!
Thanks, thats good info. I am very interested to hear about your conclusion and experience when you set it up. Are you integrating with an accountancy package like Xero/Sage?
Quaderno/Stripe sound promising to me too but I can't find genuine feedback from Quaderno users. Its a real shame Recurly isn't priced to be an easy choice. It seems expensive to triple dip on subscription fees, transaction fees and %revenue and beyond frustrating that multi-currency is an enterprise "call us for pricing" feature.
I'll probably do a write-up once we are done but it could take some time with the uncertainty of the pound and the brexit since we are 2 EU migrants.
We might end up doing multi-currency or only €/$ to avoid betting too much on the pound right now
Sorry for going off topic, beginner here. Does anyone know of a solution to receive payments in LATAM / Central America?
And could someone link a few resources on how to encapsulate the processor?
The ones that I've searched for don't support this side of the world. Even with PayPal I haven't been able to figure out how to withdraw - or even to make online purchases. I'm probably doing something wrong but I'm stumped on all accounts.
I use both. Braintree for SaaS income (monthly, one-off, client contracts), and Stripe for marketplace payments (Stripe Connect - event ticket sale service fees). It works well, and helps me reconcile the income easier into separate clearing accounts that I set up with Xero. I was originally enticed to Braintree because of the first free $50,000 of processing. I have been very happy with both.
Besides Stripe and Braintree, I would like to recommend FastSpring. Accepts credits cards, Paypal, Amazon and others. Supports recurring payments (perfect for SaaS) and single payments for products. Has great support, and the fees are very low. I have been using them for more than 2 years, and have had no issues.
Also consider what complimentary services you may need: Automated dunning, receipts / billing history management, sales tax calculations, subscription analytics, accounting integration, etc. Personally I found that the ecosystem around Stripe is better, and there's many great options for all of the above.
i have used both APIs. i would say both get the shit done. but i liked stripe more.
they have better admin interface. plus some what good documentation than Braintree.
I personally would recommend Paymentwall, as it is a more international and complete solution.
I have tried multiple payment processors, but no one has such a wide coverage. In addition to card processing, Paymentwall allows you to accept payments made with bank transfers, prepaid cards, mobile payments, and different ewallets.
I never had any issues with expanding to new markets, and am currently processing payments from the United States, Europe, Latin America, Asia, and Middle East.
The API integration was straightforward and simple, and gave me access to all of their available options at the same time.
So far it is the best payment processor for international payments I have found.
I've used both stripe and braintree to build payment processing services that do hundreds of thousands of dollars in transactions per month.
I can't really tell you which is better because it really does depend on a lot of variables that may be unique to your business (e.g., where you intend to operate, the payment methods your target customer base is comfortable using -- hint: it's not always credit cards and paypal, how you intend to bill).
Since I've got more experience with braintree, though, I can comment on some aspects of its use specifically -- primarily their drop-in UI, which has frustrated me at every turn.
Their drop-in is probably one of the most frustrating pieces of technology I've ever integrated into a website. Not because it's poor, necessarily, but because it only feels about 80% complete. The user experience is really frustrating at times. Some examples:
* Last I checked, payment method removal wasn't possible in the drop in - you have to integrate their API specifically for that.
* Choosing what payment method you want can be really confusing due to the card number / email address obfuscation they use in the drop in. For example, if you have two paypal accounts, selecting between one of the other is difficult when they're listed as p----@paypal.com and p----@paypal.com. The same thing happens if you use multiple credit cards of the same issuer (two Visas for example). Simply allowing the user to set a card name in the ui (e.g. "Personal Visa" vs "Work Visa") would mitigate this problem.
* It currently isn't possible to set a Coinbase account as the default payment method in the Drop-in. Despite the Drop-in supporting Coinbase fully in every other way. So there's another reason to incorporate the API.
* Lack of other major payment methods. With BrainTree you get Venmo, Coinbase, CC, Apple/Android pay, and Paypal. Depending on your customer base, you could be woefully under-serving them. As my current business grows, we're now looking into incorporating other processors to use alongside braintree to support things like gift cards, ACH transfers, Amazon Payments, etc. This may just be unique to my industry, but I can't stress enough to do your homework ahead of time and understand how your customers expect to pay you.
* I get numerous reports from users of being unable to pay using paypal through the drop-in if they don't have a credit card attached to the paypal account. I've contacted BrainTree numerous times about this and have yet to get a definitive answer as to why this is the case. Additionally, if a credit card is connected to the paypal account, the withdrawal comes from that and not the paypal balance. If you want to frustrate your user base, let them use their paypal account but not their paypal balance...
As I've typed this, I realized it's a pretty ranty indictment of BrainTree. On the whole it isn't a terrible service. Uptime is good, money goes in, comes out, and my business keeps on running. It's not a bad service, I just have a lot of drop-in frustration. I kind of hope I get a reply that says, "The BrainTree drop-in does all this, you're just using it incorrectly."
My 2 cents, I don't trust any company owned by Paypal as Paypal has a very strange, aggressive and non-transparent and inflexible process to holding funds from businesses, charities etc (even after providing all the extra "evidence" they ask for).
Stripe has a lot of advantages, API being a huge one. I have heard of a few people that complain about delays in responses from them, but at least for me I have never had that. In fairness too, 99% of the time the answers I have needed are in their documentation.
If I were you, no matter who you choose to integrate, I'd encapsulate it behind your own payment "service" so that even if you have to switch or you need to add more then one (highly recommended), then you can. Some will argue this is overkill, but I have done a lot of payment integrations, with specific banks, First Data and Stripe, Paypal etc. Having it encapsulated means a little more design but a lot less breakage and lets you minimize risk if a vendor decides to shut you down or freeze funds etc.
IMO if you are accepting payments you should already have encapsulated your payment vendor, as a real risk to business continuity exists if they decide to freeze your ability to charge or like Paypal freeze funds during charge back windows etc.