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.
Related
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/
I'm unable to find documentation by PayPal about how it handles webhooks for payouts. Are payouts treated the same as payments, so that a completed payout will initiate a payment completed webhook? In general, do payments and payouts translate to each other doing webhooks; or are there intricacies and gotchas someone from the paypal team could explain to me?
In a webhook perspective, the payouts transactions and sale transactions are not exactly the same thing. The payout event will be added into the webhooks supported event type list but not yet at this moment.
https://developer.paypal.com/webapps/developer/docs/integration/direct/rest-webhooks-overview/#event-type-support
So the classic IPN will still be your consideration of handling the "call-backs", for payouts and even other transaction types under RESTful API
Steps To work on payout:
go to paypal developers account and login using business account
Create new app and get client, secret etc
create some personal accounts.
Go to https://github.com/paypal/Payouts-PHP-SDK to get sample code. Update your credentials and it will work.
If you want a running code, go to https://www.voizacinc.com/ and submit inquiry. You will get working code.
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.
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.
NOTE: I've already looked at reasons for paypal 10544 Gateway Decline error. This is happening in production for us.
We use DoDirectPayment and DoReferenceTransaction with our customers to set up a regular payment transactions and when we get failures, the vast majority of them are for this error code. I've asked for details for specific transactions before and was instructed to get our client to contact PayPal directly for security reasons, which is understandable.
But I was wondering if there was something more to this particular error than the rather vague description implies. E.g. is there some setting in the account settings that causes it to occur more often than it needs to? Is it because we are a Canadian merchant accepting credit cards from other currencies?
We don't really like asking our customers to contact PayPal about this because it feels like we're passing the buck.
This is a catch-all for a variety of messages that unfortunately aren't spelled out in the Payflow Gateway Developers Guide but do appear here Classic API Error Codes with a vague explanation of:
The transaction was declined by PayPal. Contact PayPal for more information.
We recently switched to Paypal from Paymentech (but still using Payflow Gateway). About 15 of our customers with monthly service billings began getting declined. These were all customers whose credit cards were approved for years on Paymentech.
Paypal told us that (for security reasons) the customer had to call Paypal directly for more information. One of our customers did that and reported that Paypal couldn't tell them what was up so they lifted the "ban" on that card. Another customer reported that Paypal support couldn't understand that this was a problem with a Merchant account, not a Personal. Yet another left us for the competition.
In the end, I wrote code to trap for this error and print the following message on our commerce site and email notification:
Our payment processor, PayPal, was unable to process your credit card. Please try a different card, or contact PayPal Support at 888.221.1161 to determine why your credit card wasn't accepted.
Furthermore, I've ask that this be escalated within Paypal because this is bit of a hack.
There is not a lot more specific reason for this error, it is vague due to the number of reasons that can cause this. Usually this is due to an issue with the buyers account or card, in which case the buyer would need to contact PayPal to resolve the issue.