I want to simulate bank refusal(PayPal sandbox account) when attached card does not have enough money in it.
PayPal account with 0 balance.
Card with balance of 300 money(PayPal have no idea it is so).
I make payment, exceed this amount, PayPal refuses payment after I click "Pay Now".
Currently if test card is attached to PayPal account, it does have unlimited funding.
Of course, one of options is to create/use LIVE account on LIVE environment with card that have almost no balance and buy product that exceeds balance, but I would not prefer that.
Any experiences/ideas?
Thank you.
Take a look at the PayPal documentation: Testing Error Conditions with Negative Testing
You basically enable the negative testing on your sandbox account, and then you can trigger specific error codes by sending the amount that matches the error code.
For example, to trigger error code 10755 you would use 107.55 for the amount in your payment request.
Related
When I using Sandbox mode it's work fine.
But when I switch to Live Mode error was happens.
{"response":{"name":"INSTRUMENT_DECLINED","details":[],"message":"The instrument presented was either declined by the processor or bank, or it can't be used for this payment.","information_link":"https://developer.paypal.com/docs/api/payments/#errors","debug_id":"51d8a0cb6f968","httpStatusCode":400},"httpStatusCode":400}
How can I solve this problem.
I use a Thailand Debit card to pay and have an enough money to pay.
Basically this means your credit card was declined. See here for more info.
I had the same problem, but in my case it was because I did a lot of tests of payments and reversals in the same paypal`s account, with the same product. I think Paypal "blocked" my account and it starts to deny all of my payments.
Try other account or card.
I am trying to test PayPal payments that are authorised at a later date, examples being Pay on Delivery or a Bank Transfer.
I have created a new sandbox account with no credit/debit cards and £0 in the PayPal balance but when I come to make a payment I have to add a card.
I have set up a bank account and agreed the mandate so I must have something set up wrong somewhere because these type of payments happen in LIVE and we have an issue with the IPN message that comes X number of days later once the payment has cleared so I am trying to reproduce this to investigate.
Have you tried using the IPN Tester? (here after you log into your Sandbox account) https://developer.paypal.com/developer/ipnSimulator/ .
All sorts of conditions that you can test your 'listener' process against there.
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.
We are running an e-commerce web site on Ruby on Rails and for the processing of Credit Cards we use the ActiveMerchant plugin to interface to our PayPal Website Payments Pro account using our API credentials.
As part of the checkout process we first call the authorize function on our gateway object and then, after some further checks, we perform the capture part.
We have lately been experiencing a bug where an amount gets reserved twice on a customer's account: one charge being only the authorization and the second being the final purchase. So to the client it looks like we are billing him twice (once for authorization, once for final purchase) while we are actually receiving the money only once and the "second charge" on his account is simply an authorization that we don't clear for some reason. (This seems to happen particularly when PayPal FMF rejects our transaction and we re-process.)
I am trying to troubleshoot this by creating PayPal Sandbox Accounts for Buyer and for Seller. I am running through the code line by line via Rails Console and simulating different conditions to try and replicate the error. However, my successful Credit Card transactions only appear in my "seller"/"merchant" account and not in the "buyer" account on the PayPal Sandbox so I cannot see what the effect of my code sequence is having on a customer's card. This post seems to indicate that that is just the way things are and that it is indeed not possible to test the effect on Buyer Credit Card side. This post suggests using PayPal Express Checkout but that is not what we need on our site as we're specifically looking at Credit Card transactions here that are integrated to our site.
How can I test the effect of my code on a client's Credit Card? Is there perhaps something I missed in PayPal or is there maybe some mode/log/monitor in ActiveMerchant that I can use to see this? I need to find the line of code that is causing us to authorize twice.
If the initial transaction is being rejected by FMF, and then you reattempt another transaction this would cause a second hold on the buyers card as this would be a completely different transaction attempt. The bank may have approved the first transaction, but then the FMF filters declined it based on your settings. As far as the bank is concerned, it is still a valid charge that was approved. So when you run your second attempt, this will cause a second hold on the card for the same amount but for a different transaction.
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.