So you have a Web business. It used to be that customers would visit your site, buy something, and move on. But in a Web 2.0 world, merchants are looking for ways to find revenue and move money in ever more creative and flexible ways, and until recently, they were hitting a wall.
At the moment, Web business owners only have two choices for integrated merchant services: PayPal and Google. Both offer comprehensive solutions with some nifty perks, but both also take stiff cuts for processing your credit card transactions. Usually the fees work like this: a flat charge of twenty or thirty cents, plus a percentage charge. That may not sound like much, unless you want to sell your wares for, say, a dollar. Or, maybe you want buyers to be able to automate their orders, or require a minimum order. To date, those kinds of features are a huge programming headache. Enter Amazon’s Flexible Payment Service.
Amazon, apparently as determined to do everything as well as sell everything, has entered the merchant services fray with a a system meant primarily for software developers instead of business owners. Because it’s aiming for the affections of the technorati, Amazon has made its API (or Application Platform Interface) robust; as tech blogger Phil Burns explains, “[t]his isn’t a download and run project – FPS is much more complicated than that.”
While Amazon has long had a basic service called Amazon Payments, it was limited to company-approved sites (like those belonging to its network of retailers) and had simple, limited functionality. The new FPS, however, isn’t for the faint of heart. “It’s important to remember that FPS is for software developers to create flexible applications, not necessarily for merchants,” says Drew Herdnener of Amazon; “the keyword here is ‘flexible.’” While PayPal and Google gear their services toward the tech-savvy but somewhat limited business owner, Amazon has eschewed user-friendly features like cut-and-paste code, and is focused instead on enabling a legion of developers to learn the system and sell their services. The system, which debuted in closed Beta in August, has two salient benefits.
The first is a feature is micropayment functionality, which stands to revolutionize the way Web businesses can generate revenue. With micropayments, sellers can allow small payments from the same customer to accrete into batches before they’re processed, meaning that each small charge doesn’t get hit with the standard credit card processing fee. We’re talking about batches of payments that individually may not amount to more than loose change, but one need not look further than the boom in micro-finance to realize that small amounts are a big deal. The idea isn’t entirely new; Paypal has a “micropayment” rate for items under $12, but getting that rate requires an entirely separate merchant account, meaning if you accept small sums, you can’t simultaneously accept big ones.
The second (and flagship) feature of FPS enables developers to code complex “rules” which allow merchants and customers can set standing instructions for their interactions together. For example, a buyer can set a weekly spending limit, or a seller can require a minimum amount of orders per month from a given customer. FPS is also apt at taking automated payments from computer systems, so that even without human interaction, money can change hands according to pre-set conditions. This enables customers to refill orders automatically and sellers to process those orders without approving each one manually. These rules are what make micropayment a viable way of collecting revenue; they allow frequent, diminutive sums to be collected and processed automatically and cheaply.
Because Amazon allows FPS developers to conduct transactions on behalf of buyers and sellers (with the developers taking a cut of the transaction total, of course), coders well-versed in Amazon’s encyclopedic API will be able to commodify their knowledge in a new, entrepreneurial way. A marketplace application called iBaazar already purports to tutor developers on creating programs that enable them to conduct third-party payment processing, and several other services like Buxfer, FreshBooks, and JunglePayments are packaging FPS functionality in easy-to-use forms for accounting, money transfer and payments. If these early-adopters are any indication, Amazon FPS could become a widely-used platform, and spur a new economy of development in its wake.
Google and PayPal have developer software too, but as developer Nick Plante notes on his blog, “FPS is… a potential Google Checkout-killer,” and represents “everything that Paypal isn’t: well designed, API-centric, and built with developers in mind.” Most glaringly, neither PayPal’s nor Google’s API can easily accomodate micropayments; even attempting micropayment functionality produces “an unworkable solution,” according to Plante.
If it sounds like Google and PayPal have been caught with their pants down, then it’s worth noting that both services still have major advantages. Google’s is the cheapest service to use, and its biggest advantage is discounted integration with its AdWords service. PayPal’s edge is that it already has over 150 million users worldwide and has extensive telephone-based customer support. Amazon isn’t starting totally from scratch, though; it has almost 70 million customers who already have their payment information on file for retail purchases. But it’s not as cheap as Google, nor as user-friendly as PayPal, and isn’t operable for anyone but skilled developers. Amazon’s seller protection is also vaguely worded and offers less fraud reimbursement than its competitors. If Amazon FPS is to succeed, it will have to be so useful that small business owners will be willing to hire third-party developers to set it up for them. And to go though that trouble might only be worth it for the potential of micropayments. So will Amazon spark a micropayment revolution?
Programming hobbyists net-wide are buzzing with the potential of the system, many intent on stepping up to the challenge. If the API is democratized, it will cause a flourish of growth on the back of micropayment functionality, which stands to greatly benefit bloggers and small-scale Web gurus. Most blog readers, for example, aren’t willing to donate much to their favorite sites; one of the cruelties of the Web is that users expect everything for free. But imagine if a blog could accept a donation of, say, $.05 for a post well written (Amazon allows payments as small as $.01.) Then imagine that readers can automate their donations so that they send along a nickel every couple of weeks; now we’re talking about a reliable source of cash for a happy blogger. Okay, so he can’t quit his day job — but with the potential to monetize blogs, wares sites and small non-profits, the Net might yet have an untapped niche of profitability.
Of course, many small-time site administrators (like our for-instance blogger) might not have time or inclination to learn Amazon’s more complex system, and FPS could find itself at home exclusively on a smaller number of bigger sites. Both scenarios would mean success for Amazon, but acceptance among the small-time technorati would mean the potential for real game-changing ubiquity. Doubtless, PayPal and Google will wait in the wings, watching how the developers-first model fares before building out their APIs to make features like micropayment truly viable. Unfortunately, Google and Paypal didn’t respond to our questions regarding their plans on countering FPS, but with their respective successes in merchant services, there’s no doubt that a first-rate copy-cat effort, they could severely vitiate the widespread adoption of FPS. The real question is whether or not Amazon can bring its capital, innovation and brand currency together to rapidly conjure revenue where none has ever existed. If their Long Tail business model (which purports to sell “less of more”) is any predictor, Amazon FPS might gain ground quickly enough to proliferate – and completely change Web business as we know it.