I attended yesterday’s PayPal Platform Preview in San Jose and wanted to share some thoughts on the platform, Adaptive Payments, and the partner applications that were demonstrated.
First, a bit of context. PayPal has long offered a suite of callable APIs for payments acceptance. These APIs expose PayPal functionality to merchants that want to accept PayPal as a form of online payment — but they don’t really facilitate 3rd-party money movement. Yesterday’s announcement is that PayPal is opening up what is, in effect, a “Send Money” API that allows a third-party applications to move money from one account to another.
The public event was mostly an opportunity for PayPal partners to talk about and demonstrate how they are using (or plan to use) the new “Adaptive Payments” API (links to recorded video, etc are here). The event itself was pretty high-level. But the Adaptive Payments API was leaked to TechCrunch a couple of weeks ago, and has some of the details. Mashing up the leaked document with the announcement event, I think I have a pretty good idea of what PayPal is attempting to do with Adaptive Payments.
First, there is a lot going on here. But what’s most interesting to me is what some at PayPal call “split payments”. I’m not sure that term is formally used in the API document anywhere, but it was used at the event. It’s an important concept and well worth understanding.
The general idea is that a single payment from a sender can be split up and delivered to multiple receivers. The API documentation does a good job of explaining some of the use cases, and the demonstrations at yesterday’s event were chosen to reinforce this capability.
One form of split payments is called “parallel payments”. When used in this way, a single Adaptive Payments call results in a payment that is distributed in parallel to multiple recipients.
Twitpay was used at the event to to illustrate this use case. Twitpay, if you haven’t used it, allows people to make pledges to pay various parties by twitting a payment to other Twitpay users. Twitpay handles the user interface and PayPal is the underlying settlement engine.
Periodically, users go to Twitpay to settle all their pledges and this is where Adaptive Payments come in. You confirm which pledges you want to pay and and then authorize the payment with PayPal. Conceivably, this authorization step could be skipped if Twitpay made use of pre-authorized Adaptive Payments, but I’m pretty sure the demo showed a deliberate authorization step. The net result is that one Adaptive Payment call from Twitpay results in all of the pledges being settled simultaneously, in parallel, via PayPal.
Another form of split payments is called “chained payments”. When used in this way, a single Adaptive Payments call results in a series of payments that are linked together from one recipient on to the next. Think about today’s complex affiliate and syndication models. A payment to one recipient might be split up between multiple upstream content providers and service enablers. You pay me $20, for example, but my model only allows me to keep 15%, as I have to give 7% of it to my service provider and then split what’s left between three other content providers. Chained payments enables an application do all this through a single Adaptive Payment call.
At today’s event, LiveWorks nicely illustrated how such a model is being used by early adopters to outsource customer service to a team of third-party CSR reps. The CSR team leader receives the full payment, but has to share it with LiveWorks and the actual CSR reps.
Another model supported by Adaptive Payments is called “simple payments”. This aptly-named model is used when an application only needs to move money from one party to another anywhere in the world. Ironically, this seems so old fashioned.
What is fascinating about split payments is not the business models that are supported. Companies have been using these business models for years. But the capability was usually developed in-house (with a big time-to-market hit), awkward to manage (buyers had to pay intermediaries that had to manage the money, handle exceptions, pay the real recipients, etc), and almost always country specific (which limited online market uptake).
PayPal hopes to circumvent all of these problems through Adaptive Payments. Developers will have a simple set of callable APIs to move money, the money will be managed and moved by PayPal (not the developer!), and the funds will move smoothly across national borders on top of the PayPal network.
PayPal plans to formally launch the platform in November, and indicated there were more callable services to come. We’ll be sure to keep you posted. Glenbrook plans to follow Adaptive Payments closely so that we can help clients understand market opportunities, real world limitations, usage rules, etc.
It should be a lot of fun.
