PayPal AdaptivePayment : What happens if the secondary receiver's out of cash when processing a Refund API - paypal

When processing the Refund API to the payment made by AdaptivePayment Pay operation if the secondary receiver does not have enough money in their account
what happens to the API call? would it fail as whole or would the missing fees be draw out of primary receiver's account?

Testing this scenario with instant chained payment, and refund was cancelled. So obviously its all or none.

Related

Is it possible to create a market place style app with paypal?

I am working on a web application for a client and he wants the payflow to work sorta like this:
Seller makes an offer for an item
Customer purchases the item
The seller sees the item is paid for but won't get the payment
When the item has been marked shipped the payment minus app fee and paypal fees will be sent to seller
App Fee is deposited into the application's paypal account
I have implemented it using paypal's express payment api and do the payouts manually. But this has caused double paypal fee's which are incorrect. My client wants to use adaptive payments but that isn't going to work since they require the seller to be the primary receiver and the merchant service be the secondary but for out desired flow that won't work. What other option do I have?
From the description you provide, the best approach is to use Adaptive Payment Delayed Chained Payment. The buyer will make a payment for the item and the seller will directly receive the amount. You can specify the merchant services to be the secondary receiver but when using the Delayed Chained Payment, primary receiver (seller) will always get the payment first and using the Pay API, secondary receiver (merchant services) will get their portion. If you required the seller to be the last person to receive the money then they (seller) should be the secondary receiver.

Primary receiver refunds a chained payment from their PayPal account; what happens?

I'm developing a PayPal chained payment app where
Primary receiver = the service provider, gets 90% of payment
Secondary receiver = marketplace, gets 10% of payment
It's all working in the Sandbox environment, but there's a snag - when the primary receiver logs into their PayPal account, and manually refunds a payment they received, the secondary receiver doesn't appear to return their 10% automatically.
E.g.:
Primary receiver was paid $100, passed $10 automatically to
secondary receiver.
Primary receiver decides to refund using PayPal
account interface.
Refund for $100 issued; but secondary receiver
keeps their $10. Primary receiver now out of pocket by $10.
I would like it so that the secondary receiver automatically refunds their portion of a payment if the primary receiver issues a refund.
From reading the documentation from the Refund API (https://developer.paypal.com/docs/classic/api/adaptive-payments/Refund_API_Operation/), I thought this was the default behaviour, no matter if the refund was initiated through an API call or manually through the PayPal account interface.
Do I have this wrong, or is it just a bug with the Sandbox environment?
Would be useful to have this cleared up, as couldn't find any existing threads on the matter.
Update
PayPal Technical Support have told me the following:
Thank you for contacting Merchant Technical Services.
From my understanding you would like to have when a primary receiver perform a refund, the secondary receiver will automatically issued a refund.
If you would like all the receiver to refund the amount, you have to pass the paykey. May I know how the payment was made? If it is using Pay API operation, you have to use Refund API in order to refund the transaction. The refund can't be done by using PayPal account.
Use the payKey of the original transaction in the refund API, it will solve your problem.
And in case if you wish to partially refund the amount, specify the amount to be deducted from primary and secondary receivers in the "receiverList" field.
For more, refer: https://developer.paypal.com/docs/classic/api/adaptive-payments/Refund_API_Operation/#table-3-additional-fields-for-refunds-of-specific-amounts-to-specific-receivers

Incomplete Delayed Chained Payment Fees Payer

I'm setting up a delayed chained payment in PHP
I'm setting the feesPayer to SECONDARYONLY
$payRequest->feesPayer = 'SECONDARYONLY';
the transaction is made to the primary receiver
but the second leg of the chained payment (from primary to secondary receiver) is still pending.
then 90 days passed (payKey expired) and I did not complete the payment.
who pays the fees when the payKey expires?
Based on my messages with PayPal's support, I tell you that no one will pay the fees because the payment will be reverted back to the buyer !
So if you didn't complete the payment, it will go back and you will not be able to change the receivers during 90 days.

Refunds Using Paypal's Delayed Chained Payments

I am currently developing a web application which is a booking system for events.
Basically i want to use PayPal's Delayed Chained Payments system to do this:
BUYER makes a purchase through web app
ADMIN is the primary receiver of the funds
SELLER receives the funds 7 days after the event has occurred (less commission for ADMIN)
The reason i am leaving a 7 day period until the SELLER receives the funds is to allow for refunds and cancellations.
My question is:
Does the API allow me to interveen the delayed payment before the 7 days has elapsed, thus cancelling the payment to the SELLER and allow me to directly refund the BUYER the full amount. This is my ideal situation as it means their will not be the problem of the SELLERS account not having sufficient funds for the refund.
If anyone could help it would be great!
With Delayed Chained Payments you'll have the ability to cancel or execute the payment whenever you need to (within 90 days). So if the seller isn't able to supply the product to the buyer (or whatever reason) you can cancel the transaction.
Submitting a refund after a payment has been executed is a little tricky.
So to do a refund for a Chained Payment transaction you'll need to use the Permission Services API calls for the receivers to allow you to process refunds on their behalf. If they don't, you cannot refund the payment sent to another recipient.
After make delayed chained payment if you are not execute payment to secondary receiver then you can refund full amount of payment using refund api Call but you need to grand third party access .using grant api access

Chained payments and refunds

I have a question regarding chained payments and refunds. We are developing an application that sets up a chained payment, with ourselves as the primary receiver and the provider of the service as the secondary receiver. We provide a mechanism for the secondary receiver to refund the complete payment.
What we want to know is what happens when the secondary receiver has no funds in their paypal account? From testing this in the sandbox and from what we've read, it seems that the secondary receiver component of the refund becomes pending (we assume, as funds are pulled down from an associated bank account). Three things:
Has the primary receiver paid the refund in full and is now waiting to get the payment from the secondary receiver. Implying that, at this point in time, the primary receiver is out of pocket?
What happens if funds cannot be pulled down from the secondary receivers associated bank account?
What happens if we attempt a refund from an unverified user with no funds in their paypal account? Once again, does the primary receiver pay the refund in full and hope to collect the secondary receivers portion when they do have funds?
Extrapolating from the documentation:
The primary receiver does not initiate a refund until it receives the secondary receiver's refund.
If the funds cannot be pulled down from the secondary receiver's bank account (or the secondary user has no bank account linked) the refund request is cancelled.
The documentation is explicit in saying that it refunds the secondary to the primary before initiating a refund from the primary. Lack of documentation to the contrary suggests they handle the rest of the problems in this situation the same way they handle other refund problems.