Ka-Ching!

Ever since the first Amazon Web Service was released in mid-2002, we have encouraged developers to use them to create new types of businesses.

This encouragement has taken many forms over the years. Let's revisit some of the more interesting moments in the last 5 years of AWS history...

Our customer agreements have always been written so as to allow commercial use of our services, without the need to negotiate any special terms and conditions with us. This might seem like I am stating the obvious, but it isn't; there are many interesting web services out there which cannot be used for commercial purposes without a special license.

Since the first release of the E-Commerce Service in 2002, developers have been able to use the Amazon Associates program to monetize the traffic that they send to us. This pioneering service proved that the idea of "tearing down the walls" to allow developers access to our product data was both practical and valuable; over the years we have seen hundreds of different applications which take advantage of ECS and the Associates Program in unique and creative ways.

Moving right along, the Amazon Mechanical Turk gave organizations access to a world-wide, on-demand workforce, spurring developers like Nathan McFarland and Rachel Richard to create CastingWords, connecting people in need of audio transcripts with those capable of doing the work, facilitating the transfer of work, work products, and payment between each of the parties as needed.

Then we unveiled Amazon S3, started measuring all of those stored and transferred bytes of data, and billing developers for exactly what they used, no more and no less. Developers quickly caught on to our Web-Scale concept and started to build small, economical applications which could easily scale to tremendous proportions without the need for a large, up-front investment in disk drives, servers, or bandwidth that might or might not actually be needed. Many developers now tell us about how they've survived an appearance on Digg or Slashdot without breaking a sweat or breaking the bank.

Amazon EC2, and especially the new Paid AMI feature, put even more power into the hands of developers. Adding to the Web-Scale concept, developers could suddenly bring on additional computing power at the time that they needed it, allowing them to be parsimonious in their use of server and financial resources. Paid AMIs gave developers the ability to create a "business in a box," encapsulating code and a payment system into a single Amazon Machine Image or AMI which can leverage and monetize their proprietary business knowledge, code, or other expertise.

Now let's take a short excursion back to the year 1995, when Amazon.com was launched. At that time people weren't very familiar with the idea of shopping online. The idea of typing a credit card number in to a web form was new at the time and it took people some time to become comfortable with the concept. As a pioneer in this space, Amazon did a lot to help potential customers gain confidence in this method of payment. The fact that we now have 69 million active customers is a pretty good indication that we've succeeded in doing this.

Fine, you say, but where are we going with all of this?

At many of my presentations, audience members have frequently asked if we were thinking about exposing the component parts of our payment processing system as a web service. Well, we were doing a lot more than thinking about it, we were actually doing it. Because we don't talk about products before they are ready, I would simply acknowledge that this was a "good idea", promise to pass it along to the product teams, and then move on to the next question.

Today we are rolling out the Amazon Flexible Payments Service (or Amazon FPS) in beta form. The "good idea" has become a reality and developers now have yet another way to build scalable, profitable online businesses.

We've taken all that we know about dealing with credit cards, bank accounts, fraud checking and customer service and wrapped it all up into one convenient package.

In much the same way that S3 and EC2 allow developers to forget about leasing space in data centers, buying servers and negotiating for bandwidth, FPS shields developers from many of the messy and complex issues which arise when dealing with money. Once again, we take care of the "muck" and developers get to focus on being innovative and creative.

Designed specifically for developers, the "F" in FPS shouldn't be taken lightly. This is a very rich service -- the API document is over 250 pages long.

FPS provides developers with a rule-based processing model. The FPS Gatekeeper system cross-checks the payment instructions from each party in order to confirm the validity of each transaction. Using this model you can create one-time or recurring transactions, transactions limited by date, by amount, or even by a list of authorized senders or recipients. You can even aggregate a slew of micro-payments into a single large transaction that's of a reasonable size for credit card or other payment processing.

Since we've been processing payments for over ten years, we have a really good understanding of the cost and fee structures which are associated with each type of  payment method.  The cost to process a credit card, a bank account debit, or an Amazon Payments balance transfer differ greatly from each other. FPS exposes these fees directly, passing on the savings to the developer while also making provisions for the volume discounts available when large volumes of credit card payments are processed.

Any new entrant into the payment processing space faces a classic "chicken and egg" problem. Until there are lots of items to pay for, there's no real reason for people to sign up for the service. Vendors are reluctant to do the integration work needed to accept a new form of payment until there is a critical mass of people willing to use it. Fortunately, we have both ends of poultry life cycle covered. We also sell chickens and eggs, but that's another story entirely!

Seriously, the 69 million active Amazon.com customers can now use FPS to pay for the applications that you'll undoubtedly want to build. On the other end, the first wave of FPS applications will be available very soon. Here's what we know about so far (each of these developers will be posting details of their FPS implementation in the coming days):

• Jungle Disk will use FPS to support a subscription-based personal backup system.
• Freshbooks.com ("Painless billing") will allow for FPS-based payments between small businesses.
• Buxfer.com ("Track your money. Effortlessly.") uses FPS for peer-to-peer (P2P) money transfer, for settlement of IOU's between friends.
• Beetlabs.com ("Music feeds people.") combines electronic music from the Necodo application and social networking.

We anticipate that lots of new applications will start to come online in the coming weeks and months as FPS becomes available to more developers. As always, we will be featuring these applications in this blog as we become aware of them.

