Why You Shouldn't Ignore Amazon's New FPS

Amazon has been highly-regarded in the developer circles over the past year with solutions that take advantage of Amazon's scale and pass the savings down to the developer. S3 and EC2 (like S3 but for scalable servers) have been widely adopted by coders for utter reliability, cost and not having to deal with the dirty work - maintaining servers and facing the issue of scaling when growth is vital. Yesterday Amazon released a new service for developers to bounce off the walls with - Flexible Payment Services.

Amazon FPS
In a nutshell, FPS is everything Amazon has learned about dealing with money transactions, processing credit cards and more, wrapped in a shiny API. This is a godsend for thousands including solo developers trying to sell a simple app they've made, people setting up online stores of their own, and the list goes on. Up until now many companies had to work directly with VeriSign to process online payments or reluctantly deal with PayPal, which usually brings up horror stories of eBay transactions gone awry. FPS will change everything.

Above all, I think FPS is going to be widely adopted for its rock-solid micro-payments support. More and more start-ups and online companies are offering small services to their users which cost almost nothing. Unfortunately, getting the money for these small services has proved to be a big problem previously, with high credit card transaction and processing rates. You have probably dealt with micro-payments many times before - iTunes Store songs, those 1 Facebook gifts and the like, although most people consider micro-payments as even cheaper items, within the cents range. FPS can run a transaction as low as 1 cent.

Change US coins

As an example of something someone could build with FPS utilizing micro-payments support, I have been thinking about a simple system enabling blog readers to use an opt-in subscription/donate model; readers would help support a blog with small donations or micro-payments. Ideally, sending a micro-payment with Amazon FPS would be an easy, one-click process, encouraging users to donate whenever they read an article they enjoyed, et cetera. The system could even be integrated into one's comment system - "Hey, I really enjoyed your tutorial on XYZ, 1 is attached".

Barriers of entry will be annihilated. More people will be encouraged to pursue that idea they've left on the back burner because they were unsure how to go about collecting payments. PayPal should be worried. As for another issue, I can say that people trust Amazon more than PayPal. If you ran a simple random sample and gave those 5,000 people a word association test, I bet that a good percentage of people would pair PayPal with scam or fraud. Don't get me wrong, I have been using PayPal for years without any issue; people just have a belief that PayPal isn't good with all of the "beware PayPal" type stories floating around.

However, you can't directly compare PayPal and Amazon FPS. PayPal is a complete payment management/transfer service, where as FPS is more of a tool to build something to handle similar needs, albeit in a specific situation. Although there will no doubt be someone trying to build a direct PayPal competitor based on FPS. Here's the main advantage of using FPS for your next store, service or web app - millions more people already have Amazon accounts than PayPal or Google Checkout accounts, making it tremendously easy for them to use your service. They don't have to make another account to pay for something.

Technically Speaking

Amazon Flexible Payment Services is a boon for several reasons: no startup costs, monthly fees or minimums to get started and it's Amazon-backed. As such, they have a helpful Resource Center with helpful code libraries (C#, Ruby, PHP and Java currently) and sample applications (Ruby, PHP and Java currently). Security-wise, FPS is just as secure as S3 and other services that might be used in almost mission-critical situations (doubtful that anyone would use S3 for anything mission-critical, it doesn't have a Service Level Agreement). With each payment transaction, you must get a short-lived security token from Amazon to allay the possibility of someone maliciously capturing the transaction and having their way.
A token is a unique, secure handle to the Payment Instruction. A successful payment transaction requires three compatible tokens, one each for the sender, the recipient and the caller.

Each application built on FPS is recommended to use (their sample PHP application uses it) an X.509 security certificate, which is then in turn used by OpenSSL.

In Short

Amazon's recently released Flexible Payment Services will provide developers, small companies and large companies alike to handle money transactions with ease while maintaining complete control. You will see many, many people build things around FPS solely for managing micro-payments. That code monkey 3 doors down in your dorm can make a site and provide simple tech support for 75 cents a request, while that popular blogger could send out schwag to his readers, only asking for the price of a stamp and envelope. A start-up could charge a dime for each message sent by non-pro account users within their social network, Pownce could charge 30 cents for each 10MB that you go over your allotted storage space; the possibilities are endless.

Would you take advantage of sending micro-payments through Amazon if a tech blog you read daily put up a micro-payments system up in lieu of bulky advertisements? What are your thoughts about FPS?

Update: Snook believes that micro-payments with FPS only work or work best when using Amazon Payments (which must have a balance in it before sending micro-payments) instead of just someone's bank account or credit card. I think he's right.

I applied for an FPS account and FYI they ask for things like DL#, bank info, credit card, address and business name. Also, I have been messing with Amazon's digital downloads sample micro-payments application. If you decide to use it as well, be careful if putting it on your public server and placing your AWS keys in SampleApp/usecases/config/developer.ini as it can be publicly readable if you don't give it the correct file permissions.