I've created a crowd funding site, similar to KickStarter.
Everything is setup, the project finished and it requested the payments via pre-approved payments in PayPal.
There were 6 backers, when requesting the payment via a cron it failed on 4 of them but 2 of them were collected and work perfectly.
I had my own PayPal account as one of the backers, and mine was one that failed. Attached is grab of the pre-approved payment in my paypal account - this has since disappeared which I assume is because the date has passed. (EDIT: I can't attach an image).
It has;
Payment Method
Primary funding source - PayPal Account Balance
Backup funding source - Not specified
The thing that stands out is the backup funding, I had no funds in my account but it is linked to my bank/cards etc. It looks the the pre-approved payment was only going to use my PayPal balance which was zero.
I can only assume the other backers that failed were the same, and the ones that were succesful had a PayPal balance.
My question is, how do I specify, from the website point of viewer that all backers need a backup funding source. Surely Kickstarter doesn't have multiple failed payments.
Related
I'm currently trying my app to notify the buyer if he/she has no funds. But every time I use a paypal test account without funds, the payment still proceeds. What could be the cause of this error? I have negative testing on for my facilitator account.
If you have a credit card attached to the sandbox account it will use that as the funding source.
With negative testing, though, what you do is send a specific amount in the transaction request in order to get a specific error code back for testing.
See this documentation for more details.
I try to establish recurring payment from CiviCRM, using Website Payments Pro mode.
The positive testing works perfectly, I see the created payment profile, I get the IPN notifications, it's perfect.
I enabled negative testing at the profile, I tried two methods to trigger the negative case - when the initial payment fails:
PayPal recurring payments negative testing (https://developer.paypal.com/docs/classic/lifecycle/sb_error-conditions/ - with the amount of 106.10 $)
With IPN error code: https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNTesting/ - 31.22
In both cases, the payment completed successfully.
I contacted the paypal support and their best answer was this:
" You can test it with close expiry date. Usually when the expiry date almost come, PayPal will sent notification to the buyer to change credit card. But if the buyers just ignore the notification, it will lead to failed transaction. "
Even if it works, it's unacceptable, that I might have to wait 1 month to see the result. Paypal does not allow to set already expired card for the recurring payment profile.
Do you see an efficient way to test negative outcome? Maybe with IPN simulator? But how can I be sure that Send Paypal Recurring Payments commands with IPN Simulator contains the proper messages that PayPal uses today for my type of account?
Here is how to proceed: forget the sandbox, it is just not mature enough. Use the production/live paypal account, lower the recurring fee to 0.5$, launch the recurring payment from Civicrm, wait for the initial payment, you have the successful case, then ask your bank to set the POS limit to 0$, then the next recurring payment will fail. This is a totally robust way to test negative case. Do not forget to set your IPN first (https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNSetup/). Do you have any better method?
The following method works for recurring payments with Express Checkout, might as well work for Payments Pro:
Login to https://www.sandbox.paypal.com using your buyer's test PayPal account.
Replace the contents of the street address Line-1 of the buyer's test credit card, with CCREJECT-REFUSED.
Execute a typical Express Checkout payment flow against the Sandbox test environment using the same buyer account and with the same credit
card that you just modified.
This method is described on a page in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard' helpfully titled How To Recover from Funding Failure Error Code 10486 in Express Checkout
I've been working (or should I say struggling) with the PayPal SDK to get recurring billing running for my website. I managed to get it to work, however I do not see how to automatically "claim" the money?
Basically what happens is:
The profile is created, after 24 hours the payment is done and I see the following in my merchant sandbox account:
It seems I need to manually accept the payment for the amount to be added to my PayPal balance.
Is there a way of doing this automatically?
This is usually caused by an issue with the recipient's account. Most commonly, The recipient hasn’t confirmed the email address on their PayPal account. Once the email address is confirmed the amount would automatically post to the balance on future payments.
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.
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.