InfoQ

News

Amazon FPS: customized payment service & DSL

Posted by Sadek Drobi on Aug 15, 2007 12:42 PM

Community
Architecture
Topics
Domain Specific Languages,
SaaS,
Business
Tags
Amazon
On August 3rd, Amazon released a limited public beta of its new Amazon Flexible Payment Service – Amazon FPS. Amazon’s CTO Werner Vogels asserts that FPS offers “unmatched flexibility” to developers who need to introduce a payment management service in their application. Along with reduction of transaction costs, notably for micro payments, FPS makes it possible and easy to define a customized charging model using a capability called Payment Instruction.

Payment Instructions let developers define an unlimited number of individual payments conditions for each party to a transaction - a sender, a recipient and a caller (party making the API calls to Amazon FPS, acting as a recipient or as a third-party enabling a transaction).

This way, according to Amazon, FPS allows developers to create a payment service perfectly adapted to business needs and to set up relatively complex and innovative business models. This is why Paul Stamatiou believes that Amazon FPS cannot be directly compared to traditional payment services. It is not a complete service for payments process but “more of a tool to build something to handle similar needs, albeit in a specific situation.”

Amazon provides examples of possible Payment Instructions:
  • Transaction Amount: Specify fixed minimum, maximum, range, or specific amount for a certain payment.
  • Transaction Date: Configure a payment transaction to be executed at a specific time (e.g. specific day, weekly, monthly, or date range).
  • Spending Limit: Set daily, weekly or monthly limits on number of transactions or total amount spent, to control spending on your application.
  • Recipient List: Specify recipients who are authorized to access and receive funds.
  • Payment Method: Specify the payment methods (credit card, bank account debit, balance transfer) you want to accept through your application.
  • Fees: Control which party pays the Amazon FPS charges.
Once Payment Instructions are formulated by each party, a piece of FPS functionality called GateKeeper has to verify that they are compatible and install them in order to proceed with a transaction:
Developers use the InstallPaymentInstruction API to install Payment Instructions, and FPS passes back a "token." 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.
Payment Instructions can be specified through provided user interface pipelines presented as terms of service or they can be described programmatically, using the GateKeeper domain specific language. Duane Krause provided insights into the design of this DSL:
I designed this language when I was at Amazon. […] The purpose of this language is to facilitate date and currency calculations where different parties write different parts of the calculation. It also facilitates assertions statements such that if any of the statements evaluate to false, the transaction will not occur. This allows parties to set conditions and rules, similar to a dynamic contract, but via these GK code snippets. All of the snippets are combined together and run at once.
For example, the following Gatekeeper code creates a multi-use token with specific usage limits (from the documentation):
string MyTokenUsageLimit1Type := 'Amount';
TransactionTimestamp <= '2008-10-284T05:22-0700' orSay 'TransactionTimestamp used after validity';
string PaymentMethod := 'abt';
MyRole == 'Sender' orSay 'Role does not match';
money MyTokenUsageLimit1 := 'USD 100';
duration MyTokenUsageLimit2Period := '1 months';
string MyTokenUsageLimit2Type := 'Count';
integer MyTokenUsageLimit2 := 5;
According to Krause, one of the reasons why Amazon chose to design a special-purpose language for its new payment service “was a security concern about giving too much capability, as might be found with a more general language.”  Moreover, it offers the expressiveness which helps to “simplify complex tasks”.

For Paul Stamatiou, FPS is a significant innovation in the field of payment management services based on "everything Amazon has learned about dealing with money transactions."

No comments

Reply

Exclusive Content

Measuring Agile in the Enterprise: 5 Success Factors for Large-Scale Agile Adoption

Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He presents the factors which contributed to the success of BMC's Agile adoption.

Tom Preston-Werner on Powerset, GitHub, Ruby and Erlang

In this interview filmed at RubyFringe 2008, Tom Preston-Werner talks about how both Powerset and GitHub use Ruby and Erlang, as well as tools like Fuzed, god, and more.

David Laribee on Alt.NET and its Mission

David Laribee discusses the purpose of ALT.NET, its mission and future.

Discover RailsKits and Stop Writing Redundant Code

Ruby on Rails has become a popular Ruby framework for creating web applications in recent years. An aspect of creating a web application is the need to repeatedly create the same base functionality.

A Formal Performance Tuning Methodology: Wait-Based Tuning

Steven Haines talks about tackling web application performance tuning by proposing a method called wait-based tuning.

Shaw and Fowler About Forging a New Alliance

Shaw and Fowler talk about the need for a new relationship between the business department and the IT department. Studies have shown that projects mostly fail due to miscommunication between the two.

How to GET a Cup of Coffee

In this article, Jim Webber, Savas Parastatidis and Ian Robinson show how to drive an application's flow through the use of hypermedia in a RESTful application.

Archaeopteryx: A Ruby MIDI Generator

Eccentric artist turned overnight anti-celebrity, Giles Bowkett captures the heart and soul of RubyFringe as he demonstrates his revolutionary Archaeopteryx MIDI drum pattern generator.