|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
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.
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
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.
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.
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.
Submit the form on the user's behalf if you need to control the flow between your website and Amazon Payments.
|5||Add the code to your website 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 using the VerifySignature action.|
Test the button. With a developer account, you can simulate error conditions such as denied payments.
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 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 website. However, by including your merchant branding on the payment authorization web pages, buyers don't feel as if they've completely left your website to pay. Jumping from your website 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.
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 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:
In order to execute FPS actions, you must have an AWS developer account. For more information, see Amazon Payments Developer Account.
If you plan to work with Amazon Flexible Payments Service actions such as
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.
To upgrade to an Amazon Payments developer account and get a developer sandbox account
Go to http://payments.amazon.com. Click the Developer tab.
On the Developers tab, click Sign up for Amazon FPS.
The What You Need to Sign up for Amazon Flexible Payments Service displays, as shown in the following figure.
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
Settle actions. This allows you to test your actions without real money exchange.
Click Create Account or Sign In and follow the instructions on the subsequent pages.
We recommend that you test all of the buttons you create before putting them on your website. 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.
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.
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 the Amazon FPS action,
VerifySignature, which enables you to securely check a response using a server-side call.
The original implementation of signature version 2 supported client-side signature validation using PKI. Client-side signature validation was deprecated on November 3rd, 2009, and as of 10 February, 2011 it is no longer supported. If you have been using client-side signature validation, you must switch to server-side validation using the FPS action
The previous method for signing (signature version 1) was deprecated on November 3rd, 2009, and as of 10 February, 2011 it is no longer supported. Whenever you sign a request with your access keys, you must now use signature version 2.
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 - Each Access Key ID has a Secret Access Key associated with it. This key is just a long string of characters (and not a file) that you use to calculate the digital signature that you include in the request. Your Secret Access Key is a secret, and only you and AWS should have it. Don't e-mail it to anyone, include it any AWS requests, or post it on the AWS Discussion Forums. No authorized person from AWS will ever ask for your Secret Access Key.
When you create a request, you create a digital signature with your secret key and include it in the request along with your Access Key ID. When we get the request, we use your Access Key ID to look up the corresponding Secret Access Key. We use the key to validate the signature and confirm that you're the request sender.
You can use these access identifiers in both the sandbox and the production environment.
Your Access Key ID and Secret Access Key display when you create your AWS account. They are not emailed to you. If you need to see them again, you can view them at any time from your AWS account.
To view your Access Key ID and Secret Access Key
Go to the Amazon Security Credentials page at http://aws.amazon.com/security-credentials. If you are not logged in, you will be prompted for your user name and password.
Your Access Key ID is displayed on the resulting Security Credentials page in the Access Credentials area. Your Secret Access Key remains hidden as a further precaution as shown in the following figure.
To display your Secret Access Key, on the Access Keys tab, under Secret Access Key, click Show.
If you decide that it is necessary to change your access keys, the security credentials page (available from your account page at the Amazon Web Services website at http://aws.amazon.com) enables you to create a second set, and allows you to activate and deactivate the sets independently.
With both sets active, you can propagate the new set to your applications over time, maintaining the high security that signing provides. Since both sets are valid, you don't have to take your entire application down to incorporate the new keys. When the distribution is complete you can deactivate the old set.
You can have two sets of keys only. Both, one, or neither of them can be active.