New Product Development

The sample requests and responses in this guide provide only a very narrow slice of Amazon FPS functionality. The full product is divided into the five Quick Start implementations mentioned earlier in the guide (see Introduction to Amazon Flexible Payments Service). The following table gives guidance on which Quick Start implementation to use depending on your type of business and use case. You might use more than one.

All of the preceding Quick Start implementations use the same WSDL, but each one covers a different feature set. Likewise, you use different Co-Branded service APIs with each implementation to create different kinds of payment tokens. In this getting started guide, you created a single-use payment token; that is, a token that can be used once. Amazon FPS Advanced Quick Start, for example, offers multiple-use payment tokens, and Amazon FPS Aggregated Payments Quick Start offers prepaid and postpaid payment tokens.

The Amazon Payments home page (payments.amazon.com) provides a user interface for senders and callers to get Amazon Payment accounts, view them, and to perform some actions with them, such as canceling purchases. Using the Amazon FPS API, you can also program these functions into your web site. Your application needs to make sure that actions your web site performs are in sync with the actions taken in the Amazon Payments user interface, and vice versa. Amazon Payments sends transaction notifications for actions taken in the Amazon Payments user interface and some actions executed by Amazon FPS web service requests. Your application needs to be able to receive these Instant Payment Notifications (IPN) and change your records accordingly. IPN is covered in all of the different Amazon FPS developer guides.

Your application needs to keep a database of sender information such as the sender's name, shipping information, and, to keep those values secure, sender login names and passwords. As you create a database of senders, you must store with each sender transaction the callerReference value that you generate and the transactionId Amazon FPS returns in each Pay and Reserve response. These identifiers enable you to implement the full range of Amazon FPS functionality, such as providing transaction status information.

The functionality you make available on your web site or in your application should be sender-focused. Common sender tasks (beyond paying for a purchase) include canceling a purchase, asking for a refund, and getting the status of an order. Although senders can go to the Amazon Payments web site to view this information, they typically expect your web site to also provide this functionality.

Not discussed in this guide is the order fulfillment side of your business. Because the order date and shipping date of products typically fall on different days, a common business practice is to charge a sender's payment instrument only upon product shipment. Remember that you need to update Amazon FPS regarding such events. In this case, you send a Settle request to charge the sender's payment instrument, causing Amazon FPS to initiate the transfer of money to the recipient. We recommend you implement this functionality in your order fulfillment software so that you never forget to send Amazon FPS a Settle request.

In this guide, you, the developer, also serve as the recipient of the money. Amazon FPS Marketplace Quick Start enables a different scenario in which you are neither the sender nor the recipient, but the caller that hosts the recipient's e-commerce store. For that service, you charge the recipient a fee. This unique feature available in Amazon FPS provides a range of application possibilities unavailable in other payment web services.

This guide describes how to redirect buyers to the Co-Branded UI where they authorize payment. You have the option of co-branding that UI with your company's logo. The value of co-branding the CBUI web pages is that your branding appears along with Amazon's at the top of the payment authorization web pages. This makes for a smoother transition between the shopping and payment authorization steps in the purchase. To co-brand the web pages, you must provide the URL of your company's branding in the Co-Branded service request.

All of these topics are covered in greater detail in the Amazon FPS developer guides. Links to the guides are provided in the table in Which Parts of Amazon FPS Should You Use? and in Related Resources.

After you have tested your applications using the sandbox, you can start using the production environment by changing the endpoints of the Co-Branded service and Amazon FPS requests to the following URLs:

	Note
	All transactions in the production environment require a real payment instrument (credit card, bank account, or Amazon Payments balance) and move real money.

If you plan to use SOAP to make your Amazon FPS calls, then you need another set of credentials in addition to your AWS Access Key ID and Secret Access Key. These credentials are an X.509 certificate and corresponding private key, and you must associate the certificate with your AWS account.

	Tip
	If you're already using SOAP and WS-Security with another AWS service, then you already have these credentials and can skip this section.

For more information about X.509 certificates, go to http://www.webopedia.com/TERM/X/X_509.html.

You can either have AWS generate the certificate for you (which automatically associates the certificate with your AWS account), or you can upload an existing certificate you already own to the AWS site.

If you already have an X.509 certificate that you'd like to use, you need to upload it to AWS. Note that you upload only the X.509 certificate and not the corresponding private key.

You might find these additional resources helpful when you design your own application.