This is so wrong. Google Wallet is riding on the credit card rails. In Kenya, where the card networks are virtually non existent, the telecom companies stepped in as the network. And last time I checked, in Kenya, you can only send money to those on the same network as you.
This is so wrong. The title was send money with a text message. Regardless of the limitations of M-Pesa, over $25B in value was transferred with it last year, which indicates to me that it's useful and functional, regardless of what you are saying about credit card "rails".
>over $25B in value was transferred with it last year
...Which is attributed to being the first-to-market payment system for Kenya, as the person before you was describing. U.S. and Kenya merchant markets are still an apples to oranges comparison.
Sending and receiving "money" within the same network is fairly trivial from a technological point of view but once you tell customers that it is "money" that they can technically convert to and from cash, I imagine there are significant bureaucratic hoops to jump through, at least in the US. I bet even something as seemingly simple as Chase QuickPay is actually pretty complicated to implement (step one probably being: be a bank)
Help me understand the comment. Are we to be ashamed that some aspect of our country is supposedly behind a third world country somewhere? Is it giving props to Kenya? Is it pointing out how an underdeveloped country can skip ahead in some situations? Is it associating Google with America while knowing that "pay by text" has been around for quite awhile in the US?
PayPal's original business was that you could "email money". Merchant processing came later. The "viral" feature was that you had to sign up for a PayPal account to receive money.
My concern would be getting a link that I am supposed to follow where I input my debit card number. Can someone explain how I know that text message -- which can be sent by anyone to me -- has a valid link to money? I would be extremely suspicous if I got a message saying
"Hey its Peter, I can pay you back for $THING, just follow <link> and enter your debit card number to recieve $AMOUNT right now"
I'd assume <link> is a google.com domain, which one could, in theory, trust. The page, on the trusted domain, would also clearly state the same information, "enter your debit card number to receive $AMOUNT from $PERSON (and profile pic probably) for $THING
You're right, but the average person isn't very discriminating or very able to keep track of who can and cannot be trusted, so I would expect problems to occur.
Is the concern here phishing? Checking that the page is HTTPS and the domain is *.google.com should be sufficient to thwart phishing attempts. Of course, your attack would still work against uninformed users, but you can protect yourself by always being sure to check the URL.
It is not always enough. For example, recently I have found several ways to spoof the URL and HTTPS lock on Google Chrome. So phishing seems to be a concern.
If you found a way to have the address bar show an HTTPS lock on a Google domain despite actually being on one, then you've found a big hole and you could make a lot of money by reproducing/reporting this security flaw.
The fact that you have found "several ways" is intriguing. You are either mistaken, or you're one of the greatest security researchers out there.
In that case, way to go, that is very impressive! I'm surprised the bounty was so low, honestly.
In response to your first comment, I should clarify that checking for a valid HTTPS URL SHOULD be sufficient, barring implementation errors in the browser. Of course, if the browser is insecure, all bets are off wrt web security. Implications may range far beyond phishing attacks in that case.
Thank you! I got involved with the security world recently and I'm really enjoying it.
And I would like to clarify myself, the comment I made earlier was a little ambiguous. The bug that got fixed only spoofs the omnibox and not the HTTPS lock. The others spoof both.
That said, when I am able to disclose these vulnerabilities, I intend to write a post about them.
> You don't need an account of any kind if you are the receiver here. You just put in a debit card and you get the money. So it's easier for the receiver but still requires a Wallet account for the sender.
No? Unless it's completely changed since I used it last.
You could send an SMS but it was a link to create an account (or $CashTag or whatever they call it) with the app. Then you put in your debit card. Then you can accept the cash.
There's no account creation flow on Square Cash. Just put in your debit card to receive the funds (and possibly some additional verification if you trip up the fraud algo)
It absolutely could have changed since I've used it. I'm hearing you might not need an "account" any more but you still need the app and/or some kind of quick verification? Probably worth checking out again.
In either case, I like that with Wallet you don't even need an app.
Seconded. Look at the comments here briefly: ACH? That's US-only. Debit card? That's first and second-world only. No discussion of the political or engineering implications of any of the options discussed. No discussion of opening hours, transfer reliability, best and worst case transfer latency, maximum value cap, legal framework for dispute resolution, etc. No discussion of what is probably the biggest recent development in the sector: Europe's IBAN (now live in many non-EU/SEPA locations). The picture is clear. (PS. If anyone needs a global perspective on business and consumer finance, tap me on the shoulder)
Cool. Pro-tip: Use the actually machine-parseable version I maintain at https://code.google.com/p/php-iban/ ... the officially issued text and PDF versions differ and the text version often has inconsistent formatting to boot.
A lot of US startups don't even consider the fact that there might be people living outside the US, neither in their US products nor in their US PR material.
Google Wallet killed independent settlement solutions on Android by demanding that applications on the App Store (now Google Play) settle via them. I implemented (one of?) the only major carrier settlement capable applications prior to this ban for a preloaded flagship application for Samsung in 2010. We billed AT&T and T-Mobile, both of which had almost the same API for client billing running through the Israeli (now apparently rebranding to appear American) company AMDOCS. (The rumours are true: by providing 'outsourced billing' they can basically spy on most mobile networks' customers... read the public portion of their client list sometime) Anyway, we were already doing pay by text (a carrier-specific configuration) for many years all over the world before that. There are providers who set up these integrations for you and provide global multi-market pay-by-SMS services, but the problem is that the average mobile carrier does not have a unified view of its customer: particularly pre-pay and post-pay customers may be subject to very different limitations on pay-by-text availability and maximum charges. Then there's backend settlement, often time-staggered on a monthly basis and incorporating exchange rate risk exposure, etc. It's a PITA to do manually for multi-market, but a real solution (settlement method neutral and incorporating the real qualities of a settlement chain, including risk, legal jurisdiction for issue resolution, insurance, maximum and minimum settlement time, maximum and minimum volume, supported asset types, etc.) has been indefinitely deferred by the likes of Google who seem happy enough to cozy up to the existing financial establishment instead of rocking the boat. Possibly we have some hope now with Chinese device manufacturers and WePay that the Chinese government's huge push for the RMB to become a global reserve currency and their rapidly growing global network of banks may yet provide for some cross-border payment innovation where the west's incumbents have so far failed.
> "No email? No problem! Now you can send money to anyone in your contact list using just a phone number."
Are there really people with phone numbers but no email? Given how easy one can get an email for free, and the prevalence of VoIP (both in standard and proprietary forms), I'd expect the other way around to be true.
Yes. For example, literally millions of people in India have cellphones and use them exclusively for SMS. These same people will likely not have reliable access to a computer for full-fledged e-mail.
It's been quite a few years since I've lived in the US so maybe I'm out of touch. But where I live you can send money instantly to anyone if you know their bank account number. You can do it online via your bank's website, via a mobile app, or at an ATM. Can't you do that in the US via the ACH system? I recall ACH was slow, taking a couple of days, but I don't recall if you could ACH money to other people or only between accounts you control.
The whole Paypal model is based on its reversal+ resolution process which usually favors buyer, requires an army of support personnel and has resulted in them being one of the most hated companies in world.
I've had excellent results with Google Wallet customer support. I've had to contact them a few times over the years, and they're some of the best customer support experiences I've had, not that that's saying much. Google's customer support seems basically non-existent for services that don't involve money, but as soon as money is involved it seems quite good
