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.

Answer 2

The REST API is fairly new and not as feature laden as Classic. I still recommend Classic as there's nothing wrong or obsolete with it. PayPal wanted to run with the cool kids like Facebook and so they made an oauth API (I suspect it was easier for mobile but you can just as easily implement another API as well.).

Classic NVP (Name Value Pairs) is easy to understand and one of the best documented I've worked with. Your calls are all query strings you POST to the API endpoint.

METHOD=DoDirectPayment&AMT=1.00&EXPDATE=012015

I would not go the SOAP route unless you sleep under a blanket with WSDL printed on it. SOAP is just a pain to understand and work with.

Classic supports several calls REST still does not (MassPay, Buttons API, most Adaptive calls, etc). I expect PayPal will catch up eventually but, for now, Classic is the only option there for some features.

As to all the calls out there

• DoDirectPayment - Directly process a credit card. Requires a subscription to Payments Pro to use but is a full featured card processing system
• Express Checkout - Free to use. Allows you to accept PayPal accounts as a form of payment. Basically you call the API, get a token, redirect the user, they log in, PayPal redirects to you and then you use the token to get paid.
• Adaptive Payments - This is where you can do some interesting things to make creative payment systems. Say you have a third party you run cards for but you want a cut of their sales. Chained Payments do that.

The largest difference in the HTML Payments Standard solution and the API is that with the API you have to be PCI compliant. Mostly that means you don't log sensitive data (like CVV2), have security on your site and you have an SSL certificate but there could be other requirements placed on you down the road. The upside is you have complete control over the process. Payments Standard affords you no control but you have no PCI compliance either.

Answer 3

Well I have been reading most of the PayPal Classic APIs

In my humble undestanding : I can say that Express Checkout is a part of Adaptive Payments ( in Adaptive Payments, customers have the possibility to log in with PayPal and pay an item so they don't need to put their shipping address, credit card details, etc because they are already recorded on their PayPal account ) Actually, I have some notes to tell :

• Mass Payments allows you to send money to multiple accounts & Adaptive Payments does the same, so what is the difference between them ? ( the chained feature maybe ? )
• About the Invocing API : at what moment of the payment process customers can see it ? ( before payment confirmtion ? ), I still don't know its usefulness..

Finally, I have to tell you that my boss wants to develop a payment solution without the log in with PayPal feature ( in other words, he wants customers fill out directly their bank/credit cards details, we won't need shipping information since we are selling digitals goods ) so I think the best solution to choose will be the Adaptive Payments API ( We have to consider the fact that we are a non U.S developers )

What do you think ?

Answer 4

NVP & SOAP methods are now deprecated since January 2017. https://developer.paypal.com/docs/classic/express-checkout/