As you can see from the FPS Home Page, there are no minimum fees and no startup charges to use FPS. All pricing is per-transaction based on the transaction size and the payment method.

There's an FPS Sandbox so that you can test your applications under controlled conditions without actually moving real money around. We've even set things up so that you can simulate various types of errors in the payment process so that you can test your application's error handling logic.

As of this post FPS is now in a limited beta. The entire payment system is fully functional and the applications listed above are now capable of dealing with real money and real transactions. As you can imagine, there's a substantial amount of behind the scenes work happening here and we are planning to increase the load on our systems and on our people in a controlled fashion.

We are accepting signups for the FPS beta now.

We'll let as many folks in as possible and the rest will be put on a waiting list. As the beta moves forward we'll give them access to the beta in order of sign-up. Developers on the waiting list will be able to write code and to test it against the FPS Sandbox.

For more information you can consult the following resources:

• FPS Home Page
• FPS Documentation
• FPS Getting Started Guide
• Amazon Payments Account Management
• Resource Center Code Samples - C#, Java, PHP, and Ruby code.
• Developer Forums
• FPS Sandbox
• Amazon Payments Account Management

Ok, developers, the next step is up to you. Digest all of the info, come up with a game-changing concept, and execute on it!

-- Jeff;

Comments

[Richard Wallis]

This is awesome - now all I have to do is get past the 500 server error to sign up for the beta ;-)

[Fresh Sunir]

Jeff, thanks for inviting us into the program. Just so you know, we've put a detailed account of our experience so far at http://www.freshbooks.com/blog/2007/08/03/amazon-flexible-payment-service/

[Aaron]

Hey Jeff, thanks for the mention! We're really excited to be one of the first groups to board the Amazon FPS bandwagon. We see this being a really big deal for our users, and we're hoping to wrap up our integration work shortly. It's coming along famously.

We blogged on our experiences so far here:
http://www.freshbooks.com/blog/2007/08/03/amazon-flexible-payment-service/

Gives you a bit of an idea on what it's like to be first-in. Always a harrowing experience when you're breaking new ground with no real-world examples to follow! We included a couple bits of technical help in our post, so you can get some idea of how integration works without digging through all the documentation.

I can't wait to see FPS in action; the very thought of a payment service without any fees beyond the individual transaction is just phenomenal. I don't know if it'll be a micropayment revolution, but it certainly increases the chances of such a thing.

At any rate, it'll certainly be an online payment revolution. Should be fun to be a part of!

[Susan Reynolds]

Thanks for giving us the teasers for this on twitter.com Jeff. You continue to put a warm human face on what could be simply a (big dry) financial story to those not immediately affected by it.

The humor of following the thread as the twittersphere was classic.

[Susan Reynolds]

Thanks for giving us the teasers for this on twitter.com Jeff. You continue to put a warm human face on what could be simply a (big dry) financial story to those not immediately affected by it.

The humor of following the thread as the twittersphere was classic.

[Ara]

Is there any mechanism to store a customer's credit info securely with Amazon so that they do not need to reenter CCs?

[Ahmad Alhashemi]

Interesting.

But I couldn't find anything about your policy regarding international non-US developers.

[QCSitter.com]

I'm about to add payment capabilities to one of my company's websites and I'm fighting myself one which service to use, Google Checkout, PayPal, or now Amazon!

I love AWS and everything they've done but the pricing is pretty much the same on all of them and Amazon lacks true international payment support (big deal now-a-days).

My questions are:

1. When will AWS FPS support international payments completely?

2. Why, specifically, should I choose Amazon over the others (other then the pre-existing Amazon.com user base)?

[AWSFan]

"2. Why, specifically, should I choose Amazon over the others (other then the pre-existing Amazon.com user base)?"

Well,FPS is offering more features like recurring payments,prepaid etc,which might suit your business(in future,if not now)
Also,the fees for micro-transactions seem to be low.

[Damien Jorgensen]

This really does look intresting, im sure our clients will love it as an alternative!

[Abhishek]

You guys are awesome. This is a great addition to your already succesful S3 and Alexa.
I have a post with some additional ideas. I would love to see AWS as the true ecosystem where services can easily be launched.

Take a look and let me know what you think.
http://abhishek.tiwari.com/2007/08/05/amazon-the-services-operating-ecosystem/

Abhishek

[emmmc]

It would really help if
a) the rates were competitive (they're not)
b) there was a significant SLA commitment (there is not)

Until the overall offering is improved this feels like Amazon is marking up it's own merchant rate by 200% and pawning it off to 3rd partiess when there are much more established and economically beneficial processing services out there.

Lame duck until the rates are sub 2%.

[Dave]

most excellent pink floyd references. keep steppin' out jeff :)

[Rob Perry]

Have you considered Voice Biometrics to confirm account holder identity and verify online payments? You can now even use your voice to 'speak on the dotted line'

The technology has come a long way in the past few years and the benefits are obvious.

Fast, easy and intuitive - no user training is required;
Highly secure to reduce fraudulent transactions;
Verifies the physical presence of the individual accessing the web site enabling cardholder present rates to be negotiated;
Identity protection - taking the customers concerns seriously;
Defeats phishing and deters fraudsters;
Permanent audit trial of caller verifications to reduce repudiation;
Eliminates the costs associated with lost or forgotten passwords;
Reduces instances of user lock out associated with failure to remember passwords;
Improved customer experience - no more PINS, passwords or memorable information to remember.
We are now presenting to UK companies where the interest has been exceptional.