Webreakstuff's blog on design, development and strategy. Click here to subscribe.

Amazon does it again: Flexible Payments Service

Fred Oliveira on August 3, 2007 Comments (7)

I still don’t know exactly what it is, but I’ve posted about it a couple of times. Amazon has an eye for building an underlying layer of services to empower the new web. From their storage service (S3), to the Elastic Computing Cloud (EC2) - both of which we use on Goplan, our project management solution -, to the Simple Queue Service (SQS) and now their Flexible Payment Service (FPS). No wonder I think these guys rock (and Amazon stock does seem to agree).

What is the Flexible Payment Service

FPS allows you to accept payments ranging from cents to thousands of dollars by leveraging their API. Amazon is pretty much making their payment system (used to charge for S3, EC2 and the other services) available to developers, for their own apps. Here’s the rundown in the words of Jeff Barr (via the Amazon WS blog):

We’ve taken all that we know about dealing with credit cards, bank accounts, fraud checking and customer service and wrapped it all up into one convenient package.

In much the same way that S3 and EC2 allow developers to forget about leasing space in data centers, buying servers and negotiating for bandwidth, FPS shields developers from many of the messy and complex issues which arise when dealing with money. Once again, we take care of the “muck” and developers get to focus on being innovative and creative.

Some example uses for FPS

If you think about it, it’s really easy to think of ways you can use FPS to build really cool services that would otherwise be hard to bill for. Here’s a few examples, off the top of my head:

  • Twitter could use FPS for a pay-per-use pricing model (hey, so they stop losing money every month). You would pay based on the messages you send. This is by no means my recommendation to twitter, but hey, it’s an idea.
  • We could start using FPS on Goplan to charge people flexibly by number of projects and users, instead of the fixed plans we have now. Should make it much more interesting for people who want to pay based on usage.
  • Online music stores could use FPS to help kids have music allowances that they could use to get new music whenever they wanted, easily.

There’s really a lot you can do with this kind of flexibility, and while I haven’t gone through the FPS documentation myself, if this is as flexible as S3 and EC2, I know this is a winner.

Concluding thoughts

Amazon kicks ass. This could be the only conclusion here, but I’ll continue by saying I’m both pretty excited about trying out FPS on our own services (and those we build for clients), as well as see what other people come up with.

Services like S3 have proven Amazon - despite being a retailer - is also the clear leader when it comes to infrastructure. These guys are helping other developers actually pave the way to new services, not just locking them in like others are. Very smart - definitely very Amazon. I love that company.

Other takes on this story by Robert, John Musser and Pete Cashmore.


Solving the social network problem

Fred Oliveira on August 2, 2007 Comments (15)

Lets get straight to the point: there’s a big problem with social networks - the fact that there’s a new one every day. Now this would be all fine if people didn’t care, but that brings me to the second problem: people do care, and generally love to be a part of these things. The social network for music (wait, two), the one for contacts, the one with photos, the one for 43 random things - the list goes on (heck, there’s Ning packing over 80.000 of these). Crazy. But within the chaos, something in common - you and your friends.

If you’re like me, you’re tired of having to add friends or accept friend requests in all of these networks. It makes sense to connect to people in these services (that’s how you get the value out of them), but it’s really tricky to control it. It’s a huge burden to manage all this network structure - this needs a fix.

A potential fix to the problem

I’ve been thinking about how OpenId and Microformats could play into this, and apparently, I’m not alone. We already have the identification through OpenID, there’s hCard+XFN that can provide the necessary bits of information about ourselves (and our friends) to the network, why not create a mechanism allowing networks to save us the trouble of adding friends, accepting requests and setting up preferences?

Process: I want networks to ask me, right off the bat when signing up, if I already have a profile that can be imported in (through hCard+XFN). I type in the URL for my OpenID and the network gets my information (gets OpenID page, downloads hCard formatted information, builds my user information based on that). Then it can grab my list of friends from XFN formatted data. With one textfield (the URL for either my OpenID or a profile on a different network), it would pre-populate both my information and the information for friends I want to add. Sweet.

A good start: A few social networks already have microformatted data on user profiles (Last.FM, Dopplr, Twitter and Cork’d), meaning any other network could easily consume this data when you sign-up, saving you a load of trouble - which is exactly what Dopplr (being smart as it is) does. Now if other networks would tag along, that would be superb.

Because, really, we do love participating in these sites, and we love having fancy profiles with all our friends on there, but actually going through the trouble of setting that up every single time is crazy. Social network developers, help us out here, we’re going bankrupt. Thoughts? Notes of frustration? Suggestions? Feel free to leave a comment on this story.

Update: Seems like Wired picked up on the need for open social networking platforms and published an article by Scott Gilbertson called “Slap in the Facebook”. Nothing you haven’t read in the blogosphere in the last couple of days, but still a good read. Go have a look if you will.