Overview
PayPal has a wide range of payment products and services. Over the years many of them have over-lapped, and it can be very confusing what you should be using and when.
I just wanted to offer this no-fluff review of what PayPal has to offer because I see so many developers frustrated and confused by everything they provide.
PayPal Standard
If you are creating basic PayPal buttons from within your PayPal account, this is PayPal Standard.
This can also be used in other ways, but the end result is simple HTML form that sets up a basic form POST to PayPal with standard variables included for payment details.
This is the easiest method of tying PayPal payments into a website or application.
Express Checkout
This is the API method of integration PayPal payments, where buyers would typically login to a PayPal account and submit a payment (although this is not required.)
This is available as a REST/JSON service, or also as NVP/SOAP.
PayPal is calling NVP/SOAP the Classic API, and they have notices in that documentation that it is deprecated. This is not entirely true.
They are indeed trying to get people into the REST services (or others that we'll review in later) but the Classic API is not going anywhere. If you prefer NVP/SOAP for any reason, or you already have things integrated that way, you don't have to worry about it going away any time soon.
I do recommend using the REST services if you can, and I especially recommend making sure you integrate the Smart Payment Buttons.
The Smart Payment Buttons make the experience much better for buyers, and it makes it more obvious that you do NOT have to have a PayPal account in order to pay with a credit card. It will still be PayPal branded checkout, though.
Website Payments Pro
Specifically, this is the DoDirectPayment API. This is the Classic API version of processing credit cards directly, much like you would with any other credit card processor account (ie. Stripe, Intuit, PayLeap, Group ISO, etc.)
With this you would simply add a credit card form directly to your checkout where the user would enter their details. You would send those details to PayPal's server for a success/fail result.
No PayPal Branding is displayed here. It's completely up to you to build your checkout system and process the data accordingly.
Payments Pro
This one, without the "Website" included in the name, is virtually the same thing as DoDirectPayment except that it uses the PayFlow Gateway instead.
PayPal acquired the PayFlow gateway from Verisign years ago. Unfortunately, the product name they used is very much like the DDP product, so it's often confused.
If you're ever working with a client or building your own integration for "PayPal Pro" you need to make sure you know exactly which version of it you're going to be working with: DoDirectPayment or PayFlow.
I've seen quite a few people find documentation for "Pro", integrate accordingly, and later find out they used the wrong one based on what the client actually had on their account. Watch out for this.
Braintree
This is another acquisition PayPal made a few years back. Braintree is essentially another standard credit card processor like Stripe or any other, but they offer a couple of different ways to integrate things.
Drop-In UI
For a simplified integration, you can use the Braintree Drop-In UI, which embeds a Braintree hosted payment system into your application using an iFrame.
This will include PayPal, direct credit cards, Apple Pay, and Google Pay all within a single integration. This is great, and it works wonderfully in most cases. If you find it too limiting, though, you can integrate Braintree Direct.
Direct
This is essentially the same thing as PayPal Pro (DoDirectPayment and PayFlow as discussed above.) This allows you to process cards directly without any iFrame or branding at all (other than what you add yourself).
Reference Transactions
This is when you use the data that PayPal stores on their server to process future payments for the same buyer. This allows you to setup things like "one-click payment" without the need to store sensitive credit card details in your own database.
You might see this called a number of different things: Reference Transactions, Token Payments, Vaulted Payments, Future Payments, etc. They all mean the same thing.
Classic API
With the Classic API, the terminology is "Reference Transaction". This can be used with Express Checkout and PayPal Pro.
However, if you are using this with Express Checkout, the seller PayPal account will need to have "Billing Agreements" enabled on their account. This is a very difficult thing to get approved, unfortunately.
No additional approval is required for Reference transactions with PayPal Pro
REST API
This functionality is referred to as a Vault in the REST APIs.
Adaptitve Payments
This is a platform PayPal launched in 2009 that was really pretty cool, but it didn't last, and it is now officially deprecated. If you're already approved for it you can continue using it, but they are not approving any new APP IDs for Adaptive Payments applications.
What it does is allows you to split payment sin real-time during checkout, adjust who pays fees, create accounts using APIs, and some other things I won't get into much here since it's no longer available.
Adaptive Payments is meant to be replaced by PayPal Marketplaces.
PayPal Marketplaces
This is what PayPal is launching for people to build online marketplaces like eBay, Amazon, or other similar sites where 3rd party vendors are posting their products for sale, and the site owner often wants to keep a commission.
This platform will allow you to do the same sort of split payments that Adaptive Payments did, and it will also allow you to tack on your own additional fee if you would like to (above and beyond PayPal's fee.)
TIP
As of this writing, the Marketplaces API is only available to select PayPal Partners. As such, there is a bit of a gap to fill since Adaptive Payments is already deprecated, but Marketplaces is not ready yet. Check this guide for work-arounds to this problem if you find yourself stuck in this gap.
Invoicing
PayPal provides a pretty robust invoicing system for free built right into the platform. Just go to www.paypal.com/invoice and you can play around with it if you didn't already know about it.
It allows you to create invoices which are sent to the buyer with a professional, branded design. It allows your buyer to pay with a PayPal account or by using a credit directly. You can send invoice reminders, cancel invoices, etc. all from within your PayPal invoice manager.
The Invoicing APIs simply allow you to do all of this over API calls.
Instant Payment Notification (IPN)
This is a notification system where PayPal will send a POST of data to a listener that you specify any time a transaction hits your PayPal account.
IPN is designed to work with:
- PayPal Standard
- Classic APIs
Webhooks
Webhooks are the same as IPN, but they are a bit more broad and flexible. Webhooks work with the REST APIs.
It's very important to make sure you're using IPN with Classic APIs, and Webhooks with REST APIs. If you trigger a payment with REST expecting to get an IPN you'll be sitting there confused when you don't get one.
Conclusion
This was my attempt at a short and sweet, no fluff post about PayPal's products and how to avoid confusion or issues integrating the various products into your applications. This could be a MUCH longer article, though, so if I have missed something you're curious about or I've confused you just let me know and I'll clarify.
Hope this is valuable for you in some way!
Top comments (2)
Thank you Drew! This is a lot of information (and a bit of confusion generated by PayPal)
Braintree seems very cool to have an overall integration supporting credit cards, apple pay, google pay, other payment systems and of course paypal.
This from Braintree demo page is neat:
In the context of adding PayPal support for dev.to's membership program - see this ticket - what would you suggest?
The membership draws recurring payments from the credit card / stripe account of a user (I think :D)
I've never used Stripe (PayPal is king here) nor I have looked at how dev.to binds to Stripe but your insight could be precious for whomever is going to take on that feature.
I'm ccing @ben and @jess also :-)
Looks like you guys are using Shopify for your store, and it does include Stripe for Credit Cards and PayPal as another option for payment. In my experience you would most likely save some money on fees if you went with PayPal Pro for the credit cards instead of Stripe. They both start at 2.9%, but with PayPal Pro you get a discount depending on your monthly volume.
For the memberships, the $1.00 and $10.00 items should be processed using a PayPal Micropayments account. This will save you money on the fees. A standard PayPal account is 2.9% + 30¢ where-as a MicroPayments account is 5% + 5¢.
For the $1.00 charge the regular fee would be 33¢ where-as the micropayments fee would be 10¢.
For the $10.00 charge the regular fee would be 59¢ where-as the micropayments fee would be 55¢.
At $12.00 the fee is the same for each (65¢) and above $12.00 you'll want to use the standard PayPal account.
I would recommend using the REST API for Express Checkout with Smart Payment Buttons enabled, and you can build logic around your API credentials so that it uses one PayPal account or another depending on the transaction amount so that you always get the best fee.
Let me know if you have any questions or concerns about that.
Side Note
If you're reading this and you're using WooCommerce, you might be interested in my PayPal for WooCommerce plugin. It makes setting all of this up very quick and easy, and it's completely free.