The headline might say Twitter, but for payments professionals the story here is all about Amazon Payments.

The original version of Twitpay (the one that went into beta in November 2008) was based on PayPal. Consumers funded their Twitpay account by making a PayPal payment to TwitPay. This approach had all sorts of problems, many of which the TwitPay team alluded to in their announcement. PayPal was an easy way to get the money into a TwitPay account, but left TwitPay responsible for, well, almost everything else.

The new approach splits the work load between Amazon and TwitPay – with Amazon, quite frankly, doing the heavy lifting and TwitPay handling the easy stuff. Amazon authenticates participants, manages the money, complies with state-by-state money movement regulations, provides PCI security compliance, handles business continuity, etc. All TwitPay had to do was build the application to map a P2P payment system (actually Amazon’s P2P payment system) to Twitter. Amazon FPS even provides the hooks so that Twitpay can draw its own transaction fees from Amazon as Amazon (not TwitPay) moves the actual money from twitter to twitter. So this approach makes all the sense in the world.

TwitPay is satisfying in another respect. When Amazon’s Flexible Payments Service (FPS) came out 18 months ago, I predicted that we would see lots of P2P payment system built on top of Amazon Payments. Why? Not only does Amazon provide the APIs that developers need for building new payment applications, more importantly, it provides the underlying regulatory compliance that has traditionally acted as a barrier to entry for so many companies.

I’m not saying there is a market for TwitPay, or for more P2P payments systems for that matter. But given the ease with which they can today be built, I wouldn’t be surprised to see more come to market. So what’s next… NokiaPay? WiiPay? TiVoPay? We’ll see.