This article really should be titled "Why we chose Balanced over BancBox."
Stripe quite simply wasn't the service they needed and they made a mistake in initial selection. This article title implies that Balanced is "better" than Stripe when they are quite different services entirely.
Well they were using Stripe and then switched to Balanced. So I don't think the title is misleading. It's short and factual. Maybe they could have added ("Hint: Disbursements")
At the time, Stripe was the easiest and best solution for us. Our product wasn't as mature as it is now and automated developer payments weren't high on our list (as we were much smaller). But 18 months later, companies like BancBox and Balanced launched into the mix and were a much better fit for us.
> Integrating billing into an app used to be a pain in the ass. I remember integrating BrainTree into a previous startup back in 2008, and it was a four month long process. Applying for a merchant account to even start accepting credit card payments took at least three months to get approved.
This is a massive win. I remember trying to setup payments and begin rejected several times by Worldpay and this was a process that took several months and required us to keep funds in escrow. Ultimately we settled on PayPal integration which required sending customers off to paypal.com and hoping they went through with it.
I'd love to see some case-studies in terms of conversion rates for completing transactions when it comes to keeping customers on site to do payments versus sending them to a 3rd party.
The blog post was discussing the 2008 version of the Braintree APIs. We completely rewrote our core APIs in 2009. Today, I think we provide one of the most elegant payment APIs available.
We've also significantly decreased the amount of time it takes to get a merchant account -- we have an instant application process now in the US, so many of our merchants are approved and provisioned with an account as soon as they hit the "Apply" button. Our international application process isn't instant yet, but we're working hard to make it as fast as possible.
I've had a very good experience integrating with Braintree. For my use case, most of my customers have existing merchant accounts with significantly lower rates than they would pay through Stripe (or a competing product), so the ability to migrate those accounts into our Braintree account was a big win for us. Their Node.JS docs leave something to be desired, but their API is very clean and intuitive.
For what it's worth, that is not my experience. Setting up a merchant account with Braintree is a pain (but far less of one than going through a typical broker). It took me less than three weeks, most of which was spent waiting.
And the Braintree API is almost as good as Stripe's, if not equally good (it lagged a couple years ago, but they've been catching up). Stripe is a little bit slicker in my view, but not dramatically so. For normal stuff, your'e not going to see a huge difference in development time - certainly less than a man-month with either provider.
I eventually switched to Stripe because it was cheaper at low volumes (this was important to my project since it was bootstrapped), simpler, and they never asked for a personal guarantee. But it wasn't a huge difference operationally. Both companies provide very good support and are perfectly acceptable.
Both are miles ahead of Auth.net and Paypal, which are pretty horrible.
While everything practically useful almost always takes longer than almost anyone thinks it possibly could, I'm curious about some of the times I've seen in this discussions lately.
Honest question: What is it about Stripe (picking this one specifically due to having used it) that would take a month of work? Their documentation is thorough but -- at least last time I used it -- totally lacking in examples, so patching together a server-side workflow for creating and charging against profiles took a couple days of on-and-off work, but a month? I can see this if it includes other development on the project, but as far as actually getting the relevant parts of the API integrated and working, I'm wondering if other people's experience has been vastly different with this.
I've done two stripe implementations and one Braintree. None took more than a week of coding and that's being generous. Although I imagine if you had a really complex system, you could take a while.
Sorry, I should have prefaced my conversation, I was based in Singapore at the time so didn't have access to the plethora of beautiful payment options that are available in the US.
Where these new services win out is the ability to instantly be underwritten as a merchant and start processing. For WorldPay I had to submit passport, bank account statements (via fax no less), sign my life away etc.
Huh. Balanced offers same-day payouts to Wells Fargo bank accounts and next-day to others if it's before 3 PM PST. I love Stripe, but I hate the 7 day rolling period. I use Square for my in-person transactions and get the money the next day. Why can't Stripe do this?
I wonder if Balanced has good integration with the third-party shopping carts out there...
There's much higher fraud risk with online card payments than in-person ones. There's both risk that the customer presenting the card number isn't the cardholder, and risk that the merchant is itself a fraudster trying to charge stolen cards, launder money, or accomplish some other illegal act on the network.
Traditional merchant accounts mitigate some of that risk through an extensive underwriting process. Stripe does not have such a process. The only way they can mitigate the risk is by identifying patterns in transaction activity and getting chargebacks/disputes from cardholders. The 7 day period gives them sufficient time to identify the patterns and receive early disputes before the money leaves their control.
Do they? Balanced Payouts offers same-day ACH. Do funds captured from credit cards with Balanced Payments instantly enter a balance to fund an outgoing ACH with Balanced Payouts? Credit card transactions don't settle instantly, they're typically batched nightly M-F. I would be surprised to hear they let you withdraw money they don't even have in hand yet.
[12:58] <kyleb_> Do you offer next-day payouts for credit card purchases?
[12:58] <@jacobolus> kyleb_: yes, assuming I'm understanding you correctly
[12:59] <@jacobolus> kyleb_: payouts go to bank accounts, and are next business day or same-day with wells fargo bank accounts
[12:59] <kyleb_> I think so. Customer purchases $100 worth of things using a Visa on the website at noon PST. Those funds are disbursed to a bank account via ACH on the next day?
[12:59] <@jacobolus> kyleb_: yep
[12:59] <kyleb_> OK perfect. I wasn't sure if it was bank payments only that were processed next-day, or if credit cards were processed as well next-day
And has yet to offer a response other than "thanks!"
I'm also not sure how many customers Balanced has or what kind of volume they're doing, but I suspect that they're taking o a whole lot of risk with next day payouts that Stripe and Braintree refuse to take on. While some businesses may like this, I find it worrisome.
Yeah, let us know. I'll definitely hack on an integration for whatever shopping card is easiest for you. We're actually interested in opening up office hours where we help you integrate Balanced in whatever framework you want :P
If you want a stand-alone invoicing system with online credit card and ACH payments, WePay.com works pretty well. I have used it for a non-profit group I'm involved in.
They also have an API but I have not really looked into it.
At my last consultancy I heard great things about BrainTree with Python... however, that was someone else's baby, and I've only ever worked with Auth.net, Stripe, and some awful processors that are better left undiscussed. Stripe is hands-down the easiest.
If Balanced is that easy and enables escrow-style payments, that's pretty brilliant. Will definitely be looking into it for future projects.
Why not just batch all your payouts daily and do ACH with your bank for payouts? Costs us $17/mo and takes 5min no matter how many payouts we need per day by uploading a file to our bank.
I bet your bank has a great API for this as well :)
Balanced abstracts away this batching process and giving you events and nice json objects to deal with rather than parsing the batch file that eventually gets returned.
You could make the same argument for the card processing, if you really really wanted to you could bypass Balanced/WePay/Braintree/whoever and deal directly with the bank but for most people your time is better spent getting on with your core business.
The banking feature is called ACH Origination. We use a small local bank, Canandaigua National Bank, most banks should be able to do it. Writing the software to do it took me about a day.
How hard would it be for all the PSPs out there to standardize on one API, maintaining of course the ability to add proprietary extension to it? There's a shitload of the most boring work on Earth to do for integrating with each... I remember using the PayPal api time ago and even that was hell... and no matter how good an API is designed, it's still hell because it's another one to integrate with... Can't we make something like w3c for payment systems?
If an existing provider's API became the standard, the other providers would rightly complain. If a standard were made from whole cloth, then, you know: http://xkcd.com/927/
As always, xkcd is right :) ...but there's a difference between "no standard" and "one standard for each implementation", subtle as it may be. Nobody will adopt a competitor's standard, so there has to be a common standard pushed from the outside.
I don't think we want that. There is a lot of innovation going on in payment API's right now, and the competition is what is driving it. That makes it easier for everyone.
I don't think that "a lot of innovation" is what's needed here. To me it seems more like a "do it once and do it RIGHT" kind of problem, and I think that getting a bunch of very smart people to work on it would produce a solution that could just work for 90% of cases for the next ~10 years, which is enough time to review the standard and so on. This is not something to "innovate and evolve", it's something that you "get it 90% right" (and have the proprietary extensions for the rest 10% of use-cases)! This "innovation" is sucking resources that could be better used at something else that's less incredibly boring... hell, I'd even love to see a government funded payment systems api that would later grow into a world standard, as bad as it may be, and be adopted by the banks and integrated directly with their systems putting all the "new wave" fancy PSPs out there out of business (then again, the bank's dinosaurs will most likely never move to "force this into being", so it's not gonna happen).
the ACH network gained widespread adoption when the gov't pushed a new banking standard down to ensure electronic disbursement of social security payments could be made. In this way ACH is a government sponsored payment infrastructure with it's own standard. The standard is actively managed by a gov't agency (the Fed/NACHA). But ACH leaves much to be desired, which is why proprietary payment networks (VISA/MC/AMEX, PayPal, inter-bank non-ACH transfers) have been developed. I'm doubtful that the gov't again pushing a standard, even one that's as widely adopted as ACH, would be able to keep up with the changing demands of the market. We tried this already and it didn't work, but maybe I'm just being cynical.
I too, looked at both BrainTree and Balanced and decided on Balanced. However I liked that BrainTree seemed to focus more on the international part of payments.
Braintree is one of the best international payments option around (aside from PayPal, but PP has it's own host of issues). I'd also encourage you to check out WorldPay. WorldPay's underwriting process is pretty brutal from what I hear, but their international reach is impressive
You only briefly mentioned PayPal, but I'm genuinely curious; did you look into PayPal Adaptive Preapproved Payments (optionally with the embedded flow as seen here: https://www.x.com/sites/default/files/paypal/imported/lightb...)? If so, why did you decide this was not for you?
I was thinking escrow for my startup originally but stripe apps offer a different approach - i.e. cash goes straight from tenant to customer with fees (including a handling fee paid to you) deducted directly from the tenant.
It's a nice alternative to a straight-up escrow setup.
Cristina from Stripe here. Thanks for the comment.
Many marketplaces want to avoid the liability for transactions that take place on their platform. This is specifically why we built Stripe Connect (https://stripe.com/connect). It allows the marketplace to provide a way to accept payments to their sellers. The buyers and sellers can the transact with each other and the marketplace avoids liability.
Balanced provides the ability to pass disputes onto the seller, but the marketplace ultimately has full liability for chargebacks, fraud, and so on.
With Stripe Connect, each seller is responsible for charges run through their own Stripe account. This removes any liability from the marketplace, and is really useful if you want to purely be a platform of facilitating payments and don’t actually want to be involved in the risk and complexity of handling any of the money.
Yep, you can do that easily with application fees (stripe.com/docs/connect/collecting-fees).
The money from the credit card payment gets routed to your seller automatically (and we split off the application fee to send to your Stripe account). You never touch the rest of the funds, so you're never responsible for any chargebacks or refunds.
A lot of the successful marketplaces these days (e.g. Airbnb) have decided to fully intermediate the payments on their platform for security reasons. They find escrow is a way to promote trust and security on their platform. Most third-party payment platforms don't allow for this. Even eBay, which uses the most popular 3rd party payments platform of all (PayPal) had to initiate a $5000 "PayPayl guarantee" to encourage sales. Other marketplaces, like Etsy, are moving away from PayPal and building their own intermediated payments system to have a similar experience as Airbnb. My understanding is that Stripe Connect is great for store builders like Shopify, which are disaggregated, but less attractive to marketplaces like Airbnb.
I can only imagine BrainTree was different in 2008. I just integrated BrainTree into a two-platform system. It took the team a week, most of which was integrating with our order system and doing the UI. The API itself is very pleasant in my opinion.
I really like the layout of the blog. It's nice looking and clean.
The other comments about choosing the wrong tool are apt, but it's also true that this is a part of the payments business. Stripe can choose to do the sorts of holds and escrows these folks are looking for, or not, but I do think Stripe is particularly easy to integrate.
I think this piece is really trying to articulate the grouptalent business model to developers and it comes off pretty well to my mind.
The escrow is one of the core value props of the business. They're arranging development contracts for various companies. The developers know they aren't working for a deadbeat that won't pay after the work is completed, because the company already paid GT before they started work. The company knows it's not paying developers that will skip out without turning in the work product, because the developers aren't paid until after they do the work.
Aside from that, paying two parties for every contract introduces friction. Multiple payments means more work, more manager approvals, more reimbursements for the company card, etc. Some portion of the customers would simply choose not to use the service because of that added complexity; it'd be lost business.
From the article -
>Mollie, GroupTalent's Director of Happiness,...
Ok, I get you want to be hip and all, but Mollie will someday apply for like a real job in the real world, and the company will look at her resume and go "Director of Happiness...very pretentious, are the rest of us Directors of Misery or what...", and that resume meets the shredder.
Why not give Mollie a real, you know, non-vacuous title ?
Ahem, enter the official "Director of Happiness" at GroupTalent takes a bow
The title started because when I joined GT, I was doing a bit of everything and I did not, and still don't, fit into a specific title or box. I love my title and it's a wonderful ice breaker. In fact, I get comments everyday how "kick ass" my title is from employers and talent alike. People seem to respond well to someone who's job is to direct their happiness and have their best interests at heart (which I do). My day starts and ends with connecting smart, talented, kick ass people to really cool opportunities. I feel like every day I get to help people make magic happen and that, my friends, is how I direct all the happiness. :)
Because titles at smaller companies are often looked at with anything but a serious attitude. She'd probably come up with something more official if she were job hunting, or talking to certain clients.
I myself go back and forth between "Lead Janitor" and "Co-founder".
Not sure what makes you think her job is not 'real'. Her title rocks and there's nothing unreal about it. And BTW, here are some 'real world titles': Jolly Good Fellow Intergalactic Federation King Almighty and Commander of the Universe. Chief Culture Officer.
FYI, above titles are from one of the smartest companies on the planet - Google. Source: http://www.businessinsider.com/11-google-job-titles-you-wont...
Stripe quite simply wasn't the service they needed and they made a mistake in initial selection. This article title implies that Balanced is "better" than Stripe when they are quite different services entirely.