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.
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';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”.
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;
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."