Google Wallet: Send money via text message | Hacker News Reader

Google Wallet: Send money via text message

googlecommerce.blogspot.com

94 pointshowsilly66 comments

Congratulations America we just caught up with Kenya circa 2007!

I guess it should be "Congratulations Google"? Banks (at least BofA) were offering such feature for quite a while now. PayPal did it for even longer.

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.

Or going very far backwards.

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?

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)

And the Philippines in 2005...

But, hey, we're getting there!

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.

I already did report them. The first one was fixed (CVE-2015-6782), got $1k from Google. There are three more they are working on.

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.

>Of course, if the browser is insecure, all bets are off wrt web security.

I guess this is a no go for now, then?

>There are three more they are working on.

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 should, I would love to read that :)

Wow, this thread reminded me of the "best HN comeback of all time":

https://news.ycombinator.com/item?id=35079

Sounds similar to Square's Cash, exploiting an ACH trick. Except setting up Cash for sending is magnitudes easier then setting up Wallet.

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.

All that's left is to do this exact same thing but in reverse. Let a GW user send a secure REQUEST link that only requires card information to pay.

> 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.

Isn't that exactly how Square Cash works?

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.

Gotcha. Sorry, I've only used it once and don't remember creating an account, but apparently I did.

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.

Don't need an app either. Can all be done in a browser.

Well that's great news. It wasn't always that way. I'm glad to hear it is.

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)

How does GW know where to deposit the money based on a Debit Card?

Im assuming the Debit card can trace back to the routing / checking account number associated with the checking account.

It uses a reverse ACH trick. It's like charging the debit card, but in reverse. It's also why it's nearly instantaneous.

Square's Cash app does the same thing.

It files a refund, basically. It just happens to be a refund for a non-existent initial purchase.

relevant link: https://developer.visa.com/vpp/

And of course, 'anyone' covers around 5% of the world.

Ok, we took 'anyone' out of the title above.

Maybe this issue needs to be addressed in the whole startup culture.

A lot of startups don’t even consider the fact that there might be people living outside the US, neither in products nor in PR material.

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)

Indeed.

Not even Google manages to handle anything except for credit cards or PayPal – horrible.

I was thinking about writing a small JS IBAN verification lib that also format and shows the user the issuing institute and Country.

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.

No details of WHERE exactly in the world this works, I presume this a yet another US centric service

Yep, I guess so, looks like they are doing "reverse charge" to debit cards. I don't think this works in any other country than the U.S.

Frankly many other countries already have the equivalent of this service.

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.

But will the service work in India?

I assume that they mean, "No email [address for the target in your contacts list]?"

Sounds a bit like https://www.pingit.com/#!/ or http://www.paym.co.uk/

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.

I wonder what happens if that text message is intercepted; can someone claim the money before the rightful recipient?

I'm guessing they thought of that possibility.

And I'd love to hear their thoughts about it.

Well, email, which is comparatively easy to intercept has worked for PayPal and others for over a decade.

Actually it hasn't

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.

Well, PayPal has been pretty successful. The things you listed don't have much/anything to do with intercepted email fraud.

Are there fees involved? They don't seem to say anything about it in the post.

No. Just like it doesn't cost you anything to send money to friends & family on PayPal or use Square Cash.

I'd love to get rid of PayPal so we'll see how this works.

I wish they add support for sending money internationally. That would be a killer feature for Google Wallet!

Does this work for sending money to prepaid debit cards?

great cuz I want google eating up yet more of my personal habits and info

I'm sure the customer support is just ace.

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

http://www.computerweekly.com/news/4500251756/Security-flaw-...

Ffs

Reply on news.ycombinator.com