PayPal documentation ( REST, Classic : SOAP & NVP ) What to choose ?

Question

I need to develop a payment solution using PayPal APIs. Actually I started the documentation phase ( on http://developers.paypal.com )

I found the REST APIs understandable, I still don't have an idea how to implement them with SpringMVC so I'm just using cURL to test them. ( any help on this ? )

On the other hand, the Classic APIs are confusing. ( for example what can we do with the Adaptive Accounts and what's the difference between Express Checkout and Adaptive Payments, etc.. ).

Another thing, is that we need to choose between creating a hidden form ( html ) or using APIs. ( I need explanation )

The documentation is very long and I'm really confused, I don't know what to choose ( obviously the REST APIs are better for simple payments, but I really want to know more about the SOAP & NVP .. )

I'm novice, s can someone be a volunteer and help me on this ?

Thank you !

Answer 1

Having done the PayPal-integration-dance a couple of times (albeit a few years ago now) let me summarize my thoughts (and bear in mind, things may have changed slightly)

The reason for PayPal's profusion of APIs/integration methods is due to the vast array of places they want to be able to sting you for support payment from:

• If all you have is a blog, static-HTML-hosting, off-the-shelf eCommerce site or some other "primitive" web technology, submitting hidden HTML forms is pretty-much your only option. I suspect this is the original mechanism PayPal used, and while they have to keep supporting it forever, you wouldn't want to use this approach today from a modern web framework like SpringMVC.

• The NVP API is another longstanding integration scheme which was appropriate at a time when effectively stitching together parameters into a URL was all your clients could do. There's no great reason to use this API these days when the REST JSON API is available - most people find JSON much easier to read than URL-encoded parameters.

• Chronologically introduced next I suspect, the SOAP API reflects a time when XML was going to rule the world. In some (very strict and/or traditional) places, it still does. Again, these days, you probably wouldn't go down this path if you have a choice - usage with Java generally involves tight integration with a SOAP Framework like Apache CXF and mountains of machine-generated .java files.

• The REST API is the most modern and (IMHO) nicest to use from Java-land, and is the option I recommend. It's looks like it's what PayPal would prefer you to use too, so it's what I will spend the rest of this answer talking about.

As a Java developer, when you select the REST API you get a further choice of either using PayPal's SDK or rolling your own integration scheme. Consider using the SDK if:

• You can foresee your PayPal integration becoming very large and/or using advanced API features

• You don't have any other HTTP integration points and so don't already have infrastructure for calling HTTP methods from your code (e.g. Apache HttpClient or the RestTemplate functionality built into Spring 3 )

• You don't have (or don't want to have) a JSON parser available

As you've already been using the API via cURL and you understand the calls and their sequencing, you're probably undecided about this. If you're not under too much time pressure, I'd recommend going down the roll-your-own path using (and learning) Apache HttpClient together with a JSON library like Jackson - they are valuable tools in your arsenal and you'll almost certainly use them again in future integrations.

One other development tip, which applies to either REST API option - if you use a "stub server" such as this one to simulate PayPal's end of the connection, it'll log the details of every request it receives and respond appropriately. This can be a godsend for debugging exactly what is going out "over the wire" and/or testing things repeatedly.