Introducing Amazon Flexible Payment Service
A couple months ago the good folks at Amazon invited FreshBooks to be among their first few 3rd party integrators with Amazon Flexible Payment Service (FPS), the next leg in their amazing line up of web services. It follows smash hits like Amazon Simple Storage System (S3) and Amazon Elastic Computing Cloud (EC2). The service is not publicly available, and won’t be for several months, but we can now share with you the inside scoop and explain why FPS is an exciting platform for payment processing, and what it’s like to work with.
Over the last few weeks, Levi has been working closely with the Amazon FPS team to integrate their new payment gateway into FreshBooks. As the name suggests, FPS is very sophisticated because it is very flexible. It not only accepts multiple types of requests (SOAP and REST), but more importantly it also has unparalleled ability to control payment amounts and methods.
Finally, micropayments that work!
Anyone who has ever used Amazon Web Services has noticed Amazon can bill as low as only 1 cent a month. If you’ve ever been jealous they can do that and you can’t, well, now you can. With FPS, you can now bill as low as 1 cent, and Amazon will charge a transaction fee of one quarter of one cent. Bring back the penny candies, because this changes the game for the entire web. There may have been micropayment solutions before, but none backed by a major trustworthy player like Amazon.
I always wanted to run my own bank
Paying for each and every one cent purchase sounds like a headache for your customers. Amazon Flexible Payment System solves the problem by maintaining an account balance between every two parties. Much like a bank, you can add credit and make debits to your heart’s content and Amazon keeps track of the balance owing. Your customer can buy a bag of candies one penny at a time and only whip out their credit card once.
This is important and powerful. FPS is the first payment system that separates a charge from a payment. This makes it possible to pre-pay for services and then deduct fees over time from the balance. Think of independent digital music stores that let customers purchase, say, $10 credit to buy 100 songs for $0.10 each. Alternatively, you can accrue charges over time, and let your customers pay the balance owing all at once at the end of the month, much like your VoIP phone company charges long distance. This dramatically cuts down on credit card transaction fees.
Moreover, Amazon FPS provides a lot of control over your Amazon account transactions. For any payment, you can specify exactly how you want to get paid: directly out of another Amazon account, using a credit card, using a bank transfer (aka using the ACH eChecking system). Compare this to PayPal, where your buyer can use whatever method they want to pay for your product or service. If you want to cut down on credit card transaction fees, FPS can make sure your customers pay you with the lowest cost method.
Of course, for FreshBooks customers, we do not force your clients to choose any one payment method since getting paid faster is usually much better than cutting down on transaction fees.
Show me the money!
The astute amongst you may have noticed that one quarter of a cent is 25% of the transaction, which can add up. Rest assured that is only the cost for transactions under $0.05. Their fees scale well:
|Transaction size||Within Amazon Payments||Bank account (ACH)||Credit card|
|>= $10||1.5% + $0.01||2.0% + $0.05||2.9% + $0.30|
|< $10||1.5% + $0.01||2.0% + $0.05||5.0% + $0.05|
|< $0.05||20%, minimum $0.0025||n/a||n/a|
Additionally, qualified developers can apply for the following volume discounts for credit card transactions:
- 2.5% + $0.30 per transaction for payment volume from $3K- $10K
- 2.2% + $0.30 per transaction for payment volume from $10K – $100K
- 1.9% + $0.30 per transaction for payment volume over $100K
Unfortunately, because Amazon is only licensed to transfer money in the U.S., international customers can only pay by credit card for an additional 1% of the transaction amount. Additionally, in order to create an Amazon Payments account, the recipient must have a US-based bank account, billing address, and credit card.
Amazon has also taken extra security measures, which is singing our tune here at FreshBooks. For each and every payment transaction, we must request a new security token from Amazon that expires only after a short period. This greatly reduces the chance that an attacker in the middle can double charge your customers by intercepting the transaction.
To really get down into details, the PHP SDK also requires you to download an X.509 certificate, then use OpenSSL to create a .p12 keystore, and then convert it into a .pem keystore. All of this is in the interest of security.
Ruby and Java and PHP, oh my!
Speaking of SDKs, Amazon has really shown they get it by releasing the FPS SDK in Ruby, not just Java and PHP. This is the first payment gateway that has done this, and we applaud them for it.
Key tip: Levi tells me he had trouble with the Ruby SDK. For some reason, at least his version of Ruby (1.8.6) outputs two tags, contra the WS security standard, and therefore breaks the SDK.
It’s not easy being first
The biggest initial challenges we faced were simply getting IP access to the sandbox and making sure we had the most recent version of the SDK. Once we passed those hurdles, and we had some files that were missing (the PHP SDK requires a WSDL file that none of the other SDK’s require) the SDK was simple to install and I had it up and running within a few hours. Hopefully they’ll add the missing WSDL file by the time they release.
Another challenge Levi had with the FPS SDK was the lack of examples of actual SOAP requests. The PayPal API comes with a number examples of the SOAP structures, which helped when building the requests from scratch without using the PayPal SDK.
Key tip: Luckily, once Levi got the Amazon FPS PHP SDK up and running, all of the SOAP requests are available inside the log files (in
To save you the trouble, here is a basic Amazon FPS SOAP request for the following call in PHP:
$payResponse = $SoapClient->call( 'Pay', 'UniqueMessageId'.microtime(true), $keyStoreLocation, $keyStorePsswd, $payRequest, $namespace );
The elephant in the room
Well, you have to think about Amazon FPS as a payment service just like you think of Amazon S3 as a backup service or Amazon EC2 as a webhost. None of Amazon web services are meant to be fully packaged, ready to use systems. They are all lower-level systems. S3 is the storage for a backup system. EC2 has the raw Internet-connected machines you install the server goodies necessary for a modern webhost.
Building foundation computer-sciency services is easy to understand, but how does one write a more fundamental payment service? By stripping payment down to the raw functions: credits, debits, payments, payouts, and a ledger to keep it all organized.
Amazon FPS is meant for people who need more control over money flows, especially those who need the kinds of cheaper, smaller transactions in order to make their business feasible (think digital goods resellers, like digital music). In fact, you could probably build the next PayPal on top of Amazon FPS, and I have no doubt someone will try.
What’s also nice is that Amazon.com, through its more famous book, music, and merchandise channels, probably has millions of average customers that PayPal and Google Checkout do not, and now those customers are only a click away from your business. This greatly expands the marketplace of people willing to use person-to-person online payments, and that can only be a good thing.
In the meantime…
So, we’re looking forward to finishing up the integration of Amazon FPS with FreshBooks shortly. It looks like it will be a great alternative to PayPal and Google Checkout once it is fully released to the general public. In the meantime, you will be to access it indirectly through the FreshBooks API.