Why did we switch from Braintree to Stripe?(deekit.com) |
Why did we switch from Braintree to Stripe?(deekit.com) |
The reason for this is that Stripe had no phone number, and no way to contact them other than via their support channels, where I found response times to be very slow (perhaps this has changed in the past years?). With Braintree we have a rep who we can call at anytime who is very responsive.
Really for my boss it just came down to who had a phone number. I'm surprised that Stripe is lacking in this department, you would think that a company who wants you to trust them with all your payments would at least give you a way to talk to an actual human.
Last week, we expanded live chat availability, and it's now available 24 hours, Monday through Friday.
>However, we do not offer proactive phone support for self-serve users who have integrated and whose questions do not require an immediate call. For further context, a large portion of our users are self-serve, and the majority of their questions are effectively handled via email since we're able to include helpful documentation and a detailed explanation.
To be fair, I can see Stripe's problem, they don't want their phone lines clogged by some 'web dev' who pastes together Javascript asking how to init the payment fields, but it's hard to know what is a real question and what isn't.
That being said, I do think that Braintree ended up working better for us in the end due to the need for people in the financial department to create and edit various recurring plans. Looking forward to hopefully using Stripe with other clients someday!
That's not true. We use Braintree for almost the same per-seat model described in the article and we pro-rate changes to the subscription mid-cycle using Braintree's "pro-rate on upgrades/downgrades" options.
Ref docs: https://articles.braintreepayments.com/guides/recurring-bill...
Follow the users.
That's not to say Braintree wouldn't work for others. As we stated, it's an awesome solution and we couldn't fault their support at all.
That being said, I've seen nothing but praise for Stripe payments. The dev and design team are very solid and supposedly have great documentation as well.
I wonder, since Braintree is owned by PayPal, if companies have experienced the same pain points with getting locked out of funds for arbitrary reasons on that platform, or if Braintree is completely agnostic to PayPals TOS.
You don't hear about people getting upset with Braintree (or Stripe) because when someone integrates with Braintree they're aware they're making a business decision and they read the contract, and have probably looked into getting their own merchant account and have an idea of the lay of the land.
You do hear about people getting upset with PayPal because it's "laymen" who click through everything without reading, and they don't often understand the concept of a reserve at all, let alone the idea that a product delivered in the future increases the risk to the payment processor. Or the myriad other product/circumstance combinations that increase processor risk
Can you please explain what it is?
Braintree's one-iframe-per-field integration is a beautiful thing. It gives us ultimate flexibility in formatting, bypasses a lot of PCI-DSS compliancy issue, and avoids the impression that the customer is leaving our website to enter payment info.
But we don't have to deal with subscriptions, so ours is a completely different problem space than the article.
Could you elaborate on this?
There is an advantage to having your processor be both an account and a gateway in that you need only one relationship and it's much easier to get started.
I haven't checked on Braintree lately, but the few times I've had to talk to the Braintree support or sales team, they've been very unhelpful.
If your business is not the size of AirBnb they make it clear they don't really care about having you as a customer. And that's even if you process a few millions a year.
If you're outside the US, have fun signing up and jumping through hoops. If you're building a marketplace, your users will have to jump through the same hoops just to start accepting payments.
While Stripe isn't perfect either, they are a lot friendlier and helpful when you speak with them. They also have Stripe Connect and self-signup which makes it much easier to build a marketplace.
I'd rather use Stripe for credit card processing, even if that means dealing with Paypal's bottom of the barrel APIs directly to add Paypal payments. That's how bad Braintree support is.
Maybe they've gotten better and this is out of date, but based on past experience, I don't really care to find out.
As a company, they host an asinine number of public events at their 100+ person meeting hall at Chicago's Merchandise Mart. To get to that hall, you have to walk about 200ft past all of their workstations and meeting rooms. Infrastructure diagrams and unlocked workstations are pretty much everywhere.
Sure, they do a few things to mitigate the risks of people who come in by requiring sign-ins and presumably cameras everywhere, but it still feels very surreal to be a few meters away from having potential access to a large payment processor's infrastructure. I've seen at least one person there who was very clearly using a burner laptop.
Here's a USB dongle that's actually a key-logger with 2GB of storage and WiFi offloading for about $150 bucks available on Amazon:
https://www.amazon.com/Wi-Fi-Premium-Hardware-Keylogger-comp...
Options as cheap as $50 are available if you're willing to accept less storage and risk a second physical contact to recover your device (no WiFi).
I can't seem to find a payment processor that I trust to send payments to Central America (from the few I have seen - Braintree and stripe don't). There are a few caveats to this, unfortunately. My plan is to do all the legal work through the e-Estonia program but can't get started since I would need to fly out to pick up the identification card. Cash which will need to be generated through the business first.
Once that is set up it will be easier to get a payment processor (stripe, please add Estonia to your list first chance you get).
I'm wondering if it is sensible to accept payments online, generate some cash, start the e-Estonia process to have a legal business. But, I'm still stuck as to which processor to use to send the payments to to a personal account in Central America. Last I checked, I can't use paypal since that is a U.S only option. In either case, besides wondering which processor I could use, is this a sensible plan?
But as a developer I also prefer Stripe because they have better API and SDK libraries.
Also subscription model is better in Stripe. You can create plans dynamically. With Braintree the API doesn't allow you to create new plans on the fly. Existing subscriptions cannot be upgraded/downgraded between different plans.
Also Braintree sandbox has been very flaky from my experience. In 3 months they have had several downtimes which slowed down development a bit.
I believe you may be incorrect about this[0]
[0]: https://developers.braintreepayments.com/reference/request/s...
This makes automated deployment a bit more annoying with Braintree as it involves more manual fiddling with the console. With Stripe this can be part of the code so your business logic creates a plan if it doesn't exist, similar to upserts in SQL.
Some of us are still stuck with stagnant vendors like Beanstream/Bambora/Moneris that seem to have missed the last 15 years of developments in the web space.
> All funds resulting from Charges are held in pooled clearing accounts (the “Clearing Accounts”) with our Financial Services Partners. We will make Transfers to and from the Clearing Accounts in the manner described in this Agreement; however, you have no rights to the Clearing Accounts or to any funds held in the Clearing Accounts, you are not entitled to draw funds from the Clearing Accounts, and you will not receive interest from funds maintained in the Clearing Accounts.
> In certain circumstances, we may require you to place funds in reserve or to impose conditions on the release of funds (each a “Reserve”). We may impose a Reserve on you for any reason if we determine that the risk of loss to Stripe, Customers, or others associated with your Stripe Account is higher than normal. For example, we may hold a Reserve if: (i) your or your Customers’ activities increase the risk of loss to us or to your Customers, (ii) you have violated or are likely to violate this Agreement, and (iii) your Stripe Account has an elevated or abnormally high number of Disputes. If we impose a Reserve, we will establish the terms of the Reserve and provide you Notice of the amount, timing, and conditions upon which the funds in the Reserve will be released to you. In many cases, the Reserve amount will be the entire amount of Charges processed using the Payment Services. We may change or condition the terms of the Reserve based on our continuous assessment and understanding of the risks associated with your Stripe Account, if required to do so by Financial Services Providers, or for any other reason. We may fund the Reserve with funds processed through your use of Payment Services, by debiting the Payout Account or another bank account associated with your Stripe Account, or by requesting funds directly from you.
> To the extent possible, we prefer to identify the necessity for a Reserve in advance of establishing one. If you are concerned that we will impose a Reserve on you due to the nature of your business activities, please contact us before using the Services.
Check with your local embassy/consulate and ask about their travel schedule.
NB: I too would like to see Stripe support Estonia. They've been dragging their feet long enough that "soon" is now feeling like an insult.
We are a decent sized company now, so maybe that's why we have a rep. I'd be surprised if Braintree offers reps to every 1 man start up though. From a scale perspective doesn't really make sense, and yeah you'd get plenty of 'web devs' that are stitching together some code they don't understand and then asking stripe why it doesn't work...