Today, TechCrunch posted about Amazon PayPhrase going live. It appears that Amazon customers were notified of this feature, allowing them to set a phrase they can later use on 3rd party sites to check out quickly - just type in your payphrase and PIN and you're out. The TC post mentions a similarity to PayPal's student accounts, I am not sure I agree, but that's not the case. The interesting question (one also raised in the post) is - what new risks does a new feature introduce into the system?
There's a lot to be said about modeling the possible risks in a new payment feature, and I find it to be some science, some art. You have to weigh not only what users and fraudsters are doing now, but also what opportunities will they have once you introduce a feature, and understand how to design controls that mitigate the major issues without hurting functionality. That's why there's some art in it.
The main point the TC post was hinting to was the ease of user credentials being compromised. True, users forget and give away credentials without a lot of thought, and any service relying on users, as a crowd, to not get phished, is going to fail. This is why payment companies invest a lot in customer education (which I like, yet do not really support because of its passive nature) and customer engagement (which I really love) in risk management. It's been noted in the comments, and pretty straight forward in Amazon's page, that you cannot change anything in the account using payphrase, therefore cannot change a shipping address of change payment instruments, thus lowering the appeal of phishing payphrases. Not going to reduce the number of account take over cases, though, but will not boost it, either. What's more interesting is the fact that the combination of ultra-quick checkout and opening up flexible payment APIs are about to introduce a family of risks into the system; in this case, I'm thinking about payment-click-fraud.
I'm not sure how all payment companies that plan to open up to 3rd party developers prepare for the overwhelming new types of risks. I know there's a lot of thought put into that in PayPal, and am looking forward to the interesting discussions around risks in the upcoming convention. No doubt, it's a whole new world out there. So what can go wrong? Click fraud is a good example. As you can see in the link, this is an offense carried out on a platform, but not against the platform but rather towards its users. When an advertiser posts an ad, an automated ad-clicking bot can be used to inflate their advertizing bill tremendously, faking "real user" clicks without creating real value. Same goes for anyone who integrates payphrase or any other ultra-quick checkout: if a ring of fraudsters (or a shady competitor) decides to target you, they can just click away, have you ship multiple items and then deal with the chargebacks. They don't need the items; they just want you out of business. Without proper controls (monitoring, for example, user identity and velocity), new and small developers can find themselves scrambling to manage attacks even as soon as days after they integrate.
Does this mean that quick checkouts and 3rd party integrations are bad ideas? No, on the contrary. They just need to be managed correctly. Since I view risk management as a business enabling function, I think it's out role to help make this bold attempt (first by PayPal, later probably by others as well) successful. I also think that developer awareness is super important, and believe that engagement by all parties is a key component in making this new playground, where big payment companies will soon joust, a great success and a growth engine for eCommerce.
What do you think are the risks of an open developer platform?
Friday, October 30, 2009
Subscribe to:
Post Comments (Atom)
2 comments:
I think there are always two risk issues for third party payment providers outside of the banking system. Amazon and other businesses originating payments take the risk of charge-backs and unauthorized fraud. Consumers risk their checking account or card being compromised and possible identity theft. While I support entrepreneurship in payments, I'm afraid this solution simply will add more risks to payments being made via Internet. As an industry, we need to involve banks more in the payment process and "push" money instead of "pulling" funds.
Very interesting comment, Steven. We have a market where this happens, Germany, where a push method has evolved pretty independently because of the very low credit card penetration. However, I'm under the impression that banks in DE are constantly looking to find alternatives to direct debit: their fee cut is very small (and raising it will render this payment less attractive), consumers get little to no dispute privileges etc. Other than that, I'm not sure that using the banking system will fundementally remove risks from the system - bank payments have their own inherent risks.
Post a Comment