I believe the brain is too complex to compare to either an operating system or a CPU. We can perhaps analogize both of those artificial entities to individual functions that a human brain may perform, but they would not be comprehensive of its abilities. As just one additional ability, there's also a memory storage (both short-term and long-term) mechanism existent in the brain, perhaps akin to temporary and permanent memory in a computer. Artificial neural networks mimic the properties of biological neurons. And then there's the concept of intelligence and actually thinking and understanding (which is really much more complicated than mere processing as in terms of a CPU); while machines' abilities are more along the lines of imitation/simulation.
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 do realize the entire banking system is not built with the idea of ACID/transactional databases in mind? You only really need durability guarantees to implement banking properly. Bank accounts are eventually consistent logs of immutable transaction data which are reconciled in batch.
You might not need ACID during the recording of each charging transaction; however, without ACID, you won't be able to correctly apply each transaction against your account balance during the reconciliation batch processing. Marking each charging record as charged and updating your account balance must be in one transaction, whether relying on the database transaction support or building your own transactional log.
So at the end of the day (yes end of the day processing), ACID is needed.
The account balance is calculated as a function of adding all the debits and credits together. Bank accounts are not stored as some kind of balance value that gets mutated over time. The balance is simply the result of some operation that is cached. It's quite simple. No ACID required. Most of these systems at large banks were built in IMS long before relational databases even existed.
>"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).
That's a fair point. Some NoSQL products do provide ACID guarantees within the scope of a logical record. That's usually as far as they go, though. So for transactions that cross logical record boundaries and/or are commutative (i.e., the "sequence of things" matters), you would have to build the outer transaction scope in the app tier. It can be done, but it's the kind of heavy lifting that RDBMS products do pretty well. As always, right tool for the job.
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:
our system inherently includes automatic fraud prevention
If you're willing to share more, I'm listening. PayPal has "automatic fraud prevention" in the sense that, if you do something that deviates from what they expect, they suspend your account. I assume you mean something different.
Also, I followed the Quora question to this related one: http://www.quora.com/How-are-Square-and-Stripe-able-to-accep... I'm still confused about one thing, though. I understand that PayPal is both an aggregator and the merchant of record. It sounds like Braintree is not and aggregator and not the merchant of record. But this poster claims that Stripe is an aggregator, but not the merchant of record, and I don't understand what that means.
No we won't freeze, close, or withdraw money from people's accounts. Once it's open, it's open. Once the money is cleared, it doesn't go back. This is an ironclad promise we can make to users because of the unique way we process payments. Right now the model for peer-to-peer transactions is that after one party gets paid the other waits for his merchandise or services to be delivered (eWork projects). We solved this problem by creating a system that will give equal distribution of control to both parties during the entire process, disincentivising fraud on both sides. The system is specifically designed for people who outsource projects, freelance workers, and cross border peer-to-peer e-commerce. It would simulate the benefits of a face-to-face interaction by solving the problems created by the distance and time usually involved in these types of exchanges.
It's also not clear to me how what you describe prevents scams and money laundering. Note that in the case of money laundering, it's the same party on both sides of the transaction.
You are absolutely correct, it is a promise. But it is also a guarantee. There are regulations regarding money laundering that we will have to comply with of course. Users are required to fill out certain forms if the the amount of a transaction exceed 3,000 for individuals and 20,000 for businesses. And these are not just "per transaction", it is per month. As with scams our system is specifically designed to prevent users from falling into the trap scam sellers or buyers. Of course it will never be absolutely fool-proof, but it does significantly reduce the incentive for fraudulent activities on both sides. Unfortunately, I cannot give out too much detail on how we do it. We are launching our beta system sometime around March and you will be more than welcome to try it out as a beta tester.
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 think the biggest asset would simply being "not PayPal". PP has been cultivating a bad PR problem lately and systems like these will have a social lock-in effect. Not quite as bad as Facebook vs Google+ but people would be reluctant to wander too far out of bounds, especially when bank accounts are concerned.
You seem to have some great goals yourself, however. Good luck to you!
Actually it is the sellers that PayPal is turning off. Their dispute resolution policies are abstruse and keep changing in their attempt to protect buyers. They have relied too heavily in freezing, closing, and even withdrawing money from sellers’ accounts without prior notice. So many eBay sellers who have relied on PayPal had their entire businesses destroyed with one incident. A payment system that focuses on preventive security would not rely on such heavy handed tactics when resolving disputes between buyers and sellers. If all users (buyers and sellers) have an equal distribution of control during the entire transaction then incentives for committing fraud on both sides will be effectively eliminated. Right now one party gets paid then the other has to wait for his merchandise. PayGuard will solve these problems. The challenge now is to get people to start trusting new players in the market.
>An "appealing design, an expedited set-up process and better customer service" are easy to replicate.
For any bigco the size of paypal to replicate it, they would first need to realise they are doing it wrong. Which requires a relatively large critical mass of people in the management chain to accept that they've been doing it wrong. That will never happen. And then there's the technical issues of going from wrong way to right way without interrupting service. That likely requires a lot of very skilled people, many of whom probably left for greener pastures when they first saw the "wrong way" sign.
It's amazing how bureaucracy can make it difficult for large companies to make simple changes. I think we should create a better model for running large organizations. The "flat" model seems to be promising but is still not sufficient to fight the inertia that is built during a company's growth stage. Maybe decentralization if done correctly will work.
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.
That style of IntelliSense would be fantastic for languages that change the ending based on context (aka declination). I know I had troubles learning Finnish because of this, and even the easy Esperanto was tricky at first.
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.
yup....PayGuard will rock the payments industry by putting an end to the localization trend in e-commerce and create a truly global payments platform.....of course I am biased for it.....LOL
