I am a bit confused about the REST and Classic API and which one serves my business case best. My requirement is to be able to send money to one or many customers by just using their email addresses. No need to receive Payments, just to send...Additionally i do not want approvals, i just want to send the payment and the payment to be executed, since i am performing a receiver email validation via the getVerifiedStatus call.
I know there is the Mass Payment option and the Adaptive Payments option however for consistency i need to use only one API. Which API covers my needs?
This isn't yet covered well by PayPal's new REST APIs. But the MassPay api (with # of payments = a set, or just 1) can definitely do what you want. Check PayPal's handling of exception cases that is built into the MassPay product to ensure it meets your requirements; if it does then this is a great answer. The adaptive payments pay() can also definitely work; to determine which works for you will require evaluating the underlying PayPal products moreso than the APIs. They do NOT work entirely the same way....
I would stick to classic API for now as it's much more mature than the REST API is. For your situation I'd go with Adaptive Payments, specifically the Pay API. Since you are the app owner and the payer, you can simply trigger payments however you want to anybody you need.
Related
This is my first time using the PayPal API so go easy on me.
The case I am trying to handle is as follows:
My customers can purchase software licenses that can either be one time payments, or yearly payments.
They can multiple products to the cart, and each product can have either one of the pricing plans mentioned above.
If I understand correctly, "payments" in the API handle one time transactions, and "billing plans" are used for recurring payments.
Is it possible to processes both in one call to the API? If not, is there a different way to achieve this?
Any suggestions would be greatly appreciated! TIA!
Not one API call, but you can do it in one checkout flow with multiple API calls.
For PayPal wallet payments (logging in to PayPal and paying) I would recommend using Express Checkout w/ Recurring Payments.
With that you would be using SetExpressCheckout, GetExpressCheckoutDetails, and then either DoExpressCheckoutPayment, CreateRecurringPaymentsProfile, or a combination of both of those depending on the products in the card and whether they need one-time payment or recurring.
The CRPP call will allow you to setup a recurring profile and include an "initial payment" which would be charged when the profile is created. This could be used as the one time payment if you want, and then you wouldn't need the DECP call.
Alternatively, you could use DECP to process the one time payment and then follow that up with CRPP to create the profile. There are advantages and disadvantages to the different methods depending on your business needs.
For setting up profiles with direct credit cards you'll need PayPal Payments Pro. In this case you would either use the same CRPP call mentioned above, but it would be used by itself and include the credit card details. Or, depending on the version of Pro they put you on, which depends on the version of PayPal account you have, you might end up using PayFlow instead.
If you're working with PHP this PayPal PHP SDK will make all of those API calls very quick and easy for you.
I know that's a pretty broad answer, but that's because it's a pretty broad question. :)
I am setting up a monthly automated backend process that will transfer money from a central account to thousands of PayPal accounts. The transactions will vary anywhere from $50 to $10,000. The key requirements here are:
Receiver must pay the fees
No user input required. By this, I mean this process should run without any kind of action on my end (I've noticed that some PayPal integrations require a redirect, approval on the sender side, etc.).
Here are the possible ways I see that you can send money using PayPal:
Mass Pay
Uses classic SOAP APIs. Sender must pay fee, so not an option
Payouts API
Uses new REST APIs. Sender must pay fee, so not an option
AdaptivePayments
Uses classic SOAP API. However, you can force the receiver to pay the fees.
Rest API Payments
See https://developer.paypal.com/docs/rest/api/payments/#payment
Uses REST API, which is good.
Can you force the receiver to pay the fee?
Can this be used without a web browser?
So, it seems like AdaptivePayments or REST API Payments are the only options that could work (there could be more, though). I'd obviously prefer to use the more modern REST API, especially for a new project, but if the functionality that I want to achieve is not possible, then I supposed I will have to use the classic Adaptive Payments option. Any insight would be greatly appreciated.
The only option that allows you to force the receiver to pay the fee is Adaptive Chained Payments, but that would not work for your situation. The type of payment you would be sending would be an Implicit Simple payment, which only allows the sender to pay the fee.
So, your best option would be to use the MassPay API, primarily because of the fee. For US payments, the fee is 2%, capped at $1 which is a significant saving over sending a regular payment at 2.9% + $0.30.
If the fee is that important, you could program it to reduce the amount you send by 2% or $1, whichever is higher.
It appears as though the newish payout (including batch) endpoints more or less match up with the older MassPay functionality. The fee structures seem to match up, with payouts having an advantage for transfers within the US. Even some of the events get logged as MassPay. It appears for all practical purposes that payouts is meant to replace MassPay.
What I haven't been able to find is a definitive statement from PayPal to that effect. I have looked for an announcement from when payouts was introduced, through technical and general support documentation, and generally in every place I could think of.
Obviously, the LACK of such a statement could say something all on its own. It just doesn't seem like it should be the case.
Has anyone seen an official statement that I can refer to? Or, if PayPal folks are listening, is such a statement possible?
Something along the lines of, "PayPal is encouraging developers to build new systems needing MassPay functionality using the Payout endpoints of the REST API"
Thanks!
The Payouts API is a brand new REST-based API that replaces Mass Payments classic APIs. Payouts has more features as compared to Mass Payments.
Businesses which need to send disbursements to up to 500 recipients in a single API call will use the Payouts API.
These new API’s close the product gap between PayPal Payouts capabilities, and our new crop of competitors. And crucially the new Payouts API’s solve numerous product problems inherent in the Mass Payments APIs
What does Payouts API have over Mass Payments API:
US and CA domestic pricing - $0.25 USD flat fee for US domestic payouts, and $0.32 CAD for CA domestic payouts
Send up to 500 payouts in a single API call
Duplicate checking – PayPal can check for duplicate payout requests
New Single payout capability – PayPal will return transaction status directly in the Payouts call response
-1:1 mapping of an entire batch’s requests – easily retrieve via API call the status of each request in a batch, when ever you want, how frequently you want
On-Demand Reporting – Allows you to easily query for payouts by time, status or recipient
What doesn’t Payouts have?
Payouts does not allow for manual file uploading.
https://developer.paypal.com/docs/integration/direct/payouts-overview/
They do the same thing; they even share a lot of internal PayPal code. The Payouts APIs essentially just more modern wrappers.
PayPal has yet to ever deprecate and replace APIs (which is a huge problem & source of confusion). So you are entirely welcome to use either set of APIs -- for now and, given the number of people already using the MassPay APIs, probably for a long, long time.
But yes, theoretically the Payouts APIs are the replacement for MassPay just as the other REST Payments APIs are the replacement for Express Checkout.
I'm using paypal to make my users able to payout their credits, which they can earn on my site. So i am actually buying my users efforts. As i have up to 200 payments per month, i would like to know, is there a possibility to send payments to my users via paypal api?
If yes, which methods should i use and what should i take care of? I possible i would also take a ready to go implementation in php.
I tried to check the documentation of the paypal api, but it was to complex, so i did not find any solution.
If you'll be submitting payments to 200+ people at the same time, the MassPay API would work nicely for you, but you'll need to call PayPal to request it and get it specifically approved on your account.
If the users will be doing this on their own, one at a time, then you'll want to look at the Pay API, which is part of the Adaptive Payments platform.
You can use my PHP class library for PayPal to make the API calls very quick and easy for you regardless of which method you end up using.
I'm trying to figure out whether it is possible to send money directly from any paypal account to any other via PayPal API.
I tried to find the answer in the API documents as hard as I could, but unfortunately haven't found it :-(
Two choices: Mass Pay and Adaptive Payments API.
Mass payments is the simplest of the two, and also the old, legacy one (note also it is limited to 250 payments at once).
https://www.x.com/developers/paypal/products/mass-pay
The Adaptive Payments API is the next-generation API, allowing for more complex scenarios and implementations.
https://www.x.com/developers/paypal/products/adaptive-payments
Hope this helps.