PayPal is best-known as a provider of electronic payments for e-commerce Web sites. Lately, the company has been working on a developer platform and associated APIs that allow deep integration of sophisticated payment processing into applications as well.

Consumer-facing applications are a special target of this platform, especially after Apple announced that it would allow embedded payment integration into iPhone applications. PayPal unveiled its new developer platform at its Innovate 2009 Developer Conference.

Artima spoke earlier this year with Damon Hougland, PayPal’s senior director of the PayPal Platform, about the evolution of integrated electronic payments and PayPal's APIs:

We had a [developer] platform for many years, but it was primarily focused on merchant and consumer-type solutions. For example, a typical scenario is that a merchant wants to integrate [with] our platform to sell items in a shopping cart to consumers. We've been very successful in that area, and enabled that [use-case] in 190 countries, and in 9 different currencies. However, that today feels limiting in terms of what a developer can really do when it comes to payments...

While our current use-cases are very successful, they are also very defined at the same time. To mention another example, we have an Express Checkout API that's very successful: you can think of it as the Rolls-Royce of the checkout experience. But at the end of the day it's still just a checkout experience. And checkout isn't the only way developers might want to move money.

The PayPal X Platform's goal is to make it adaptable and configurable so that much more advanced payments can be made as well, and also to provide more capabilities in how developers can integrate with the platform. We don't believe that we have the knowledge or understanding to guess [all] the different use-cases developers might envision. Our biggest focus has been on listening, and calling on developers to find out what kind of things they would want to do with payments, and to open as many of our capabilities to developers as possible.

One example of a use-case supported by this platform is being able to split money in a payment, and to do disbursements when sending money. One customer using ActivePayments does some pretty unique disbursements over its network of 20,000 independent call-center agents. These agents need to get paid, but they are not typical employees. In this case, they can use our new adaptable API to send money and split it between an aggregator and an independent call center agent.

Regarding integration, we have seen all sorts of feedback on various integration methods. Our earliest integration method was using an HTML snippet that allowed developers to have an extremely easy experience. That makes sense for a lot of developers, because the last thing they want to spend time on is adding payments to their applications instead of adding unique capabilities.

At the other extreme, you might want to use something like SOAP, even though there's more overhead with a SOAP integration. In general, name/value pairs over HTTPs is a good middle-ground, and today the vast majority of our integration is done via that method: You get a lot more flexibility than what you'd get with HTML snippets, but it doesn't have the overhead and complexity of SOAP. We have a lot different SDKs as well, including Ruby and Java and .NET and other frameworks.

To what extent do you think integrating payments into end-user applications will affect developers?