Amazon Simple Pay Concepts

Topics

In order to understand Amazon Simple Pay and to use it most easily, you should be familiar with the terminology and concepts found in this section.

Simplified Button Creation and Customization

Implementing the advanced features of Amazon Simple Pay does not require a high level of programming expertise. Developers create the HTML for one or many buttons dynamically, making small per-product adjustment as needed.

Amazon Simple Pay Implementation Process

1

You need the Amazon Payments business account to use the most basic Amazon Simple Pay features. You use the business sandbox account to test the buttons you create. Getting both accounts is described in "Before you Begin" in the Amazon Simple Pay Getting Started Guide.

To work with the Amazon Flexible Payments Service APIs detailed in this guide you need an Amazon Web Services developer account. For more information on getting a developer account, see Amazon Payments Developer Account.

2

Create an HTML button form dynamically or using the Amazon Simple Pay user interface. As a developer you have flexibility to adjust the button functionality, its content, and whether to sign it for security. If you do choose to sign the button, you also can set the signature strength to either SHA256 or SHA1.

3

The button form provides the exact functionality and features required by your chosen button. Insert the HTML form element into your web page, again either manually or dynamically, to make it available to users.

4

Submit the form on the user's behalf if you need to control the flow between your web site and Amazon Payments.

5Add the code to your web site to handle form responses when someone clicks the Amazon Simple Pay button. You can capture button responses, IPN responses, and certain Amazon Flexible Payments Service action returns. You can also ensure that the responses returned to your application have originated with Amazon by programmatically validating the signature (either using the VerifySignature action, or programmatically using PKI based authentication).
6

Test the button. With a developer account, you can simulate error conditions such as denied payments.


Five Commonly Used Buttons

Amazon Simple Pay enables you to create five different payment buttons that online shoppers can use to purchase items. Each button perform a different task:

  • Standard—You use standard buttons to offer Amazon Simple Pay as a standalone payment method for one-time purchases.

  • Marketplace—The marketplace button lets you display and sell the goods of other sellers, optionally charging them a fee for the service.

    The marketplace button is similar to the standard button in appearance. However, it is functionally different, because it involves three parties instead of only two.

  • Donation—Donation buttons are an easy-to-use and secure way for US-based, IRS-certified 501(c)3 non-profit organizations to solicit donations.

  • Marketplace-Enabled Donation Button—A special donation button which enables third parties to collect donation funds on behalf of a 501(c)3 non-profit organization.

  • Subscription—Subscription buttons enable an easy way to charge your customers a recurring fee.

Co-Branding with Amazon Simple Pay

Co-branding is simply adding your merchant logo to each of the payment authorization web pages.

When your buyers click one of your Amazon Simple Pay buttons, the browser navigates to the Amazon Simple Pay payment authorization web pages (hosted by Amazon). These web pages require the buyer to sign in, specify a payment method such as a credit card, and authorize the payment. If you have ever purchased something on Amazon.com, you're familiar with the checkout process.

Clicking an Amazon Simple Pay button directs buyers away from the merchant's web site. However, by including your merchant branding on the payment authorization web pages, buyers don't feel as if they've completely left your web site to pay. Jumping from your web site to Amazon's without co-branding could confuse buyers. Co-branding provides continuity between the shopping and purchasing experience.

For more information about setting up co-branding, see Configuring Default Button Values.

Settling Later Versus Paying Now

A buyer's payment instrument is not necessarily charged immediately for a product when he or she clicks an Amazon Simple Pay button. Amazon Simple Pay standard, marketplace, and donation buttons give the developer the option of either charging the buyer immediately or settling later. If you choose to settle later, Amazon Payments reserves the purchase price against the buyer's payment instrument.

When you create a standard, marketplace, on donation button and you decide to settle later, use the Amazon Flexible Payments Service Settle action to implement the settle functionality. Settling and Refunding Transactions Programmatically describes how to use the Amazon Flexible Payments Service API to settle a transaction.

Amazon Flexible Payments Service Actions

Amazon Simple Pay handles many tasks for you so that you do not need to write code for your web page. However, there are some tasks that Amazon Simple Pay does not handle. Sometimes, you can use Amazon Flexible Payments Service (Amazon FPS) actions to add some functionality to Amazon Simple Pay, and some of those actions are described in this guide. The actions that are described in this guide are:

 

[Note]Note

In order to execute FPS actions, you must have an AWS developer account. For more information, see Amazon Payments Developer Account.

Amazon Payments Developer Account

If you plan to work with Amazon Flexible Payments Service actions such as CancelSubscriptionandRefund, Refund, or Settle, you must upgrade your Amazon Payments business account to an Amazon Payments developer account. In addition, because the developer account is separate from the business account, you must get a developer sandbox account to test your FPS actions.

[Note]Note

You do not need an Amazon Payments developer account to use the VerifySignature action.

To upgrade to an Amazon Payments developer account and get a developer sandbox account

  1. Go to http://payments.amazon.com. Click the Developer tab.

  2. On the Developer tab, click Sign up for this Service.

    The What You Need to Sign up for Amazon Flexible Payments Service displays, as shown in the following figure.

  3. Click Sign Up and follow the instructions on the web pages.

    We recommend that before you put your solution into production, you test it in the sandbox. The developer sandbox is not the same as the business sandbox, so you must get an account in the developer sandbox to test the Cancel, Refund, or Settle actions. This allows you to test your actions without real money exchange.

  4. Go to https://payments-sandbox.amazon.com/sdui/sdui/index.htm.

  5. Click Enter the Sandbox as shown in the figure above, and follow the instructions on the subsequent pages.

Developer Sandbox

We recommend that you test all of the buttons you create before putting them on your web site. The Amazon Simple Pay Getting Started Guide, has instructions on setting up an Amazon Payment business account and an Amazon Payments business sandbox account. However, in order to execute Amazon Flexible Payments Service (Amazon FPS) actions, you must also have an AWS developer account and its corresponding developer sandbox account. You cannot test Amazon FPS actions using your business account sandbox. To get your Amazon Payments developer account, see Amazon Payments Developer Account.

In the developer sandbox you can operate the advanced features of Amazon Simple Pay buttons without incurring charges or making purchases. For more information about using the developer sandbox, see Testing Your Applications in the Amazon Payments Sandbox.

Keeping Payments Secure

Payments between buyers and merchants using Amazon Simple Pay are handled through web service requests. To make these requests more secure, Amazon Simple Pay uses the following means of securing requests:

  • SSL —All requests communicate over Secure Sockets Layer using HTTPS

  • Signed Buttons —If you choose, you can opt to sign your buttons with a signature based on the button parameters and your AWS access identifiers, which provides a way for Amazon to verify that a button action originated from your application. The method of signing is based on signature version 2, which supports the SHA1 and SHA256 encryption algorithms. For more information on signature version 2, see About Signature Version 2

    The instructions in this guide have you create signed buttons. For complete information on creating a signed button, see Creating Button Forms Dynamically

    Amazon Payments uses the signature to validate the requests it receives. A signed button's signature is based on the parameter values contained in the form.

  • Signed and Verifiable Responses —Both the Return URL and IPN responses are also signed, using the signature version 2 method. The FPS Action VerifySignature enables you to easily check that the content in the response has not been modified after sending.

    If you wish to programmatically validate the signature on your end, you can do so using PKI algorithm and make use of certificate location provided in the responses. For more information, see Client-side Signature Validation.

About Signature Version 2

For inbound requests, signature version 2 signing uses the entire HTML button form as the basis for the signature, and encryption is based on the unique security credentials for your account.

For outbound notifications, signature version 2 provides two ways to verify that return URL responses and IPN notifications originate from Amazon Payments:

  • A new Amazon FPS action, VerifySignature, enables you to securely check a response using a server-side call. This is the simplest and recommended way. For more information, see VerifySignature.

    [Note]Note

    You don't have to sign the VerifySignature request, nor do we require you to have a developer account to invoke VerifySignature.

  • Both the return URL and IPN responses also include a certificateUrl parameter, which contains a URL to a signing certificate. If you prefer to validate the signature on the client side, you can use the certificate for validating the response. (The certificate is cached on your server and automatically updated when needed.) For more information, see Client-side Signature Validation.

For inbound requests, signature version 2 supports AWS access key rotation, further enhancing the security of your button content. For more information, see Access Key Rotation.

[Important]Important

The previous method for signing will expire on 01 November, 2010. At that time, any signing you do with your access keys must be done using the new method.

Using Access Identifiers

When you have your AWS developer account, download your access identifiers. You will need them for sending REST requests and for signing buttons.

  • AWS Access Key ID You use this to identify yourself when you send requests to the co-branded service or when you send REST requests to Amazon FPS

  • AWS Secret Access Key You use this to generate URL signatures that provide tamper-proof requests

[Important]Important

You can use these access identifiers in both the sandbox and the production environment.

To view your Access Key ID and Secret Access Key

  1. Go to the Amazon Web Services web site at http://aws.amazon.com.

  2. Point to Your Account to display a list of options.

    You will be prompted to log in to your AWS account if you are not logged in.

  3. Click Security Credentials.

    Your Access Key ID is displayed on the resulting Security Credentials page. Your Secret Access Key remains hidden as a further precaution as shown in the following figure.

    AWS Access Identifiers Page
  4. Click Show in the Your Secret Access Key: area to display your Secret Access Key.

  5. Secure these keys locally for later use in signing buttons or sending FPS requests.