I'm working with the PayPal REST API for Payouts, and my problem is: I'm not able to find anything in the documentation if I want to reverse a payment when using Payouts.
I would also like to know if there is any way to avoid duplicate payments with this Payouts API.
You cannot reverse (really, refund) a payout. Only the recipient can reverse it, so you would need third party permissions to each recipient's account to act on their behalf, if you wanted to undo a payout you sent to them.
For avoiding duplicate payments, there is some general documentation on idempotency: https://developer.paypal.com/docs/api-basics/#api-idempotency
And for Payouts in particular, a unique sender_batch_id will not be processed more than once: https://developer.paypal.com/docs/api/payments.payouts-batch/v1/
Related
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.
Using the payouts API (in Ruby) I have some payouts that are error due to RISK_DECLINE:
name="RISK_DECLINE"
message="Transaction was declined"
information_link="https://developer.paypal.com/webapps/developer/docs/api/#RISK_DECLINE
What does RISK_DECLINE mean and what can be done to fix it?
Note: the information_link contains returned by the API doesn't contain any information.
This indicates that PayPal's risk/fraud engine has decided that PayPal should decline to process the payment.
It could be nearly anything, or some combination of things, that triggered the alarm. If most of your payouts are OK and only some are declined it is likely (primarily) issue(s) with the other parties' PayPal accounts, not your account.
You can contact PayPal to see if they can and are willing to give you any more specific reasons, but this isn't a technical problem and does not have a technical fix.
My application already receive payments using Stripe API. Once payment is received, I must pay affiliates related to the transaction. This could be 1 to many recipients.
I want to use PayPal, I want to wire an API into my application so that I may pay all pending payments by clicking a "release funds" button...clicking the release funds button would pay related recipients to their email address from a paypal account that I will keep flush with funds.
Which PayPal API will achieve this? (paying many recipients from one paypal account)
I've done a lot of research on this and alternatives. Before I spend valuable dev time on this, I need to know I'm heading down the right path so any advice would be most helpful.
thanks
The MassPay API will do it, but you'll need to get MassPay enabled on your PayPal account in order to use it. It's free, but it's just not enabled by default.
You could also look into Adaptive Payments, specifically the Pay API. In that case you would build a script that loops through all your recipients and sends payments one at a time.
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.
I developed a Web Application that accepts payments via the ExpressCheckout API, for users to become a members.
Everything works fine.
I now want to extend my Web Application Services and offer my users with the possibility to buy items which are sold by third parties (my members).
The principle I would like to implement is quite simple: for each order, let the user pay for the item they choose and then transfer a part of the amount I received to the item provider, and keep some money for me. I would like to automate this process so that once I received the payment notification, I compute the amount of money to transfer to the item provider who might or not have a Paypal account (in other words, this means that I could maybe need to transfer the money to a bank account, using the IBAN/SWIFT data) and then proceed with the money transfer.
I tried to find a solution reading your documentation and came across the "chained payment" but the latter does not seem to be used within the ExpressCheckout workflow.
Also, since my implementation of the ExpressCheckout flow works, I would not like to have to find a totally different solution but rather extend it... if possible.
Could you please tell me which is the best solution for me?
In advance, many thanks for your help.
You could do 1 of 2 things. You could use Express Checkout with parallel payments. This means you could split the transaction up between different accounts at the time of purchase. The other option would be to just receive all of the funds into your account, and then when you are wanting to send money to the other accounts you could either use the Adaptive Payments (Pay) API or the MassPayments API to send money to the other accounts. Keep in mind you would have to send it to their PayPal accounts, you would not be able to send it directly to a bank account with either one of these API's.
I had the same issue and I got an answer from PayPal that it is not allowed to use Express Checkout to transfer money to your PayPal account and - at a later point in time - transfer the amount minus your service fee (which stays on your PayPal account) via Adapative Payments API to the seller's PayPal account. PayPal suggested to use Chained Payments API instead. All works fine in the sandbox, but once you need a Live APP ID from PayPal they will review your business case and deny it. At least that what happened to me.
I know that is old question, but anyway, I tried to find solution and was enable to perform the simillar thing like described in question. So, then I asked paypal about this, and they gave me advice to use SellerDetailsType Fields that 's called PayPalAccountID, description for this field is Unique identifier for the merchant. For parallel payments, this field is required and must contain the Payer Id or the email address of the merchant. It wasn't clear for me to use this field for solving my problem. Here is link https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/SetExpressCheckout_API_Operation_SOAP/ I described field for soap request, for NVP it's called PAYMENTREQUEST_n_SELLERPAYPALACCOUNTID, but the idea is the same. I hope it will help someone.