When I integrate PayPal with my sandbox test account, all transactions I create via the DoExpressCheckoutPayment API call, or PayPal's new /execute REST call are pending and I have to manually accept them, or I have to wait 3-5 days. Why?
This would occur for both live and test transactions and depends on several factors.
PayPal will set the transaction to a 'pending' state if:
The currency you are sending the transaction in is not a currently configured currency on your account
'Payment review' is enabled on your sandbox test account
PayPal deems the live transaction requires manual review by a PayPal analyst
The live or test transactions flags one of the Fraud Management Filters you have set up in your account, and the default action for the filter is set to 'Review'.
Your buyer uses a non-instant funding source
1:
This usually happens if you create a US PayPal test account, and send transactions in GBP or EUR (or any other non-USD currency).
By default US accounts are configured to accept USD and asks you - the merchant - if you want to accept transactions in any other currency. For non-US accounts, they are typically configured to accept payments in USD and the currency of the country you're registered in (i.e., USD and GBP for British accounts, USD and EUR for Irish accounts).
If you want to change this behaviour, log into your live or test account, go to the profile, 'Payment receiving preferences', and change from "Ask me" to "No, accept them and convert them to [your primary currency]."
Alternatively you can go to 'Currencies' and open a new currency balance within your account.
2:
In order to ease the testing of pending transactions, PayPal's developer site allows you to enable specific sandbox (seller) accounts for 'payment review'.
Payment review will mean that all transactions sent to that account will be held for manual review. When payment review is switched off, all transactions are released and are completed.
This is functionality intended to simulate the live behaviour as explained in point #3.
You can enable or disable payment review via https://developer.paypal.com > Applications > Sandbox accounts > Click the little arrow for the business account > Profile > Settings.
3:
For live transactions, PayPal may opt to hold transactions for manual review.
This is more of a policy question, so I won't delve too deeply into it, but essentially PayPal deems it more risky than other transactions, thus requiring manual review by a PayPal analyst.
Once this review is completed, the payment is either completed or denied.
It's good practice to integrate with PayPal Instant Payment Notification, so you are notified whenever an action occurs on this transaction.
4:
PayPal offers a product for PayPal Website Payments Pro accounts called 'Fraud Management Filters'.
This products lets you selectively apply filters to your Pro transactions (those initiated via the DoDirectPayment API call).
For example, you might want to automatically deny or review all transactions where the IP address is known to be risky.
If you have enabled this filter, and the transaction triggers this filters, the transaction may be set to pending until such time you take an action on the transaction (either rejecting or accepting it).
For more information about PayPal's fraud management filters, I highly suggest reading the Fraud Management Filters guide at our developer site.
5:
Your buyer might have used a non-instant funding source such as a bank transfer or eCheck.
This may take 3-5 business days to clear and for the transaction to be marked as 'completed'.
If you're integrated with PayPal IPN, you will receive IPN message at the time of the transaction having been completed.
Related
We operate an application that utilizes PayPal's Mass Payments API to handle bulk payments of our users' customers. We have a listener set up to handle the IPNs for these payments, and process the successes/failures accordingly.
Recently, we discovered that one of our major clients had mistakenly disabled IPNs from their PayPal account, causing a large number of Payments to not have their final status in our application. While the "Resend IPN" option was available, is there an API or anything we can call out to to check payment status for these without relying solely on IPNs?
You could try this , but you need sufficient access to that particular account which means the account holder have to grant you the permission to view the transaction.
I'm not a developer, but a project manager. So please excuse my lack of proper language.
We are trying to figure out how to handle subscription refunds and then limit account access on the site.
Here's a scenario. Member signs up for an annual subscription to gain certain capabilities in the account. 3 months into it member decides to cancel and requests a refund. Normally, if no refund is issued, subscription is good until the end of the billing period, at which point account is deactivated.
In our case, if a refund is issued, account should be deactivated immediately. Question: is it possible to set this up as part of PayPal Subscriptions? Some type of call from PayPal to our system that will trigger account deactivation.
Thank you.
We recommend using IPN (Instant Payment Notifications) to be asynchronously notified of any events, in this case of those related to existing subscription/recurring payments.
https://developer.paypal.com/webapps/developer/docs/classic/ipn/gs_IPN/
If you enable IPN notifications you will receive a POST of PayPal in the following events (among others):
When a recurring profile is cancelled.
When a refund has been made to a previous completed transaction.
This way, you can set up your IPN script to keep the subscription “open” in your side for the remainder of the month even if the profile has been cancelled, or to deactivate it if the last month has been refunded.
For more information about IPN variables:
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNandPDTVariables/
We're running a marketplace with merchants that sell services to customers. Payments go directly from the customer to the merchant, and our server facilitates this, through the Authorize & Capture mechanism in Paypal Express Checkout.
In checkout, when the customer's Paypal is authenticated an authorization is created, and at the end of the interaction with the merchant the payment is captured by our server on behalf of the merchant.
There is, however, a back door enabling the merchant to intervene directly on Paypal and to capture the funds in the pending authorization before the order is completely delivered. We'd like to prevent that, or at least insert a notice somewhere in the merchant's Paypal account not to capture the payment, and to instead let our server do that for them when the order is delivered. Any ideas?
Normally, you can't do that. But you can read IPN Paypal message to know if transaction are effectives. Take a look to Paypal IPN Guide, retrieve informations and compare to your informations database transaction to check if all is right.
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:
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?
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?
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.
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.
I am using PayPal PreApproved payments for my crowd funding website, where project backers are only charged if the project is successfully backed.
I am worried that high rate of payments will fail when the PayPal API tries to collect the funds when a project is successful:
a backer might not have any funds in their PayPal account
a backer might close their account once the project is successful (to intentionally stop payment)
a backer might remove/cancel their preapproved payment
etc...
There are a number of ways that the payment could fail which would mean that the project owner would not get their funds.
Can anyone suggest a way of tightening or securing payments. Please note, that PayPal will only allow you to use PreApproved payments for crowdfunding. Please also note that project owners need to be able to receive the funds from my site. Sometimes, these funds can be as small as $10 or up to $10,000 so we need to use PayPal to pay them as there is not other method of getting the funds to the project owner
I've implemented Paypal Adaptive payments and used them for payments at http://www.wethetrees.com and we had the exact problems you are describing. The capture rate is almost random, we were down to 35% with one campaign and had to manually send all backers invoices.
When capturing we had backers with closed/unauthorized accounts, insufficient funds, unavailable payment methods etc. We switched to just doing direct capture for a while, which is great since we get 100% of all pledges, but Paypal closed our account without notice when one of our campaigns mentioned the word "Cuba".
The solution in the end was to scrap Paypal so now we're using Wepay and Dwolla, and we're considering Bitpay (Bitcoin) as well. Seems to like Paypal wants to kill crowdfunding or doesn't understand it. Anything less than a 90% capture rate is totally unacceptable and will cause projects to fail.
Preapproval isn't the only thing they'll allow you to use. That's just one part of the Adaptive Payments API, but you could go with a delayed chained payment, too.
This way your account can be treated sort of like an Escrow. You can use the Pay API to create payments in the system that are split between receivers accordingly. Only the primary receiver would get paid at first, though, and then you can call ExecutePayment to submit the secondary payments from the primary account within 90 days.
This way the primary account holds all of the funds so they're available to pay out when the goal is reached. If the goal is not reached the payments could be refunded.