AWS News Blog
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;