Some thoughts about Amazon’s Flexible Payment System
UPDATE: Ran across the blog post announcing this bad boy. They say all the right things - except for the major issue of the UI pipeline - this service sounds incredibly compelling. I also found Don’s position on this on his SmugMug blog - my views seem pretty close to his, although he’s found a mysterious way to use FPS where the pipeline isn’t a show stopper for him, definitely curious to see how he uses it. Both posts are well worth checking out.
So I came back to find that, strangely, things continued to happen in my absence. I’m not sure why, but I need to look into it. One of these things that didn’t wait was that Amazon announced their newest service Flexible Payment System. I haven’t delved too deeply into it, but I read through their “Getting Started Guide” and feel like I’ve got the broad strokes of it.
As background, I’ve worked primarily with VeriSign’s PayflowPro product (which is now PayPal’s PayflowPro) and before that PayflowLink (and waaay before all that CyberCash). I’ve worked a little bit with PayPal’s own shopping cart system and a wee bit with Concord payments. So I’ve been around the block with payment systems, I’ve not built anything incredibly complex, but I’ve banged the tires on PayflowPro a fair bit, recurring charging and all.
I read through that guide with great interest and mild confusion. The interesting part is how good the documentation seemed and how powerful the api could prove to be. Everything seemed put together very thoughtfully and it looked like it put a lot of flexibility into the hands of the developer. Now, I have been pretty satisfied with PayflowPro - in fact, as far as API vendors go, I’ll go so far to say that I’ve been very happy with them. But the FPS seemed to be an evoluationary step beyond PFP.
It’s got a SOAP interface, which I could take or leave, but it also has a RESTish interface that appeals to me for the simplicity of it all. Sadly, in the docs they slight Perl (as usual) in favour of Java, PHP and the new golden child - Ruby. But, it doesn’t really matter, I don’t need an SDK to put together a query string.
One thing I love about it is the tokens and the ability to set callbacks for certain events or poll for specific events periodically. Payflow’s recurring events are kind of finicky to work with and this system seems to be a good improvement over it. The system supports the means for pre and post-pay micropayments, which could herald some new and interesting applications. It just seems like a payment system that was built with current and forward looking needs in mind - very smart. There are a bunch more features that I’d like to play with as well.
Here’s the problem. In order to use it at some point in the checkout process your client must leave your site and go for a few pages to an amazon co-branded UI pipeline page - they need to do this to login and authorize (more or less) the payment they are about to make to you. To me that makes this product compete not with Payflow Pro but with PayflowLink or PayPal’s shopping cart - easier to use but inherently less powerful systems. It’s a slap in the UI face for an application to send someone off to some random page to login (probably again, since they probably already logged in to your site) with an interface that looks nothing like yours and maybe just has your logo somewhere on the page.
The problem is this - Payflow Link or PayPal’s shopping cart are really easy to build. They target, rightly IMHO, a non-technical audience who wants to add e-commerce to their site. They make it really easy for anyone to use - in exchange you give up a fully integrated system that keeps the user in a single consistent user interface. FPS, on the other hand, requires a developer, it’s targeted at developers and a market that might otherwise use a product like Payflow Pro. Unfortunately, unlike Payflow Pro it doesn’t give you full control of the user experience, it gives you more than Link and Paypal’s shopping cart, but not full control and for me that’s a real problem.
The problem is two fold. The first and most obvious one is the UI consistency problem. Sending people to a completely different looking site in the middle of their e-commerce transaction is jarring and not professional seeming. The second problem is that, in my experience, putting more pages and things to fill out between someone deciding to buy and actually buying gives them more time to decide they don’t want it and bail from the transaction. That’s why amazon’s patented one-click, because that’s the shortest way to get someone from deciding to buy to buy. Using this forces an increase in steps that could have a problematic impact on the bottom line.
So there it is - I read it with rapt excitement for the power it seemed to promise. You know I love my boys in Seattle. But, this pipeline thing they make you do is kind of for the birds. I’m not sure what the solution ultimately is - they probably are leery of allowing 3rd parties access to someone’s amazon credentials, but I think ultimately that’s where the problem lies. For me and my clients, I don’t believe it’s a viable solution at this point.
August 9th, 2007 at 11:10 pm
I think in order to avoid the extra checkout steps of getting a single-use authorization (token) from the customer on every purchase through FPS, websites can probably have their “trusting” customers provide them with a multi-use token upto a particular limit and then use that to charge them for purchases. This way the redirect to Amazon UI (and the extra steps) shall not be required every time a returning customer makes a purchase.
I know this doesn’t work for new customers but atleast its an option for returning (and trusting) customers.
August 10th, 2007 at 10:10 am
Mavryk - thanks for stopping by. It’s true that there’s ways to mitigate this - it even shows the flexibility and power of the API that these are possible to do. But for me - it still isn’t a viable solution. I still lose control over first time (and thus my most delicate) users as well as a potentially offputting request to pre-authorize many purchases that they might never make. Sigh.