>"You do realize the entire banking system is not built with the idea of ACID/transactional databases in mind?"
Well, I was referring to payments/transactions, not banking. As I specifically said, we are building a third party payments aggregator (TPPA). So, we handle transactions; we're not a bank.
In our case, there are many scenarios where ACID is needed. A couple of the most basic are the need to rollback a transaction (e.g. if it was cancelled, or if it did not succeed) and the need to recover from a failure (specifically, to get back to a consistent state to resume a failed transaction).
We were actually considering MongoDB for our system, given its scalable, high-performance, and open source qualities. However, since we are building a payments platform (specifically, a third party payments aggregator), we soon learned that our case is the exception where MongoDB--or any other pure NoSQL DB for that matter--is not an ideal solution (and is specifically noted as a less well suited use case on the MongoDB site), because NoSQL DBs are not transactional.
Any possible work-around proved to be complicated and tedious--likely requiring heavy application-side logic--if not inadequate. Going hybrid was an option (RDBMS for critical parts, and NoSQL for other non-critical parts), but that may not have been a prudent way to start building this thing, since it would be difficult to predict the portions that might be correlated or codependent in the future (where a JOIN between the RDBMS and the NoSQL DB would be inefficient, if not impossible).
As a payments platform, we cannot afford to lose any transactions, and every penny must be accounted for, so a transactional and ACID-compliant data storage is a must. Thus, we decided to go with a traditional RDBMS. With that said, and looking towards the future, I am considering the use of an ultra-high throughput RDBMS such as VoltDB for our system... A VoltDB vs. MongoDB (or any other NoSQL DB) would be interesting.
You are absolutely correct. That's one of PayPal's main weaknesses. I am not sure how Stripe is dealing with it; though they probably have to go through a similar screening process, which isn't foolproof.
I am a co-founder of a nascent third party payments aggregator (TPPA) called PayGuard (currently in stealth mode - Beta version is being built), and our system inherently includes automatic fraud prevention; so we not only save money by eliminating the screening process, but we also save by virtually eliminating all 'dispute resolution'-leading scenarios.
As far as a comparison for Stripe, they seem to be similar to Braintree, but geared more towards early stage online merchants. The following link may answer some of your other questions:
I think this issue is very significant these days, with the boom of outsourcing and remote freelance work. For scenarios with no down payment requirement, there's no guarantee the service provider will receive payment at all (and no guarantee the rest of the payment will be paid for the down payment scenario either). And for scenarios where a down payment (or full payment) is paid, there's no guarantee the service will ever be delivered to the requester. And how about scenarios where the wrong service was delivered? And how about if the service provider and requester are not in the same country (how do you go about taking legal action)?
I am a co-founder of a nascent third party payments aggregator (TPPA) called PayGuard. We are currently building our Beta, but our system specifically targets such scenarios. And with such capability, our system inherently solves the same issues with material products as well (a market PayPal currently dominates, though it does so extremely unsatisfactorily).
The article states: "[WePay's] ambition: to move beyond what WePay calls the “unstructured economy” to be the dominant way people make payments and buy things online. ...Since WePay can’t yet match PayPal’s brand or awareness, it aims to offer more appealing design, an expedited set-up process and better customer service."
If WePay intends to overtake PayPal, I think it will need to do more than that. An "appealing design, an expedited set-up process and better customer service" are easy to replicate.
How about thinking out of the box and re-engineering the system? How about focusing on and addressing PayPal's weaknesses? How about creating a system that inherently includes automatic fraud prevention (for both buyers and sellers)? How about minimizing (nearly eliminating) all dispute resolution scenarios? How about extending such protection to the services marketplace (as opposed to just products)? How about creating a truly globalized payments platform (there are several countries where PayPal fails because credit cards are not used or available as the main form of payment)?
I am a co-founder of a nascent third party payments aggregator (TPPA) called PayGuard. We are currently building our Beta, and our system addresses all these issues.
I actually thought of a similar idea before, while I was meditating in rural Philippines attempting to figure out a viable business idea and trying to avoid a return to the rat race in the US. Unfortunately, the idea seemed too daunting to take on by myself.
I don't know if Duolingo already has plans to incorporate it, but I had also originally thought that 'word completion' functionality would assist in the process of learning a new language. For example, a beginner trying to learn the Tagalog language (but knows a few simple words) could begin by typing the word 'Gusto', and then typing a space after the word would produce a drop-down with possible words that could follow, such as 'ko', 'niya', 'nila', 'mo', etc. In essence, it would be 'Intellisense' functionality that provides grammatically correct word-completion to help students learn sentence structure -- which is a major part of learning a foreign language, as opposed to just translating / memorizing fragments (e.g. words). I was even to the point where I was considering how an AI approach using an inference engine / chaining might make this
process more efficient.
Anyway, I e-mailed Luis von Ahn about it, but he was probably too busy to read or react to my e-mail. I am just happy to see someone else was able to make the idea a reality -- another testament that brilliant ideas are virtually worthless without brilliant execution.
The competition looks stiff, but I'm rooting for them. Terence Pua, Insync's co-founder, is a seasoned internet entrepreneur -- one of the guys behind Friendster (Philippines) back in the day, before getting killed by Facebook.
I had the opportunity to join Insync's team back when I was living in Manila; but I came across Payguard ( http://www.younoodle.com/startups/payguard ) and decided to try to revolutionize online payments instead.
Well, I was referring to payments/transactions, not banking. As I specifically said, we are building a third party payments aggregator (TPPA). So, we handle transactions; we're not a bank.
In our case, there are many scenarios where ACID is needed. A couple of the most basic are the need to rollback a transaction (e.g. if it was cancelled, or if it did not succeed) and the need to recover from a failure (specifically, to get back to a consistent state to resume a failed transaction).