You are here
Amazon FPS (flexible payments system) in a nutshell
A few weeks ago I looked into Amazon FPS (Flexible Payments Service), just to see what our options are for premium services like commercial support. You know, the stuff we can't give away even if we wanted to because their are real costs involved which we couldn't subsidize without going bankrupt.
Note that we're probably not going to be using FPS in the near term but I did research it exhaustively before I ruled it out (for now). While it's fresh in my mind here's the summary for the benefit of those who might be considering it as an option.
FPS has two modes of operation:
- the regular web service mode
- the "hosted" Amazon Simple Payments mode
Let's start with the regular web service mode.
Amazon Flexible Web Payments (web service)
The documentation is hundreds of pages long and it can seem complex but most of it just repeats a few basic concepts.
Payment authorization => Payment token
The underlying concept is simple. Amazon is your payment service. They mediate transactions of all sorts with your users, which may not fully trust you or your (potentially) insecure website with their financial stuff. But they trust Amazon.
To resolve this trust issue Amazon, unlike other financial services (e.g., merchant account providers or payment gateways) are always part of the user experience loop. Your site can't settle things with Amazon Payments in the background. One way or another authorization is always provided on Amazon's site, which your users of course have to log into.
As a small consolation, Amazon's payment pipeline can be co-branded by adding your logo, but that's as far you can go.
After authorizing the payment, the user is redirected back to your site bearing a gift: a payment token, which is really just a random unique ID that points to an entry in Amazon's payments database which represents the payment "contract" the user has just authorized.
You can ask Amazon to ask the user to authorize a range of payment authorization types. A one-time payment, a multi-use payment, a recurring payment at regular intervals, a prepaid balance which you can decrement value from, and a postpaid credit balance.
A one-time payment authorization is like asking for cash and is the simplest. However if you use it exclusively you'll have to keep asking the user to authorize more payments which can provide for a bad user experience.
Other payment authorization types fall somewhere between a cash one-time payment and a credit card which I just trust you to charge me appropriately.
What they have in common is that unlike a credit card they are strictly defined and limited in advance. The user sees all the fine print and has to accept it.
And that's a big gotcha. Multiple payments or postpaid? User has to authorize in advance a maximum spending limit after which the authorization expires. Recurring payments (e.g., a subscription)? Automatically expire after one year after which the user has to create a new payment authorization.
For example, the experience of authorizing a postpaid payment (I.e., the closest thing to a credit card type authorization that FPS offers) is all too close to signing up for a new credit card. And then signing up for a new credit card when the previous credit card maxes out a year later.
Amazon do this to minimize charge-backs on credit cards by for most users I expect the experience would be complex and kind of scary. You can't just skim through this part or do it drunk.
Back-end processing of payment tokens
Getting a payment token isn't the same as getting payed. It's just half the story, though once you get the token the user's involvement is finished (for this payment authorization).
It's still up to your application's back-end to pass the token to Amazon's payment API to make money change hands. Amazon doesn't make any assurances that the API will always be in-order so you'll probably want to add retry logic to your application, for robustness, even if you are just processing a one-time payment.
In case it's not clear, multi-use or recurring payment tokens don't operate themselves. Your application's billing logic will have to make a request to Amazon API whenever it's time to charge, just like with a credit card, except with more restrictions.
To make all of this complex logic and back-end stuff a bit easier to digest Amazon (like PayPal and others) provides a free development sandbox you can use to test your site before it goes into production with play money.
Extra gotchas
- There doesn't seem to be a Python interface for FPS. We would probably have to implement our own. Boto has something really simple in there but I don't what it's worth.
- Amazon payments can only withdraw to US bank accounts
- Accepting international credit cards costs an extra 1% in fees.
- Transactions below $10 are even more expensive: start off from 5% (compared with 3%).
- Even bank account debits cost 2%. Once you have volume, most credit card merchant accounts would competitively charge less then than for credit cards! (I've seen 1.9% quoted)
Details, details
The above is the ghist of it. Obviously hundreds of pages of documentation contain much more detail. You can do more things with tokens than I mentioned. For example, you could reserve a payment for up to 7 days before actually settling it, you can cancel transactions, provide refunds, cancel tokens, etc.
Amazon Simple Payments
After about a couple of years I think it became clear to Amazon that FPS was way too difficult to implement for most potential users so they created a simpler version called Amazon Simple Payments.
It's based on FPS but has the back-end stuff hosted by Amazon. It doesn't support payment methods that woud need back-end calls such as prepaid or postpaid balance but the one-time and recurring payments are supported.
For some simple usage scenarios you wouldn't need any programming at all to integrate with it. Just create a of static payment button on Amazon's web site and put the HTML on your site.
For more complex usage scenarios (e.g., marketplace) where you want to have dynamic payment buttons you would just need to integrate the code that creates the HTML on your web site. The only slightly tricky part is the button signature that prevents users from changing the input variables (e.g., price) passed to Amazon for authorization.
The user provides authorization on Amazon's site, gets redirected back to your web site. No token. You just get the money deposited to your Amazon Payments account which you can then withdraw to your (US) bank account.
You can leave it at that if you don't care about security but then users can fake a payment/subscription by going through the pipeline and faking a redirect back to your web site after it was "completed". You could deliver the goods, but never get paid.
To prevent this sort of thing Amazon Simple Payments allows you to register an IPN (Instant Payments Notification) callback url which Amazon Payments will use to call up your web site once a payment is concluded.
The recommended best practice is to provide UI feedback based on the redirects but only update your database based on IPN.
Comments
Online payment options
I'll probably write this up in a separate blog post, but here's the gist of it.
If you have a US merchant account (e.g., Authorize.Net), you have quite a few options for outsourcing your billing infrastructure, and most of them seem to provide a much better user experience than Amazon FPS. In particular I've heard good things about BrainTree.
Unfortunately, if you don't have a US merchant account, most of these options aren't available to you.
You can also roll your own, but there are a lot of hidden gotchas and serious security liabilities so unless you have the scale and a good justification it probably isn't a good idea.
Horror stories aside, PayPal is the defactor standard in online transactions, especially on the low-end. PayPal would be one of the simplest options for a small company to implement. You don't even need a merchant account to start out, and once you get going you can go through the process of signing up for the Website Payments Pro account, which lets you process credit card payments on the back-end just like you would with a regular merchant account.
I understand PayPal is relatively expensive though (I.e., compared to a merchant accounts) but I think the main reason most people shy away from PayPal is they've made a terrible reputation for being capricious and arbitrary with regards to account freezes. If their automatic fraud detection algorithms look at you funny, you are in for a world of pain. OTOH, fraud is a big problem in this space and PayPal has a huge amount of volume. Even if 1 in 10,000 people have a bad experience and 1 in 100,000 blog about it that could be enough to make them look bad when you go a-Googling. People usually don't blog so much about good experiences as bad.
To be fair PayPal does seem to have improved on this front quite a bit in recent years. I've never had any problems with them myself, and I've read they provide a decent customer service experience now (e.g., a human being you can talk to), at least in some cases.
Finally, if you don't mind paying more, there are ecommerce engines such as FastSpring and Plimus which looked really attractive last time I looked at them. You get advanced billing options, the ability to run special promotions, bundle products (I.e., GoDaddy style), advanced revenue reports, etc.
I don't think so...
As you have 100 customers buying 100 products I don't see how you could do it any other way... It needs to be 100 different transactions!
You could double check on the AWS forums (they know much more about it than me) but I really don't think so...
Pages
Add new comment