While LGPL and MPL are similar, there are differences and they should not be lumped together.
The biggest difference is that MPL allows static linking while LGPL does not. While in the past this wasn't a big deal, it is important for iOS development since you cannot dynamically link to libraries in iOS apps.
Can I suggest you announce loudly and publicly when you're ready to roll out in non-US countries (in my case, Australia), remembering that many of us will have already written you off as "US only" in our heads and will skip straight past future mentions of you, expecting to be disappointed.
Grr. Argh.
I don't know what the market outside of the US but since there's basically no one serving us in this space you would think it would be a huge opportunity if anyone figures out how to crack it.
WS callbacks (aka webhooks) that notify you before a recurring payment happens, and after success/failure.
Incremental billing support, so you can e.g. tack on overage charges or small micro-charges to the next upcoming bill without needing a separate transaction for each one. Depending on your business model this could save you a lot of transaction fees.
Well I doubt it'll be any lower than the industry standard of 2.9% + $0.30 for < $3k/month. If it is, that would be pretty disruptive.
What will be more interesting is if they can match both Amazon and PayPal's microtransaction rate of 5% + $0.05 for products under $10 (Amazon) to $12 (PayPal).
Does Braintree eliminate the need for a merchant account, with all the complexity that entails? Do they offer a developer API that's super-friendly to write for, allowing for weird use cases like processing payments from native BlackBerry apps without exposing you to PCI requirements or risks of publicly exposing your API keys by shipping them in apps?[1] And most importantly, is it a piece of cake to communicate directly with Braintree's founders?
'Cause that's what I've seen so far from Stripe. They're incredibly responsive and helpful. They even changed their SSL cert provider for me because older BlackBerries had a rough time with their prior cert provider.
Not to rag on Braintree, they've sounded like a good choice for a long time, but Stripe's changing some of the rules of the game. Killing the need for a merchant account is a really big deal and I'm happy to pay their rate.
[1] This isn't a rhetorical question, actually. I'd be interested in whether you can do this with Braintree.
Braintree's API is crazy simple. You can do pretty much anything you need with a single call to a well-designed endpoint using a sane object model. They have working client libraries for pretty much every tech too.
All designed and written in the last few years, and thus completely free of legacy insanity from the 70s.
You need your own Merchant Account though. They'll find you a provider if you need one.
I can't speak to Braintree because we don't use them. I do believe that they will set up a merchant account for you as a proxy or agent, IIRC.
But I can speak to the economics of all this "complexity" of which you speak.
We currently use CyberSource for our gateway and associated banks for our Merchant Accounts, and we maintain several accounts. Each account takes less than a day to set up, with our representatives at each company.
Integrating with the CyberSource API takes roughly 20 developer-hours.
An increase in transaction costs to 5%+0.30, would cost us roughly the salary+benefits+taxes+overhead of two fulltime developers, per year. That's a cost that's simply unacceptable.
There is also the issue of "killing the need for a merchant account", being problematic from a number of legal/accounting angles( tracing this transaction from A to M, entity separation and identifcation ), as well as customer service angles( what is this PAYCSTRIPE_TCMERCH charge on my card?? ).
You've got what's called a nice problem to have. At that rate you must be charging many millions per year, so sure, it's all about minimizing your fees. But for those of us with much smaller-to-nonexistent revenues, wondering whether our app will even make money at all, Stripe makes all kinds of sense and is a prefect place to start.
On the surface they are more expensive than PayPal (2.9% + $0.30) Fees.
The fees for Stripe are 5% + $0.30.
However when you take a deeper look you see that things are not so simple.
Compared to PayPal's free product, you are not forced to leave your website and go to a 3rd party site to complete the transaction.
Compared to PayPal's Web Payments Pro product, you don't have the $30 monthly fee.
Also this doesn't even taken into consideration the complexity and cost of implementing PayPal's Payments Pro api vs Stripe's simpler JSON api.
I await with ears wide open... and will keep my eyes open for a beta slot. I suspect that this would scratch a rather itchy itch that I have at the moment with my app.
Yes. People often make the mistake of thinking that if you aren't storing credit cards then you don't have to deal with PCI compliance. While it does remove a few requirements, if you accept/transmit the credit card through any of your systems (web server -> web-app -> 3rd party API) for instance, you're still on the hook for PCI compliance. Which is a huge pain.
Thanks for clarifying. That's my understanding of it, too.
If the form that the user puts their credit card info into POSTs to your web server, then you are on the hook. Now that I think about it, the form may POST to a third party payment processing web service from your web app which prevents the user from feeling like they have left your web app. In that case, I think that your web app is off the hook for PCI compliance.
Is that true though? If you have XSS vulnerabilities on your website, someone can lift the CC info right from the form before posting of any data happens. I am not sure whether PCI talks about this but I sure would be worried about this.
We (at Spreedly) have talked to several QSA's about this question, and their take is that using a redirect removes the application from PCI scope. It's a really good illustration of how PCI != security.
Thanks for pointing this out! This needs a lot more attention IMO! The PCI verbage is "store, process, or transmit", which means that if you host a payment form on your site, you are on the hook for SAQ-D.
The biggest difference is that MPL allows static linking while LGPL does not. While in the past this wasn't a big deal, it is important for iOS development since you cannot dynamically link to libraries in iOS apps.