Delayed chained payments vs. Authorize/Capture + Mass Pay - use case scenario

Question

My use case: buyer buys service from seller, our app facilitates and guaranties the transaction. It should work in the way that buyer sends the money to us, we check if buyer received the service, in that case we send the money to seller. Otherwise we refund the buyer. Important is to have 2 payments solutions for the buyer: paypal account and card payment without account. The whole use case is international. I'm testing this in sandbox environment.

Possible solutions:

1. Adaptive payments - Delayed chained payments: Works fine. Disadvantage is that the seller must grant us permission so that the refund works. The problem here is that the permission api is under maintenance, so i am waiting for all the changes https://developer.paypal.com/docs/classic/permissions-service/integration-guide/PermissionsWhatsNew/ . Is this big deal?

2. Express checkout Authorize/Capture + Mass Pay: Works OK. Advantage here is that in case of refund (void after authorize) we don't have to pay the fee. Disadvantage here is that I'm not sure if authorize holds the funds, so that even buyer without account paying with card cannot touch the money and I can capture them in 3 days. Another issue is that when I authorize 40$ from PayPal account with 30$ balance, I capture the whole 40$. How come?

I have no previous experience with PayPal I now the app should work on international scale. Please if you have any tips, articles or practical experience with this use case share it!

---

EDIT: Delayed Chained Payment is great. I solved the issue by making my application the secondary receiver and the seller primary one. Seller must grant a permision to my app in case of refunds, but there is no better way.

However, now the issue is that when buyer pays without account (Guest Payment - with card) all receivers must be Business or Premier account holders:

Each receiver of a guest payment must be a verified PayPal business or premier account holder.

Source: https://developer.paypal.com/docs/classic/api/adaptive-payments/Pay_API_Operation/

The issue is that in sanbox it works even if the primary receiver (seller) is NOT Business or Premiere account. What is wrong?

Answer 1

1) Do you have yourself set as the primary receiver? If so, I don't think you would need to have permissions granted unless you had already run ExecutePayment to push the money to the secondary receiver account. If you're refunding before that happens you shouldn't need permissions (though I haven't tested this specifically, so I could be wrong.)

2) Regarding the fee, if you refund a payment that went through Adaptive then PayPal would refund the fee back to you, so you're not really gaining anything here as far as that goes.

The authorizations can be tricky. I theory, the authorized funds should be guaranteed for 3 days, but you still capture within 30 days (or maybe 60) even though it may or may not have funds available at that point (it would simply succeed or fail).

You could run a Reauthorization after the first 3 days to get yourself an additional 3 days of guaranteed funds, but I don't think you can do that more than once.

Much of that depends on the card issuing banks, though. Even though PayPal's docs may specify certain things regarding how authorizations work, if the card issuing bank has different rules associated with their credit cards that could throw things off.

As for why a $40 auth would work when the PayPal balance is only $30, I think that may be because of secondary funding sources. If you have bank account and/or credit cards setup in the account, PayPal would assume it can pull from those sources when the time comes to capture if the PayPal funds alone don't cover it. Depending on your use-case this may or may not be ideal.

Answer 2

You are mixing multiple concepts with this question. There are different PayPal PAYMENT products (adaptive with chained payments vs express checkout) and then there is the question of authorizations vs immediate payments.

Agree with Andrew that fees in the refund case is not the right basis to choose a solution. Much more significant is what the sender & receivers will see in their accounts (payments to/from you, or from/to the other party?), simplicity/reliability of the overall system (can an error on your side cause failed or multiple payments?), liability, and even regulatory questions (e.g., are you acting as an escrow service?).

If PayPal gives you an auth from a PayPal buyer it means that PayPal guarantees (with certain very limited exceptions) that it will honor a capture of those funds within the specified time and amount limits (which can vary with the specific scenario). PayPal might make that guarantee based on the sender's balance, credit cards, bank accounts, or combination of factors. You as the recipient needn't care - that is between PayPal and the buyer. (And it's PayPal's limits/conditions which apply to that auth, NOT the conditions of the sender's underlying credit card/bank/etc; PayPal protects you from that complexity.)

In contrast if the auth is from a card network rather than a PayPal account (ie the user gives card info rather than using a PP account, whether or not PayPal is your payment processor), then that network specifies and controls the conditions of the auth.

PS: if you are waiting for Adaptive Payments changes, you may have a long wait. Release 89 was quite some time ago and PayPal's priorities are on the RESTful APIs, not Adaptive.