PayPal Adaptive Payments

by Russ Jones on July 24, 2009

in P2P, PayPal, Russ Jones, Technology, TwitPay

Post image for PayPal Adaptive Payments

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.

11 Responses to “PayPal Adaptive Payments”

  1. Felix says:

    And as usual, the banks are completely transparent to their own customers, loosing all the way to intermediaries….keep moving slow old fellows, PayPal (almost) does not need you any more…

  2. anon says:

    twitpay is also using amazon payments

  3. I think the big story in all of this is the following: the major Card Brands such as Visa, MasterCard, American Express and Discover have done an exceptional job over the years building a global network of cardholders and accepting merchants to facilitate commerce. It’s now a global standard. They have built substantial barriers to entry for others (look at Revolution Money who has raised around a $100 million to try and penetrate the U.S. market).

    Collectively, the internet, globalization, social networks, and mobile phones have been shifting the payments landscape and reducing these barriers. It’s the wave that Paypal and other innovators have been riding and has turned what was a potential threat and minor scratch for the Card Brands into an open wound.

  4. Matt Sexstone says:

    Correction to the Twitpay link — should be

    Thanks for the preview Russ!

  5. Andrew says:

    The reason why split payments hasn’t been widely supported by the credit card industry is that it is fraught with risk.

    Let’s say I make a purchase at Russ’ computers and Russ in turn has components dropped shipped from 4 wholesalers to me. It sounds clever that one payment from me can be split to Russ and the 4 wholesalers but what happens when 1 of the wholesalers fails to deliver/perform? Arguably the computer is worthless to me without all of the components so my first reaction is to dispute or charge back the transaction. The safe bet, since Paypal sits in the middle of all disputes, is that Paypal won’t be the one to take the financial hit. It either means that buyers lose protection, or that sellers become responsible for the performance of everyone else in the payment chain.

  6. Gajendran says:

    The one that was demonstrated was Liveops ( and not liveworks. Thanks.

  7. So what do we think will happen for chargebacks that involve multiple recipients? Will they all lose money? Is it possible that paypal has an interface to say which part was broken and needs a refund for, or something like this?

    Either way for ad networks, downloadable products from multi-vendor stores, this is going to mean a lot of new business. Hopefully the price point for micro-points will be a small percentage and not a fixed amount (i.e. of 5 cents like Amazon FPS does) so that ad networks can run through this, paying out publishers instantaneously.

  8. Regarding chargebacks and risk when splitting payments, my strategy is this:

    – You can place a “hold” on money from the client for a period of time. The money isn’t drawn out of their account. Say this is tickets to a concert – you can withdraw the money from their account on the day of the concert, even if they “bought” the tickets 2 months in advance. This is similar to a hold that a hotel might place on your credit card for additional expenses after you leave.

    – At the time when the money is finally withdrawn (i.e. when the concert goes ahead), you then use adaptive payments to split the money appropriately, e.g. 10% to the ticketing agency and 90% to the production company.

    – If the event doesn’t go ahead, no money is withdrawn, the hold expires and everything’s back to normal.

    This strategy also happens to save a LOT of transaction fees and processing and reduces risk. It does however introduce one additional risk: that at the time you draw the money from the person’s paypal account they don’t have enough in there.

    That’s a separate issue though and unlikely (I hope) to bite people on the butt too much.

  9. FW says:

    So, any news on this new split payment functionality?

    • Russ Jones says:

      I anticipate the details will be discussed at the upcoming PayPal Developers Conference on November 3rd. 2009. Looks like there is a session on Adaptive Payments that promises the “full scoop” on its usage. I’ll be there for sure.

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics